From nobody Thu Feb 1 05:59:51 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2EF12EADA for ; Thu, 1 Feb 2018 05:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 jy4q22od2PQi for ; Thu, 1 Feb 2018 05:59:47 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C05D712EAC1 for ; Thu, 1 Feb 2018 05:59:47 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 77809B819EE; Thu, 1 Feb 2018 05:59:47 -0800 (PST) To: agl@google.com, wtc@google.com, nmav@redhat.com, joachim@secworks.se, simon@josefsson.org, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: xavier.bonnetain@inria.fr, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180201135947.77809B819EE@rfc-editor.org> Date: Thu, 1 Feb 2018 05:59:47 -0800 (PST) Archived-At: Subject: [TLS] [Technical Errata Reported] RFC7905 (5251) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 13:59:49 -0000 The following errata report has been submitted for RFC7905, "ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5251 -------------------------------------- Type: Technical Reported by: Xavier Bonnetain Section: 4. Security Original Text ------------- Poly1305 is designed to ensure that forged messages are rejected with a probability of 1-(n/2^107), where n is the maximum length of the input to Poly1305. In the case of (D)TLS, this means a maximum forgery probability of about 1 in 2^93. Corrected Text -------------- Poly1305 is designed to ensure that forged messages are rejected with a probability of 1-(n/2^106), where n is the maximum length of the input to Poly1305. In the case of (D)TLS, this means a maximum forgery probability of about 1 in 2^92. Notes ----- The security claimed on poly1305 is slightly beyond what was proven by the designer (see https://cr.yp.to/mac/poly1305-20050329.pdf), and the trivial forgery attempt with a message of length 1 succeeds with probability 2^{-106}. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7905 (draft-ietf-tls-chacha20-poly1305-04) -------------------------------------- Title : ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS) Publication Date : June 2016 Author(s) : A. Langley, W. Chang, N. Mavrogiannopoulos, J. Strombergson, S. Josefsson Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Thu Feb 1 07:38:47 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C8C13169C for ; Thu, 1 Feb 2018 07:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 Hn0Rhm_inbiu for ; Thu, 1 Feb 2018 07:38:42 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A516013173A for ; Thu, 1 Feb 2018 07:38:37 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id c2so26908663qtn.9 for ; Thu, 01 Feb 2018 07:38:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=POTV+sFq/Q4DsDd4nUXTvLCK2BGXImEiUBFK4JZuX9w=; b=DGgjn+GoYUcpeqdiN+mDnar4JOL6psGIzzWjVOcXNC0KY7jOuCgJZ1Q/mWsSqBCRD6 cyQZwWIjo9MI5mYFwe2Ng6kAb0r4hZD+kmolTvPPHywcZJS4trcn4+vj9dxVfwnfdzi5 BI5gWNxfwdtkBCRqoj/Nsv4mCJqUNpwHhfuFE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=POTV+sFq/Q4DsDd4nUXTvLCK2BGXImEiUBFK4JZuX9w=; b=Er098RJRrGVFnW63PUrN/vJ7W5s87BUOltRYF64twFrUnROyhpmpayPxfQwvPorlkd jTzuFbVRE1DmJjBuAsWcmu0JeiW3NODzPbvhOHTc2AqwSo5lizHA8WkDjzG4E87AT0gr E3NslP4eygDirIar5Qsp8uTn24Y3uVhQ3aRuMAH03HsHoLs+1kUrQhhoBSjsMjFMpNsA azE0fSjRZFrZI7Phi5FmeECd145Eh0WKCW7/9doQH4ovVQ+2DOGFB75rlyGXT4VN2bfc p86DUVBZ6lapneQWAosrRfj0VrGTXjh156h83iuUbtIQsAnoSVieE4UT1pfTZJa+vF2U mWNQ== X-Gm-Message-State: APf1xPCsWTH4VAvqQMVCOPJgaBIatGSeqjK9/dFYx6PXIcznQup+zQu8 x0K4uchSNnDmN27fxPbcyjoR6g== X-Google-Smtp-Source: AH8x225EWMqI96x1s4ojsP4dYbQ8oe9APtUbCdWzWy1VwiLyDvoqIWw8jdTagi9kodF4iQFhawVJVA== X-Received: by 10.237.60.197 with SMTP id e5mr2759398qtf.9.1517499516835; Thu, 01 Feb 2018 07:38:36 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id k20sm8427079qtj.72.2018.02.01.07.38.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Feb 2018 07:38:35 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: <9126f0e6-e135-5421-f9b9-1ff880fd19e8@akamai.com> Date: Thu, 1 Feb 2018 10:38:34 -0500 Cc: Victor Vasiliev , "tls@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <73EB10C4-14FA-47C2-B1AB-8E8610FAE4C9@sn3rd.com> References: <151696190108.24397.6150515497869897080@ietfa.amsl.com> <20180126102659.GA5204@pinky> <4ef441ff-6075-626e-b208-a0e5da3d18f0@akamai.com> <9126f0e6-e135-5421-f9b9-1ff880fd19e8@akamai.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 15:38:45 -0000 > On Jan 31, 2018, at 16:41, Benjamin Kaduk wrote: >=20 >> I also wondered whether there was any sense in reserving codepoint 0 = (of >> CertificateCompressionAlgorithm) for "uncompressed". I guess not, = since >> support for uncompressed certificates is implicit by means of not = using >> the extension. But sometimes keeping value 0 (basically) reserved is >> still useful. >>=20 >> I've considered that, but decided that this would just introduce two = ways to do >> the same thing (send certificate uncompressed), so I decided against = it. >=20 > Sure. I don't see a reason to add a code point for uncompressed, but = maybe there is an aesthetic argument for leaving 0 reserved entirely. = But I definitely do not insist on anything. We could just reserve it and not assign any meaning to it. spt= From nobody Fri Feb 2 06:25:20 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C9212D863 for ; Fri, 2 Feb 2018 06:25:19 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 H-K5cmDMmHP7 for ; Fri, 2 Feb 2018 06:25:17 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 584DA12AF6E for ; Fri, 2 Feb 2018 06:25:17 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id m11so3544295qtn.10 for ; Fri, 02 Feb 2018 06:25:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YRbbsIU5DTSvZefCmNYSXg2wKj9dvwPjP+BKNFwMhPE=; b=hbEoaU5yPFoKn1ap6o3/wm+DvO/MAgQFkzukYqyIBfhlE9i8CobSs4iSscaf5vuZFx Oy8OigaaQre9dG3zt6nriu3R6IwtyfjtFjJH98GUuWyRuXwzdofU88IWy8AQZQd0ERT/ eDb69KP5GDJzvuyDud64YzIy/SOAdg0ihc0ZM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YRbbsIU5DTSvZefCmNYSXg2wKj9dvwPjP+BKNFwMhPE=; b=uRJ3k93181RlZJYKsqaQleSDgvB/fAU2a63ezjAEzwWOyak5dqnf9EdSXan0DJs+Pt RgM3gjndxOCkQGMZkh5LYbJ/vlVlOilhBJU+28JFX5lm4uV0+BK4wrzhiCLgHQv9YKdp RoOdGnNA9XNEg4uDPtJbbYRxRA4kFaAqygqXXh1+0n1QEaANO0Ffnj34lPwVBaMoM9gP j+W+4A2FL2NiDwjssqsYVSlTwG8eXO0Ur9Cf7NMgLdldIzRIOu3wDSVOvMNl5MLxg9IZ sh32zHkLeHuIzaCOX336bhtoYP2p+MmRoEzDVdUJ3y0mNFAlGOoDtYFOszP9uTgMhdRf Vtpg== X-Gm-Message-State: APf1xPBHeW7eqaalwaGjbZU/ND25UaiBgLe2C5AUXEQJdCqRgbMj9HFx nkuW/DT3eev9sslOeYtRzR0Hxg== X-Google-Smtp-Source: AH8x226jGslLEL8+iOoKjVKeRL7CRR3gNeQxiKrh51wIIWYOfqLIXsjoj9u1nWVBoyYtyNS+uvmTSw== X-Received: by 10.200.57.3 with SMTP id s3mr4285544qtb.328.1517581516482; Fri, 02 Feb 2018 06:25:16 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id f2sm1438724qkb.19.2018.02.02.06.25.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Feb 2018 06:25:12 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: <20180126102659.GA5204@pinky> Date: Fri, 2 Feb 2018 09:25:11 -0500 Cc: tls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <151696190108.24397.6150515497869897080@ietfa.amsl.com> <20180126102659.GA5204@pinky> To: Alessandro Ghedini X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 14:25:19 -0000 > On Jan 26, 2018, at 05:26, Alessandro Ghedini = wrote: >=20 > Me and Victor would like to ask for early codepoints assignment again, = if you > think we are ready now. This now on the chair=E2=80=99s list of things to do. It=E2=80=99s been = a week and nobody has complained so I=E2=80=99m thinking the draft is on = the right track. Got one question before we start the RFC7120-dictated = early code point assignment dance: Q. What=E2=80=99s the plan for the dictionary? Is a field going to be = included later to indicate which one is in use, or is the dictionary = going to be linked to the extension number and a new one will be minted = when the dictionary is updated? I got some other minor nits (I=E2=80=99ll submit them in GH but thought = I=E2=80=99d include them here as well): 0) s4: includes the following: If the format of the Certificate message is altered using the server_certificate_type extension [RFC7250], the resulting altered message is compressed instead. Shouldn=E2=80=99t it also mention client_certificate_type? 1) Is it worth expanding a bit on the text quoted above to note that = it=E2=80=99s more than just altering the message it=E2=80=99s also about = changing how the authentication messages are computed? E.g., = CertificateVerify is now Transcript-Hash(Handshake Context, = CompressedCertificate). 2) Likewise, is it worth noting that in TLS 1.3 currently using = compression on CertificateType.RawPublicKey is not going yield much in = the way of compression? Is it worth saying that future values of = CertificateType should indicate whether compression is a good idea or = not? 3) s7.3: to match the table: OLD: The values in this registry shall be allocated under "IETF Review" policy for values strictly smaller than 64, and under "Specification Required" policy otherwise (see [RFC8126] for the definition of relevant policies). NEW: The values in this registry shall be allocated under "IETF Review" policy for values strictly smaller than 64, under "Specification Required" policy for values 64-223, and under =E2=80=9CPrivate Use=E2=80= =9D otherwise (see [RFC8126] for the definition of relevant policies). 4) s7.3: probably worth adding how to get one under the spec required: The procedures for requesting values in the Specification Required space are specified in [ID.tls-iana-registry-updates]. Our AD/IANA will ask later who is the expert (experts are implied as = part of Spec Required), so how about we use the existing expert pool. Note that the above 4 nits I don=E2=80=99t think really affect whether = the early code point assignment starts. spt From nobody Fri Feb 2 06:32:38 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B8C12AF6E; Fri, 2 Feb 2018 06:32:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: Kathleen.Moriarty.ietf@gmail.com, tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.71.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151758195630.31892.8861152486847376129.idtracker@ietfa.amsl.com> Date: Fri, 02 Feb 2018 06:32:36 -0800 Archived-At: Subject: [TLS] tls - New Meeting Session Request for IETF 101 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 14:32:36 -0000 A new meeting session request has just been submitted by Sean Turner, a Chair of the tls working group. --------------------------------------------------------- Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: Sean Turner Number of Sessions: 2 Length of Session(s): 2.5 Hours, 1 Hour Number of Attendees: 120 Conflicts to Avoid: First Priority: quic rtcweb stir curdle saag uta acme cfrg httpbis tokbind perc dispatch suit Second Priority: dprive ace Third Priority: tcpinc lamps People who must be present: Eric Rescorla Sean Turner Joseph A. Salowey Kathleen Moriarty Benjamin Kaduk Resources Requested: Special Requests: If sec-dispatch ends up being a thing please don't schedule us against that. Also please don't put us up against the TEEP. --------------------------------------------------------- From nobody Fri Feb 2 10:22:16 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064D812D9FE for ; Fri, 2 Feb 2018 10:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.12 X-Spam-Level: X-Spam-Status: No, score=-0.12 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nerd.ninja 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 N424qcbLcEYY for ; Fri, 2 Feb 2018 10:22:13 -0800 (PST) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 331DB12D80F for ; Fri, 2 Feb 2018 10:22:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1517595728; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; l=5774; bh=ITsOokUTXjyj+XFioHXMCxkSujIVVp1LyI+TZ4awjuI=; b=GqSBkkPdpwWXfQ2zZ62dJSc2RjDpC6ChTmFz0xMrsiLZINgDjMSV8pvGoH1OeDPj RuvbnHL1PC9fgUtZ3/ICYeaNHxVyVimkwYO9kX/e6tIcoMLyEJcjjjHB7R+SQcHTCvh gJj0NmJxd/hEGLKri4x/KLJt/VmYX81WxliLSbNw= Received: from [192.168.123.225] (dynamic-acs-24-112-242-116.zoominternet.net [24.112.242.116]) by mx.zohomail.com with SMTPS id 1517595728759290.3013338548386; Fri, 2 Feb 2018 10:22:08 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Fri, 02 Feb 2018 13:22:06 -0500 From: R du Toit To: "tls@ietf.org" Message-ID: <389CDA50-B152-473B-84BA-CCE226F1EF40@nerd.ninja> Thread-Topic: ClientHello record header version Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3600422528_1190211606" X-ZohoMailClient: External X-ZohoMail: Z_658201841 SPT_1 Z_47369130 SPT_1 SLF_D Archived-At: Subject: [TLS] ClientHello record header version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 18:22:15 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3600422528_1190211606 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable In the process of testing my TLS 1.3 draft-23 implementation against OpenSS= L (openssl.git:50ea9d2b3521467a11559be41dcf05ee05feabd6) I ran into an inter= operability issue: the retry ClientHello record header version is set at 0x0= 301, while the ServerHello (HRR) and fake CCS records arriving from the serv= er have record header version 0x0303.=C2=A0 I know this is according to the lett= er of the spec, specifically this sentence from Section 5.1: =20 In order to maximize backwards compatibility, records containing the Client= Hello MUST have version 0x0301 and records containing the ServerHello MUST h= ave version 0x0303, reflecting TLS 1.0 and TLS 1.2 respectively. =20 In diagram format: 0x0301:CH --> <-- 0x0303:SH(HRR) <-- 0x0303:CCS 0x0301:CH(retry) --> <-- 0x0303:SH etc =20 .. but I do think it will cause more issues down the line due to the record= header version toggling between 0x0301 and 0x0303.=C2=A0 At the point in the ha= ndshake where the retry ClientHello is sent the "compatibility mode" changes= have already served its purpose.=C2=A0 I believe some interop issues could be a= voided by sending the retry ClientHello with record header version 0x0303. =20 --Roelof =20 --B_3600422528_1190211606 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

In the process of testing my TLS 1.3 draft-23 implementation against Open= SSL (openssl.git:50ea9d2b3521467a11559be41dcf05ee05feabd6) I ran into an int= eroperability issue: the retry ClientHello record header version is set at 0= x0301, while the ServerHello (HRR) and fake CCS records arriving from the se= rver have record header version 0x0303.=C2=A0 I know this is according to the le= tter of the spec, specifically this sentence from Section 5.1:

 

In ord= er to maximize backwards compatibility, records containing the ClientHello M= UST have version 0x0301 and records containing the ServerHello MUST have ver= sion 0x0303, reflecting TLS 1.0 and TLS 1.2 respectively.<= /i>

 

In diagram format= :

0x0= 301:CH -->

<-- 0x0303:SH(HRR)

<-- 0x0303:CCS

0x0301:CH(retry) -->

<-- 0x0303:SH

etc

 

.. but I do think it will cause more= issues down the line due to the record header version toggling between 0x03= 01 and 0x0303.=C2=A0 At the point in the handshake where the retry ClientHello i= s sent the "compatibility mode" changes have already served its pu= rpose.=C2=A0 I believe some interop issues could be avoided by sending the retry= ClientHello with record header version 0x0303.

 

--Roelof

<= p class=3DMsoNormal> 
--B_3600422528_1190211606-- From nobody Fri Feb 2 10:49:03 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3DB612DB72 for ; Fri, 2 Feb 2018 10:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 YXPlsGoLGH8C for ; Fri, 2 Feb 2018 10:48:59 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 956351252BA for ; Fri, 2 Feb 2018 10:48:59 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id z12so25139840qkf.12 for ; Fri, 02 Feb 2018 10:48:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YG9P1TbqM5RwTgjO98xVq4GzuteSc/+B4+I0KVT2gQo=; b=Bw9hOx3Zv2NTCHeOBuqTmyzBkhPmdHdBCqOOXQxgvLo6YlF0jvGgJ7Fdi10LCqaj+h +Js39+CGm8kC5myFcyyqadmqRRBsg8YgWOmVmzr1+JVAiH1au8qAoKQPDA97ABJI4jtw HGgTQI1QLA0WMDucPT0sT5uMMS/OLIplQu1GM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YG9P1TbqM5RwTgjO98xVq4GzuteSc/+B4+I0KVT2gQo=; b=ds8v83WFYkfgWFj0vHTlnYnC/jxaP48Zr7wmpCadQ4EZJzxa+LiXB60kma9KF0HtDv CVMUdS1DpfZY9VndT/VPS27l/W7Wr9k5sz8a1CxcFoOvGUkHQGpPDEuHT39thNDK7E6N 4fxWSEtXNdaTbhi6k354pHz6ybQZzPp49+WFW7al7JkWL/fQ+bXMqs0oBEcvSs1jC6+0 J7IaAA9WHVO+lRRECq+bflwOdheVKqM0b1Mfxo45A7zexQAHXS82h8Qxn1fwxSnxSx1Q A5xQmLtO+B939kxIPyMkx+hDRB6+6NjRlB1jGd+nu/kg88h6FXqxVWZX29oDixv0gTV2 bMxg== X-Gm-Message-State: AKwxyteB4NS8h4PnJQvz6jGKQSqkUR+GWWR12JcIs3+lWy6kzZhcslRN Hps1Hq2FpebtFX66Az0kYqeqW5kC7TDT+gl8t6CMQ+0= X-Google-Smtp-Source: AH8x224gVrl4WZTI6FEnQnJ00517t0ZYVk4skAzeMzOxVvfXreoaTMxC6GlTVBvro8hiDgn636L/HFDzPfaBoHX4kNY= X-Received: by 10.55.16.196 with SMTP id 65mr63880835qkq.110.1517597338434; Fri, 02 Feb 2018 10:48:58 -0800 (PST) MIME-Version: 1.0 References: <389CDA50-B152-473B-84BA-CCE226F1EF40@nerd.ninja> In-Reply-To: <389CDA50-B152-473B-84BA-CCE226F1EF40@nerd.ninja> From: David Benjamin Date: Fri, 02 Feb 2018 18:48:46 +0000 Message-ID: To: R du Toit Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1146f31a457e3c05643f2a4b" Archived-At: Subject: Re: [TLS] ClientHello record header version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 18:49:02 -0000 --001a1146f31a457e3c05643f2a4b Content-Type: text/plain; charset="UTF-8" What implementation are you working on? Section 5.1 says that, in TLSPlaintext, the legacy_record_version "MUST be ignored for all purposes". And, of course, any pre-1.3 middleboxes which hit this case are non-compliant. That would imply they assume they can parse messages following a ClientHello they did not produce, which is invalid. I agree it would probably be prudent for the second ClientHello to say 0x0303, though. That's what our implementation does. We can fix the spec by replacing some "ClientHello"s with "first ClientHello"s. We did indeed come across a buggy non-compliant middlebox which paid attention to the record-layer version for messages after a ClientHello it did not produce. We didn't test subsequent client messages specifically, so it's possible they only care about the server ones. That one was actually a TLS-terminating middlebox, but their strategy for deciding when to terminate involves sniffing the server response. (This is, of course, non-compliant behavior. It is, again, invalid to assume that you can parse anything following a ClientHello you did not produce. This middlebox did not implement TLS 1.2 correctly.) David On Fri, Feb 2, 2018 at 1:22 PM R du Toit wrote: > In the process of testing my TLS 1.3 draft-23 implementation against > OpenSSL (openssl.git:50ea9d2b3521467a11559be41dcf05ee05feabd6) I ran into > an interoperability issue: the retry ClientHello record header version is > set at 0x0301, while the ServerHello (HRR) and fake CCS records arriving > from the server have record header version 0x0303. I know this is > according to the letter of the spec, specifically this sentence from > Section 5.1: > > > > *In order to maximize backwards compatibility, records containing the > ClientHello MUST have version 0x0301 and records containing the ServerHello > MUST have version 0x0303, reflecting TLS 1.0 and TLS 1.2 respectively.* > > > > In diagram format: > > 0x0301:CH --> > > <-- 0x0303:SH(HRR) > > <-- 0x0303:CCS > > *0x0301*:CH(retry) --> > > <-- 0x0303:SH > > etc > > > > .. but I do think it will cause more issues down the line due to the > record header version toggling between 0x0301 and 0x0303. At the point in > the handshake where the retry ClientHello is sent the "compatibility mode" > changes have already served its purpose. I believe some interop issues > could be avoided by sending the retry ClientHello with record header > version 0x0303. > > > > --Roelof > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1146f31a457e3c05643f2a4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What implementation are you working on? Section 5.1 s= ays that, in TLSPlaintext, the=C2=A0legacy_record_version "MUST be ign= ored for all purposes". And, of course, any pre-1.3 middleboxes which = hit this case are non-compliant. That would imply they assume they can pars= e messages following a ClientHello they did not produce, which is invalid.<= /div>

I agree it would probably be prudent for the second Cli= entHello to say 0x0303, though. That's what our implementation does. We= can fix the spec by replacing some "ClientHello"s with "fir= st ClientHello"s.

We did indeed come across a buggy= non-compliant middlebox which paid attention to the record-layer version f= or messages after a ClientHello it did not produce. We didn't test subs= equent client messages specifically, so it's possible they only care ab= out the server ones. That one was actually a TLS-terminating middlebox, but= their strategy for deciding when to terminate involves sniffing the server= response. (This is, of course, non-compliant behavior. It is, again, inval= id to assume that you can parse anything following a ClientHello you did no= t produce. This middlebox did not implement TLS 1.2 correctly.)

David

On Fri, Feb 2, 2018 at 1:22 PM R du Toit <r@nerd.ninja> wro= te:

In= the process of testing my TLS 1.3 draft-23 implementation against OpenSSL = (openssl.git:50ea9d2b3521467a11559be41dcf05ee05feabd6) I ran into an intero= perability issue: the retry ClientHello record header version is set at 0x0= 301, while the ServerHello (HRR) and fake CCS records arriving from the ser= ver have record header version 0x0303.=C2=A0 I know this is according to th= e letter of the spec, specifically this sentence from Section 5.1:

= =C2=A0

In order to maximize backwards compatibility, records co= ntaining the ClientHello MUST have version 0x0301 and records containing th= e ServerHello MUST have version 0x0303, reflecting TLS 1.0 and TLS 1.2 resp= ectively.

=C2=A0

In diagram format:

<= p class=3D"MsoNormal">0x0301:CH --><= /u>

<-- 0x0303:SH(HRR)

<-- 0x0303:CCS

0x0301:CH(retry) -->

<-- 0x0303:SH

= etc

=C2=A0

.. but I do think it will cause more issues down the = line due to the record header version toggling between 0x0301 and 0x0303.= =C2=A0 At the point in the handshake where the retry ClientHello is sent th= e "compatibility mode" changes have already served its purpose.= =C2=A0 I believe some interop issues could be avoided by sending the retry = ClientHello with record header version 0x0303.

=C2=A0

--Roelof=

=C2=A0

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a1146f31a457e3c05643f2a4b-- From nobody Fri Feb 2 13:01:29 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A6C129C6C for ; Fri, 2 Feb 2018 13:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nerd.ninja 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 4GsfyCyr5N8g for ; Fri, 2 Feb 2018 13:01:27 -0800 (PST) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 043C91243FE for ; Fri, 2 Feb 2018 13:01:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1517605284; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=Date:Subject:From:To:CC:Message-ID:References:In-Reply-To:Mime-version:Content-type; l=4134; bh=h0oiDkXIGKUSKsbs1s62L+JMf6hmOBxjTRsGLq8cFFg=; b=wWDAmtN8vqi3ecJviAiq6ntAfv+DUddZXXckQi951UQjgFQGlR4IeVdkjp+Qtu5B hPTMCtF0XV0E11i0SrptqAgnfPc46IHYT5FCUVqt+e5eHsfHIZcLIqEHeCkq/tM8d8T A9B9wTvn4Y0uwloqmsQpsJgFfbRUMIVfbEKzhaSk= Received: from [192.168.123.225] (dynamic-acs-24-112-242-116.zoominternet.net [24.112.242.116]) by mx.zohomail.com with SMTPS id 1517605284203829.5514056304032; Fri, 2 Feb 2018 13:01:24 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Fri, 02 Feb 2018 16:01:21 -0500 From: R du Toit To: David Benjamin CC: "tls@ietf.org" Message-ID: Thread-Topic: [TLS] ClientHello record header version References: <389CDA50-B152-473B-84BA-CCE226F1EF40@nerd.ninja> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3600432084_2060546240" X-ZohoMailClient: External X-ZohoMail: Z_658201841 SPT_1 Z_47369130 SPT_1 SLF_D Archived-At: Subject: Re: [TLS] ClientHello record header version X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 21:01:28 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3600432084_2060546240 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable > What implementation are you working on?=20 Proprietary, closed-source TLS stack. =20 >=C2=A0 Section 5.1 says that, in TLSPlaintext, the legacy_record_version "MUST= be ignored for all purposes".=20 Agree.=C2=A0 The interop issue was definitely on my side, and I was just using = it as background for my question. =20 Section 5.1 also says: "This value MUST be set to 0x0303 for all records ge= nerated by a TLS 1.3 implementation other than the ClientHello".=C2=A0 With my "= implementer's hat" on the word "MUST" implies that it must be enforced. =20 =20 > And, of course, any pre-1.3 middleboxes which hit this case are non-compl= iant. Indeed.=C2=A0 If BoringSSL already uses 0x0303 on the retry CH while OpenSSL us= es 0x0301 then some (non-compliant) thing-a-ma-jig-in-the-middle will cause = issues... and trigger the Universal Law of Users. =20 --B_3600432084_2060546240 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

> What implementation are you wor= king on?

Proprietary, closed-source TLS st= ack.

 

>=C2=A0 Section 5.1 says that, in TLSPlaintext, the legacy_record_vers= ion "MUST be ignored for all purposes".

Agree.=C2=A0 The interop issue was definitely on my side, and I was just= using it as background for my question.

 

Section 5.1 also says: "This valu= e MUST be set to 0x0303 for all records generated by a TLS 1.3 implementatio= n other than the ClientHello".=C2=A0 With my "implementer's hat" = on the word "MUST" implies that it must be enforced.

 

 

> And, of course, any pre-1.3 middleboxes which h= it this case are non-compliant.

Indeed.=C2=A0 I= f BoringSSL already uses 0x0303 on the retry CH while OpenSSL uses 0x0301 th= en some (non-compliant) thing-a-ma-jig-in-the-middle will cause issues... an= d trigger the Universal Law of Users.

=  

--B_3600432084_2060546240-- From nobody Mon Feb 5 06:19:34 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37E01201F8 for ; Mon, 5 Feb 2018 06:19:32 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 VOtRvW2aYvaD for ; Mon, 5 Feb 2018 06:19:31 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27C211242F7 for ; Mon, 5 Feb 2018 06:19:31 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id m11so12214113qtn.10 for ; Mon, 05 Feb 2018 06:19:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=7wtZAOpJA4xrCXBDW03M7KzPSi3lrGQodmIRwJZ3fKU=; b=S3XB8U3UyF1yVufSzZVMGz4rc/IDK1JJ21bQNdp6Qt3rP7H0eR+C76xuT4AOzvHRZa 6NxTZzylwUcFTqmV1SiTXDM+KJ/X0Y6p6/bpoS+dpzPXCA/YXfKk+eFYkTpx98pxaiTe 7TBT1QVlVPnr4TDPhsUGWkfmAIGt6XakAisyI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=7wtZAOpJA4xrCXBDW03M7KzPSi3lrGQodmIRwJZ3fKU=; b=cp/X7kE6xTLYMV2ueJyk/SULQv/fhPYUJPTKwWYyl02cSj0OB2jwhgEMAISWG2atzq g2fnpIkRvWC+GGSBRa1J9xw94gKMKkFwkSbFEz721fTqAshvX7inl922rAuOUsbnb9HK JVpkteQdyyo9iRB/8fEt1UGF/uqjkdvbZ+TnO/RoGag/8dVe2LahSKHEWQZImppJEA7Y Gs+wyDK5AMul3cdi8cVEjdMIvmwxJZJqng4mXbCKLXJESO0+iBMCLKRcqQ0VPai2ExvG MtQiHP82u+o82KySazV6Ha5omLkzrvktPzuEnC8GkwVWK41BN0nJFTnl57WjXxrPBFI3 zFBQ== X-Gm-Message-State: AKwxytclFUKrHxvuMvvgoIouFQHNeG2abEOApn3bQLeF1uOSImLMYLGO 1q1e0tXDLieAoj3fjfKy2NO7xBKQfkY= X-Google-Smtp-Source: AH8x227IxxGveTM5Uyh164rlm1QMaP91STG+7nZMwepdRKRVd3bSsNO9Fw0D7wiwfdbJTkRNZ+3uoQ== X-Received: by 10.200.40.165 with SMTP id i34mr76165601qti.176.1517840370052; Mon, 05 Feb 2018 06:19:30 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id x207sm5763921qka.91.2018.02.05.06.19.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Feb 2018 06:19:29 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 5 Feb 2018 09:19:28 -0500 References: <20180122164254.GA25745@LK-Perkele-VII> To: "" In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 14:19:33 -0000 Martin=E2=80=99s got an editor=E2=80=99s copy that incorporates all WGLC = to date. The WGLC for this draft ends tomorrow so if you have any more = comments please send them in by then. Note I=E2=80=99ve also uploaded the Shepherd=E2=80=99s write-up; I used = the abbreviated version. Cheers, spt > On Jan 22, 2018, at 18:41, Martin Thomson = wrote: >=20 > On Tue, Jan 23, 2018 at 3:42 AM, Ilari Liusvaara > wrote: >> Since the count includes the content type byte in TLS 1.3, the = maximum >> value for TLS 1.3 is 16385 bytes, not 2^14=3D16384. >=20 > Yes, the editor's copy says: >=20 > For TLS 1.2 and earlier, that limit is 2^14 octets. TLS 1.3 uses a > limit of 2^14+1 octets. From nobody Mon Feb 5 08:11:46 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A5C12D865 for ; Mon, 5 Feb 2018 08:11:45 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 zCrvrZYTBDTV for ; Mon, 5 Feb 2018 08:11:43 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE8D712D860 for ; Mon, 5 Feb 2018 08:11:42 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id r13so6788239qtm.8 for ; Mon, 05 Feb 2018 08:11:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=E+NqBwx7vMEl0mZ+LUwY8e6pYG0USfWuTTzA1O9ODiU=; b=P3L7WC9kcqaPTURgJIr8nV9NGl1DDTPAy7IA41PjzZ8Ad1YhRi5Z0ZI+Qw4xx4Y1An VaMPTRR2zI1GgbydFIhuMvUTP1Cp0hqMRvO8OFHg6MWg0Z4afZbJIOHzm0VNhFgrArL+ 7rXQnwN4V8wMS8WqEwpyNdD/stmr3w2v/ipNE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=E+NqBwx7vMEl0mZ+LUwY8e6pYG0USfWuTTzA1O9ODiU=; b=gVC34nQhu+T3KDRn6bOkbWUTz4E+VP8IkqEsEPFw7G88KJVruOiPe1TPwANVCEFLaJ 2Ap/k7drNrlEtcHG68/KzFqfC8SZ95BBeMOHRlpCOLyo29+WeySsQOqkBgy48YRhVBwW sGQpyDgpiHlPbIiLeJlkGFMJcagHsd6yOSV932zC6bPSmK/vBs6bwPIYDHgi9JREsBxO VK/HiUmu7cca3NmvTE5p9wmavtzwfkT3EedouNDhze/qaBGFD5fATP3oNKfd6fq6pb19 61pXAMSREmk87zdCJ4joDaCAy/OiKpm8d543+9BqOrDo/A87Lkg61bVOzrMWphWwZwEm o8uA== X-Gm-Message-State: APf1xPBtatOTk5PSWgVQnIguXSphHFXRkVzkDAmTCPnP/XPGAz12+ryd pxzorelWvigngBP+3XRA/qRUzlVfS+E= X-Google-Smtp-Source: AH8x224GsHZp9A1vvBsC6jLVFt1JxjCiFP6zPEbjrfT4HGciJRVlRa9FXfK70a3WHqEgG34dDRcdKQ== X-Received: by 10.200.63.50 with SMTP id c47mr12671179qtk.286.1517847101844; Mon, 05 Feb 2018 08:11:41 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id h195sm3749957qke.66.2018.02.05.08.11.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Feb 2018 08:11:41 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 5 Feb 2018 11:11:39 -0500 References: To: "" In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 16:11:45 -0000 Martin, This draft is probably going to arrive in the RFC Editor=E2=80=99s queue = weeks before draft-ietf-tls-iana-registry-updates. I=E2=80=99m thinking = that it would be okay to add the text that indicates this a "Yes" for = the newly minted Recommended column. Along the same lines, I guess the = question is should the value for max_fragment_length be =E2=80=9CNo" in = this draft as well (I=E2=80=99ve got it as =E2=80=9CYes=E2=80=9D right = now)? spt > On Jan 22, 2018, at 00:12, Sean Turner wrote: >=20 > All,=E2=80=99 >=20 > This is the working group last call for the "Record Size Limit = Extension for TLS" draft available at = http://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/. Please = review the document and send your comments to the list by 6 February = 2018. >=20 > Thanks your chairs: J&S From nobody Mon Feb 5 08:28:35 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B318F1271DF for ; Mon, 5 Feb 2018 08:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 IzRKGQNDZH0G for ; Mon, 5 Feb 2018 08:28:32 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E90B1270AE for ; Mon, 5 Feb 2018 08:28:32 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id 69so20129159qkz.2 for ; Mon, 05 Feb 2018 08:28:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=HwAdLo656e+vEn+C8OydrWY4rh5DcknH5CUJIY+s1fg=; b=ZAEUhd20VqGX4xVpqJj5bgSVOdcWpezdjDkxpVUcqnPlYfLoMJR2zfOu7SnQkJOLup QNyUWe1DEEtymZs3ljlwZVOWy6N84LQV6uYeGbmDAxjLODEnFSyaM1eMUMKWCxF+F/iE 6qIHyhop7cOvvn8Y4G7BeQ0DssThTBaahcfGs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=HwAdLo656e+vEn+C8OydrWY4rh5DcknH5CUJIY+s1fg=; b=cekX0cL6Yly6rMFGImN5ixZTP/EXGCa4Aml/8mMohB9cJzqh17cJYy0Tsqt24idrc8 bxCnz8lUZ206CKEsiSioJWJwJySSM4+zm1B++vDeWOqxXZyn8Y/LOJzUnbvNJ57shTfn dnfF9TqD9zOTJmZRFdVdwcu8HDKk47ytN5PdKHaUavjQ5u7R1vtC1FYHeKUvYEUa4TbD 5+y0R45C54IA6fQSDiJyaUrx0KBvQcIofu66iOKo6aQnZUTmrUab5hLpcqMrH5ph3Krs 27pfN23v20lqo8PyCgh9g3QHK5//hZwJUViXxRYmfa1FrK/lZqrJRemZjbo6z6gG4r9/ b6rA== X-Gm-Message-State: APf1xPBQavkYzmavkKP8Ouhg0EDfbMUJBamIMOMBGgfGfv+l/9EQsQ/s zb3VW+isFrdeP+81uTFpIJcS/7JNNgA= X-Google-Smtp-Source: AH8x224fhxSbxMZPGFbuN+bYOTIJUb6d4jMRhQsTYihU/yh/tMKsx+6GY7Y1ZCPpkITPVVdkcdLvmA== X-Received: by 10.55.64.75 with SMTP id n72mr2076567qka.354.1517848110988; Mon, 05 Feb 2018 08:28:30 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id i41sm6203803qkh.27.2018.02.05.08.28.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Feb 2018 08:28:29 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Mon, 5 Feb 2018 11:28:28 -0500 References: To: "" In-Reply-To: Message-Id: <4811531E-7162-47BD-AF85-B3D0DE165AB7@sn3rd.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 16:28:34 -0000 never mind. this is address in the IANA section: "it is recommended and marked as "Encrypted" in TLS 1.3." > On Feb 5, 2018, at 11:11, Sean Turner wrote: >=20 > Martin, >=20 > This draft is probably going to arrive in the RFC Editor=E2=80=99s = queue weeks before draft-ietf-tls-iana-registry-updates. I=E2=80=99m = thinking that it would be okay to add the text that indicates this a = "Yes" for the newly minted Recommended column. Along the same lines, I = guess the question is should the value for max_fragment_length be =E2=80=9C= No" in this draft as well (I=E2=80=99ve got it as =E2=80=9CYes=E2=80=9D = right now)? >=20 > spt >=20 >> On Jan 22, 2018, at 00:12, Sean Turner wrote: >>=20 >> All,=E2=80=99 >>=20 >> This is the working group last call for the "Record Size Limit = Extension for TLS" draft available at = http://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/. Please = review the document and send your comments to the list by 6 February = 2018. >>=20 >> Thanks your chairs: J&S >=20 From nobody Mon Feb 5 09:14:10 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FAA12D863; Mon, 5 Feb 2018 09:14:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: Kathleen.Moriarty.ietf@gmail.com, tls-chairs@ietf.org, smccammon@amsl.com, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.71.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151785084808.5807.1739151430358833439.idtracker@ietfa.amsl.com> Date: Mon, 05 Feb 2018 09:14:08 -0800 Archived-At: Subject: [TLS] tls - Update to a Meeting Session Request for IETF 101 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 17:14:08 -0000 An update to a meeting session request has just been submitted by Stephanie McCammon, on behalf of the tls working group. --------------------------------------------------------- Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: Stephanie McCammon Number of Sessions: 2 Length of Session(s): 2.5 Hours, 1 Hour Number of Attendees: 120 Conflicts to Avoid: First Priority: quic rtcweb stir curdle saag uta acme cfrg httpbis tokbind perc dispatch suit Second Priority: dprive ace Third Priority: tcpinc lamps People who must be present: Eric Rescorla Sean Turner Joseph A. Salowey Kathleen Moriarty Benjamin Kaduk Resources Requested: Special Requests: 1 hour slot pre-plenary If sec-dispatch ends up being a thing please don't schedule us against that. Also please don't put us up against the TEEP. --------------------------------------------------------- From nobody Mon Feb 5 10:33:02 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8018A127369 for ; Mon, 5 Feb 2018 10:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 GZFTLYqLq2PD for ; Mon, 5 Feb 2018 10:32:59 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B4E5124B17 for ; Mon, 5 Feb 2018 10:32:59 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id x27so40811769qtm.12 for ; Mon, 05 Feb 2018 10:32:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1DcRVcMPTKaqmbUXm8NJOAwIt5Tb6Kv1FGmOlk0GY6g=; b=psVlGC41Pc69Eu0h/RGqmqKlu4Hqd6h+db8qNh98kYg89msgHXHEmd1D1EzjlwQkDx z1bRN+Z4x7HxBO5r0sEsu+EH4MWkJEk8o7AYjKei4rbHtjbUOR3Bl1mgcAh6CCr/rIkE 3coTgmkUElOKTkJmWi+DaCBypOTZYzYR4utIlIFZjGfnZCk52OQ5LpsqMJABFML/OCe8 A7vYkkw+S1+WQiMzcU3tt/HHzoT800GjrVuVKDaPBEuzfP7HhNEI9tG8QdvuwdnCqJ6I LGkqBu2v0myADjspa78RmNkk0pOHKP6ChJmlR+MLJSBquu+viDSlLhrr4MOwqSxsz0r5 9BuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1DcRVcMPTKaqmbUXm8NJOAwIt5Tb6Kv1FGmOlk0GY6g=; b=D7yPIHpcDqRyoqxegA7Rt65RsI3mbQYlJBs+H39wXytFxkaPkEpEqUOVSyxuQ9QC1N K+o6ZONDgBd0YYe1WEGSMMNO6oxVMnWPjn9eo+5znG1XTBNdPioiAQ/0j98UKamGBW2O 8GFFuW2HSTEo7U+OrkXKoDmDBbe+s17+rQkXYDT6Q1vqTD1FnJTThSWQ+maEcA3JcdCA PP4L8S/WO/NGljqUI5f9M9yI0+6BFfoi4cOtgBQchab6PK+BJVydF7O+1PkJDjLirqGs 9VyoIRXcAaM7Xh0SACeD619jHJ4r6WQclvtxTy+Ry1y7697pgLbYWkmqPkVIegxn9nWb Lo0w== X-Gm-Message-State: AKwxyteJpqtBIAxc6nUDNSqI8ys80Q1c7yj8qWpnSjLfPOb9qj2x/lqb H24PIRQ/KL/bY+722DMu2uQ+jCO6Gj1mAtwjuYAE2NkP X-Google-Smtp-Source: AH8x225/qPCkMscgYavfEGDCRd1LgynSItUZC/W+nZF2YDsWDxkxsoU0ihcTyBJlxcrIByhYby7oGodICX5W0ouoht4= X-Received: by 10.237.56.9 with SMTP id j9mr40753961qte.32.1517855578264; Mon, 05 Feb 2018 10:32:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.34.132 with HTTP; Mon, 5 Feb 2018 10:32:57 -0800 (PST) In-Reply-To: References: <151696190108.24397.6150515497869897080@ietfa.amsl.com> <20180126102659.GA5204@pinky> From: Victor Vasiliev Date: Mon, 5 Feb 2018 13:32:57 -0500 Message-ID: To: Sean Turner Cc: Alessandro Ghedini , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1149e47290e72a05647b4a66" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 18:33:01 -0000 --001a1149e47290e72a05647b4a66 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 2, 2018 at 9:25 AM, Sean Turner wrote: > > > > On Jan 26, 2018, at 05:26, Alessandro Ghedini > wrote: > > > > Me and Victor would like to ask for early codepoints assignment again, > if you > > think we are ready now. > > This now on the chair=E2=80=99s list of things to do. It=E2=80=99s been = a week and nobody > has complained so I=E2=80=99m thinking the draft is on the right track. = Got one > question before we start the RFC7120-dictated early code point assignment > dance: > > Q. What=E2=80=99s the plan for the dictionary? Is a field going to be in= cluded > later to indicate which one is in use, or is the dictionary going to be > linked to the extension number and a new one will be minted when the > dictionary is updated? > The plan is to allocate a new algorithm codepoint for each (compression method, dictionary) tuple. I don't want to decouple them, because it turns out that for different algorithms the dictionary can be supplied in different ways, and thus the actual content for the dictionary may vary. (I'll address the nits a little bit later) --001a1149e47290e72a05647b4a66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 2, 2018 at 9:25 AM, Sean Turner <sean@sn3rd.com> wrote:=


> On Jan 26, 2018, at 05:26, Alessandro Ghedini <alessandro@ghedini.me> wrote:
>
> Me and Victor would like to ask for early codepoints assignment again,= if you
> think we are ready now.

This now on the chair=E2=80=99s list of things to do.=C2=A0 It=E2=80= =99s been a week and nobody has complained so I=E2=80=99m thinking the draf= t is on the right track.=C2=A0 =C2=A0Got one question before we start the R= FC7120-dictated early code point assignment dance:

Q. What=E2=80=99s the plan for the dictionary?=C2=A0 Is a field going to be= included later to indicate which one is in use, or is the dictionary going= to be linked to the extension number and a new one will be minted when the= dictionary is updated?

The plan is to = allocate a new algorithm codepoint for each (compression method, dictionary= ) tuple.=C2=A0 I don't want to decouple them, because it turns out that= for different algorithms the dictionary can be supplied in different ways,= and thus the actual content for the dictionary may vary.

(I'll address the nits a little bit later)
--001a1149e47290e72a05647b4a66-- From nobody Tue Feb 6 07:19:47 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0AD21243FE for ; Tue, 6 Feb 2018 07:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 NyVxJCxP1dtQ for ; Tue, 6 Feb 2018 07:19:42 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D9861201F8 for ; Tue, 6 Feb 2018 07:19:42 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id d72so2693810qkc.6 for ; Tue, 06 Feb 2018 07:19:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EDS9wZvawqR4XyUHcDpaCQQKMY1yeVF+SjOCpAPK5SM=; b=P158/9UnxoN3uoUbLMd9zBujIgDIdfVU5CnerGuvAAo7q3OD2yuhByb2a41j9tva+c b32uNqraij6JfY9XP2kX+W8QnjJ1TOf5JAuO3Rno8UdD4Z0fgI2s+WuzsR+eEh/9OVHa oKlLOqkTRfnCXrjKzmWkQfAG4UHRyZMaWz39w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EDS9wZvawqR4XyUHcDpaCQQKMY1yeVF+SjOCpAPK5SM=; b=jPngxgvQO9Zr8UVA/wVRD1xIff9m/EMxpT2aEq/3cbyIWy0T8IHUrHk2tphBa7UB7j 2QoqejfWBdWPUpT2ZS/zY015UBhATQkmtYg7ZG0a3nVUUCsFbvTAHyG6Vs39hKExBlcc ilyRRd+qgbmEpMVx88q9Wys1m9vT7rLW8kbcMPFQ1nhte2IIqmS0VAQkO+0lalHkgScp HtIq7wSrz7V5Zh6fscRM2ycibOFGgclZc8do5/EzqAAyfZfLjk6XaB99INRl56WIiYl8 6yd9lJ7ZNJf5K2feKdovZ1N7QwP4d/IZWnCZS9WTh5uVBYthIs7Iv8PfdT90i4xgNtBW Vu9g== X-Gm-Message-State: APf1xPAbN1guRBuJmY/fVQxb/ivVZ/vN9z0YCmkRkwnBdKuElMgXQ89/ A89ev9Xxo1kIeH6GuFbF/1dMn9xQJMw= X-Google-Smtp-Source: AH8x226NrkqKprDx1Jm7x2xoAxlBO51+onqbW6Xr2dwPwA30vI/xEVswwi/ZCLQYtfoF8VqkHrDTFA== X-Received: by 10.55.106.193 with SMTP id f184mr3881102qkc.211.1517930381208; Tue, 06 Feb 2018 07:19:41 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id n189sm1413879qkc.0.2018.02.06.07.19.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Feb 2018 07:19:40 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: Date: Tue, 6 Feb 2018 10:19:38 -0500 Cc: Alessandro Ghedini , "tls@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <406F63A7-4869-4FD3-BFFC-68258443A63B@sn3rd.com> References: <151696190108.24397.6150515497869897080@ietfa.amsl.com> <20180126102659.GA5204@pinky> To: Victor Vasiliev X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 15:19:45 -0000 > On Feb 5, 2018, at 13:32, Victor Vasiliev wrote: >=20 > On Fri, Feb 2, 2018 at 9:25 AM, Sean Turner wrote: >=20 >=20 > > On Jan 26, 2018, at 05:26, Alessandro Ghedini = wrote: > > > > Me and Victor would like to ask for early codepoints assignment = again, if you > > think we are ready now. >=20 > This now on the chair=E2=80=99s list of things to do. It=E2=80=99s = been a week and nobody has complained so I=E2=80=99m thinking the draft = is on the right track. Got one question before we start the = RFC7120-dictated early code point assignment dance: >=20 > Q. What=E2=80=99s the plan for the dictionary? Is a field going to be = included later to indicate which one is in use, or is the dictionary = going to be linked to the extension number and a new one will be minted = when the dictionary is updated? >=20 > The plan is to allocate a new algorithm codepoint for each = (compression method, dictionary) tuple. I don't want to decouple them, = because it turns out that for different algorithms the dictionary can be = supplied in different ways, and thus the actual content for the = dictionary may vary. >=20 > (I'll address the nits a little bit later) I can live with this approach because it=E2=80=99s better than minting a = new extension every time. But just for the record then the code points = we=E2=80=99re looking to assign now are =E2=80=9Cno dictionary=E2=80=9D. spt= From nobody Tue Feb 6 17:26:12 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE05912DA22; Tue, 6 Feb 2018 17:25:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Matthew Miller To: Cc: ietf@ietf.org, draft-ietf-tls-dnssec-chain-extension.all@ietf.org, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151796675979.25928.2038193051971303546@ietfa.amsl.com> Date: Tue, 06 Feb 2018 17:25:59 -0800 Archived-At: Subject: [TLS] Genart telechat review of draft-ietf-tls-dnssec-chain-extension-06 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 01:26:00 -0000 Reviewer: Matthew Miller Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-tls-dnssec-chain-extension-06 Reviewer: Matthew A. Miller Review Date: 2018-02-06 IETF LC End Date: 2018-02-07 IESG Telechat date: 2018-02-08 Summary: This document is ready, with one issue that I think could benefit from some clarification. Major issues: NONE Minor issue: This is more a question, that might warrant some clarification: In 7. Verification, the last paragraph discusses client-side caching of the RRsets. If a client has cached the full RRset chain from TLSA to root RRSIG (and that cache is still viable), is the client still expected to specify the "dnssec_chain" extension? In my reading, that does not seem necessary, and I think it might be worth noting if that is true. Nits/editorial comments: NONE From nobody Tue Feb 6 19:19:41 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CFA120725; Tue, 6 Feb 2018 19:19:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-tls-dnssec-chain-extension@ietf.org, Joseph Salowey , shuque@gmail.com, tls-chairs@ietf.org, joe@salowey.net, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151797357502.25862.16667889525841537162.idtracker@ietfa.amsl.com> Date: Tue, 06 Feb 2018 19:19:35 -0800 Archived-At: Subject: [TLS] Adam Roach's Yes on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 03:19:35 -0000 Adam Roach has entered the following ballot position for draft-ietf-tls-dnssec-chain-extension-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I like this mechanism and look forward to its deployment. I have one point of clarification and a small handful of editorial comments. First, the point of clarification: §4: > if the server does not recognize the > provided name and wishes to proceed with the handshake rather than to > abort the connection, the server uses the domain name associated with > the server IP address to which the connection has been established. Unless I missed something important, this scenario doesn't seem to make much sense: if the client provides name A and the server replies with name B, the client either (1) isn't performing server name validation (in which case it is nonsense for the client to ask for a dnssec_chain), or (2) is going to error out the connection. Do I have that right? If there's some situation in which the server acting as described above provides some benefit, I would love to see it described in here. If it's just a matter of having completely described behavior for corner cases, it may be worthwhile indicating that the client will reject the connection if the server decides to complete the handshake like this. --------------------------------------------------------------------------- > Intended status: Standards Track R. Barnes > Expires: July 27, 2018 Mozilla s/Mozilla/Cisco/ --------------------------------------------------------------------------- §1: > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. This document has significant usage of these terms in lowercase. Please consider using the boilerplate from RFC 8174 instead. --------------------------------------------------------------------------- §3.3: > the case in DANE in which a client either ignores the name in > certificate (as specified in [RFC7671] or there is no attestation of Nit: "...in the certificate..." Nit: Add closing paren after [RFC7671] --------------------------------------------------------------------------- §4: > specific processing needed for aliases and wildcards. If DNS > responses messages contain any domain names utilizing name Nit: "response" From nobody Tue Feb 6 19:28:45 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33463127599; Tue, 6 Feb 2018 19:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 HwXLWubfZQ6S; Tue, 6 Feb 2018 19:28:36 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 227FB124D37; Tue, 6 Feb 2018 19:28:36 -0800 (PST) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 20FC57A3309; Wed, 7 Feb 2018 03:28:35 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: <151797357502.25862.16667889525841537162.idtracker@ietfa.amsl.com> Date: Tue, 6 Feb 2018 22:28:33 -0500 Cc: The IESG , tls@ietf.org, draft-ietf-tls-dnssec-chain-extension@ietf.org, tls-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <23185062-60CA-4BA6-BAA5-5DDD6279558B@dukhovni.org> References: <151797357502.25862.16667889525841537162.idtracker@ietfa.amsl.com> To: Adam Roach X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Adam Roach's Yes on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 03:28:38 -0000 > On Feb 6, 2018, at 10:19 PM, Adam Roach wrote: >=20 > Unless I missed something important, this scenario doesn't seem to = make much > sense: if the client provides name A and the server replies with name = B, the > client either (1) isn't performing server name validation (in which = case it is > nonsense for the client to ask for a dnssec_chain), or (2) is going to = error > out the connection. Do I have that right? If there's some situation in = which > the server acting as described above provides some benefit, I would = love to > see it described in here. If it's just a matter of having completely = described > behavior for corner cases, it may be worthwhile indicating that the = client > will reject the connection if the server decides to complete the = handshake > like this. DANE clients sometimes accept more than one name for the server. This = happens when the server name is obtained indirectly from MX OR SRV records, or = as the result of (DNSSEC-validated) CNAME expansion. So in principle, more than one name might be acceptable to the client. = In practice however, I don't yet see a mechanism where a client that can't = do DNSSEC validation on its own would be in a position to do this. So the server may indeed be able to validate a certificate for some name that the client did not expect, and it would then be up to some external mechanism (prompt the user?) to accept that name or not. It is not entirely unreasonable to allow the client that freedom, but it would likely not be a mainstream mode of operation. Perhaps I am not thinking creatively enough about other ways for the = client to be configured security to accept one of many names for the server, = and to "guess" the wrong one. --=20 Viktor. From nobody Tue Feb 6 19:40:14 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7C21241F3; Tue, 6 Feb 2018 19:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=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 iIgcz9H7zPVF; Tue, 6 Feb 2018 19:40:05 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47FD7120227; Tue, 6 Feb 2018 19:40:05 -0800 (PST) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w173e0Sm054652 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 6 Feb 2018 21:40:00 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Viktor Dukhovni Cc: tls-chairs@ietf.org, draft-ietf-tls-dnssec-chain-extension@ietf.org, The IESG , tls@ietf.org References: <151797357502.25862.16667889525841537162.idtracker@ietfa.amsl.com> <23185062-60CA-4BA6-BAA5-5DDD6279558B@dukhovni.org> From: Adam Roach Message-ID: Date: Tue, 6 Feb 2018 21:39:55 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <23185062-60CA-4BA6-BAA5-5DDD6279558B@dukhovni.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [TLS] Adam Roach's Yes on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 03:40:07 -0000 On 2/6/18 9:28 PM, Viktor Dukhovni wrote: > >> On Feb 6, 2018, at 10:19 PM, Adam Roach wrote: >> >> Unless I missed something important, this scenario doesn't seem to make much >> sense: if the client provides name A and the server replies with name B, the >> client either (1) isn't performing server name validation (in which case it is >> nonsense for the client to ask for a dnssec_chain), or (2) is going to error >> out the connection. Do I have that right? If there's some situation in which >> the server acting as described above provides some benefit, I would love to >> see it described in here. If it's just a matter of having completely described >> behavior for corner cases, it may be worthwhile indicating that the client >> will reject the connection if the server decides to complete the handshake >> like this. > DANE clients sometimes accept more than one name for the server. This happens > when the server name is obtained indirectly from MX OR SRV records, or as the > result of (DNSSEC-validated) CNAME expansion. Ah, that's an interesting point. You may want to keep this in mind when responding to the question put forth by the GEN-ART reviewer. > So in principle, more than one name might be acceptable to the client. In > practice however, I don't yet see a mechanism where a client that can't do > DNSSEC validation on its own would be in a position to do this. My understanding is that this mechanism isn't just for clients that can't do their own DNSSEC validation; it's also intended to reduce latency for interactive applications (web browsers and real-time-communication clients in particular). > So the server may indeed be able to validate a certificate for some name > that the client did not expect, and it would then be up to some external > mechanism (prompt the user?) to accept that name or not. > > It is not entirely unreasonable to allow the client that freedom, but it > would likely not be a mainstream mode of operation. > > Perhaps I am not thinking creatively enough about other ways for the client > to be configured security to accept one of many names for the server, and > to "guess" the wrong one. I think we're in the same boat here. :) /a From nobody Tue Feb 6 20:21:59 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A76012422F; Tue, 6 Feb 2018 20:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 IQQ4xbDhQNlV; Tue, 6 Feb 2018 20:21:50 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E79D3120227; Tue, 6 Feb 2018 20:21:49 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id d13so521603iog.5; Tue, 06 Feb 2018 20:21:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0l+tfcpLm2lQu4otVm7KW7xH6cvwAZ/1oX9XEunj9r4=; b=VPCmDctYVs1GjSYspO7ZO/NtC0td6AN9KjqXesDVEEerrGCcW0GkJPkNm0sptnSKls 8VfgfxXqCTgl7zN281q2I+uplctZzbDucOLhfwwDwOHr40GQcbNIpCMJPsElxTz11Pda gHU7o70as0lAeipCB2dqXvTSmYFxFU1RtFyP2mR6Db8lnxOQ6eUoCKYYkUiWTyQsniyx W2hPr9kUqa2pT2cyQbRCKf/1KcTnot7lSmDms59aNwxOCV6Q1PYNPlWNgnNackz9PSdo tipcAnw94Ips73/iFACK0xEtvT+ufiLXVxTF2A7CsoqoXV8apYSErfyFRSTczpXjOEWY jxEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0l+tfcpLm2lQu4otVm7KW7xH6cvwAZ/1oX9XEunj9r4=; b=Q6RRvVZyJrifunBoxUq92QrpxjI+pPja76Kjxi2GnWp5jsaC+qmFloRgDq/m4tx9iW XZ09PrPtWy46eyb6Zh2flZtSOIbmqi8ZNkaHHIjQxAV9/0a5t9Zvk85NHEM6wlTK+jTP taeI1lOax2bRk4JYzCB1McckVNT3OcJRrQypMqz7b1cGbprCJpHSYmqRxn8jJMDF+bMR ZnTRMyPDsvdnne5/27kcRdDxPpbJwa7jtQiStnfjkJDCyWbwVkQ8E4VWGRMfQzBKNXqD 4E0bxLX/rFp82/EMWD3uK94H6voy+p1de2c8JPDhmENeAjnEMB/v4Ce+rDF27X97RUM5 y4MA== X-Gm-Message-State: APf1xPDPGpNP1WFjs8pwKWQm83YpHsnEsFg9tCJGnoXAcWFpqkJTu+dc fkZsdomgfQTKWUu7EEE8pfnIK6Co+r4k82TnR8s= X-Google-Smtp-Source: AH8x224rHvT6Z/4oFSrxSKD1FZQmz98QWB1mb7WdSc/dbzQwLcmiq7CHDx5L64zy589CUVMx1XcqVX/1YSevDlBgwa8= X-Received: by 10.107.53.213 with SMTP id k82mr5645184ioo.170.1517977309198; Tue, 06 Feb 2018 20:21:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.201.198 with HTTP; Tue, 6 Feb 2018 20:21:48 -0800 (PST) In-Reply-To: References: <151797357502.25862.16667889525841537162.idtracker@ietfa.amsl.com> <23185062-60CA-4BA6-BAA5-5DDD6279558B@dukhovni.org> From: Shumon Huque Date: Tue, 6 Feb 2018 23:21:48 -0500 Message-ID: To: Adam Roach Cc: Viktor Dukhovni , tls-chairs@ietf.org, draft-ietf-tls-dnssec-chain-extension@ietf.org, The IESG , TLS WG Content-Type: multipart/alternative; boundary="001a1144a1a64abe22056497a20f" Archived-At: Subject: Re: [TLS] Adam Roach's Yes on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 04:21:52 -0000 --001a1144a1a64abe22056497a20f Content-Type: text/plain; charset="UTF-8" On Tue, Feb 6, 2018 at 10:39 PM, Adam Roach wrote: > On 2/6/18 9:28 PM, Viktor Dukhovni wrote: > >> >> On Feb 6, 2018, at 10:19 PM, Adam Roach wrote: >>> >>> Unless I missed something important, this scenario doesn't seem to make >>> much >>> sense: if the client provides name A and the server replies with name B, >>> the >>> client either (1) isn't performing server name validation (in which case >>> it is >>> nonsense for the client to ask for a dnssec_chain), or (2) is going to >>> error >>> out the connection. Do I have that right? If there's some situation in >>> which >>> the server acting as described above provides some benefit, I would love >>> to >>> see it described in here. If it's just a matter of having completely >>> described >>> behavior for corner cases, it may be worthwhile indicating that the >>> client >>> will reject the connection if the server decides to complete the >>> handshake >>> like this. >>> >> DANE clients sometimes accept more than one name for the server. This >> happens >> when the server name is obtained indirectly from MX OR SRV records, or as >> the >> result of (DNSSEC-validated) CNAME expansion. >> > > Ah, that's an interesting point. You may want to keep this in mind when > responding to the question put forth by the GEN-ART reviewer. > > So in principle, more than one name might be acceptable to the client. In >> practice however, I don't yet see a mechanism where a client that can't do >> DNSSEC validation on its own would be in a position to do this. >> > > My understanding is that this mechanism isn't just for clients that can't > do their own DNSSEC validation; it's also intended to reduce latency for > interactive applications (web browsers and real-time-communication clients > in particular). > >> >> > Yes, that's true. But if we were to consider the MX/SRV use case, then for this specification to be complete, it would have to consider clients that are unable to validate on their own. This means the dnssec_chain extension would have to provide records that can (also) validate the MX or SRV records, which it doesn't do right now. In early discussions about the scope of this draft, I believe we decided to omit the MX/SRV case to keep things simple. This is why the draft only references RFC 6698 and 7671, and not 7672 and 7673. (Well it mentions 7672 only tangentially to suggest that such clients likely won't need this mechanism). Shumon Huque --001a1144a1a64abe22056497a20f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 6, 2018 at 10:39 PM, Adam Roach <adam@nostrum.com> wr= ote:
On 2/6/18 9:28 PM, Viktor Dukhovni wrote:

On Feb 6, 2018, at 10:19 PM, Adam Roach <adam@nostrum.com> wrote:

Unless I missed something important, this scenario doesn't seem to make= much
sense: if the client provides name A and the server replies with name B, th= e
client either (1) isn't performing server name validation (in which cas= e it is
nonsense for the client to ask for a dnssec_chain), or (2) is going to erro= r
out the connection. Do I have that right? If there's some situation in = which
the server acting as described above provides some benefit, I would love to=
see it described in here. If it's just a matter of having completely de= scribed
behavior for corner cases, it may be worthwhile indicating that the client<= br> will reject the connection if the server decides to complete the handshake<= br> like this.
DANE clients sometimes accept more than one name for the server.=C2=A0 This= happens
when the server name is obtained indirectly from MX OR SRV records, or as t= he
result of (DNSSEC-validated) CNAME expansion.

 Ah, that's an interesting point. You may want to keep this in mind when= responding to the question put forth by the GEN-ART reviewer.

So in principle, more than one name might be acceptable to the client.=C2= =A0 In
practice however, I don't yet see a mechanism where a client that can&#= 39;t do
DNSSEC validation on its own would be in a position to do this.

 My understanding is that this mechanism isn't just for clients that can= 't do their own DNSSEC validation; it's also intended to reduce lat= ency for interactive applications (web browsers and real-time-communication= clients in particular).
=C2=A0
<= br>
Yes, that's true. But if we were to consider the MX/SRV u= se case, then for this specification to be complete, it would have to consi= der clients that are unable to validate on their own. This means the dnssec= _chain extension would have to provide records that can (also) validate the= MX or SRV records, which it doesn't do right now.

=
In early discussions about the scope of this draft, I believe we decid= ed to omit the MX/SRV case to keep things simple. This is why the draft onl= y references RFC 6698 and 7671, and not 7672 and 7673. (Well it mentions 76= 72 only tangentially to suggest that such clients likely won't need thi= s mechanism).

Shumon Huque=C2=A0

--001a1144a1a64abe22056497a20f-- From nobody Tue Feb 6 20:24:01 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4626124319; Tue, 6 Feb 2018 20:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 loUuMaUU8BWc; Tue, 6 Feb 2018 20:23:57 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DC06120227; Tue, 6 Feb 2018 20:23:57 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id u12-v6so14145151ite.0; Tue, 06 Feb 2018 20:23:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xs8MYBukQIUmbWO3XXsBH97HLipZi8TOzHHtmc+inZk=; b=VK3D++LI392h6iIczYChq+Rte0eUSbM4H5dO/jENgtsycDKdIK2GqDdRminjsTwBp7 AEwA8TCYamORj7HzgAocFMkldm48YSkNCOCpO+zBBg4qmrqxd8IBTdRLtBCXAW9AO/3A 9HU4MdSvIuFMgArqvHkaGekysfUwVJgG74ALYg43oDUyN2wcHSWgdrXN19y7P4TUKDEM DU/JpWuie6PE2O0fzLsKTPKNgkZjdDU7S5YupR9MnYjych+ubt2kRvTo5cueUr82kCpU xoPQh1TyQR+0TzKe+2diI77aT5e68+Aozui+EcZBE3FDI25lZ2K1bUhKnp3MyLkU1C7u E+FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xs8MYBukQIUmbWO3XXsBH97HLipZi8TOzHHtmc+inZk=; b=m1IDh/dRuCdmPEM8I4pORSqYCitejPxnABX5wUNhd02QnAs1D5/fUY8ijeWvLc5vL5 4fUEYTxjaUsWkijphntnOdu3WFvVJSPwLeXMmh0VRKtiPgstSiTBfkq9x7fpuQXd0ZLD rBeQM0Rna8lE7Syh1TYJJijmQLn1EXNQKIhr+nNZNNx7O0vz4wmw/IgIM6HZnU8rzHf5 BrO5Ej5shf3VqW3/MaEsofKa/g3J87vamPY+07CCXikC5Fi5IVBZ3swd31ycrdt/iNY6 z4svsXtTWXYVnsLYXzVJk9oQ4xrk4LB0zQYYbVIBqDrVDhAHZFj3zeDkV3a5nOlZKXxf MUCA== X-Gm-Message-State: APf1xPCY4llqp/rIJVw5fdgQRBaCYPhscBC8e1XVrPtFWslodZq7n1Um 6Yb5SWcE+I83dtCcjts/JHksZ4MzqF5bKKoj4IU= X-Google-Smtp-Source: AH8x227lfIaNg68bILDiALIs4p0w2AcKy8bXxJCbnv/Ts3lC9RH1CRCG5XIVLhpeGa46CRnntUkpYeZgOu+uU0dOhBI= X-Received: by 10.36.167.67 with SMTP id s3mr6584109iti.66.1517977436813; Tue, 06 Feb 2018 20:23:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.201.198 with HTTP; Tue, 6 Feb 2018 20:23:56 -0800 (PST) In-Reply-To: <151797357502.25862.16667889525841537162.idtracker@ietfa.amsl.com> References: <151797357502.25862.16667889525841537162.idtracker@ietfa.amsl.com> From: Shumon Huque Date: Tue, 6 Feb 2018 23:23:56 -0500 Message-ID: To: Adam Roach Cc: The IESG , draft-ietf-tls-dnssec-chain-extension@ietf.org, Joseph Salowey , tls-chairs@ietf.org, TLS WG Content-Type: multipart/alternative; boundary="f403045fb1c8e60096056497a980" Archived-At: Subject: Re: [TLS] Adam Roach's Yes on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 04:24:00 -0000 --f403045fb1c8e60096056497a980 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 6, 2018 at 10:19 PM, Adam Roach wrote: > Adam Roach has entered the following ballot position for > draft-ietf-tls-dnssec-chain-extension-06: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I like this mechanism and look forward to its deployment. I have one poin= t > of > clarification and a small handful of editorial comments. > > First, the point of clarification: > > =C2=A74: > > > if the server does not recognize the > > provided name and wishes to proceed with the handshake rather than to > > abort the connection, the server uses the domain name associated with > > the server IP address to which the connection has been established. > > Unless I missed something important, this scenario doesn't seem to make > much > sense: if the client provides name A and the server replies with name B, > the > client either (1) isn't performing server name validation (in which case > it is > nonsense for the client to ask for a dnssec_chain), or (2) is going to > error > out the connection. Do I have that right? If there's some situation in > which > the server acting as described above provides some benefit, I would love = to > see it described in here. If it's just a matter of having completely > described > behavior for corner cases, it may be worthwhile indicating that the clien= t > will reject the connection if the server decides to complete the handshak= e > like this. > > ------------------------------------------------------------ > --------------- > > > Intended status: Standards Track R. Barne= s > > Expires: July 27, 2018 Mozill= a > > s/Mozilla/Cisco/ > > ------------------------------------------------------------ > --------------- > > =C2=A71: > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > > document are to be interpreted as described in [RFC2119]. > > This document has significant usage of these terms in lowercase. Please > consider > using the boilerplate from RFC 8174 instead. > > ------------------------------------------------------------ > --------------- > > =C2=A73.3: > > > the case in DANE in which a client either ignores the name in > > certificate (as specified in [RFC7671] or there is no attestation of > > Nit: "...in the certificate..." > > Nit: Add closing paren after [RFC7671] > > ------------------------------------------------------------ > --------------- > > =C2=A74: > > > specific processing needed for aliases and wildcards. If DNS > > responses messages contain any domain names utilizing name > > Nit: "response" > > Adam - nits have been noted, and will be fixed. Shumon Huque --f403045fb1c8e60096056497a980 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 6, 2018 at 10:19 PM, Adam Roach <adam@nostrum.com> wr= ote:
Adam Roach has entered the following= ballot position for
draft-ietf-tls-dnssec-chain-extension-06: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/= doc/draft-ietf-tls-dnssec-chain-extension/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

I like this mechanism and look forward to its deployment. I have one point = of
clarification and a small handful of editorial comments.

First, the point of clarification:

=C2=A74:

>=C2=A0 if the server does not recognize the
>=C2=A0 provided name and wishes to proceed with the handshake rather th= an to
>=C2=A0 abort the connection, the server uses the domain name associated= with
>=C2=A0 the server IP address to which the connection has been establish= ed.

Unless I missed something important, this scenario doesn't seem to make= much
sense: if the client provides name A and the server replies with name B, th= e
client either (1) isn't performing server name validation (in which cas= e it is
nonsense for the client to ask for a dnssec_chain), or (2) is going to erro= r
out the connection. Do I have that right? If there's some situation in = which
the server acting as described above provides some benefit, I would love to=
see it described in here. If it's just a matter of having completely de= scribed
behavior for corner cases, it may be worthwhile indicating that the client<= br> will reject the connection if the server decides to complete the handshake<= br> like this.

-----------------------------------------------------------------= ----------

> Intended status: Standards Track=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0R.= Barnes
> Expires: July 27, 2018=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Mozilla

s/Mozilla/Cisco/

-----------------------------------------------------------------= ----------

=C2=A71:

>=C2=A0 =C2=A0The key words "MUST", "MUST NOT", &quo= t;REQUIRED", "SHALL", "SHALL NOT",
>=C2=A0 =C2=A0"SHOULD", "SHOULD NOT", "RECOMMEN= DED", "MAY", and "OPTIONAL" in this
>=C2=A0 =C2=A0document are to be interpreted as described in [RFC2119].<= br>
This document has significant usage of these terms in lowercase. Please con= sider
using the boilerplate from RFC 8174 instead.

-----------------------------------------------------------------= ----------

=C2=A73.3:

>=C2=A0 the case in DANE in which a client either ignores the name in >=C2=A0 certificate (as specified in [RFC7671] or there is no attestatio= n of

Nit: "...in the certificate..."

Nit: Add closing paren after [RFC7671]

-----------------------------------------------------------------= ----------

=C2=A74:

>=C2=A0 specific processing needed for aliases and wildcards.=C2=A0 If D= NS
>=C2=A0 responses messages contain any domain names utilizing name

Nit: "response"


Adam - ni= ts have been noted, and will be fixed.

Shumon Huqu= e

--f403045fb1c8e60096056497a980-- From nobody Tue Feb 6 20:31:38 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70231243F6; Tue, 6 Feb 2018 20:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 XQWH5v1J1WOp; Tue, 6 Feb 2018 20:31:23 -0800 (PST) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AA4412422F; Tue, 6 Feb 2018 20:31:20 -0800 (PST) Received: by mail-it0-x230.google.com with SMTP id k131so613000ith.4; Tue, 06 Feb 2018 20:31:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JbfG52p0Xkowqo9dfpQZoa1Q5FJxcbxsm6LGGCXed9k=; b=GZzkxhxiSA7pCevT6QRoua3O3pmIPz/A+eye5GbKGdKFzfCFZHKx4ZY/Q3Wzti5O1G 0Ht2xQz0NmpcJhAzRvHYvyDkuUh7+w3fNL9xccWA/d3a3EUR5C4/uDtryIfLuR4ZtPmr qCRPCuT6qIGpeyL8vrbHO8ofmpqUZqAmh2iA4578SywE6147x8so21OmO08NiR0wUB7B 663vH6LRaYhfVpDlFv47qk5nn5MEMOf7Y3x1xl4vk74CvetB19+UP5VJG+6GVB1WFHzg haGNjFVtvJ2o8JJcSx5KbFJXYcPH1xd+VqTxpEVD+1o55lpUhDdTjss6j0RrtohRLFK3 nxcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JbfG52p0Xkowqo9dfpQZoa1Q5FJxcbxsm6LGGCXed9k=; b=KfgZWCzxvqEs/ajz7ih8qPYLqcRUcKUPS7hUoRzjlrESinez8qzz4edO/tMpxigvlA WqTV41n8FusfNsop2kqWznmA84ZOAMe2posrQx+yOhJNi1g1qAjifegmDvaaSU6hshBZ iFv2kzqiezJq41DfzEg+PeQ7EkXpeqnoRElOwdB91lzUQfk5F/QVuz/8eiYkColYgJkB M+psuAho9Ermf03Hhx4TVncjf9TcxTBIQs9JDLmwCyZ37dOHohecuEV6MJ3MahD4wiRT ecOtjzRzIilBZYQ/NcfwtzlJqFACpLatCfU8Yrji6T1T8SpCjopQH1KKXtbkB/HnLmr1 vYsA== X-Gm-Message-State: APf1xPD/wE1IxP0tkjhRIylttApFPza4MhqkTo47hAKnDWcjK7t6PNsZ PJreHAx5vKKoVZg5dsyZOi/ZB0oS8S3zen6ve/4= X-Google-Smtp-Source: AH8x226uFspNKNkgiw71w3gAaFGEp5el6SVX+6dgYN7hOZ/dISkfKFkV+xyXVkYMlmEC0o1wHh2UR5TNeOIe5VCXEkE= X-Received: by 10.36.73.77 with SMTP id z74mr140321ita.72.1517977879979; Tue, 06 Feb 2018 20:31:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.201.198 with HTTP; Tue, 6 Feb 2018 20:31:19 -0800 (PST) In-Reply-To: <151796675979.25928.2038193051971303546@ietfa.amsl.com> References: <151796675979.25928.2038193051971303546@ietfa.amsl.com> From: Shumon Huque Date: Tue, 6 Feb 2018 23:31:19 -0500 Message-ID: To: Matthew Miller Cc: gen-art@ietf.org, ietf , draft-ietf-tls-dnssec-chain-extension.all@ietf.org, TLS WG Content-Type: multipart/alternative; boundary="001a11c145d05029c3056497c466" Archived-At: Subject: Re: [TLS] Genart telechat review of draft-ietf-tls-dnssec-chain-extension-06 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 04:31:26 -0000 --001a11c145d05029c3056497c466 Content-Type: text/plain; charset="UTF-8" On Tue, Feb 6, 2018 at 8:25 PM, Matthew Miller < linuxwolf+ietf@outer-planes.net> wrote: > Reviewer: Matthew Miller > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-tls-dnssec-chain-extension-06 > Reviewer: Matthew A. Miller > Review Date: 2018-02-06 > IETF LC End Date: 2018-02-07 > IESG Telechat date: 2018-02-08 > > Summary: > > This document is ready, with one issue that I think could benefit > from some clarification. > > Major issues: > > NONE > > Minor issue: > > This is more a question, that might warrant some clarification: > In 7. Verification, the last paragraph discusses client-side > caching of the RRsets. If a client has cached the full RRset chain > from TLSA to root RRSIG (and that cache is still viable), is the > client still expected to specify the "dnssec_chain" extension? > > In my reading, that does not seem necessary, and I think it might > be worth noting if that is true. > Yes, if the client has cached either the validated TLSA RRset or the full chain, then it doesn't need to send the dnssec_chain for subsequent connections. If it has only cached other portions of the chain, then it needs to. We can clarify this. Shumon Huque --001a11c145d05029c3056497c466 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 6, 2018 at 8:25 PM, Matthew Miller <linuxwolf+ietf@o= uter-planes.net> wrote:
Rev= iewer: Matthew Miller
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq<= /a>>.

Document: draft-ietf-tls-dnssec-chain-extension-06
Reviewer: Matthew A. Miller
Review Date: 2018-02-06
IETF LC End Date: 2018-02-07
IESG Telechat date: 2018-02-08

Summary:

This document is ready, with one issue that I think could benefit
from some clarification.

Major issues:

NONE

Minor issue:

This is more a question, that might warrant some clarification:
In 7. Verification, the last paragraph discusses client-side
caching of the RRsets. If a client has cached the full RRset chain
from TLSA to root RRSIG (and that cache is still viable), is the
client still expected to specify the "dnssec_chain" extension?
In my reading, that does not seem necessary, and I think it might
be worth noting if that is true.

<= div>full chain, then it doesn't need to send the dnssec_chain for subse= quent


<= div>We can clarify this.

--001a11c145d05029c3056497c466-- From nobody Wed Feb 7 05:21:33 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F66129C5D; Wed, 7 Feb 2018 05:21:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-tls-dnssec-chain-extension@ietf.org, Joseph Salowey , shuque@gmail.com, tls-chairs@ietf.org, joe@salowey.net, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151800968634.4877.12510609339415982154.idtracker@ietfa.amsl.com> Date: Wed, 07 Feb 2018 05:21:26 -0800 Archived-At: Subject: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-tls-dnssec-chain-extension-06=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 13:21:26 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-tls-dnssec-chain-extension-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Two minor, mostly editorial comments: 1) Intro (sec 2): " It also provides the ability to avoid potential problems with TLS clients being unable to look up DANE records because of an interfering or broken middlebox on the path between the client and a DNS server." Is that actually a well-known problem (can you provide a reference?) or would it be enough to say something like this: " It also provides the ability to avoid potential problems with TLS clients being unable to look up DANE records when DNS server is not reachable." 2) IANA Considerations should probably be updated. From nobody Wed Feb 7 06:34:41 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9125012D779; Wed, 7 Feb 2018 06:34:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-tls-dnssec-chain-extension@ietf.org, Joseph Salowey , shuque@gmail.com, tls-chairs@ietf.org, joe@salowey.net, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com> Date: Wed, 07 Feb 2018 06:34:40 -0800 Archived-At: Subject: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 14:34:41 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-tls-dnssec-chain-extension-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This draft seems generally sound, but I believe there are pieces that are still underspecified. These should be easy to fix. the Signer's Name field in canonical form and the signature field excluded. IMPORTANT: I'm not sure that this is actually sufficient to allow an independent implementation without referring to the other documents. I mean, I think I pretty clearly can't validate this chain from the above. Similarly, although I think this is enough to break apart the RRSETs into RRs, it doesn't tell me how to separate the RRSETs from each other. I think you need to either make this a lot more complete or alternately stop saying it's sufficient. abort the connection, the server uses the domain name associated with the server IP address to which the connection has been established. IMPORTANT: "the domain name" is not unambiguous. Hosts can have multiple names for the same IP. DNSSEC authentication chain extension from a server, SHOULD use this information to perform DANE authentication of the server. In order to do this, it uses the mechanism specified by the DNSSEC protocol IMPORTANT: What happens if the DANE validates but the cert is revoked or alternately the cert validates but DANE does not? [RFC4035] [RFC5155]. This mechanism is sometimes implemented in a DNSSEC validation engine or library. IMPORTANT: shouldn't it be a requirement to perform this validation? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- typically not be used for general DNSSEC validation of TLS endpoint names. Can you rephrase this. I *think* it means "it's not used to validate the A/AAAA lookup"...? validation of endpoint names, but is more appropriate for validation of DANE TLSA records. Same comment as abive This mechanism is useful for TLS applications that need to address the problems described above, typically web browsers or VoIP and XMPP applications. It may not be relevant for many other applications. Nit; cites to SIP/XMPP appropriate here, ClientHello message that the DNS authentication chain be returned in the (extended) ServerHello message. If the server is configured for DANE authentication, then it performs the appropriate DNS queries, This is not correct for TLS 1.3. 3.1. Protocol, TLS 1.2 You should probably provide some guidance about whether the server should still provide the whole X.509 chain to the client. I believe with these semantics, the server cannot tell which DANE mode the client wants and therefore has to provide the entire chain. Servers receiving a "dnssec_chain" extension in the ClientHello, and which are capable of being authenticated via DANE, MAY return a serialized authentication chain in the extended ServerHello message, Nit: I believe you want to remove the commas here, as they indicate a nonrestrictive clause. arbitrary domain names using this mechanism. Therefore, a server MUST NOT construct chains for domain names other than its own. "its own" is a bit fraught, as servers may not actually know all their domain names, at least at the TLS layer.. Can you be more specific about what the server algorithm is. Servers receiving a "dnssec_chain" extension in the ClientHello, and which are capable of being authenticated via DANE, SHOULD return a serialized authentication chain in the extension block of the Why is this a SHOULD where the corresponding reqt for TLS 1.2 and below is a MAY? to a DNSSEC trust root. This has the added benefit of mitigating an unknown key share attack, as described in [I-D.barnes-dane-uks], since it effectively augments the raw public key with the server's "unknown key share (UKS)" handshake, to a domain name which has been validated as belonging to the owner name. The key point here is that the commitment is bound to the EE key. Also, this only really works for TLS 1.3 and modes with EMS because otherwise there are other UKS attacks I think you probably want to cite SIGMA and triple handhshake here. opaque AuthenticationChain<0..2^16-1> Is 0 actually appropriate here as a lower bound? Presumably at least one such instance must be present? RR(i) = owner | type | class | TTL | RDATA length | RDATA I assume the notation here is "i is the ith RR"? Is there a reason not to describe this in TLS language? . DNSKEY RRSIG(. DNSKEY) How does this differ from the algorithm that you would use in response to the TLSA query? the draft is adopted by the WG, the authors expect to make an early allocation request as specified in [RFC7120]. Do you want this to be marked RECOMMENDED? From nobody Wed Feb 7 10:22:46 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 748E81270AE; Wed, 7 Feb 2018 10:22:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-tls-dnssec-chain-extension@ietf.org, Joseph Salowey , shuque@gmail.com, tls-chairs@ietf.org, joe@salowey.net, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151802776446.4849.12008167318274714913.idtracker@ietfa.amsl.com> Date: Wed, 07 Feb 2018 10:22:44 -0800 Archived-At: Subject: [TLS] Alexey Melnikov's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 18:22:44 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-tls-dnssec-chain-extension-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I think this is a useful document and I will ballot Yes once my small issues are resolved: 1) In 3.4: The first RRset in the chain MUST contain the TLSA record set being presented. However, if the owner name of the TLSA record set is an alias (CNAME or DNAME), then it MUST be preceded by the chain of alias records needed to resolve it. DNAME chains should omit SHOULD? What are the implications if this is not followed? unsigned CNAME records that may have been synthesized in the response from a DNS resolver. 2) TLS 1.3 needs to be a normative reference, but it is not even listed in References. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The first mention of NSEC3 need a normative reference. From nobody Wed Feb 7 12:34:06 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615DE12D863 for ; Wed, 7 Feb 2018 12:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 Y6cZTFWLpeF1 for ; Wed, 7 Feb 2018 12:34:02 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 061C512D86C for ; Wed, 7 Feb 2018 12:34:02 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id y204so2848386qkb.10 for ; Wed, 07 Feb 2018 12:34:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=FGoQlmIyhBEwqORJ0mAEyUaOA55XTHT+GDLhwCWLgGY=; b=D85xRGV9bL2w6hGZsCRazwsjgPcDvmJvu14kIdXttaqqZAsdqx+nkzoOkK7kwbV0jg te3qO8YZ5rX/dwmUcTwQMQZSSSZE7F/UBGXHlcfBxhYMSy6QaV0CTcFqOKbwJ+vkksFO dLKrCkt0EGyIgnjo/tmiaoLjY9+pwOGBzr7bA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=FGoQlmIyhBEwqORJ0mAEyUaOA55XTHT+GDLhwCWLgGY=; b=J6CAWBaa0tJp0GlGI22YX2vYiAbRZiAX5QtCnRKLqJ/Y1BeiCk1ARMW1FW9AFxrHFK xkGpuN9mt0E5xSfyqZsLV3S/01kS2Ti0YqzJVeWrXd9zZb83aElbcagAZ1/VE034Wqao Lj7/aVETs4+KOFeAKKUfOPzuBl6SNXLGmvKoqZgWBzAAikxd6Twns3VHGQVX3ErKjbpi 603dzCaOjynawrOlEc/Buxx7laUWe4lVD6HskPhqaI8Kn2f8JW0l7SQK+taPAKORBQCF XPBCH1UgBdaMFAJ8dVjZdHMlk2zitu+r0m0NAKfDAOMv6qjleTcL0USF8UxVXilrcoWv bKYA== X-Gm-Message-State: APf1xPD+9EXtAZYZD1sv3lpJ2t2rOzA9uHrkYg0ROre8mqHP9imSwj7I lHOU8/jJKTR6BagVDofqW4XUvekK3Es= X-Google-Smtp-Source: AH8x224RsDD3jmxyDz52/xCtYZMULHdaXvg1ycKeaQRNfj6sEWAou7iSO2gmCfux2ErE1VXSo8BG3w== X-Received: by 10.55.125.197 with SMTP id y188mr11180587qkc.111.1518035640914; Wed, 07 Feb 2018 12:34:00 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id u1sm1663553qtb.65.2018.02.07.12.34.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 12:34:00 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <0BD40460-F194-4A2B-8E7C-4FD2D084111B@sn3rd.com> Date: Wed, 7 Feb 2018 15:33:59 -0500 To: "" X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [TLS] Recommended yes->no for max_fragment_length extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 20:34:05 -0000 All, Prior to pushing draft-ietf-tls-record-limit [0] to the IESG, the WG = needs to confirm that draft-ietf-tls-record-limit should change = max_fragment_length [1] from =E2=80=9CYes=E2=80=9D in our soon to be = created Recommended column (see [2]) to a =E2=80=9CNo=E2=80=9D. Please = indicate by 2359 UTC on 14 Feb whether you are for or against this = change; and if you are against please indicate why. spt [0] https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ [1] https://datatracker.ietf.org/doc/rfc6066/ [2] = https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/= From nobody Wed Feb 7 12:37:53 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AB81275F4 for ; Wed, 7 Feb 2018 12:37:52 -0800 (PST) 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 autolearn_force=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 H2254HDclY3M for ; Wed, 7 Feb 2018 12:37:50 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6483D1275AB for ; Wed, 7 Feb 2018 12:37:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 48B3C3005D0 for ; Wed, 7 Feb 2018 15:37:48 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id T1F8a-qjJqlO for ; Wed, 7 Feb 2018 15:37:47 -0500 (EST) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 327A6300441; Wed, 7 Feb 2018 15:37:47 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <0BD40460-F194-4A2B-8E7C-4FD2D084111B@sn3rd.com> Date: Wed, 7 Feb 2018 15:37:48 -0500 Cc: IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: References: <0BD40460-F194-4A2B-8E7C-4FD2D084111B@sn3rd.com> To: Sean Turner X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Recommended yes->no for max_fragment_length extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 20:37:52 -0000 If the WG is going to publish the standards track RFC, then the = extension it defines should say 'Yes' in the recommended column. Russ > On Feb 7, 2018, at 3:33 PM, Sean Turner wrote: >=20 > All, >=20 > Prior to pushing draft-ietf-tls-record-limit [0] to the IESG, the WG = needs to confirm that draft-ietf-tls-record-limit should change = max_fragment_length [1] from =E2=80=9CYes=E2=80=9D in our soon to be = created Recommended column (see [2]) to a =E2=80=9CNo=E2=80=9D. Please = indicate by 2359 UTC on 14 Feb whether you are for or against this = change; and if you are against please indicate why. >=20 > spt >=20 > [0] https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ > [1] https://datatracker.ietf.org/doc/rfc6066/ > [2] = https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Feb 7 12:56:15 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5823D128959 for ; Wed, 7 Feb 2018 12:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 nTNzm2KlxG9f for ; Wed, 7 Feb 2018 12:56:12 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DA97127863 for ; Wed, 7 Feb 2018 12:56:12 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id x190so1057458ywd.10 for ; Wed, 07 Feb 2018 12:56:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pwcGnUYiIGixINWceBzN5sl3DnGaDsRTkHH2hJnelUY=; b=w/P72H0aGoQQ/IzF28oWA18RoMRHA8XIZVZpX51kYZFxO44sjvk9pMnJDOQco+IOEC 62zAL2M7KMRZ8/nfxA3XQ4xkd3jl9HiOH3/s7mWqO85VFSN+IWuBcvXDPcI/bTb7u5jc Ax91ddI2GJcjDbDLneNPxs8DIRlT/ikCbvrLJpg7V9bqjrwYSmnDT+XQSkYWOIvgqvuo BuDi1NbUpc5biEmAEHh1YzQSBiIBdQAls6ucGL9q9lEzbJwpE0Te4/0cbITm3gSeEtOh AXumnDdB7n3PWpjAUTVu6RgiugV042MJUMWQeFa0oEviV2LPJUDgbjuwZYm+0GAgN1i9 MSTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pwcGnUYiIGixINWceBzN5sl3DnGaDsRTkHH2hJnelUY=; b=b81YB40suVnKle9AbgUu10me2MKlrqzkE/b1rsVSI29Tm494DwaxpYoxg5XsRSTClH 5zCqSh+rEx+fEZg/PAg2vmg5RWmE1tWMk6FlZEoKFI1BTw8dXg3dVKV3flQ7tTCJvIxV p6rRCtmS1YSX6f69Fv1PKLsWQUU/TnCwwNflUf4pylcJeROYgZNvL6kvZcb68mYeIxFd 2N/WCnvlzdrqZNQBu9aCFeFVf+gKbFqxJOuHyfVESa2wDwRvKsJtXFrjll+8hIZHN0Q5 wB7pbCT5g73mljOCv9lzj2H43kzkf4TjgHmY+7YKwlc8PH3Dj7cBTJoDjH39XhZQs+U6 JTNw== X-Gm-Message-State: APf1xPBZj+QedYzEI/H9cIHlV5X4sipynApUerBp3USNBgswkfIwf/D5 XQEGRyevrwAM5M/Wc0S9c4ckZZdq+ONVefhVv0iv7EEb X-Google-Smtp-Source: AH8x225TWO+mdyrM1Z6pJ32Y1v6nLeypdE2eoitktRah8XgkONAZF+MrNhLH5esj2Oizn3S4AjJRo7NvbXkgS4RItFE= X-Received: by 10.129.161.16 with SMTP id y16mr5000003ywg.2.1518036971329; Wed, 07 Feb 2018 12:56:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.160.201 with HTTP; Wed, 7 Feb 2018 12:55:30 -0800 (PST) In-Reply-To: <0BD40460-F194-4A2B-8E7C-4FD2D084111B@sn3rd.com> References: <0BD40460-F194-4A2B-8E7C-4FD2D084111B@sn3rd.com> From: Eric Rescorla Date: Wed, 7 Feb 2018 12:55:30 -0800 Message-ID: To: Sean Turner Cc: "" Content-Type: multipart/alternative; boundary="001a114f89bc6eaf7e0564a5860e" Archived-At: Subject: Re: [TLS] Recommended yes->no for max_fragment_length extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 20:56:14 -0000 --001a114f89bc6eaf7e0564a5860e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am for this change. -Ekr On Wed, Feb 7, 2018 at 12:33 PM, Sean Turner wrote: > All, > > Prior to pushing draft-ietf-tls-record-limit [0] to the IESG, the WG need= s > to confirm that draft-ietf-tls-record-limit should change > max_fragment_length [1] from =E2=80=9CYes=E2=80=9D in our soon to be crea= ted Recommended > column (see [2]) to a =E2=80=9CNo=E2=80=9D. Please indicate by 2359 UTC = on 14 Feb whether > you are for or against this change; and if you are against please indicat= e > why. > > spt > > [0] https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ > [1] https://datatracker.ietf.org/doc/rfc6066/ > [2] https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates= / > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114f89bc6eaf7e0564a5860e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am for this change.

-Ekr

On = Wed, Feb 7, 2018 at 12:33 PM, Sean Turner <sean@sn3rd.com> wrot= e:
All,

Prior to pushing draft-ietf-tls-record-limit [0] to the IESG, the WG needs = to confirm that draft-ietf-tls-record-limit should change max_fragment_leng= th [1] from =E2=80=9CYes=E2=80=9D in our soon to be created Recommended col= umn (see [2]) to a =E2=80=9CNo=E2=80=9D.=C2=A0 Please indicate by 2359 UTC = on 14 Feb whether you are for or against this change; and if you are agains= t please indicate why.

spt

[0] https://datatracker.ietf.org/d= oc/draft-ietf-tls-record-limit/
[1] https://datatracker.ietf.org/doc/rfc6066/
[2] https://datatracker.ietf.o= rg/doc/draft-ietf-tls-iana-registry-updates/
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a114f89bc6eaf7e0564a5860e-- From nobody Wed Feb 7 12:56:41 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019FA12D86C for ; Wed, 7 Feb 2018 12:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 hlOqXZT1nJEc for ; Wed, 7 Feb 2018 12:56:38 -0800 (PST) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFBAE127863 for ; Wed, 7 Feb 2018 12:56:37 -0800 (PST) Received: by mail-ot0-x22c.google.com with SMTP id f56so2117528otj.13 for ; Wed, 07 Feb 2018 12:56:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=vFNuuYhaMokEhhoScxzcf1Yzn/gI87Pbwlalbe7ssiU=; b=bMGMoTZH/MrkuGKXsSb6iFu0Zff9qZySuWuA/F1IjpmxsLm50OE5Q4cPcqseAIvA7x 5M17dVDIrRSTR/doXgHdPU3h/48FmAA1Wxd7/wLMAVUN4RADm9GUm1dOoyxhiAwOsSci 1o3kWg57YyyBaJIjTyCm1sz1YNVmQrBzRVP/NfnBKSQiN7gkjwhW7ZOcjw866zrKv+pN iIEWt19x88SWNRAA2fw2B4PQUhS3qTdy839c69InDhymNCQ4WAsQ0EfgRejsT6TUs3BB Isn5spYEG1CjEx/gq99w3w6X48OPNHqOZqu46880mwukpB2VGkA+lchTF4pPC7zkpsXA PyuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=vFNuuYhaMokEhhoScxzcf1Yzn/gI87Pbwlalbe7ssiU=; b=rNK5VyUT/s6jTlPYe8K076ot02JSVIjYHc1iYHzTczsC2dzSEDw6/S2WKKRB6q9yNC GTSlD6vFv9NO2SSojeZ2HWxn0K1shnD/xc/zK6Y643K9lP79TnGiZv77r5RnmTTuK3TR xVHgALwq79Imcsluqs4wsqjSi9vIH4+60iw2M4bET0DbIj1YnY3O1ddjefYoCWCiTu2y uxa6mNYMEvri9UJ5AfWcyeLx2oC2vrFs+OKms6cnVJ4GQm9upgAD8OLxZ/kHxOp9x/wh eMKoLYp5Tpm8kVk/Z1rXfr6I0arZHT5ibfDwNUktoFO1oLP913zYajS5T7YtjgD+nhT7 Ya8w== X-Gm-Message-State: APf1xPD3p/ZalsUD/X2heKr5Q0NyIJjQN37NyDQkv5XlOPF9KkFvIjOT SeCg3YI/nSAHBduTukizOfkfFSv9KtmbxKU57SQ= X-Google-Smtp-Source: AH8x224wrO8Fx6LwLrQNIVl4eGMIjbgrxnZVykKSKnekACeNqrjxzc29nQMJRNKqKnOR1tNHjR8tRzfPiurPQPgxcd0= X-Received: by 10.157.72.221 with SMTP id a29mr5581578otj.308.1518036997187; Wed, 07 Feb 2018 12:56:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.196 with HTTP; Wed, 7 Feb 2018 12:56:36 -0800 (PST) In-Reply-To: References: <0BD40460-F194-4A2B-8E7C-4FD2D084111B@sn3rd.com> From: Martin Thomson Date: Thu, 8 Feb 2018 07:56:36 +1100 Message-ID: To: Russ Housley Cc: Sean Turner , IETF TLS Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Recommended yes->no for max_fragment_length extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 20:56:40 -0000 This is about the OLD extension. I think that NO is appropriate for something we deprecate. https://github.com/tlswg/tls-record-limit/pull/14 On Thu, Feb 8, 2018 at 7:37 AM, Russ Housley wrote: > If the WG is going to publish the standards track RFC, then the extension= it defines should say 'Yes' in the recommended column. > > Russ > > >> On Feb 7, 2018, at 3:33 PM, Sean Turner wrote: >> >> All, >> >> Prior to pushing draft-ietf-tls-record-limit [0] to the IESG, the WG nee= ds to confirm that draft-ietf-tls-record-limit should change max_fragment_l= ength [1] from =E2=80=9CYes=E2=80=9D in our soon to be created Recommended = column (see [2]) to a =E2=80=9CNo=E2=80=9D. Please indicate by 2359 UTC on= 14 Feb whether you are for or against this change; and if you are against = please indicate why. >> >> spt >> >> [0] https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ >> [1] https://datatracker.ietf.org/doc/rfc6066/ >> [2] https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-update= s/ >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Feb 7 13:11:07 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAD312D847 for ; Wed, 7 Feb 2018 13:11:05 -0800 (PST) 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 autolearn_force=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 1lH9nw9-pTmZ for ; Wed, 7 Feb 2018 13:11:04 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BAED12785F for ; Wed, 7 Feb 2018 13:11:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DD7AD300A0D for ; Wed, 7 Feb 2018 16:11:01 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id cX1_0d3cs0oI for ; Wed, 7 Feb 2018 16:11:00 -0500 (EST) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 6EFBF3005B4; Wed, 7 Feb 2018 16:11:00 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Wed, 7 Feb 2018 16:11:01 -0500 Cc: Sean Turner , IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: References: <0BD40460-F194-4A2B-8E7C-4FD2D084111B@sn3rd.com> To: Martin Thomson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Recommended yes->no for max_fragment_length extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 21:11:05 -0000 I misread the question. You are right, is should be "No". Russ > On Feb 7, 2018, at 3:56 PM, Martin Thomson = wrote: >=20 > This is about the OLD extension. I think that NO is appropriate for > something we deprecate. >=20 > https://github.com/tlswg/tls-record-limit/pull/14 >=20 > On Thu, Feb 8, 2018 at 7:37 AM, Russ Housley = wrote: >> If the WG is going to publish the standards track RFC, then the = extension it defines should say 'Yes' in the recommended column. >>=20 >> Russ >>=20 >>=20 >>> On Feb 7, 2018, at 3:33 PM, Sean Turner wrote: >>>=20 >>> All, >>>=20 >>> Prior to pushing draft-ietf-tls-record-limit [0] to the IESG, the WG = needs to confirm that draft-ietf-tls-record-limit should change = max_fragment_length [1] from =E2=80=9CYes=E2=80=9D in our soon to be = created Recommended column (see [2]) to a =E2=80=9CNo=E2=80=9D. Please = indicate by 2359 UTC on 14 Feb whether you are for or against this = change; and if you are against please indicate why. >>>=20 >>> spt >>>=20 >>> [0] https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ >>> [1] https://datatracker.ietf.org/doc/rfc6066/ >>> [2] = https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls From nobody Wed Feb 7 14:09:00 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5B5124239; Wed, 7 Feb 2018 14:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=X/0BoFpc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=H1GjwjHp 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 kBaYf22P1Okh; Wed, 7 Feb 2018 14:08:53 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50AF91205F0; Wed, 7 Feb 2018 14:08:53 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id AC6CA20B7A; Wed, 7 Feb 2018 17:08:52 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Wed, 07 Feb 2018 17:08:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=8YggcmLmk57ZVCy7jwAasU8PNk5A4Nck0HBaDdbL2bA=; b=X/0BoFpc xAxnjG3XKqK1kd/TTZl4fAqk0nH2mnCfkeotWQNEsZE7x+WpAGsgkCKZ4uWTxu6N PgphCXS8T7F/XLYljlUBEy04SRNSrL0rktF1Ynmfe+/GRm5kJwR/U8Vy/8OfSIbP AGN22YKyR/ENcEfAtwyfoRi7KP4sO1d4pwk9xyV/4Zuui8NEvuaysI6bocQYSeAd aCNiDT/55Sp5wi81u5UEY19e0fEZ/ri9Ge0Nec+Li6QYXFMwYi+MflKrTy3Z7wZ0 0l4D8mFa/ZvT4VUdkiqfLltyikm1o2pMCQdIlVe8j8X8ASMhh9OoDq6hsNwJ+kbS YEk4RZikWDVFiA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=8YggcmLmk57ZVCy7jwAasU8PNk5A4 Nck0HBaDdbL2bA=; b=H1GjwjHpXU59tO/9HCwn0BdzkjgwgMFeYW7A8aJERUXZ2 sVQFA/tPcJ9pFbRF0gIKEVZAFCLS9Un3HOCjQh13ouhOC+zXtboYydSHNHZ0jFs3 BzVqN6pI8ie5FmjLFY7KfMt4TzTHPkXZfmnocmNuuCk/2FGfYzF3DI9Xk3Pf9smR Dy7Wi55Ufnat6fQfmg+rvJwOqg2yo7IrVlmmNGvxl+vRx2LyFWrTunpTRgeuS6UN qxfYvbuvojNqSBc7OqqjAdxbQ3f205rcv+KaMViv6Bu2u541jU8HzkxQZcgQrrxd T1tZB2Da/RJyLtvV7FhayqWT0jUZF239N3q3rPqhQ== X-ME-Sender: Received: from rtp-vpn5-983.cisco.com (unknown [173.38.117.76]) by mail.messagingengine.com (Postfix) with ESMTPA id 154E424404; Wed, 7 Feb 2018 17:08:52 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_84AD1DCF-268E-4A7D-8267-FCD29EC2BB7B" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: Date: Wed, 7 Feb 2018 17:08:50 -0500 Cc: "gen-art@ietf.org Review Team" , draft-ietf-tls-dnssec-chain-extension.all@ietf.org, TLS WG Message-Id: <6E7803A9-D78A-4078-BA09-4A48C7A0612E@cooperw.in> References: <151796675979.25928.2038193051971303546@ietfa.amsl.com> To: Shumon Huque , Matthew Miller X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] [Gen-art] Genart telechat review of draft-ietf-tls-dnssec-chain-extension-06 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 22:08:55 -0000 --Apple-Mail=_84AD1DCF-268E-4A7D-8267-FCD29EC2BB7B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Matt, thanks for your review. Shumon, thanks for your response. I have = entered a No Objection ballot. Alissa > On Feb 6, 2018, at 11:31 PM, Shumon Huque wrote: >=20 > On Tue, Feb 6, 2018 at 8:25 PM, Matthew Miller = > wrote: > Reviewer: Matthew Miller > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at >=20 > >. >=20 > Document: draft-ietf-tls-dnssec-chain-extension-06 > Reviewer: Matthew A. Miller > Review Date: 2018-02-06 > IETF LC End Date: 2018-02-07 > IESG Telechat date: 2018-02-08 >=20 > Summary: >=20 > This document is ready, with one issue that I think could benefit > from some clarification. >=20 > Major issues: >=20 > NONE >=20 > Minor issue: >=20 > This is more a question, that might warrant some clarification: > In 7. Verification, the last paragraph discusses client-side > caching of the RRsets. If a client has cached the full RRset chain > from TLSA to root RRSIG (and that cache is still viable), is the > client still expected to specify the "dnssec_chain" extension? >=20 > In my reading, that does not seem necessary, and I think it might > be worth noting if that is true. >=20 > Yes, if the client has cached either the validated TLSA RRset or the=20= > full chain, then it doesn't need to send the dnssec_chain for = subsequent > connections. >=20 > If it has only cached other portions of the chain, then it needs to.=20= >=20 > We can clarify this. >=20 > Shumon Huque >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --Apple-Mail=_84AD1DCF-268E-4A7D-8267-FCD29EC2BB7B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Matt, thanks for your review. Shumon, thanks = for your response. I have entered a No Objection ballot.

Alissa

On = Feb 6, 2018, at 11:31 PM, Shumon Huque <shuque@gmail.com> = wrote:

On Tue, Feb 6, 2018 at 8:25 PM, Matthew Miller = <linuxwolf+ietf@outer-planes.net> wrote:
Reviewer: Matthew = Miller
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-tls-dnssec-chain-extension-06
Reviewer: Matthew A. Miller
Review Date: 2018-02-06
IETF LC End Date: 2018-02-07
IESG Telechat date: 2018-02-08

Summary:

This document is ready, with one issue that I think could benefit
from some clarification.

Major issues:

NONE

Minor issue:

This is more a question, that might warrant some clarification:
In 7. Verification, the last paragraph discusses client-side
caching of the RRsets. If a client has cached the full RRset chain
from TLSA to root RRSIG (and that cache is still viable), is the
client still expected to specify the "dnssec_chain" extension?

In my reading, that does not seem necessary, and I think it might
be worth noting if that is true.

Yes, if the client has = cached either the validated TLSA RRset or the 
full chain, then it doesn't need to send the dnssec_chain for = subsequent
connections.

If it has only cached other portions of = the chain, then it needs to. 

We can clarify this.

Shumon Huque

_______________________________________________
Gen-art = mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

= --Apple-Mail=_84AD1DCF-268E-4A7D-8267-FCD29EC2BB7B-- From nobody Wed Feb 7 15:22:28 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6442E124207; Wed, 7 Feb 2018 15:22:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-tls-dnssec-chain-extension@ietf.org, Joseph Salowey , shuque@gmail.com, tls-chairs@ietf.org, joe@salowey.net, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151804574240.17212.10913434710504079523.idtracker@ietfa.amsl.com> Date: Wed, 07 Feb 2018 15:22:22 -0800 Archived-At: Subject: [TLS] Ben Campbell's Yes on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 23:22:22 -0000 Ben Campbell has entered the following ballot position for draft-ietf-tls-dnssec-chain-extension-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am happy to see this published, but have a few minor comments: - I agree with Alexey's comments. -3.4: "If the TLSA record set was synthesized by a DNS wildcard, the chain must include the signed NSEC or NSEC3 records that prove that there was no explicit match of the TLSA record name and no closer wildcard match." Should that "must" be a "MUST"? - Nit in Authors List: Unless I've missed something, Richard's affiliation is no longer current. (I only point it out in case it's an oversight; I have no objection if it's that way on purpose.) From nobody Wed Feb 7 18:05:33 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9928128C0A; Wed, 7 Feb 2018 18:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 g61HQfCXra05; Wed, 7 Feb 2018 18:05:24 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A48A1129C5D; Wed, 7 Feb 2018 18:05:15 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id l17so4185863ioc.3; Wed, 07 Feb 2018 18:05:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TiO/4FhdEWZp4jZ+Yc5S8eqdnrvvZgaC8okg+6zmhGI=; b=P4ybRZRNAA0Q9kt8yNXehY0ztTE/G02UxfQ2PQsDEvLye4amUHPlcXldMzcc1uSTY0 rX5EL3pNBQV34KB3eAjpqoOJDhYWE7dbWtF//3rqMh484/AZdCUGa+fQQUuo6pUEhT8A a2ORecZSzJQqovRIH3vPveq1FCeXkqhD8U4ZS2DNyNsQN3XMn4SAgks1iH5mJ/X4irk3 wJAWTcrMbOWh4Q5XFcjXv9mph9MfAVXG5keRc+322LzZYXyC9/8VAlAJrDaLPj6EsiD5 Vftyd9aSnlFVKJZdrMjsqX99FtoCfUmk7lDcvj1oCPZhiQKXI/gEKcMc/R9zE1Z45pOa xgsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TiO/4FhdEWZp4jZ+Yc5S8eqdnrvvZgaC8okg+6zmhGI=; b=IMmKYXzq6fzQS00upgvzxw6NR88FaYq9B6CC1tJwnw3h/qT8D/1HuUPcEgPiUqb4lK a1+nRmsmvk93GRFIFG0CELaCARIOssXF/m89qAfK6jrOPD5aXgnWMAH6Gt+YUJbc6lSb DtFaU1/F7GZAbvj21D1Bb4urWiVg4Bhvl/Th0SMgG7gPL9ZfLZ7rUhPKcvbxg7yNwLcE SlKe5AlPE/+mVBfVxMLLRk3yl4iTFk5Bg27FygaArhF2wVLQhXG6+0hBE+efOhrw7KgO AHg6+LvMikae2Psj/byPnSDcaTEoRsIu9ZReCDUE0vM9D+57u3td7N8YXgsK+zJ1VFdw 9hiw== X-Gm-Message-State: APf1xPD6yyjtFLsBuvr81qrpwbcO+NGO7YvD0IQiTp6TVIjuRTGEhxm3 C4oLk/5jH/HWcqUeaGdm5wsERlFBOu2K9401y8E= X-Google-Smtp-Source: AH8x224ukVzTGBDP2pysMTIQ4CFjzg3izboYyglw9LUvTtP0lQCx058thzc/uniYkuWl80Gu4bvfjsml2KVbHhRjNfU= X-Received: by 10.107.53.213 with SMTP id k82mr9813144ioo.170.1518055514996; Wed, 07 Feb 2018 18:05:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.201.198 with HTTP; Wed, 7 Feb 2018 18:05:14 -0800 (PST) In-Reply-To: <151802776446.4849.12008167318274714913.idtracker@ietfa.amsl.com> References: <151802776446.4849.12008167318274714913.idtracker@ietfa.amsl.com> From: Shumon Huque Date: Wed, 7 Feb 2018 21:05:14 -0500 Message-ID: To: Alexey Melnikov Cc: The IESG , draft-ietf-tls-dnssec-chain-extension@ietf.org, Joseph Salowey , tls-chairs@ietf.org, TLS WG Content-Type: multipart/alternative; boundary="001a1144a1a6b886910564a9d734" Archived-At: Subject: Re: [TLS] Alexey Melnikov's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 02:05:29 -0000 --001a1144a1a6b886910564a9d734 Content-Type: text/plain; charset="UTF-8" On Wed, Feb 7, 2018 at 1:22 PM, Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-tls-dnssec-chain-extension-06: Discuss > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I think this is a useful document and I will ballot Yes once my small > issues are resolved: > > 1) In 3.4: > > The first RRset in the chain MUST contain the TLSA record set being > presented. However, if the owner name of the TLSA record set is an > alias (CNAME or DNAME), then it MUST be preceded by the chain of > alias records needed to resolve it. DNAME chains should omit > > SHOULD? What are the implications if this is not followed? > Ok. I guess we need the upper case word here, yes. Implication: If the synthesized CNAME records are included in the chain then the client will have to ignore them (they aren't signed and thus can't be validated) - the signed DNAME record is sufficient for the client to securely validate the mapping and continue processing. It might make things simpler to just make this a MUST. I would guess this would not raise any objections from the working group. > unsigned CNAME records that may have been synthesized in the response > from a DNS resolver. > > 2) TLS 1.3 needs to be a normative reference, but it is not even listed in > References. > Ok, we will add it. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The first mention of NSEC3 need a normative reference. > Yup, will do [RFC 5155] Shumon Huque --001a1144a1a6b886910564a9d734 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 7, 2018 at 1:22 PM, Alexey Melnikov <aamelnikov@fastmail.fm= > wrote:
Alexey Melnikov ha= s entered the following ballot position for
draft-ietf-tls-dnssec-chain-extension-06: Discuss

-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

I think this is a useful document and I will ballot Yes once my small issue= s are resolved:

1) In 3.4:

=C2=A0 =C2=A0The first RRset in the chain MUST contain the TLSA record set = being
=C2=A0 =C2=A0presented.=C2=A0 However, if the owner name of the TLSA record= set is an
=C2=A0 =C2=A0alias (CNAME or DNAME), then it MUST be preceded by the chain = of
=C2=A0 =C2=A0alias records needed to resolve it.=C2=A0 DNAME chains should = omit

SHOULD? What are the implications if this is not followed?
=

Ok. I guess we need the upper case word here, yes.

Implication: If the synthesized CNAME records are incl= uded in the chain
then the client will have to ignore them (they = aren't signed and thus can't be=C2=A0
validated) - the si= gned DNAME record is sufficient for the client to securely=C2=A0
= validate the mapping and continue processing.

It m= ight make things simpler to just make this a MUST. I would guess this
=
would not raise any objections from the working group.

<= /div>

=C2=A0 =C2=A0unsigned CNAME records that may have been synthesized in the r= esponse
=C2=A0 =C2=A0from a DNS resolver.

2) TLS 1.3 needs to be a normative reference, but it is not even listed in = References.

Ok, we will add it.


-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

The first mention of NSEC3 need a normative reference.

Yup, will do [RFC 5155]

Shumon Huq= ue

--001a1144a1a6b886910564a9d734-- From nobody Wed Feb 7 18:09:16 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5696128954; Wed, 7 Feb 2018 18:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 fvRP_7XkyqaO; Wed, 7 Feb 2018 18:09:12 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D9A0124B18; Wed, 7 Feb 2018 18:09:12 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id z6so4165599iob.11; Wed, 07 Feb 2018 18:09:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aeOYvn2HZdAaqA38yxsPDMG/nyMgMwY1mh61vDzKEQ0=; b=XKXBMy4b5+NpxzNnHPFzFbJQz7qw8Hal3HRtdX5+AUNH6OXsvocrhu37myXoY/+rs+ gOsucDB/TAQ46572AaQk2f1mY0c2AUFlks9pWzR5JNBJwNVN61MN0eC4YX0n/ATSA4LS 4Qbtgx5u7TerBZ+nfwX6eulMs0zDVR8I6IxQ2m4kEnei5pnHa44vJMcRaeMjcW5pOjGX OCb9hsRpX6tZuAckpKsP8GikMi4iWKu+rE1H3XXUTihB7l2dd46hBWaZDMNlsLu6ntas BBLjl0GyUlyIr0pL7nXv7wqOghE+0Lw3jz2XFjgUL55Hj5Twd865jd0PsEouqBF04zxh ZprA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aeOYvn2HZdAaqA38yxsPDMG/nyMgMwY1mh61vDzKEQ0=; b=qddOV1C1Nnymccy9+LPyAk+Elyw7TX6Z7xmApq2ag49pYibmosaWbHCsop8f5tvHhw xEvYIhoMvQ7wr61yI9SfkSAURTq6flXuMMCL52sEdt9YvjnMeYYlrKTPMDS1TKckIdEY +zU7dPq/b3YvcIHTR/OlryxRwgkcSvF2KnBGOhSVbtcj3rwi6cfiXbSxh2c1ld0hgivX ndJpSfxmqrhBXI+J2aoLgLgWwKfFwqpM5AzuXTNkvSpXhwaTR0Capp6iL/NwwKsOv9qW LOge4g4AgHPPR6G6X6lu+FHSU4DbtPzGocZP3a6s0i47nrKqTeGxlIEF3lRf1xOkQwms Yelw== X-Gm-Message-State: APf1xPDZFzTlX3HGw5oKfwgqfJMEIqGI340LqVrRrz9OoUYQWBazAA9V B+2nTxxJc6H8ELOqmJJoFWF93hkKq5HGdMgP5GA= X-Google-Smtp-Source: AH8x225thSQ+4kq3wdLwOvOVzsu+IwM/xs+dOnpB/968/BD9DQBLMFkv4fPD2jkVfcatA3I4K4QYo2BnXOfxkQhG+zI= X-Received: by 10.107.89.11 with SMTP id n11mr10411308iob.154.1518055751723; Wed, 07 Feb 2018 18:09:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.201.198 with HTTP; Wed, 7 Feb 2018 18:09:11 -0800 (PST) In-Reply-To: <151804574240.17212.10913434710504079523.idtracker@ietfa.amsl.com> References: <151804574240.17212.10913434710504079523.idtracker@ietfa.amsl.com> From: Shumon Huque Date: Wed, 7 Feb 2018 21:09:11 -0500 Message-ID: To: Ben Campbell Cc: The IESG , draft-ietf-tls-dnssec-chain-extension@ietf.org, Joseph Salowey , tls-chairs@ietf.org, TLS WG Content-Type: multipart/alternative; boundary="f4f5e8067198d4b0a30564a9e501" Archived-At: Subject: Re: [TLS] Ben Campbell's Yes on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 02:09:14 -0000 --f4f5e8067198d4b0a30564a9e501 Content-Type: text/plain; charset="UTF-8" On Wed, Feb 7, 2018 at 6:22 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-tls-dnssec-chain-extension-06: Yes > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I am happy to see this published, but have a few minor comments: > > - I agree with Alexey's comments. > Yup, addressed previously in email .. > > -3.4: "If the TLSA record set was synthesized by a DNS wildcard, the chain > must include the signed NSEC or NSEC3 records that prove that there > was no explicit match of the TLSA record name and no closer wildcard > match." > > Should that "must" be a "MUST"? > Yes, thanks for catching that. > > - Nit in Authors List: Unless I've missed something, Richard's affiliation > is > no longer current. (I only point it out in case it's an oversight; I have > no > objection if it's that way on purpose.) > I'll let Richard chime in .. Shumon --f4f5e8067198d4b0a30564a9e501 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 7, 2018 at 6:22 PM, Ben Campbell <ben@nostrum.com> wro= te:
Ben Campbell has entered the followin= g ballot position for
draft-ietf-tls-dnssec-chain-extension-06: Yes

-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

I am happy to see this published, but have a few minor comments:

- I agree with Alexey's comments.

Y= up, addressed previously in email ..
=C2=A0

-3.4: "If the TLSA record set was synthesized by a DNS wildcard, the c= hain
=C2=A0 =C2=A0must include the signed NSEC or NSEC3 records that prove that = there
=C2=A0 =C2=A0was no explicit match of the TLSA record name and no closer wi= ldcard
=C2=A0 =C2=A0match."

Should that "must" be a "MUST"?
Yes, thanks for catching that.
=C2=A0

- Nit in Authors List: Unless I've missed something, Richard's affi= liation is
no longer current. (I only point it out in case it's an oversight; I ha= ve no
objection if it's that way on purpose.)

=
I'll let Richard chime in ..

Shumon
=

--f4f5e8067198d4b0a30564a9e501-- From nobody Wed Feb 7 18:27:54 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA9F127978; Wed, 7 Feb 2018 18:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 5nFiPL0eUNaf; Wed, 7 Feb 2018 18:27:45 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6595124B18; Wed, 7 Feb 2018 18:27:45 -0800 (PST) Received: by mail-io0-x22a.google.com with SMTP id l17so4228711ioc.3; Wed, 07 Feb 2018 18:27:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JwB+BzkZsmBb6Ie3hcrL0pgL7fHkDQqv4QtlQgiTM20=; b=bxYa9GO54ZMVpNXfokrY+NP3WYKm8NMtpei7BLkLxUP56BaByvzT/MZGofLbKL/Lqs ozzWwjynvBXlsUffgDF+QLjM+4XvNH1BvYgXIsPV2LuRnA3hwMWom2fdl3hMaGCVK4fB OHSY/4xJNQQxpF0AEppPv1tIt5AfsMoTctF6+9ZPUhnSXndmit4OPxh571N1FjsNOdiw 0aEt0hbTTZXqErUetFI/4NFSqFVnSczB6xUCZU6E10cnH6XMCRtUwo/VH/fZEqYF9AxU fMeR84oUxJDyYOL6aDHEh+3AQP3OuSGCWnMFNYBCXJs3XRNjUhHnmnUZ6i30K8TJF2ix CZjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JwB+BzkZsmBb6Ie3hcrL0pgL7fHkDQqv4QtlQgiTM20=; b=h7azbj9L31SqKBwYFeY24bYdDw+77Pc23gmbOoN221O+VjUXV67p0CJySlpXjNTb/X Atl7Amh6qjjLGa+ij5KbIceg4UFJTy2G7h+N0w7uBM2WQYOsBmyFf+dFJmcjZOoBRwjl mHZiD2jpNUARCtP01uv1NmwTNVdAGU9fOxEv0EsGAn1r3X8aDdT2AWWuWB3HEj6VrIqq vKeqRCCj7Z1UvNl7g29jZc/lOWsGAweNaLwYymAZE/CdnkW9dg4Y+aDvFH39jJsC24Sc 4sAWEsWGpw1M+pGDZwFTCGHgikm4s5inGbjK+FZXtn9eH1QqTLWSCRi5E5tGzDgg6UOY bO7g== X-Gm-Message-State: APf1xPCqlXzZU40WbO9HSrsnSDvUr/0/yPDHwfRfWfKTFmYH+xq1IwdO K1AahS0ZyTfjCPFmp28SbPCKwIhxc5N3802vC1w= X-Google-Smtp-Source: AH8x226oqdTthT4tDTlyu/MTBWfLaXaa/c2uKIeP1uKMoSiyrwUON507vphgYyANKpuPwg24pHk5yMUabN/1XmsBZvU= X-Received: by 10.107.8.148 with SMTP id h20mr10278419ioi.204.1518056865024; Wed, 07 Feb 2018 18:27:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.201.198 with HTTP; Wed, 7 Feb 2018 18:27:44 -0800 (PST) In-Reply-To: <151800968634.4877.12510609339415982154.idtracker@ietfa.amsl.com> References: <151800968634.4877.12510609339415982154.idtracker@ietfa.amsl.com> From: Shumon Huque Date: Wed, 7 Feb 2018 21:27:44 -0500 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: The IESG , draft-ietf-tls-dnssec-chain-extension@ietf.org, Joseph Salowey , tls-chairs@ietf.org, TLS WG Content-Type: multipart/alternative; boundary="001a113f987e30516a0564aa288f" Archived-At: Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-dnssec-chain-extension-06=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 02:27:47 -0000 --001a113f987e30516a0564aa288f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 7, 2018 at 8:21 AM, Mirja K=C3=BChlewind = wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-tls-dnssec-chain-extension-06: No Objection > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Two minor, mostly editorial comments: > > 1) Intro (sec 2): " It also provides the > ability to avoid potential problems with TLS clients being unable to > look up DANE records because of an interfering or broken middlebox on > the path between the client and a DNS server." > Is that actually a well-known problem (can you provide a reference?) Some folks (at Google and NLnet Labs if I recall; maybe others) have done measurements to show this is an actual problem -- for a relatively small bu= t still non-trivial fraction of clients. We'll try to see if we can dig up specific references to documents that could be cited. or would > it be enough to say something like this: " It also provides the > ability to avoid potential problems with TLS clients being unable to > look up DANE records when DNS server is not reachable." > Your rewording of this sentence would unfortunately not be accurate. It's usually not the DNS server that is unreachable, but that some middlebo= x has done something wrong, such as: not allow DANE queries or responses through; not allow DNSSEC signatures through; not allow EDNS options that enable DNSSEC through, or engage in other misbehavior. > 2) IANA Considerations should probably be updated. > I guess you are suggesting that the last sentence is probably obsolete: "If the draft is adopted by the WG, the authors expect to make an early allocation request as specified in [RFC7120]." Agreed. It's a little late for that! :-) We will remove it. Shumon Huque --001a113f987e30516a0564aa288f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 7, 2018 at 8:21 AM, Mirja K=C3=BChlewind <ietf@kuehlewind.net> wrote:
Mi= rja K=C3=BChlewind has entered the following ballot position for
draft-ietf-tls-dnssec-chain-extension-06: No Objection

-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

Two minor, mostly editorial comments:

1) Intro (sec 2): " It also provides the
=C2=A0 =C2=A0ability to avoid potential problems with TLS clients being una= ble to
=C2=A0 =C2=A0look up DANE records because of an interfering or broken middl= ebox on
=C2=A0 =C2=A0the path between the client and a DNS server."
Is that actually a well-known problem (can you provide a reference?)

Some folks (at Google and NLnet Labs if I recall;= maybe others) have done
measurements to show this is an actual p= roblem -- for a relatively small but
still non-trivial fraction o= f clients. We'll try to see if we can dig up specific
referen= ces to documents that could be cited.

or would
it be enough to say something like this: " It also provides the
=C2=A0 =C2=A0ability to avoid potential problems with TLS clients being una= ble to
=C2=A0 =C2=A0look up DANE records when DNS server is not reachable."

Your rewording of this sentence would un= fortunately not be accurate.
It's usually not the DNS server = that is unreachable, but that some middlebox
has done something w= rong, such as: not allow DANE queries or responses=C2=A0
through;= not allow DNSSEC signatures through; not allow EDNS options
that= enable DNSSEC through, or engage in other misbehavior.


2) IANA Considerations should probably be updated.
I guess you are suggesting that the last sentence is probably o= bsolete:

=C2=A0 =C2=A0 "If the draft is adopt= ed by the WG, the authors expect to make an
=C2=A0 =C2=A0 =C2=A0e= arly allocation request as specified in [RFC7120]."

Agreed. It's a little late for that! :-)

We will remove it.

Shumon Huque

--001a113f987e30516a0564aa288f-- From nobody Thu Feb 8 01:51:37 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220D312D88A; Thu, 8 Feb 2018 01:51:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 LTv2ZkhQBYLl; Thu, 8 Feb 2018 01:51:30 -0800 (PST) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (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 A79DB1250B8; Thu, 8 Feb 2018 01:51:29 -0800 (PST) Received: from [IPv6:2a04:b900:0:1:411c:86ef:6e38:d3a6] (unknown [IPv6:2a04:b900:0:1:411c:86ef:6e38:d3a6]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id A9BBE8EBE; Thu, 8 Feb 2018 10:51:27 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1518083487; bh=uvBOKUmlpntVnQ4EK5YFgOU43i0oJFJwYbz8/MunPgE=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=XYw+y/4bqtKKbQR8/PMizwAZnwZOHO06jf9LfbYugL6UeF9eSEkbhWoIwlw4+Jx+3 6y4MqYX5CZw4WEGPROZ08bIg6nQ6Eup5kclpetZ/QDxZ71CgAscbU3H/7wBrZatmrJ r9hlK+pz2EjW6bEIdt55QAcUZH+GTJiM43GVZJ4c= To: Shumon Huque , =?UTF-8?Q?Mirja_K=c3=bchlewind?= Cc: The IESG , draft-ietf-tls-dnssec-chain-extension@ietf.org, Joseph Salowey , tls-chairs@ietf.org, TLS WG References: <151800968634.4877.12510609339415982154.idtracker@ietfa.amsl.com> From: Willem Toorop Message-ID: <4c90bb83-5ba1-8193-df67-38e25f76caf8@nlnetlabs.nl> Date: Thu, 8 Feb 2018 10:51:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-dnssec-chain-extension-06=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 09:51:33 -0000 Op 08-02-18 om 03:27 schreef Shumon Huque: > On Wed, Feb 7, 2018 at 8:21 AM, Mirja Kühlewind > wrote: > > Mirja Kühlewind has entered the following ballot position for > draft-ietf-tls-dnssec-chain-extension-06: No Objection > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Two minor, mostly editorial comments: > > 1) Intro (sec 2): " It also provides the >    ability to avoid potential problems with TLS clients being unable to >    look up DANE records because of an interfering or broken middlebox on >    the path between the client and a DNS server." > Is that actually a well-known problem (can you provide a reference?) > > > Some folks (at Google and NLnet Labs if I recall; maybe others) have done > measurements to show this is an actual problem -- for a relatively small but > still non-trivial fraction of clients. We'll try to see if we can dig up > specific > references to documents that could be cited. I wouldn't call it a relatively small fraction :) DNSSEC is severely hampered for end-entities by broken infrastructure in many different ways. Sometimes an upstream resolver can be used for positive DNSSEC answers (i.e. existing records), but not for non-existent or wildcard answers, because it simply doesn't forward the NSEC(3) proof for it. The last measurements we at NLnet Labs did was in July 2015: Gorjón, Xavier Torrent, and Willem Toorop. "Discovery method for a DNSSEC validating stub resolver." (2015) https://nlnetlabs.nl/pub/os3-2015-rp2-xavier-torrent-gorjon.pdf Measurements were done with RIPE Atlas, with at the time +-8200 probes. At the time only 56% of probes received enough DNSSEC data from their upstreams to be able to perform DNSSEC validation for both positive and non-existent answers (required for DANE). There is a RFC that outlines detection and mitigation techniques on how to deal with this from DNSSEC validation stub resolvers: RFC8027 - DNSSEC Roadblock Avoidance Ultimately such a stub resolver has to be able to fallback to full recursive resolving (i.e. iterating from the root). Although even that might fail... Furthermore, hampered DNS (but not specifically DNSSEC), is the primary motivation for the new DNS over HTTPS draft (and workgroup): https://tools.ietf.org/html/draft-ietf-doh-dns-over-https (DoH might be the ultimate final fallback in DNSSEC Roadblock Avoidance) > > or would > it be enough to say something like this: " It also provides the >    ability to avoid potential problems with TLS clients being unable to >    look up DANE records when DNS server is not reachable." > > > Your rewording of this sentence would unfortunately not be accurate. > It's usually not the DNS server that is unreachable, but that some middlebox > has done something wrong, such as: not allow DANE queries or responses  > through; not allow DNSSEC signatures through; not allow EDNS options > that enable DNSSEC through, or engage in other misbehavior. > > > 2) IANA Considerations should probably be updated. > > > I guess you are suggesting that the last sentence is probably obsolete: > >     "If the draft is adopted by the WG, the authors expect to make an >      early allocation request as specified in [RFC7120]." > > Agreed. It's a little late for that! :-) > > We will remove it. > > Shumon Huque > From nobody Thu Feb 8 06:18:50 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E03B12DA05; Thu, 8 Feb 2018 06:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 5T8MMzvm9sSI; Thu, 8 Feb 2018 06:18:41 -0800 (PST) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2A6112DA18; Thu, 8 Feb 2018 06:18:37 -0800 (PST) Received: by mail-it0-x232.google.com with SMTP id j21-v6so18140441ita.1; Thu, 08 Feb 2018 06:18:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1jRJJ10fFmTvRzguQCGmhZ9UF9oOrbvckqIx11Y4fQI=; b=QEjUwM3GdE8fUdeteVFcXUxNViILwYpkseC/PwsPEUa9mzWoMUmx9RbFPu48kUviMy TCn+W+fIYFEH2u1K+r8FajFUi/jbFmpll5dvSIl9OJv5jhN4R7P6RQ/T5Nh6P6MmUHVK +5uIRi2fDddY/WbTRPITlzNML+PScj+VmmBF8PI9WpRxvD5Ip+23opSVWqSZho+Fd0ba z6fMzgb2k/j74EuI2GtHOUg7/odHsQ9RBQvORzXApkhXurCWHeevhbs9LDEYvTuMr0GN /6Bci/ciWS6knNT8Ujsu73wzpBpIA35vG2M/XDR5l5sXkmWTBpH2rDPoJHgzDUob56kj ZMHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1jRJJ10fFmTvRzguQCGmhZ9UF9oOrbvckqIx11Y4fQI=; b=cPA5FuZVk3NbcYgfM91Lz2O06HF65r0dZB+xBphCJhVuhllgOjGB4SwdZvjWfLo3Nm +wheKiKuDS93htkYJoX4xbqcjHUrOAjnDcdBETQrd/2kxb0xIVztcdmx16L8HBoEU5l4 i30bLz8XpNs7+XBS9vdLZWFn8NQU8PD0PV/4Y6ADtHX9Aoni+zleRsxJI+yEEo8ERhrB VYWu5Glm6icpg8ofiVSkKQCRVJKfACPKTr1ckiWs9dpTT8aXgONqwFUBuSGuSJBMxfoM p2YBDb/mrnUQe/Ig16rW+E6jcI5i2niW+1nCt/Da+PY1duueLE08nuZFXekHbl4L4LC7 NDzA== X-Gm-Message-State: APf1xPAvD0mqe2lSWfWVYAMtY5IZm48ZYzk+1o62+N2lxX3mXXmE8CVa TeQf0RGufrumtPUucVAw9S2yYYfiqofXO6C2eqoE/R7S X-Google-Smtp-Source: AH8x226faSd7o3Sv/1SEovK5dgkvWx2j1jxxDXYea5rqy3g+sxAWRY8pdD/zJa7dCuD5LsdZkai/b8igcM+ORVQ2gVY= X-Received: by 10.36.73.77 with SMTP id z74mr1686230ita.72.1518099517055; Thu, 08 Feb 2018 06:18:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.201.198 with HTTP; Thu, 8 Feb 2018 06:18:36 -0800 (PST) In-Reply-To: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com> References: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com> From: Shumon Huque Date: Thu, 8 Feb 2018 09:18:36 -0500 Message-ID: To: Eric Rescorla Cc: The IESG , draft-ietf-tls-dnssec-chain-extension@ietf.org, Joseph Salowey , tls-chairs@ietf.org, TLS WG Content-Type: multipart/alternative; boundary="001a11c145d072a6f20564b416de" Archived-At: Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 14:18:47 -0000 --001a11c145d072a6f20564b416de Content-Type: text/plain; charset="UTF-8" On Wed, Feb 7, 2018 at 9:34 AM, Eric Rescorla wrote: > Eric Rescorla has entered the following ballot position for > draft-ietf-tls-dnssec-chain-extension-06: Discuss > Thanks Eric for your detailed review and comments. > This draft seems generally sound, but I believe there are pieces that > are still underspecified. These should be easy to fix. > > the Signer's Name field in canonical form and the signature field > excluded. > > IMPORTANT: I'm not sure that this is actually sufficient to allow an > independent implementation without referring to the other documents. I > mean, I think I pretty clearly can't validate this chain from the > above. We could add an explicit reference here to the DNS protocol document(s) and sections within them that define the canonical form of domain names (RFC 4034, Section 6 probably is the best reference), or even excerpt the relevant text from that document. Would this satisfy your concern? We deliberately didn't include in this document a detailed description of the DNSSEC validation algorithm. The algorithm is sufficiently complicated (and lengthy to describe) that those details are best left to the relevant DNSSEC RFCs. I think it would be helpful to point specifically to which documents and sections here though (mainly RFC 4035 Section 5, and RFC 5155 Section 8). We could also include a brief synopsis of the algorithm and refer to these documents for further details. Otherwise, can you suggest more specifically what level of additional detail you'd like to see in this document? > Similarly, although I think this is enough to break apart the > RRSETs into RRs, it doesn't tell me how to separate the RRSETs from > each other. I think you need to either make this a lot more complete > or alternately stop saying it's sufficient. We can add some text about this. Basically the client would scan the chain reading RRs and group adjacent RRs that share the same RR name, type, and class into a distinct RRset. > > abort the connection, the server uses the domain name associated with > the server IP address to which the connection has been established. > IMPORTANT: "the domain name" is not unambiguous. Hosts can have multiple names for the same IP. > Yes, indeed. This sentence is dealing with the case where the client has not indicated to the server which name it wants to connect to, so the server is basically guessing anyway. Perhaps we could reword this to say something like, "the server picks one of its configured domain names for the associated IP address". (This situation could also have been avoided by mandating client use of the SNI extension). > DNSSEC authentication chain extension from a server, SHOULD use this > information to perform DANE authentication of the server. In order > to do this, it uses the mechanism specified by the DNSSEC protocol > > IMPORTANT: What happens if the DANE validates but the cert is revoked > or alternately the cert validates but DANE does not? This depends on the mode of DANE in use (i.e. the Certificate Usage field of the TLSA record). If I recall correctly, this should all be covered in detail in RFC 7671 ("DANE Updates and Operational Guidance"). * With DANE-EE, only the EE certificate is matched against the certificate data/hash in the TLSA record. There is no CRL/OCSP style revocation. Revocation would be performed by removing the TLSA record from the DNS. * With DANE-TA, the indicated CA certificate referenced in the TLSA record may have advertised revocation mechanisms that need to be consulted. * With PKIX-EE and PKIX-TA modes, the standard PKIX revocation mechanisms need to be consulted and honored. Would you like us to discuss this in the draft? Or is referring to RFC 7671 sufficient? On your last case, "cert validates but DANE does not", I assume you mean the cert validates via PKIX but not DANE? I'm not sure this is explicitly discussed in any other DANE document but presumably if DANE is being used, DANE must validate. I suppose individual application protocols could specify a fallback mode where the client could fallback to normal PKIX if DANE failed. On a related note, I believe most envisioned use cases of this draft will be for the DANE-* modes. The PKIX constraining modes have the issue that for them to work securely, the client must be able to confirm the presence of DANE records, which leads to the issues of how to mandate use of this mechanism (Section 8 of this document). > [RFC4035] [RFC5155]. This mechanism is sometimes implemented in a > DNSSEC validation engine or library. > IMPORTANT: shouldn't it be a requirement to perform this validation? Your question I assume is about the sentence preceding this: "A TLS client making use of this specification, and which receives a DNSSEC authentication chain extension from a server, SHOULD use this information to perform DANE authentication of the server." Yes, I think I agree. If the client is using this spec, then presumably it intends to use DANE if available. So this should be a "MUST". > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > > typically not be used for general DNSSEC validation of TLS endpoint > names. > Can you rephrase this. I *think* it means "it's not used to validate the A/AAAA > lookup"...? Yes, that makes it clearer (and is it what it means). We'll reword. > > validation of endpoint names, but is more appropriate for validation > of DANE TLSA records. > Same comment as abive > Ok. > This mechanism is useful for TLS applications that need to address > the problems described above, typically web browsers or VoIP and XMPP > applications. It may not be relevant for many other applications. > Nit; cites to SIP/XMPP appropriate here, Ok. > > ClientHello message that the DNS authentication chain be returned in > the (extended) ServerHello message. If the server is configured for > DANE authentication, then it performs the appropriate DNS queries, > This is not correct for TLS 1.3. Right, this text predated TLS1.3 .. The TLS version-specific protocol elements involved in delivering this extension are described in Section 3. For the Introduction section from which the above text is excerpted, I would suggest the following rewrite: The extension described here allows a TLS client to request that the TLS server return the DNSSEC authentication chain corresponding to its DANE record. If the server is configure for DANE ... > > 3.1. Protocol, TLS 1.2 > You should probably provide some guidance about whether the server should still > provide the whole X.509 chain to the client. I believe with these semantics, > the server cannot tell which DANE mode the client wants and therefore has to > provide the entire chain. Sure, we can elaborate. The DANE mode to be used is advertised by the server in its TLSA record(s), so the server already knows whether it needs to return the X.509 chain. If the TLSA RRset has only DANE-EE, then only the end-entity certificate needs to be returned. If DANE-TA, then only the chain from the TA cert to the EE needs to be returned. If using the PKIX modes, then yes, the entire X.509 chain has to be sent. > Servers receiving a "dnssec_chain" extension in the ClientHello, and > which are capable of being authenticated via DANE, MAY return a > serialized authentication chain in the extended ServerHello message, > Nit: I believe you want to remove the commas here, as they indicate a > nonrestrictive clause. Ok. > arbitrary domain names using this mechanism. Therefore, a server > MUST NOT construct chains for domain names other than its own. > "its own" is a bit fraught, as servers may not actually know all their domain > names, at least at the TLS layer.. Can you be more specific about what the > server algorithm is. To implement this specification, the TLS layer does need to have preconfigured knowledge of the names for which it has DANE records. This text is also a bit imprecise and should be improved anyway. The server doesn't construct chains for its own domain name, but rather the TLSA record name corresponding to that domain name. This domain name is either one explicitly indicated by the client via SNI (assuming that the indicated name is one the server recognizes as its own), or if no SNI is provided, one that the server picks from its known set of names (as discussed previously). The purpose of the MUST NOT sentence here is to prevent clients from using the TLS server to lookup arbitrary domain names. > > Servers receiving a "dnssec_chain" extension in the ClientHello, and > which are capable of being authenticated via DANE, SHOULD return a > serialized authentication chain in the extension block of the > Why is this a SHOULD where the corresponding reqt for TLS 1.2 and below is a > MAY? They should clearly be consistent. My preference would be "SHOULD" for both. > to a DNSSEC trust root. This has the added benefit of mitigating an > unknown key share attack, as described in [I-D.barnes-dane-uks], > since it effectively augments the raw public key with the server's > "unknown key share (UKS)" > > handshake, to a domain name which has been validated as belonging to > the owner name. > The key point here is that the commitment is bound to the EE key. Also, this > only really works for TLS 1.3 and modes with EMS because otherwise there are > other UKS attacks Ok, we will clarify this. > I think you probably want to cite SIGMA and triple handhshake here. Ok. > > opaque AuthenticationChain<0..2^16-1> > Is 0 actually appropriate here as a lower bound? Presumably at least one such > instance must be present? Yes, there should be a non-zero number of bytes in the extension data. So: opaque AuthenticationChain<1..2^16-1> > > RR(i) = owner | type | class | TTL | RDATA length | RDATA > I assume the notation here is "i is the ith RR"? Yes, we can mention that. > > Is there a reason not to describe this in TLS language? I think because the extension data contains only a sequence of DNS wire format RRs which are precisely defined in DNS documents, and we felt it was redundant to redefine them in another format. > > . DNSKEY > RRSIG(. DNSKEY) > How does this differ from the algorithm that you would use in response to the > TLSA query? Sorry, I don't follow your comment here. Differ from what? Can you elaborate? > > the draft is adopted by the WG, the authors expect to make an early > allocation request as specified in [RFC7120]. > Do you want this to be marked RECOMMENDED? In response to Mirja's earlier comment, I think we are taking out this sentence. Shumon Huque --001a11c145d072a6f20564b416de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 7, 2018 at 9:34 AM, Eric Rescorla <ekr@rtfm.com> wrote:
Eric Rescorla has enter= ed the following ballot position for
draft-ietf-tls-dnssec-chain-extension-06: Discuss

Thanks Eric for your detailed review and comments.

> This draft seems generally sound, but I believe t= here are pieces that
> are still underspecified. These should = be easy to fix.
>
> the Signer's Name field i= n canonical form and the signature field
>=C2=A0 =C2=A0 exclud= ed.
>
> IMPORTANT: I'm not sure that this is = actually sufficient to allow an
> independent implementation w= ithout referring to the other documents. I
> mean, I think I p= retty clearly can't validate this chain from the
> above.<= /div>

We could add an explicit reference here to the DNS= protocol document(s)
and sections within them that define the ca= nonical form of domain
names (RFC 4034, Section 6 probably is the= best reference), or even
excerpt the relevant text from that doc= ument. Would this satisfy your
concern?

= We deliberately didn't include in this document a detailed description<= /div>
of the DNSSEC validation algorithm. The algorithm is sufficiently=
complicated (and lengthy to describe) that those details are bes= t left
to the relevant DNSSEC RFCs. I think it would be helpful t= o point
specifically to which documents and sections here though = (mainly
RFC 4035 Section 5, and RFC 5155 Section 8). We could als= o include a
brief synopsis of the algorithm and refer to these do= cuments for
further details.

Otherwise, = can you suggest more specifically what level of additional
detail= you'd like to see in this document?

> Simi= larly, although I think this is enough to break apart the
> RR= SETs into RRs, it doesn't tell me how to separate the RRSETs from
=
> each other. I think you need to either make this a lot more compl= ete
> or alternately stop saying it's sufficient.

We can add some text about this. Basically the client woul= d scan the chain
reading RRs and group adjacent RRs that share th= e same RR name, type, and
class into a distinct RRset.
=
>
>=C2=A0 =C2=A0 abort the connection, the s= erver uses the domain name associated with
>=C2=A0 =C2=A0 the = server IP address to which the connection has been established.
&= gt; IMPORTANT: "the domain name" is not unambiguous. Hosts can ha= ve multiple names for the same IP.
>

= Yes, indeed. This sentence is dealing with the case where the client has
not indicated to the server which name it wants to connect to, so t= he
server is basically guessing anyway. Perhaps we could reword t= his to say
something like, "the server picks one of its conf= igured domain names for
the associated IP address".

(This situation could also have been avoided by mandating = client use of
the SNI extension).

>= =C2=A0 =C2=A0 DNSSEC authentication chain extension from a server, SHOULD u= se this
>=C2=A0 =C2=A0 information to perform DANE authenticat= ion of the server.=C2=A0 In order
>=C2=A0 =C2=A0 to do this, i= t uses the mechanism specified by the DNSSEC protocol
>
<= div>> IMPORTANT: What happens if the DANE validates but the cert is revo= ked
> or alternately the cert validates but DANE does not?

This depends on the mode of DANE in use (i.e. the Cer= tificate Usage
field of the TLSA record). If I recall correctly, = this should all be
covered in detail in RFC 7671 ("DANE Upda= tes and Operational Guidance").

* With DANE-E= E, only the EE certificate is matched against the
=C2=A0 certific= ate data/hash in the TLSA record. There is no CRL/OCSP
=C2=A0 sty= le revocation. Revocation would be performed by removing the
=C2= =A0 TLSA record from the DNS.

* With DANE-TA, the = indicated CA certificate referenced in the TLSA
=C2=A0 record may= have advertised revocation mechanisms that need to be
=C2=A0 con= sulted.

* With PKIX-EE and PKIX-TA modes, the stan= dard PKIX revocation mechanisms
=C2=A0 need to be consulted and h= onored.

Would you like us to discuss this in the d= raft? Or is referring to
RFC 7671 sufficient?

On your last case, "cert validates but DANE does not", I as= sume
you mean the cert validates via PKIX but not DANE? I'm n= ot sure this
is explicitly discussed in any other DANE document b= ut presumably
if DANE is being used, DANE must validate. I suppos= e individual
application protocols could specify a fallback mode = where the
client could fallback to normal PKIX if DANE failed.

On a related note, I believe most envisioned use cas= es of this draft
will be for the DANE-* modes. The PKIX constrain= ing modes have the
issue that for them to work securely, the clie= nt must be able to
confirm the presence of DANE records, which le= ads to the issues of how
to mandate use of this mechanism (Sectio= n 8 of this document).


> [RFC403= 5] [RFC5155].=C2=A0 This mechanism is sometimes implemented in a
= >=C2=A0 =C2=A0 DNSSEC validation engine or library.
> IMPOR= TANT: shouldn't it be a requirement to perform this validation?

Your question I assume is about the sentence preceding th= is:

=C2=A0 =C2=A0"A TLS client making use of = this specification, and which receives a
=C2=A0 =C2=A0DNSSEC auth= entication chain extension from a server, SHOULD use this
=C2=A0 = =C2=A0information to perform DANE authentication of the server."
=

Yes, I think I agree. If the client is using this spec,= then presumably
it intends to use DANE if available. So this sho= uld be a "MUST".


> ---= -------------------------------------------------------------------
> COMMENT:
> -------------------------------------------= ---------------------------
>
>
>
> typically not be used for general DNSSEC validation of TLS end= point
>=C2=A0 =C2=A0 names.
> Can you rephrase th= is. I *think* it means "it's not used to validate the A/AAAA
=
> lookup"...?

Yes, that makes it clea= rer (and is it what it means). We'll reword.

&= gt;
>=C2=A0 =C2=A0 validation of endpoint names, but is more a= ppropriate for validation
>=C2=A0 =C2=A0 of DANE TLSA records.=
> Same comment as abive
>

Ok.

>=C2=A0 =C2=A0 This mechanism is useful = for TLS applications that need to address
>=C2=A0 =C2=A0 the p= roblems described above, typically web browsers or VoIP and XMPP
= >=C2=A0 =C2=A0 applications.=C2=A0 It may not be relevant for many other= applications.
> Nit; cites to SIP/XMPP appropriate here,

Ok.

>
>=C2=A0= =C2=A0 ClientHello message that the DNS authentication chain be returned i= n
>=C2=A0 =C2=A0 the (extended) ServerHello message.=C2=A0 If = the server is configured for
>=C2=A0 =C2=A0 DANE authenticatio= n, then it performs the appropriate DNS queries,
> This is not= correct for TLS 1.3.

Right, this text predated TL= S1.3 ..

The TLS version-specific protocol elements= involved in delivering this
extension are described in Section 3= . For the Introduction section from
which the above text is excer= pted, I would suggest the following rewrite:

=C2= =A0 =C2=A0The extension described here allows a TLS client to request that<= /div>
=C2=A0 =C2=A0the TLS server return the DNSSEC authentication chai= n corresponding
=C2=A0 =C2=A0to its DANE record. If the server is= configure for DANE ...

>
> 3.1.= =C2=A0 Protocol, TLS 1.2
> You should probably provide some gu= idance about whether the server should still
> provide the who= le X.509 chain to the client. I believe with these semantics,
>= ; the server cannot tell which DANE mode the client wants and therefore has= to
> provide the entire chain.

Sure,= we can elaborate.

The DANE mode to be used is adv= ertised by the server in its TLSA record(s),
so the server alread= y knows whether it needs to return the X.509 chain.
If the TLSA R= Rset has only DANE-EE, then only the end-entity certificate
needs= to be returned. If DANE-TA, then only the chain from the TA cert to the=C2= =A0
EE needs to be returned. If using the PKIX modes, then yes, t= he entire X.509
chain has to be sent.

&g= t;=C2=A0 =C2=A0 Servers receiving a "dnssec_chain" extension in t= he ClientHello, and
>=C2=A0 =C2=A0 which are capable of being = authenticated via DANE, MAY return a
>=C2=A0 =C2=A0 serialized= authentication chain in the extended ServerHello message,
> N= it: I believe you want to remove the commas here, as they indicate a
<= div>> nonrestrictive clause.

Ok.

=
>=C2=A0 =C2=A0 arbitrary domain names using this mechanism.= =C2=A0 Therefore, a server
>=C2=A0 =C2=A0 MUST NOT construct c= hains for domain names other than its own.
> "its own&quo= t; is a bit fraught, as servers may not actually know all their domain
> names, at least at the TLS layer.. Can you be more specific abou= t what the
> server algorithm is.

To = implement this specification, the TLS layer does need to have
pre= configured knowledge of the names for which it has DANE records.
=
This text is also a bit imprecise and should be improved any= way. The
server doesn't construct chains for its own domain n= ame, but rather
the TLSA record name corresponding to that domain= name. This domain
name is either one explicitly indicated by the= client via SNI (assuming
that the indicated name is one the serv= er recognizes as its own),
or if no SNI is provided, one that the= server picks from its known
set of names (as discussed previousl= y).

The purpose of the MUST NOT sentence here is t= o prevent clients from
using the TLS server to lookup arbitrary d= omain names.

>
>=C2=A0 =C2=A0 Serv= ers receiving a "dnssec_chain" extension in the ClientHello, and<= /div>
>=C2=A0 =C2=A0 which are capable of being authenticated via DA= NE, SHOULD return a
>=C2=A0 =C2=A0 serialized authentication c= hain in the extension block of the
> Why is this a SHOULD wher= e the corresponding reqt for TLS 1.2 and below is a
> MAY?

They should clearly be consistent. My preference woul= d be "SHOULD" for
both.

>= =C2=A0 =C2=A0 to a DNSSEC trust root.=C2=A0 This has the added benefit of m= itigating an
>=C2=A0 =C2=A0 unknown key share attack, as descr= ibed in [I-D.barnes-dane-uks],
>=C2=A0 =C2=A0 since it effecti= vely augments the raw public key with the server's
> "= ;unknown key share (UKS)"
>
>=C2=A0 =C2=A0 h= andshake, to a domain name which has been validated as belonging to
>=C2=A0 =C2=A0 the owner name.
> The key point here is t= hat the commitment is bound to the EE key. Also, this
> only r= eally works for TLS 1.3 and modes with EMS because otherwise there are
> other UKS attacks

Ok, we will clarify t= his.

> I think you probably want to cite SIGMA = and triple handhshake here.

Ok.

>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = opaque AuthenticationChain<0..2^16-1>
> Is 0 actually ap= propriate here as a lower bound? Presumably at least one such
>= ; instance must be present?

Yes, there should be a= non-zero number of bytes in the extension data.
So: opaque Authe= nticationChain<1..2^16-1>

>
>= ;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RR(i) =3D owner | type | = class | TTL | RDATA length | RDATA
> I assume the notation her= e is "i is the ith RR"?

Yes, we can ment= ion that.

>
> Is there a reason no= t to describe this in TLS language?

I think becaus= e the extension data contains only a sequence of DNS wire
format = RRs which are precisely defined in DNS documents, and we felt it
= was redundant to redefine them in another format.

= >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 . DNSKE= Y
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RRSIG(. DN= SKEY)
> How does this differ from the algorithm that you would= use in response to the
> TLSA query?

Sorry, I don't follow your comment here. Differ from what? Can you ela= borate?

>
>=C2=A0 =C2=A0 the draft= is adopted by the WG, the authors expect to make an early
>= =C2=A0 =C2=A0 allocation request as specified in [RFC7120].
> = Do you want this to be marked RECOMMENDED?

In resp= onse to Mirja's earlier comment, I think we are taking out this
sentence.

Shumon Huque

--001a11c145d072a6f20564b416de-- From nobody Thu Feb 8 06:33:11 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C5C1201F2; Thu, 8 Feb 2018 06:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 a_b7DJmoEDEi; Thu, 8 Feb 2018 06:33:01 -0800 (PST) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83FB312DA06; Thu, 8 Feb 2018 06:32:56 -0800 (PST) Received: by mail-it0-x231.google.com with SMTP id b66so6742330itd.5; Thu, 08 Feb 2018 06:32:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=I8B9iRc9hcoMiJ404fhj+9KlADYgWbX+M3i1dpMRTLI=; b=EuKzPK2bWgIMVivzsnDP4pOBOgL6s/qTZpcfNlAc1oXN9Dfv5IIkZaC7MZY6/gUaGX JKNwqNJpddYq0OFwymunpbijCz0M5rC0xDwcwKYwiOmioJA/oWf7D+NIVpyXMYnqLpS8 qSspAHjvspKOtbbHkIUAzDrMW4ORsSG4g2RAinui1KCDXYxbE57pHcM8leRxmFwYVJmm IrkM6PnoC+ZCtDLHGMf/JsnIspdk+f1ceXIUfkRmB32ekJqpsS3Ho5bY9Hw90xh2ixcP DS1L/UEGK/KbuSa922xLGxpR28gvEUqLlNExqVGJo6PrThgK/zpae43OJ4/d8pl0SGJG RMBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=I8B9iRc9hcoMiJ404fhj+9KlADYgWbX+M3i1dpMRTLI=; b=gXE2IO+vvgTCHs7vddzGi0/NGRnADT3upGaR6CzfKUpPYoyALJnWNims7JI7dJ1z7v WawiybrUTGKZXMt9sAydoBuzWm3jKdPExFtBoGPz7JrPU4/IzNNxg720I1lWPHYppOpv 8oR8FYDTiUWB9ouDowrbsNoTR1QJ+7mpPykieMSckoeEWXbJCGM/ApJhROFwrVKLw3bx IuCoOm/GCrO2JmLetLORJZB0U+ZMhiAPO+WzQPIzXk5v6pwjTkh944oweENcWrq/KMiv aHWqnByiniE0SJ2TgTd8RKVq5t24bPvgYu0EjoxzD9oSbmlCJNgCHsl+0GXtX691FVQF Ygfg== X-Gm-Message-State: APf1xPABIqCa+kaJKUdJcV9wa04QtybVY+YTxt+aJf9QCGR1ouPO4w/6 CQeXS4+K2yyInDBBB+n4Q3CFdwnEF5JLPJnM4PM= X-Google-Smtp-Source: AH8x227nHAG/+0edHYTR/cVZDEyKVzO8mgc/M58UarNlOVXiEbpWkXMebyXOIPTSroowgqsZ8H1LW4SST3Ku0tdNI+U= X-Received: by 10.36.167.67 with SMTP id s3mr1746616iti.66.1518100375782; Thu, 08 Feb 2018 06:32:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.201.198 with HTTP; Thu, 8 Feb 2018 06:32:55 -0800 (PST) In-Reply-To: <4c90bb83-5ba1-8193-df67-38e25f76caf8@nlnetlabs.nl> References: <151800968634.4877.12510609339415982154.idtracker@ietfa.amsl.com> <4c90bb83-5ba1-8193-df67-38e25f76caf8@nlnetlabs.nl> From: Shumon Huque Date: Thu, 8 Feb 2018 09:32:55 -0500 Message-ID: To: Willem Toorop Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , The IESG , draft-ietf-tls-dnssec-chain-extension@ietf.org, Joseph Salowey , tls-chairs@ietf.org, TLS WG Content-Type: multipart/alternative; boundary="f403045fb1c8a1ca2e0564b4496d" Archived-At: Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-dnssec-chain-extension-06=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 14:33:05 -0000 --f403045fb1c8a1ca2e0564b4496d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 8, 2018 at 4:51 AM, Willem Toorop wrote: > Op 08-02-18 om 03:27 schreef Shumon Huque: > > On Wed, Feb 7, 2018 at 8:21 AM, Mirja K=C3=BChlewind > > wrote: > > > > Mirja K=C3=BChlewind has entered the following ballot position for > > draft-ietf-tls-dnssec-chain-extension-06: No Objection > > > > ------------------------------------------------------------ > ---------- > > COMMENT: > > ------------------------------------------------------------ > ---------- > > > > Two minor, mostly editorial comments: > > > > 1) Intro (sec 2): " It also provides the > > ability to avoid potential problems with TLS clients being unabl= e > to > > look up DANE records because of an interfering or broken > middlebox on > > the path between the client and a DNS server." > > Is that actually a well-known problem (can you provide a reference?= ) > > > > > > Some folks (at Google and NLnet Labs if I recall; maybe others) have do= ne > > measurements to show this is an actual problem -- for a relatively smal= l > but > > still non-trivial fraction of clients. We'll try to see if we can dig u= p > > specific > > references to documents that could be cited. > > I wouldn't call it a relatively small fraction :) DNSSEC is severely > hampered for end-entities by broken infrastructure in many different > ways. Sometimes an upstream resolver can be used for positive DNSSEC > answers (i.e. existing records), but not for non-existent or wildcard > answers, because it simply doesn't forward the NSEC(3) proof for it. > > The last measurements we at NLnet Labs did was in July 2015: > > Gorj=C3=B3n, Xavier Torrent, and Willem Toorop. > "Discovery method for a DNSSEC validating stub resolver." > (2015) > > https://nlnetlabs.nl/pub/os3-2015-rp2-xavier-torrent-gorjon.pdf > > Measurements were done with RIPE Atlas, with at the time +-8200 probes. > At the time only 56% of probes received enough DNSSEC data from their > upstreams to be able to perform DNSSEC validation for both positive and > non-existent answers (required for DANE). > Ah, thanks. I'd forgotten that it was so high! I think my "relatively small" comment was recalling an earlier study (I think by Google) that saw a breakage of around ~ 5%, but I think that was just measuring the ability to lookup and obtain less common RR types and did not measure ability to perform full DNSSEC validation. Shumon. --f403045fb1c8a1ca2e0564b4496d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 8, 2018 at 4:51 AM, Willem Toorop <willem@nlnetlabs.nl> wrote:
Op 08-02-18 om 03:27 schreef= Shumon Huque:
> On Wed, Feb 7, 2018 at 8:21 AM, Mirja K=C3=BChlewind = <ietf@kuehlewind.net
> <mailto:ietf@kuehlewind.net>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Mirja K=C3=BChlewind has entered the following ball= ot position for
>=C2=A0 =C2=A0 =C2=A0draft-ietf-tls-dnssec-chain-extension-06: No O= bjection
>
>=C2=A0 =C2=A0 =C2=A0----------------------------------------------= ------------------------
>=C2=A0 =C2=A0 =C2=A0COMMENT:
>=C2=A0 =C2=A0 =C2=A0----------------------------------------------= ------------------------
>
>=C2=A0 =C2=A0 =C2=A0Two minor, mostly editorial comments:
>
>=C2=A0 =C2=A0 =C2=A01) Intro (sec 2): " It also provides the
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0ability to avoid potential problems wi= th TLS clients being unable to
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0look up DANE records because of an int= erfering or broken middlebox on
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0the path between the client and a DNS = server."
>=C2=A0 =C2=A0 =C2=A0Is that actually a well-known problem (can you prov= ide a reference?)
>
>
> Some folks (at Google and NLnet Labs if I recall; maybe others) have d= one
> measurements to show this is an actual problem -- for a relatively sma= ll but
> still non-trivial fraction of clients. We'll try to see if we can = dig up
> specific
> references to documents that could be cited.

I wouldn't call it a relatively small fraction :)=C2=A0 DNSSEC i= s severely
hampered for end-entities by broken infrastructure in many different
ways.=C2=A0 Sometimes an upstream resolver can be used for positive DNSSEC<= br> answers (i.e. existing records), but not for non-existent or wildcard
answers, because it simply doesn't forward the NSEC(3) proof for it.=C2= =A0


The last measurements we at NLnet Labs did was in July 2015:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Gorj=C3=B3n, Xavier Torrent, and Willem Toorop.=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Discovery method for a DNSSEC validating = stub resolver."
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (2015)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://n= lnetlabs.nl/pub/os3-2015-rp2-xavier-torrent-gorjon.pdf

Measurements were done with RIPE Atlas, with at the time +-8200 probes.
At the time only 56% of probes received enough DNSSEC data from their
upstreams to be able to perform DNSSEC validation for both positive and
non-existent answers (required for DANE).

Ah, thanks. I'd forgotten that it was so high!

<= div>I think my "relatively small" comment was recalling an earlie= r study (I think by
Google) that saw a breakage of around ~ 5%, b= ut I think that was just measuring
the ability to lookup and obta= in less common RR types and did not measure ability=C2=A0
to perf= orm full DNSSEC validation.

Shumon.

=
--f403045fb1c8a1ca2e0564b4496d-- From nobody Thu Feb 8 06:50:03 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3246512DA1A for ; Thu, 8 Feb 2018 06:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 wqW4pQ3k47WW for ; Thu, 8 Feb 2018 06:49:58 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20F0812DA14 for ; Thu, 8 Feb 2018 06:49:58 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id m84so2757988ywd.5 for ; Thu, 08 Feb 2018 06:49:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=I4J+39CQaKM1b4tEPTWV4hKAmat8L6rche8Bqs1DYRk=; b=W6Brr30p10yj8Kq6V+Grt5QSIfjsLemKQ+BW9wrlXo8XLhAtr/bf1+JJI5mfvMGgQD K/ICfr8Pp80WQwrAapy7hSvdTIsErduYxPxBAnYjH91ZnFsVoC731d7m8vKQlpwSu4UN 4eeJA5DyTwgKTQI8J86XtkpL8T49inDaWl3bShEVxynw5kCD40lnSWPiX1GVZb+35e1Q uY+UGmT8OGWIGJF/18n+DxdEbnOf7Be6ozQAAnketYbJVr4nkYZLG371uu1x3yCwhmrA 4erWrpIzpQuw3lzO2GX1WLTZueIjCMpbwWr051ZXtmKQImL121Wsqxu0E92v6SyVYt4b IIkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=I4J+39CQaKM1b4tEPTWV4hKAmat8L6rche8Bqs1DYRk=; b=V1HGIqNoc5Ys9EgNqUjDuNxOv2//1lkJs2PGXLZkqL95fkADdx4Lv+hiXoyiX93gtK O1nxRgerJ6sB4amBUxHDa1tHWSZ9vkI0LKZaEWZoMq9YDDRWEkijOoX4NhPHjcw/FOE+ UdgfZIjdrZ+DX/RXLi4BV8QW7qpJlXmWUO7Nk2/wbNWOPdpwClTi1dV0WD2hMo+eYQpf Vcl5HMckMIqcso0CucGUI4JA9VyZd9my1c1tffwkM0I7hmkjIc6HPaK5Gq4kMry8Xl+0 9oYd2Hma5j6nV3b8BfVcrz+3GtXoCJEd1kjHwJuIpfFWMnW9G3udtxG98SkLuK/TTdbI dTuw== X-Gm-Message-State: APf1xPCqVF7jalpGACcchoUz1XGGOsAyotmhgL8hbG3zSeoMAWVUEbYN 0x51sKibk82o+eor0zFDLzJJHyUZ+gJpWynkLf2GdQ== X-Google-Smtp-Source: AH8x227LD8RxkYI9T6vqDQZQmcLu+O79UPimWMv9qE4dMRIuqZjxFtKbCAAK44kyqvK4c+pIMHH2b/yJMU4cuhVW/DY= X-Received: by 10.37.79.130 with SMTP id d124mr681346ybb.200.1518101397138; Thu, 08 Feb 2018 06:49:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.160.201 with HTTP; Thu, 8 Feb 2018 06:49:16 -0800 (PST) In-Reply-To: References: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Thu, 8 Feb 2018 06:49:16 -0800 Message-ID: To: Shumon Huque Cc: The IESG , draft-ietf-tls-dnssec-chain-extension@ietf.org, Joseph Salowey , tls-chairs , TLS WG Content-Type: multipart/alternative; boundary="001a113bccc88281fc0564b48614" Archived-At: Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 14:50:02 -0000 --001a113bccc88281fc0564b48614 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 8, 2018 at 6:18 AM, Shumon Huque wrote: > On Wed, Feb 7, 2018 at 9:34 AM, Eric Rescorla wrote: > >> Eric Rescorla has entered the following ballot position for >> draft-ietf-tls-dnssec-chain-extension-06: Discuss >> > > Thanks Eric for your detailed review and comments. > > > This draft seems generally sound, but I believe there are pieces that > > are still underspecified. These should be easy to fix. > > > > the Signer's Name field in canonical form and the signature field > > excluded. > > > > IMPORTANT: I'm not sure that this is actually sufficient to allow an > > independent implementation without referring to the other documents. I > > mean, I think I pretty clearly can't validate this chain from the > > above. > > We could add an explicit reference here to the DNS protocol document(s) > and sections within them that define the canonical form of domain > names (RFC 4034, Section 6 probably is the best reference), or even > excerpt the relevant text from that document. Would this satisfy your > concern? > Well, and remove your text about it being possible to implement solely from this document. We deliberately didn't include in this document a detailed description > of the DNSSEC validation algorithm. The algorithm is sufficiently > complicated (and lengthy to describe) that those details are best left > to the relevant DNSSEC RFCs. I think it would be helpful to point > specifically to which documents and sections here though (mainly > RFC 4035 Section 5, and RFC 5155 Section 8). We could also include a > brief synopsis of the algorithm and refer to these documents for > further details. > It's not the algorithm. I don't believe this document is sufficient to parse the structure. Otherwise, can you suggest more specifically what level of additional > detail you'd like to see in this document? > See above. > Similarly, although I think this is enough to break apart the > > RRSETs into RRs, it doesn't tell me how to separate the RRSETs from > > each other. I think you need to either make this a lot more complete > > or alternately stop saying it's sufficient. > > We can add some text about this. Basically the client would scan the chain > reading RRs and group adjacent RRs that share the same RR name, type, and > class into a distinct RRset. > I'd have to review your text to know if it was sufficient. > > > abort the connection, the server uses the domain name associated with > > the server IP address to which the connection has been established. > > IMPORTANT: "the domain name" is not unambiguous. Hosts can have multiple > names for the same IP. > > > > Yes, indeed. This sentence is dealing with the case where the client has > not indicated to the server which name it wants to connect to, so the > server is basically guessing anyway. Perhaps we could reword this to say > something like, "the server picks one of its configured domain names for > the associated IP address". > Yes, that would be fine. (This situation could also have been avoided by mandating client use of > the SNI extension). > > > DNSSEC authentication chain extension from a server, SHOULD use this > > information to perform DANE authentication of the server. In order > > to do this, it uses the mechanism specified by the DNSSEC protocol > > > > IMPORTANT: What happens if the DANE validates but the cert is revoked > > or alternately the cert validates but DANE does not? > > This depends on the mode of DANE in use (i.e. the Certificate Usage > field of the TLSA record). If I recall correctly, this should all be > covered in detail in RFC 7671 ("DANE Updates and Operational Guidance"). > > * With DANE-EE, only the EE certificate is matched against the > certificate data/hash in the TLSA record. There is no CRL/OCSP > style revocation. Revocation would be performed by removing the > TLSA record from the DNS. > > * With DANE-TA, the indicated CA certificate referenced in the TLSA > record may have advertised revocation mechanisms that need to be > consulted. > > * With PKIX-EE and PKIX-TA modes, the standard PKIX revocation mechanisms > need to be consulted and honored. > Well, neither of these modes is useful here, as an attacker will simply ignore the extension. Would you like us to discuss this in the draft? Or is referring to > RFC 7671 sufficient? > I think you should discuss it in the draft as it is relevant to TLS implementation. On your last case, "cert validates but DANE does not", I assume > you mean the cert validates via PKIX but not DANE? I'm not sure this > is explicitly discussed in any other DANE document but presumably > if DANE is being used, DANE must validate. > Why would that be so? This only is useful in DANE-EE and DANE-TA modes in the first place, and so there is a possibilityt aht PKIX is valid. note, I believe most envisioned use cases of this draft > will be for the DANE-* modes. The PKIX constraining modes have the > issue that for them to work securely, the client must be able to > confirm the presence of DANE records, which leads to the issues of how > to mandate use of this mechanism (Section 8 of this document). > Yes, I don't think those modes are useful here. The TLS version-specific protocol elements involved in delivering this > extension are described in Section 3. For the Introduction section from > which the above text is excerpted, I would suggest the following rewrite: > > The extension described here allows a TLS client to request that > the TLS server return the DNSSEC authentication chain corresponding > to its DANE record. If the server is configure for DANE ... > Yes, this is fine. > 3.1. Protocol, TLS 1.2 > > You should probably provide some guidance about whether the server > should still > > provide the whole X.509 chain to the client. I believe with these > semantics, > > the server cannot tell which DANE mode the client wants and therefore > has to > > provide the entire chain. > > Sure, we can elaborate. > > The DANE mode to be used is advertised by the server in its TLSA record(s), > so the server already knows whether it needs to return the X.509 chain. > If the TLSA RRset has only DANE-EE, then only the end-entity certificate > needs to be returned. If DANE-TA, then only the chain from the TA cert to > the > EE needs to be returned. If using the PKIX modes, then yes, the entire > X.509 > chain has to be sent. > The problem is that the client is the decider about what it wants to accept, not the server. > arbitrary domain names using this mechanism. Therefore, a server > > MUST NOT construct chains for domain names other than its own. > > "its own" is a bit fraught, as servers may not actually know all their > domain > > names, at least at the TLS layer.. Can you be more specific about what > the > > server algorithm is. > > To implement this specification, the TLS layer does need to have > preconfigured knowledge of the names for which it has DANE records. > > This text is also a bit imprecise and should be improved anyway. The > server doesn't construct chains for its own domain name, but rather > the TLSA record name corresponding to that domain name. This domain > name is either one explicitly indicated by the client via SNI (assuming > that the indicated name is one the server recognizes as its own), > or if no SNI is provided, one that the server picks from its known > set of names (as discussed previously). > > The purpose of the MUST NOT sentence here is to prevent clients from > using the TLS server to lookup arbitrary domain names. > OK. Well, perhaps some better text is needed here. > Servers receiving a "dnssec_chain" extension in the ClientHello, and > > which are capable of being authenticated via DANE, SHOULD return a > > serialized authentication chain in the extension block of the > > Why is this a SHOULD where the corresponding reqt for TLS 1.2 and below > is a > > MAY? > > They should clearly be consistent. My preference would be "SHOULD" for > both. > That's a WG decision. > > > > opaque AuthenticationChain<0..2^16-1> > > Is 0 actually appropriate here as a lower bound? Presumably at least one > such > > instance must be present? > > Yes, there should be a non-zero number of bytes in the extension data. > So: opaque AuthenticationChain<1..2^16-1> > > > > > RR(i) = owner | type | class | TTL | RDATA length | RDATA > > I assume the notation here is "i is the ith RR"? > > Yes, we can mention that. > > > > > Is there a reason not to describe this in TLS language? > > I think because the extension data contains only a sequence of DNS wire > format RRs which are precisely defined in DNS documents, and we felt it > was redundant to redefine them in another format. > > > > > . DNSKEY > > RRSIG(. DNSKEY) > > How does this differ from the algorithm that you would use in response > to the > > TLSA query? > > Sorry, I don't follow your comment here. Differ from what? Can you > elaborate? > You provided an algorithm for how to construct responses. How is it different from the algorithm that the name server would use to respond to a query for the TLSA record. > > > > the draft is adopted by the WG, the authors expect to make an early > > allocation request as specified in [RFC7120]. > > Do you want this to be marked RECOMMENDED? > > In response to Mirja's earlier comment, I think we are taking out this > sentence. > You're still registering the code point, so you need to determine if it's RECOMMENDED or not. -Ekr > Shumon Huque > > --001a113bccc88281fc0564b48614 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Feb 8, 2018 at 6:18 AM, Shumon Huque <shuque@gmail.com><= /span> wrote:
On Wed, Feb 7,= 2018 at 9:34 AM, Eric Rescorla <ekr@rtfm.com> wrote:
Eric Rescorla has entered the fol= lowing ballot position for
draft-ietf-tls-dnssec-chain-extension-06: Discuss

Thanks Eric for your detailed review and comments.

> This draft seems generall= y sound, but I believe there are pieces that
> are still under= specified. These should be easy to fix.
>
> the S= igner's Name field in canonical form and the signature field
= >=C2=A0 =C2=A0 excluded.
>
> IMPORTANT: I'= m not sure that this is actually sufficient to allow an
> inde= pendent implementation without referring to the other documents. I
> mean, I think I pretty clearly can't validate this chain from th= e
> above.

We could add an exp= licit reference here to the DNS protocol document(s)
and sections= within them that define the canonical form of domain
names (RFC = 4034, Section 6 probably is the best reference), or even
excerpt = the relevant text from that document. Would this satisfy your
con= cern?

Well, and rem= ove your text about it being possible to implement solely from this=C2=A0
document.


We deliberately didn't include in this document a detailed d= escription
of the DNSSEC validation algorithm. The algorithm is s= ufficiently
complicated (and lengthy to describe) that those deta= ils are best left
to the relevant DNSSEC RFCs. I think it would b= e helpful to point
specifically to which documents and sections h= ere though (mainly
RFC 4035 Section 5, and RFC 5155 Section 8). W= e could also include a
brief synopsis of the algorithm and refer = to these documents for
further details.

It's not the algorithm. I don't beli= eve this document is sufficient to parse the
structure.


<= div class=3D"gmail_extra">
Otherwise, can yo= u suggest more specifically what level of additional
detail you&#= 39;d like to see in this document?

See above.


> Similarly, although I think this i= s enough to break apart the
> RRSETs into RRs, it doesn't = tell me how to separate the RRSETs from
> each other. I think = you need to either make this a lot more complete
> or alternat= ely stop saying it's sufficient.

We can= add some text about this. Basically the client would scan the chain
<= div>reading RRs and group adjacent RRs that share the same RR name, type, a= nd
class into a distinct RRset.

I'd have to review your text to know if it was s= ufficient.
=C2=A0

>=C2=A0 =C2=A0 abort the connection, the server us= es the domain name associated with
>=C2=A0 =C2=A0 the server I= P address to which the connection has been established.
> IMPO= RTANT: "the domain name" is not unambiguous. Hosts can have multi= ple names for the same IP.
>

Y= es, indeed. This sentence is dealing with the case where the client has
not indicated to the server which name it wants to connect to, so th= e
server is basically guessing anyway. Perhaps we could reword th= is to say
something like, "the server picks one of its confi= gured domain names for
the associated IP address".

Yes, that would be fine.


(This situa= tion could also have been avoided by mandating client use of
the = SNI extension).

>=C2=A0 =C2=A0= DNSSEC authentication chain extension from a server, SHOULD use this
=
>=C2=A0 =C2=A0 information to perform DANE authentication of the se= rver.=C2=A0 In order
>=C2=A0 =C2=A0 to do this, it uses the me= chanism specified by the DNSSEC protocol
>
> IMPO= RTANT: What happens if the DANE validates but the cert is revoked
> or alternately the cert validates but DANE does not?

This depends on the mode of DANE in use (i.e. the Certifica= te Usage
field of the TLSA record). If I recall correctly, this s= hould all be
covered in detail in RFC 7671 ("DANE Updates an= d Operational Guidance").

* With DANE-EE, onl= y the EE certificate is matched against the
=C2=A0 certificate da= ta/hash in the TLSA record. There is no CRL/OCSP
=C2=A0 style rev= ocation. Revocation would be performed by removing the
=C2=A0 TLS= A record from the DNS.

* With DANE-TA, the indicat= ed CA certificate referenced in the TLSA
=C2=A0 record may have a= dvertised revocation mechanisms that need to be
=C2=A0 consulted.=

* With PKIX-EE and PKIX-TA modes, the standard PK= IX revocation mechanisms
=C2=A0 need to be consulted and honored.=

Well, neither of t= hese modes is useful here, as an attacker will simply ignore the
= extension.


Would you like us to discuss this in the draft? Or is referring to
=
RFC 7671 sufficient?

I think you should discuss it in the draft as it is relevant to TLS = implementation.=C2=A0



On your last case, "cert validates but DA= NE does not", I assume
you mean the cert validates via PKIX = but not DANE? I'm not sure this
is explicitly discussed in an= y other DANE document but presumably
if DANE is being used, DANE = must validate.

Why= would that be so? This only is useful in DANE-EE and DANE-TA modes in
the first place, and so there is a possibilityt aht PKIX is valid.


=C2=A0note= , I believe most envisioned use cases of this draft
will be for t= he DANE-* modes. The PKIX constraining modes have the
issue that = for them to work securely, the client must be able to
confirm the= presence of DANE records, which leads to the issues of how
to ma= ndate use of this mechanism (Section 8 of this document).
=

Yes, I don't think those modes a= re useful here.


The TLS version-specific protocol elements involved in delivering t= his
extension are described in Section 3. For the Introduction se= ction from
which the above text is excerpted, I would suggest the= following rewrite:

=C2=A0 =C2=A0The extension des= cribed here allows a TLS client to request that
=C2=A0 =C2=A0the = TLS server return the DNSSEC authentication chain corresponding
= =C2=A0 =C2=A0to its DANE record. If the server is configure for DANE ...

Yes, this is fine.
=C2=A0

> 3.1.=C2=A0 Protocol, TLS 1.2
> You should prob= ably provide some guidance about whether the server should still
= > provide the whole X.509 chain to the client. I believe with these sema= ntics,
> the server cannot tell which DANE mode the client wan= ts and therefore has to
> provide the entire chain.
=
Sure, we can elaborate.

The = DANE mode to be used is advertised by the server in its TLSA record(s),
so the server already knows whether it needs to return the X.509 cha= in.
If the TLSA RRset has only DANE-EE, then only the end-entity = certificate
needs to be returned. If DANE-TA, then only the chain= from the TA cert to the=C2=A0
EE needs to be returned. If using = the PKIX modes, then yes, the entire X.509
chain has to be sent.<= /div>

The problem is that= the client is the decider about what it wants to accept, not
the= server.


=
>=C2=A0 =C2=A0 arbitrary domain names using this mecha= nism.=C2=A0 Therefore, a server
>=C2=A0 =C2=A0 MUST NOT constr= uct chains for domain names other than its own.
> "its ow= n" is a bit fraught, as servers may not actually know all their domain=
> names, at least at the TLS layer.. Can you be more specific= about what the
> server algorithm is.

To implement this specification, the TLS layer does need to have
preconfigured knowledge of the names for which it has DANE records= .

This text is also a bit imprecise and should be = improved anyway. The
server doesn't construct chains for its = own domain name, but rather
the TLSA record name corresponding to= that domain name. This domain
name is either one explicitly indi= cated by the client via SNI (assuming
that the indicated name is = one the server recognizes as its own),
or if no SNI is provided, = one that the server picks from its known
set of names (as discuss= ed previously).

The purpose of the MUST NOT senten= ce here is to prevent clients from
using the TLS server to lookup= arbitrary domain names.

OK. Well, perhaps some better text is needed here.
=C2=A0


>=C2=A0 =C2=A0 Servers receiving a "dnssec_chain" e= xtension in the ClientHello, and
>=C2=A0 =C2=A0 which are capa= ble of being authenticated via DANE, SHOULD return a
>=C2=A0 = =C2=A0 serialized authentication chain in the extension block of the
<= div>> Why is this a SHOULD where the corresponding reqt for TLS 1.2 and = below is a
> MAY?

They should = clearly be consistent. My preference would be "SHOULD" for
<= div>both.

That'= s a WG decision.

=C2=A0


>= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 opaque AuthenticationChain= <0..2^16-1>
> Is 0 actually appropriate here as a lower = bound? Presumably at least one such
> instance must be present= ?

Yes, there should be a non-zero number of= bytes in the extension data.
So: opaque AuthenticationChain<1= ..2^16-1>

>
>= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RR(i) =3D owner | type | c= lass | TTL | RDATA length | RDATA
> I assume the notation here= is "i is the ith RR"?

Yes, we ca= n mention that.

>
&g= t; Is there a reason not to describe this in TLS language?

I think because the extension data contains only a sequence= of DNS wire
format RRs which are precisely defined in DNS docume= nts, and we felt it
was redundant to redefine them in another for= mat.

>
>=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 . DNSKEY
>=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RRSIG(. DNSKEY)
> How d= oes this differ from the algorithm that you would use in response to the
> TLSA query?

Sorry, I don't= follow your comment here. Differ from what? Can you elaborate?
=

You provided an algorithm for = how to construct responses. How is it different from the
algorith= m that the=C2=A0 name server would=C2=A0 use to respond to a query for the = TLSA record.


>
>=C2=A0 =C2=A0 the draft is adopted= by the WG, the authors expect to make an early
>=C2=A0 =C2=A0= allocation request as specified in [RFC7120].
> Do you want t= his to be marked RECOMMENDED?

In response t= o Mirja's earlier comment, I think we are taking out this
sen= tence.

You're s= till registering the code point, so you need to determine if it's RECOM= MENDED or not.

-Ekr


Shumon Huque


--001a113bccc88281fc0564b48614-- From nobody Thu Feb 8 08:36:02 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDEDF126B6E; Thu, 8 Feb 2018 08:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 sgaB6MehX5tj; Thu, 8 Feb 2018 08:35:53 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A04E12426E; Thu, 8 Feb 2018 08:35:53 -0800 (PST) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 7B51D7A3309; Thu, 8 Feb 2018 16:35:52 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 8 Feb 2018 11:35:51 -0500 Cc: Shumon Huque , TLS WG , draft-ietf-tls-dnssec-chain-extension@ietf.org, The IESG , tls-chairs Content-Transfer-Encoding: quoted-printable Message-Id: References: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 16:35:56 -0000 > On Feb 8, 2018, at 9:49 AM, Eric Rescorla wrote: >=20 >> This depends on the mode of DANE in use (i.e. the Certificate Usage >> field of the TLSA record). If I recall correctly, this should all be >> covered in detail in RFC 7671 ("DANE Updates and Operational = Guidance"). >>=20 >> * With DANE-EE, only the EE certificate is matched against the >> certificate data/hash in the TLSA record. There is no CRL/OCSP >> style revocation. Revocation would be performed by removing the >> TLSA record from the DNS. >>=20 >> * With DANE-TA, the indicated CA certificate referenced in the TLSA >> record may have advertised revocation mechanisms that need to be >> consulted. >>=20 >> * With PKIX-EE and PKIX-TA modes, the standard PKIX revocation = mechanisms >> need to be consulted and honored. >=20 > Well, neither of these modes is useful here, as an attacker will = simply ignore the > extension. Good point. Well, if a server publishes "CA constraint" (PKIX-TA(0)) or "service certificate constraint" (PKIX-EE(1)) TLSA records, presumably it is precisely because they believe that PKIX alone is not enough, and would like to require at least one of the specified constraints to be satisfied. So if the records do make it to the client, the client should probably honour them if it is doing DANE-based authentication. However, as you correctly observe, with this in-band TLSA record delivery mechanism, an attacker who is able to able PKIX-verifiable certificates and keys for the target domain can simply not respond with the extension and deliver just the PKIX key material. So if a client is willing to go with just PKIX for servers that don't support the extension, then it subject to a "dane-stripping" downgrade attack when using this mechanism. We should also note that clients might cache the obtained TLSA records, and so might not accept just PKIX while cached records are available, even if TLSA records are stripped on a subsequent connection. But the key question boils down to whether the client is configured to *require* DANE for the connection (in which case just PKIX is clearly not enough), or whether it is doing a form of "opportunistic DANE" (for lack of a better term in this message) with the server optionally providing the records, but otherwise the client resorts to using just PKIX. In the "opportunistic DANE" case one might argue that, when PKIX-TA(0) or PKIX-EE(1) fail, but PKIX alone would otherwise succeed, the client should accept PKIX alone, since a downgrade attack can typically strip DANE. But if the client is caching previously seen TLSA records, then the downgrade attack is partially mitigated (for the TTL of the cached records). The client may elect to request new TLSA records before the expiration of the previous ones are expired, extending such protection until it stops communicating with the server sufficiently regularly to be able to keep a copy of unexpired TLSA records in its cache. So all in all, I think there may be enough merit in rejecting on DANE failure, subject to local policy, but the client might elect to trust bare PKIX. For clients that do reject PKIX success based on DANE failure, and cache obtained TLSA records, it might have been good to recommend refreshing the TLSA records while the cached data is still valid (say the smaller of some refresh time or 50% of TTL has expired). That way, for a client that keeps communicating regularly may be (partially) protected against downgrades. Perhaps it is too late to make such a change at this stage in the document's life-cycle. Summary as I see it: * Mandatory DANE:=0D=1B MUST Refuse absence of TLSA RRs or failure of PKIX-TA(0) and PKIX-EE(1). Must fail when no TLSA RRs are cache and the server does not present the extension. * "Opportunistic DANE": MAY refuse failed PKIX-TA(0) and PKIX(1) if caching replies, and SHOULD attempt to refresh cache before expiration to reduce opportunity for downgrades. Non-caching clients don't really gain security by refusing valid PKIX on DANE failure, and MAY choose to continue. --=20 Viktor. From nobody Thu Feb 8 13:43:14 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B0E1275C5 for ; Thu, 8 Feb 2018 13:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ghedini.me 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 mqKbkdWPKK3t for ; Thu, 8 Feb 2018 13:43:11 -0800 (PST) Received: from blastoise.ghedini.me (blastoise.ghedini.me [IPv6:2001:19f0:6c01:a56:5400:1ff:fe4a:5694]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00D7C126C3D for ; Thu, 8 Feb 2018 13:43:11 -0800 (PST) Received: from localhost (unknown [IPv6:2a02:8010:6241:0:b8f6:3896:c9b3:2aff]) by blastoise.ghedini.me (Postfix) with ESMTPSA id 0E2C5DF267 for ; Thu, 8 Feb 2018 21:43:09 +0000 (UTC) Date: Thu, 8 Feb 2018 21:43:07 +0000 From: Alessandro Ghedini To: tls@ietf.org Message-ID: <20180208214307.GA29309@pinky> Mail-Followup-To: tls@ietf.org References: <151696190108.24397.6150515497869897080@ietfa.amsl.com> <20180126102659.GA5204@pinky> <4ef441ff-6075-626e-b208-a0e5da3d18f0@akamai.com> <9126f0e6-e135-5421-f9b9-1ff880fd19e8@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9126f0e6-e135-5421-f9b9-1ff880fd19e8@akamai.com> User-Agent: Mutt/1.9.3 (2018-01-21) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ghedini.me; s=mail; t=1518126189; h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=1IKCbKFSamHbLjLa7J6MPeLL3+N7CSGpCVCsiDRDYF8=; b=MVGRJQFZlWWMmbfYUIKcoqlA98mtFsDeQZRkJzheLrwL5/n7/qXWsRhZtXTsZgZzkW/1Zv qvBnuFuH3JSOmvSeqTzJtkNmWh9t2/B2hQTmND6VU7F5tkA1WF6rHlWAL6AMH3a0ck13PP YGJX2JC4pYqAX48cOi4pzdNIZaAi6/A= Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 21:43:13 -0000 On Wed, Jan 31, 2018 at 03:41:34PM -0600, Benjamin Kaduk wrote: > On 01/30/2018 04:02 PM, Victor Vasiliev wrote: > > I also wondered whether there was any sense in reserving codepoint > > 0 (of > > CertificateCompressionAlgorithm) for "uncompressed".  I guess not, > > since > > support for uncompressed certificates is implicit by means of not > > using > > the extension.  But sometimes keeping value 0 (basically) reserved is > > still useful. > > > > > > I've considered that, but decided that this would just introduce two > > ways to do > > the same thing (send certificate uncompressed), so I decided against it. > > Sure.  I don't see a reason to add a code point for uncompressed, but > maybe there is an aesthetic argument for leaving 0 reserved entirely.  > But I definitely do not insist on anything. Yeah, makes sense to keep 0 reserved. I made a PR for this: https://github.com/tlswg/certificate-compression/pull/12 and looks like Victor already merged it. Cheers From nobody Thu Feb 8 16:48:11 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CE412DA47 for ; Thu, 8 Feb 2018 16:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 y2hCDa-zKTVz for ; Thu, 8 Feb 2018 16:48:06 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8A5912DA44 for ; Thu, 8 Feb 2018 16:48:06 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id l11so815819ywh.2 for ; Thu, 08 Feb 2018 16:48:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=umpgZm2Hm3NnMTz7Qn6+nGKB7MpNKILP3V1n/boYQNQ=; b=BKc3ycaZSozX2atFmZUywKTn8ElXnQeV+5ie5a+A1vPONLdXkUffM2F7ort35c2Ltf csuTJef+zQH5SPI2oxY+pHAKF8xMufeIX/RDdPHMEs+f+QRKQLJGdWb3pkq/1WJ4Q2vf +zG7493FD9tUCL/AqVTzwVccIYjnxsgnU9oNBHO/BdxyEN2ofelXr7wuipwQwYZdv+B3 /CJI1Q82Wn2m60sbW+RGZiN0san2roWdbmzrUrf+iKEvS1XOEH08J3sghuoxljb580qh kmUZe3sQfw7FGAWCgw/iW0KT4i9fvc2KF0fybm8a14eDENQpGwyScxl8eK3L14oJXos/ x2pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=umpgZm2Hm3NnMTz7Qn6+nGKB7MpNKILP3V1n/boYQNQ=; b=kVykTgp5x0w13M6BSepKPT32fzU0BwJxCwBkPFSdYmEVLcIgUzzhkN5Pxov+U+RKe6 7NMFSdfPLtkvp/Tey2/4kptVB/242JWH/yPiNGh7mtymI4PJY07TZzi7mXpQufxhyYdB sTJ12ha5BKP3JIfyhZ4dLKbBJwRl9OJwCuVluJLLhd0w+lRvkgK5Q+1x08IO+YvHhubp /W7LE8PLAYXWArqDaUq5tng9U67AAVxqV+W4afsqFr1iwvu6ekVDcQRbZm/727pdr7nS pEYGkzhzsrXoAQntZM3i+z03ayQ4aas6Vtxl8nzJsldX5yFLw9cleL+8tJEb+YiL8ayY uIvQ== X-Gm-Message-State: APf1xPA/MZ55j9j8G/4d4ClCkxFn38VGM34IoUbZC9Qg2pN7yjxiSfmL aVOAkoWriwkLr6L9B2bOtyschJq1fB+PmShNr102jA== X-Google-Smtp-Source: AH8x224AKgFFx9/YwcTvZTkv6YL7EpVFUXnAD+O5rVqdATtxLiGWCC6Jo4Dw6Gd/XbAmfFU1pKysoYtlLNWb0Rl0SnI= X-Received: by 10.129.161.16 with SMTP id y16mr810394ywg.2.1518137285749; Thu, 08 Feb 2018 16:48:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.160.201 with HTTP; Thu, 8 Feb 2018 16:47:25 -0800 (PST) In-Reply-To: References: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Thu, 8 Feb 2018 16:47:25 -0800 Message-ID: To: Viktor Dukhovni Cc: Shumon Huque , TLS WG , draft-ietf-tls-dnssec-chain-extension@ietf.org, The IESG , tls-chairs Content-Type: multipart/alternative; boundary="001a114f89bca349370564bce1ac" Archived-At: Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 00:48:09 -0000 --001a114f89bca349370564bce1ac Content-Type: text/plain; charset="UTF-8" Yeah this doesn't seem unreasonable -Ekr On Thu, Feb 8, 2018 at 8:35 AM, Viktor Dukhovni wrote: > > > > On Feb 8, 2018, at 9:49 AM, Eric Rescorla wrote: > > > >> This depends on the mode of DANE in use (i.e. the Certificate Usage > >> field of the TLSA record). If I recall correctly, this should all be > >> covered in detail in RFC 7671 ("DANE Updates and Operational Guidance"). > >> > >> * With DANE-EE, only the EE certificate is matched against the > >> certificate data/hash in the TLSA record. There is no CRL/OCSP > >> style revocation. Revocation would be performed by removing the > >> TLSA record from the DNS. > >> > >> * With DANE-TA, the indicated CA certificate referenced in the TLSA > >> record may have advertised revocation mechanisms that need to be > >> consulted. > >> > >> * With PKIX-EE and PKIX-TA modes, the standard PKIX revocation > mechanisms > >> need to be consulted and honored. > > > > Well, neither of these modes is useful here, as an attacker will simply > ignore the > > extension. > > Good point. > > Well, if a server publishes "CA constraint" (PKIX-TA(0)) or "service > certificate constraint" (PKIX-EE(1)) TLSA records, presumably it is > precisely because they believe that PKIX alone is not enough, and > would like to require at least one of the specified constraints to > be satisfied. > > So if the records do make it to the client, the client should > probably honour them if it is doing DANE-based authentication. > > However, as you correctly observe, with this in-band TLSA record > delivery mechanism, an attacker who is able to able PKIX-verifiable > certificates and keys for the target domain can simply not respond > with the extension and deliver just the PKIX key material. So if > a client is willing to go with just PKIX for servers that don't > support the extension, then it subject to a "dane-stripping" > downgrade attack when using this mechanism. > > We should also note that clients might cache the obtained TLSA > records, and so might not accept just PKIX while cached records > are available, even if TLSA records are stripped on a subsequent > connection. > > But the key question boils down to whether the client is configured > to *require* DANE for the connection (in which case just PKIX is > clearly not enough), or whether it is doing a form of "opportunistic > DANE" (for lack of a better term in this message) with the server > optionally providing the records, but otherwise the client resorts > to using just PKIX. > > In the "opportunistic DANE" case one might argue that, when PKIX-TA(0) > or PKIX-EE(1) fail, but PKIX alone would otherwise succeed, the client > should accept PKIX alone, since a downgrade attack can typically strip > DANE. But if the client is caching previously seen TLSA records, then > the downgrade attack is partially mitigated (for the TTL of the cached > records). The client may elect to request new TLSA records before the > expiration of the previous ones are expired, extending such protection > until it stops communicating with the server sufficiently regularly to > be able to keep a copy of unexpired TLSA records in its cache. > > So all in all, I think there may be enough merit in rejecting on DANE > failure, subject to local policy, but the client might elect to trust > bare PKIX. > > For clients that do reject PKIX success based on DANE failure, and > cache obtained TLSA records, it might have been good to recommend > refreshing the TLSA records while the cached data is still valid > (say the smaller of some refresh time or 50% of TTL has expired). > That way, for a client that keeps communicating regularly may be > (partially) protected against downgrades. Perhaps it is too late > to make such a change at this stage in the document's life-cycle. > > Summary as I see it: > > * Mandatory DANE: > MUST Refuse absence of TLSA RRs or failure > of PKIX-TA(0) and PKIX-EE(1). Must fail when no TLSA RRs > are cache and the server does not present the extension. > > * "Opportunistic DANE": MAY refuse failed PKIX-TA(0) and PKIX(1) > if caching replies, and SHOULD attempt to refresh cache before > expiration to reduce opportunity for downgrades. Non-caching > clients don't really gain security by refusing valid PKIX on > DANE failure, and MAY choose to continue. > > -- > Viktor. > > --001a114f89bca349370564bce1ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah this doesn't seem unreasonable

-Ekr


On Thu, Feb 8, 2018 at 8:35 AM, Viktor Dukhovni <ie= tf-dane@dukhovni.org> wrote:


> On Feb 8, 2018, at 9:49 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>> This depends on the mode of DANE in use (i.e. the Certificate Usag= e
>> field of the TLSA record). If I recall correctly, this should all = be
>> covered in detail in RFC 7671 ("DANE Updates and Operational = Guidance").
>>
>> * With DANE-EE, only the EE certificate is matched against the
>>=C2=A0 =C2=A0certificate data/hash in the TLSA record. There is no = CRL/OCSP
>>=C2=A0 =C2=A0style revocation. Revocation would be performed by rem= oving the
>>=C2=A0 =C2=A0TLSA record from the DNS.
>>
>> * With DANE-TA, the indicated CA certificate referenced in the TLS= A
>>=C2=A0 =C2=A0record may have advertised revocation mechanisms that = need to be
>>=C2=A0 =C2=A0consulted.
>>
>> * With PKIX-EE and PKIX-TA modes, the standard PKIX revocation mec= hanisms
>>=C2=A0 =C2=A0need to be consulted and honored.
>
> Well, neither of these modes is useful here, as an attacker will simpl= y ignore the
> extension.

Good point.

Well, if a server publishes "CA constraint" (PKIX-TA(0)) or "= ;service
certificate constraint" (PKIX-EE(1)) TLSA records, presumably it is precisely because they believe that PKIX alone is not enough, and
would like to require at least one of the specified constraints to
be satisfied.

So if the records do make it to the client, the client should
probably honour them if it is doing DANE-based authentication.

However, as you correctly observe, with this in-band TLSA record
delivery mechanism, an attacker who is able to able PKIX-verifiable
certificates and keys for the target domain can simply not respond
with the extension and deliver just the PKIX key material.=C2=A0 So if
a client is willing to go with just PKIX for servers that don't
support the extension, then it subject to a "dane-stripping"
downgrade attack when using this mechanism.

We should also note that clients might cache the obtained TLSA
records, and so might not accept just PKIX while cached records
are available, even if TLSA records are stripped on a subsequent
connection.

But the key question boils down to whether the client is configured
to *require* DANE for the connection (in which case just PKIX is
clearly not enough), or whether it is doing a form of "opportunistic DANE" (for lack of a better term in this message) with the server
optionally providing the records, but otherwise the client resorts
to using just PKIX.

In the "opportunistic DANE" case one might argue that, when PKIX-= TA(0)
or PKIX-EE(1) fail, but PKIX alone would otherwise succeed, the client
should accept PKIX alone, since a downgrade attack can typically strip
DANE.=C2=A0 But if the client is caching previously seen TLSA records, then=
the downgrade attack is partially mitigated (for the TTL of the cached
records).=C2=A0 The client may elect to request new TLSA records before the=
expiration of the previous ones are expired, extending such protection
until it stops communicating with the server sufficiently regularly to
be able to keep a copy of unexpired TLSA records in its cache.

So all in all, I think there may be enough merit in rejecting on DANE
failure, subject to local policy, but the client might elect to trust
bare PKIX.

For clients that do reject PKIX success based on DANE failure, and
cache obtained TLSA records, it might have been good to recommend
refreshing the TLSA records while the cached data is still valid
(say the smaller of some refresh time or 50% of TTL has expired).
That way, for a client that keeps communicating regularly may be
(partially) protected against downgrades.=C2=A0 Perhaps it is too late
to make such a change at this stage in the document's life-cycle.

Summary as I see it:

=C2=A0 * Mandatory DANE:
=C2=A0 MUST Refuse absence of TLSA RRs or failure
=C2=A0 =C2=A0 of PKIX-TA(0) and PKIX-EE(1).=C2=A0 Must fail when no TLSA RR= s
=C2=A0 =C2=A0 are cache and the server does not present the extension.

=C2=A0 * "Opportunistic DANE": MAY refuse failed PKIX-TA(0) and P= KIX(1)
=C2=A0 =C2=A0 if caching replies, and SHOULD attempt to refresh cache befor= e
=C2=A0 =C2=A0 expiration to reduce opportunity for downgrades.=C2=A0 Non-ca= ching
=C2=A0 =C2=A0 clients don't really gain security by refusing valid PKIX= on
=C2=A0 =C2=A0 DANE failure, and MAY choose to continue.

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.


--001a114f89bca349370564bce1ac-- From nobody Fri Feb 9 11:45:30 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8DD12708C for ; Fri, 9 Feb 2018 11:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 xQoTG6HdeNFB for ; Fri, 9 Feb 2018 11:45:26 -0800 (PST) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97CCA1242F7 for ; Fri, 9 Feb 2018 11:45:26 -0800 (PST) Received: from mail08.wdf.sap.corp (mail01.sap.corp [194.39.131.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3zdQX420fwzR0 for ; Fri, 9 Feb 2018 20:45:24 +0100 (CET) X-purgate-ID: 152705::1518205524-0000081F-D681418C/0/0 X-purgate-size: 2021 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail08.wdf.sap.corp (Postfix) with ESMTP id 3zdQX41DQlz2xF5 for ; Fri, 9 Feb 2018 20:45:24 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 1EDD5409B; Fri, 9 Feb 2018 20:45:24 +0100 (CET) To: tls@ietf.org Date: Fri, 9 Feb 2018 20:45:24 +0100 (CET) Reply-To: mrex@sap.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20180209194524.1EDD5409B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: [TLS] Network middlebox corrupting TLS session resumes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 19:45:29 -0000 Hi, During the analysis of a recent customer support call, I determined from a wireshark/network trace that the cause of unexpected failures of TLS session resumption handshakes were caused by some broken network middlebox, which allegedly was configured for "SSL inspection". I would like to know whether this problem is visible on the telemetry data collections of any browser folks. The network middlebox was seemingly *NOT* doing MitM-Attacks on the connection, because the full handshakes with (remote 3rd-party) servers succeeded just fine with genuine TLS server certs. I noticed what looked like three subtly different kind of failures, but only got the wireshark trace of one of these for analysis. TLS session resumes were corrupted by that "SSL inspecting" network middlebox in the follwoing fashion: (1) non-critical (but negligent) corruption: the protocol version number of the TLS record that carries ServerHello was changed from (3,3) to (3,1) by that network middlebox on TLS session resume attempts. This change did not occur on TLS full handshakes, and the genuine server sends (3,3) at the record layer both times. (2) fatal corruption: the 5-byte TLS record header of the ChangeCipherSpec handshake message was missing (removed from the network stream). and the remaining content byte (01) is obviously not a valid start of a new TLS record, causing our TLS client to abort the handshake with a fatal TLS illegal_parameter alert (although it seems that the appropriate alert would be decode_error). The genuine server was sending the TLS record with ServerHello and the TLS record with ChangeCipherSpec in the same TCP segment and IP datagram (152 bytes on the wire), and the filtered response that went through that network middlebox was just 147 bytes on the wire, with the 5-byte TLS record header of ChangeCipherSpec missing. -Martin From nobody Fri Feb 9 12:02:27 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637FA1242F7 for ; Fri, 9 Feb 2018 12:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 vbC7MHnSvMcH for ; Fri, 9 Feb 2018 12:02:24 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B41BF120726 for ; Fri, 9 Feb 2018 12:02:23 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id s27so12044073qts.4 for ; Fri, 09 Feb 2018 12:02:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o1MypUa2DkpoJFE5lDTrm1mW8shTdX3Y04seUDf9NAw=; b=HOzOTINtrI+zLiYHCl9di5voAt7kFs55fy4EyL4rjrIXtYllcBusBRM6cVngzHH6Tk 1qnFonULNWeOMOxIZ7Zjol4uSxAz7kSDnoM+dxMQms7K8t+3ZkYDZso4H9uttYaRQwev ssQuUGckEWiZ0YH1HskMhTewixGaGDOUTTaKk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o1MypUa2DkpoJFE5lDTrm1mW8shTdX3Y04seUDf9NAw=; b=nC8eECEAqZW3oJ6D3iquwXa/jyHPYq6XRo1pr2Rc84F2bnWw0tNTiMwDPET8/FLL3D Ve2Q9IUcn6IdSgxVZViE5ks4Aw4oy/pm8vECDVF2/ib6d6WSKmJmdcOC03j3zGslH5uQ oUAoVktwyCg5+sAS1ztHSejEQDFrItJe2suWEuK/EELD6qyCXcxsQYJFcgm2t0HTerOD +2I+MQCHEMqk6w+s7XKtMXFSDzmhDyLhHcUI2H/wbpWQobhyUed+tPyn+bBI3nYF3dX8 S0YMrce8h6GHAU0lqqnpt2gUgIeyZszzeCCOsa/c7BDLK2v2084aEfWm0ihEMkfp2FSk ZOMg== X-Gm-Message-State: APf1xPDsMnsiK/5fTkgSbWJHxNqIgn0qsCDu0vSm6YemWPOX14uPHz+9 nisv7skEI19QUF7/y994TTXMfEPWlt7l9WvZ2fiI X-Google-Smtp-Source: AH8x224A18jhoF5dGR9xM2HPgX0c1JsLPcjEoLJQCGZupZpWgT8BlT4IcDXYz9sTL06w6JnrMF9+Mk33Uxv9a5uke4c= X-Received: by 10.200.82.4 with SMTP id r4mr6415966qtn.75.1518206542721; Fri, 09 Feb 2018 12:02:22 -0800 (PST) MIME-Version: 1.0 References: <20180209194524.1EDD5409B@ld9781.wdf.sap.corp> In-Reply-To: <20180209194524.1EDD5409B@ld9781.wdf.sap.corp> From: David Benjamin Date: Fri, 09 Feb 2018 20:02:11 +0000 Message-ID: To: mrex@sap.com Cc: tls@ietf.org Content-Type: multipart/alternative; boundary="f4f5e80c6c9cad34780564cd01f4" Archived-At: Subject: Re: [TLS] Network middlebox corrupting TLS session resumes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 20:02:26 -0000 --f4f5e80c6c9cad34780564cd01f4 Content-Type: text/plain; charset="UTF-8" I don't think we've observed this particular issue. We have observed middleboxes which, when they see a ServerHello they can't parse (such as the pre-draft-22 TLS 1.3 ServerHello), drop the ServerHello record on the floor, but pass through any following application_data records as-is. That's similar to your (2), though not quite as we didn't observe the record headers getting mangled. (TLS 1.3 did not include a CCS then, so I don't know if it would have mangled a CCS's record header.) I think if there's anything I've learned from this mess, it is that there are no bounds on how badly broken middleboxes are. We've seen middleboxes that break when we change our cipher suite preferences, because they suddenly start detecting our ClientHellos as SIP messages! (Yes, SIP. The text protocol.) David On Fri, Feb 9, 2018 at 2:45 PM Martin Rex wrote: > Hi, > > During the analysis of a recent customer support call, I determined > from a wireshark/network trace that the cause of unexpected failures > of TLS session resumption handshakes were caused by some broken > network middlebox, which allegedly was configured for "SSL inspection". > > I would like to know whether this problem is visible on the telemetry > data collections of any browser folks. > > > The network middlebox was seemingly *NOT* doing MitM-Attacks on the > connection, because the full handshakes with (remote 3rd-party) servers > succeeded just fine with genuine TLS server certs. > > > I noticed what looked like three subtly different kind of failures, > but only got the wireshark trace of one of these for analysis. > > TLS session resumes were corrupted by that "SSL inspecting" > network middlebox in the follwoing fashion: > > (1) non-critical (but negligent) corruption: > the protocol version number of the TLS record that carries > ServerHello was changed from (3,3) to (3,1) by that > network middlebox on TLS session resume attempts. > This change did not occur on TLS full handshakes, and the > genuine server sends (3,3) at the record layer both times. > > (2) fatal corruption: > the 5-byte TLS record header of the ChangeCipherSpec handshake > message was missing (removed from the network stream). and > the remaining content byte (01) is obviously not a valid start > of a new TLS record, causing our TLS client to abort the handshake > with a fatal TLS illegal_parameter alert (although it seems > that the appropriate alert would be decode_error). > > The genuine server was sending the TLS record with ServerHello > and the TLS record with ChangeCipherSpec in the same > TCP segment and IP datagram (152 bytes on the wire), > and the filtered response that went through that network > middlebox was just 147 bytes on the wire, with the > 5-byte TLS record header of ChangeCipherSpec missing. > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f4f5e80c6c9cad34780564cd01f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't think we've observed this particular issue= . We have observed middleboxes which, when they see a ServerHello they can&= #39;t parse (such as the pre-draft-22 TLS 1.3 ServerHello), drop the Server= Hello record on the floor, but pass through any following application_data = records as-is. That's similar to your (2), though not quite as we didn&= #39;t observe the record headers getting mangled. (TLS 1.3 did not include = a CCS then, so I don't know if it would have mangled a CCS's record= header.)

I think if there's anything I've learn= ed from this mess, it is that there are no bounds on how badly broken middl= eboxes are. We've seen middleboxes that break when we change our cipher= suite preferences, because they suddenly start detecting our ClientHellos = as SIP messages! (Yes, SIP. The text protocol.)

Da= vid

= On Fri, Feb 9, 2018 at 2:45 PM Martin Rex <mrex@sap.com> wrote:
Hi,<= br>
During the analysis of a recent customer support call, I determined
from a wireshark/network trace that the cause of unexpected failures
of TLS session resumption handshakes were caused by some broken
network middlebox, which allegedly was configured for "SSL inspection&= quot;.

I would like to know whether this problem is visible on the telemetry
data collections of any browser folks.


The network middlebox was seemingly *NOT* doing MitM-Attacks on the
connection, because the full handshakes with (remote 3rd-party) servers
succeeded just fine with genuine TLS server certs.


I noticed what looked like three subtly different kind of failures,
but only got the wireshark trace of one of these for analysis.

TLS session resumes were corrupted by that "SSL inspecting"
network middlebox in the follwoing fashion:

=C2=A0 (1) non-critical (but negligent) corruption:
=C2=A0 =C2=A0 =C2=A0 the protocol version number of the TLS record that car= ries
=C2=A0 =C2=A0 =C2=A0 ServerHello was changed from (3,3) to (3,1) by that =C2=A0 =C2=A0 =C2=A0 network middlebox on TLS session resume attempts.
=C2=A0 =C2=A0 =C2=A0 This change did not occur on TLS full handshakes, and = the
=C2=A0 =C2=A0 =C2=A0 genuine server sends (3,3) at the record layer both ti= mes.

=C2=A0 (2) fatal corruption:
=C2=A0 =C2=A0 =C2=A0 the 5-byte TLS record header of the ChangeCipherSpec h= andshake
=C2=A0 =C2=A0 =C2=A0 message was missing (removed from the network stream).= and
=C2=A0 =C2=A0 =C2=A0 the remaining content byte (01) is obviously not a val= id start
=C2=A0 =C2=A0 =C2=A0 of a new TLS record, causing our TLS client to abort t= he handshake
=C2=A0 =C2=A0 =C2=A0 with a fatal TLS illegal_parameter alert (although it = seems
=C2=A0 =C2=A0 =C2=A0 that the appropriate alert would be decode_error).

=C2=A0 =C2=A0 =C2=A0 The genuine server was sending the TLS record with Ser= verHello
=C2=A0 =C2=A0 =C2=A0 and the TLS record with ChangeCipherSpec in the same =C2=A0 =C2=A0 =C2=A0 TCP segment and IP datagram (152 bytes on the wire), =C2=A0 =C2=A0 =C2=A0 and the filtered response that went through that netwo= rk
=C2=A0 =C2=A0 =C2=A0 middlebox was just 147 bytes on the wire, with the
=C2=A0 =C2=A0 =C2=A0 5-byte TLS record header of ChangeCipherSpec missing.<= br>
-Martin

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--f4f5e80c6c9cad34780564cd01f4-- From nobody Mon Feb 12 06:10:31 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609C61270FC for ; Mon, 12 Feb 2018 06:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01] autolearn=ham autolearn_force=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 dCvVqQNWQLFm for ; Mon, 12 Feb 2018 06:10:28 -0800 (PST) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 968F2126BFD for ; Mon, 12 Feb 2018 06:10:28 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 93B5684258 for ; Mon, 12 Feb 2018 14:10:26 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4FC7EFD915 for ; Mon, 12 Feb 2018 14:10:24 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Mon, 12 Feb 2018 15:10:18 +0100 Message-ID: <48986853.OUDrGe6E9e@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1742119.xancDaXH3U"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Mon, 12 Feb 2018 14:10:27 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Mon, 12 Feb 2018 14:10:27 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: [TLS] coalescing of CCS messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 14:10:30 -0000 --nextPart1742119.xancDaXH3U Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Rules for CCS messages in record layer are missing, allowing in theory send= ing multiple CCS messages in a single record layer I've proposed a PR that requires the same kind of processing rules for CCS = and=20 Alert messages: https://github.com/tlswg/tls13-spec/pull/1146 - no=20 fragmentation and no coalescing. That automatically solves the empty CCS=20 record case. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart1742119.xancDaXH3U Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlqBoEoACgkQkqjRuAHS 9fU/OA/9H8fwCRlT7Z0efeiAdwbLmpCAujscfW575TR1uUHIJOn6swUNWUTnajmP Bm62bjrxWcjWmW95+/2tQeQUdRc9PcFemVMfxPzpOrHsbZHdzDNl+f81KWDh0Lha JhFhl5yfF/r/CgbDviOMPZRcGJ95Nx2iLexvMIokwSxLxw+NMRYNCF52Ux+FUXVc twVkgxFCWPiUCmGg8FB6+F9qQJXA5fpNergZL69KUef8bgkvG2UAzcgcfbkSGo2K Jfc/c7PZ1kfPbLWycia7Y567ErQrAanR5ETQgC3immRHtIXG8qeCv4cdWAxi3LRT PoxD0ETcN+24piU1Hcdb+ovvaunAfi3LEGVU67itDvTJdkFhulmhJ9knhbl9LNwK 31VeXLlLa0KgvpQ2n2geawDkWDKvH00vhwgHQPwPn/YeMK9fQPI/ZWXc99p2IVf+ 3bPa2QynUhj/XcvRYJDSZlTtgxQENdqjZ0JEHnElDwo8TKQVe51LZXiF0gf4MMqS NmQZ7+HkLpC4/6ipbkXD+lKrODfknHQQm5kfQGCS30x0DZPzT0ZlSvgdpRdUhLh2 CRuPdHOQp0NUJcS9VuzGoaxkzvUCD4rFrAd9UdlUgq4TxrJymhy2tOIoHl8PsvNm c746cHkuhwNLQ+atIuG31yrEEy7CAqdrlzIG+3PmeZId2lZxByM= =mPGh -----END PGP SIGNATURE----- --nextPart1742119.xancDaXH3U-- From nobody Mon Feb 12 06:38:40 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23FF129516 for ; Mon, 12 Feb 2018 06:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 9rgdyhKUMLxq for ; Mon, 12 Feb 2018 06:38:37 -0800 (PST) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FFA3126C2F for ; Mon, 12 Feb 2018 06:38:37 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id c78so9984132ywb.13 for ; Mon, 12 Feb 2018 06:38:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FMy6HYql1riFReO7cAblC+LIQY8LAaNAkxljYz+LHIA=; b=p7yeQw9XbRsQUyrm8EmyQCAKAwXn8Mcf6v+bo/R15y1tqljuIR2+lIx/Y+CPhb+fIF 12ZjhpctYpvyz5TlpCygQJq4UDBKvHiBPqxf0ta8NQsNyJ1f/2htZgIp/gDUi5N98PTR 0A0OCTPbUu86noMTt+P9eLJm47cD44FkfTxa5/m/C7PVRRtrtPbfzIJiKQ53kZmc7JWD u9YiMX9P7W3+JknV+5JTCZrBkILKMTaesOfkbGXNtzdLFIgmq6Qr/n931pCSObhmXOLc AmGZlGgdRr2bkeHiWtXJsxbJI9UvQFooazrb/GBPTiaz/ge4aLWvgsWiT1kFjIr7uJd8 rOUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FMy6HYql1riFReO7cAblC+LIQY8LAaNAkxljYz+LHIA=; b=nARyj0IMOaPv/wFHk2LHCXseNna4r9qaIb9U00g67+erbh5G2kRgBEVPc+iXtz3Fq+ j9/zxjhEnEF2WAFBzMdQsoScrEK/vn/BMieurUXeBu6txfXbjplOfapyuyUR6B126qPs QwcdLr/WqsZFd3Qj3Wfjd5So5jmh4Wq/v8BR+H0UDCgLB05lDPJAEv1vX2bGE7E/Ejwl GgkMRBCXJxgYMPBUZKmWlAR4+ks2tgyDTeOk20LuzLr3Wfm1AnJFTes/al34g9X4b6YY 9bype8h6dg0cKS+r6qKZ9yPC84kI9NJERXSFuvDkGqF4LF2120cChJc8Pw/eBzYLBYVN wNfg== X-Gm-Message-State: APf1xPCwnd9p+U0NiHr51gmDjrU88a7tfpSsVB7FJei8ZOnHMwTeDO4q jxa1JfuVHxz5P8w02H1ogT+VjOQb8JlN25i3riwBIQ== X-Google-Smtp-Source: AH8x224B1hb6gbdxFB3sgDBUXVQgNgI1dB01zbrnR0S9bVIeVeJBnLW5rJkcQBs1RNmYbqbJOkuVDFUlhnIZc0g1Nfo= X-Received: by 10.129.201.2 with SMTP id o2mr4991664ywi.2.1518446316411; Mon, 12 Feb 2018 06:38:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.160.201 with HTTP; Mon, 12 Feb 2018 06:37:55 -0800 (PST) In-Reply-To: <48986853.OUDrGe6E9e@pintsize.usersys.redhat.com> References: <48986853.OUDrGe6E9e@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Mon, 12 Feb 2018 06:37:55 -0800 Message-ID: To: Hubert Kario Cc: "" Content-Type: multipart/alternative; boundary="089e0821ead84d23d8056504d5dd" Archived-At: Subject: Re: [TLS] coalescing of CCS messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 14:38:39 -0000 --089e0821ead84d23d8056504d5dd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 12, 2018 at 6:10 AM, Hubert Kario wrote: > Rules for CCS messages in record layer are missing, allowing in theory > sending > multiple CCS messages in a single record layer > > I've proposed a PR that requires the same kind of processing rules for CC= S > and > Alert messages: https://github.com/tlswg/tls13-spec/pull/1146 - no > fragmentation and no coalescing. That automatically solves the empty CCS > record case. > https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#record-protoco= l "An implementation may receive an unencrypted record of type change_cipher_spec consisting of the single byte value 0x01 at any time after the first ClientHello message has been sent or received and before the peer=E2=80=99s Finished message has been received and MUST simply drop = it without further processing. Note that this record may appear at a point at the handshake where the implementation is expecting protected records and so it is necessary to detect this condition prior to attempting to deprotect the record. An implementation which receives any other change_cipher_spec value..." And of course Alert already has this rule: "Alert messages (Section 6 ) MUST NOT be fragmented across records and multiple Alert messages MUST NOT be coalesced into a single TLSPlaintext record. In other words, a record with an Alert type MUST contain exactly one message." -Ekr > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --089e0821ead84d23d8056504d5dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Feb 12, 2018 at 6:10 AM, Hubert Kario <hkario@redhat.com&g= t; wrote:
Rules= for CCS messages in record layer are missing, allowing in theory sending multiple CCS messages in a single record layer

I've proposed a PR that requires the same kind of processing rules for = CCS and
Alert messages: https://github.com/tlswg/tls13-spe= c/pull/1146 - no
fragmentation and no coalescing. That automatically solves the empty CCS record case.

<= div>
"An implementation may receive an unencrypted recor= d of type=20 change_cipher_spec consisting of the single byte value 0x01 at any time=20 after the first ClientHello message has been sent or received and before the peer=E2=80=99s Finished message has been received and MUST simply drop= it=20 without further processing. Note that this record may appear at a point at the handshake where the implementation is expecting protected=20 records and so it is necessary to detect this condition prior to=20 attempting to deprotect the record. An implementation which receives any other change_cipher_spec value..."

And of co= urse Alert already has this rule:
"Alert messages (Section 6) MUST NOT be fragmented across records and multiple Alert messages MUST=20 NOT be coalesced into a single TLSPlaintext record. In other words, a=20 record with an Alert type MUST contain exactly one message."

-Ekr

=C2=A0
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech Republic=
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--089e0821ead84d23d8056504d5dd-- From nobody Mon Feb 12 15:30:38 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90AA2126C25 for ; Mon, 12 Feb 2018 15:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 FLia1G4et_ns for ; Mon, 12 Feb 2018 15:30:34 -0800 (PST) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3E1E120726 for ; Mon, 12 Feb 2018 15:30:33 -0800 (PST) Received: by mail-wr0-x236.google.com with SMTP id o76so13767561wrb.7 for ; Mon, 12 Feb 2018 15:30:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Lj2MPvSpuchtLt84rsQ9KEiBATDzxjS0retrkYwazck=; b=trea1CFI7GNBuU187mmSEgbS14PIwC8sikHhH5TdgGL9McPxuimJ1xzy2rD7WHUKXq fWoacCIj3iU1wYajxVu5qJhW0AHY149n2KPry7SF9e3PLoOu5aAgOAmYGazpkHT8kI6Q dM9VmWTNAWi9v88aeLf3HWKBqbVaxsDW2qma+FTC8PQaB6t7KYYE6b6YKJi6aXmPUM94 LN83sGEFUjqnnjHP3mRa8CdXWhcdSxrfrbtiWkCYGCvjNu870Ref5gvpwWnyt2VnMf81 wanfgaFAV1weV5iMiIxAoyQqo0WVJq33wy1Ne+gy1MMNg/6BAaEmh2bI+5EVFLTGF3Dk Gpbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Lj2MPvSpuchtLt84rsQ9KEiBATDzxjS0retrkYwazck=; b=MG1R+6VhoVqwCveq3Chqq7BCQZw/ZQTmWbAVUsVdaU+AJeb7XEjhsbj4tFW09g/qCd vgvQF5Gvxb4V2a8UPWA5iJAHlBIs1b6nPpBeXX5/iNW2hYQ1XxF2gTJygk5fxXpQ3/e2 juJAQZlZaclGW91qM3tpHZsUKAFD1VhbNa6oQkSkTe/QqUUTzrFe4hUwqoKYz3xzRFyF fi8c+OtjTn+mKE3yRXFRtNuZ6Agpw294JcI6sPUel3qB1TUIJ/8LyhXErS5pHpElRG+w nd50K6CvnLKXIEdq+/DFpqz3NzYIhUb6uPLG+Y2FFYbes6YA8PQt8ZT8SOmIAW6da19Q Ou3g== X-Gm-Message-State: APf1xPBH0/CcGIs4p7B8QGvyYlypNPaNw0xWwL2R54EN0myx9Ed8jtPI 64NnjFwAFD1bIMloul/qojtqS4lHAjJa8TpxW1h+OQ== X-Google-Smtp-Source: AH8x227JH14He+5NCHNOmxS/GvVzSYlQQj7Szz1YyCSsX5U8QIq0SKSedWypsg2dMRLMQzjHRrb+b8ACAN4EYtcOHR0= X-Received: by 10.223.150.65 with SMTP id c1mr3200613wra.167.1518478232269; Mon, 12 Feb 2018 15:30:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.114.9 with HTTP; Mon, 12 Feb 2018 15:30:11 -0800 (PST) In-Reply-To: <20180201135947.77809B819EE@rfc-editor.org> References: <20180201135947.77809B819EE@rfc-editor.org> From: Adam Langley Date: Mon, 12 Feb 2018 15:30:11 -0800 Message-ID: To: RFC Errata System Cc: Wan-Teh Chang , Nikos Mavrogiannopoulos , =?UTF-8?Q?Joachim_Str=C3=B6mbergson?= , Simon Josefsson , Kathleen Moriarty , Eric Rescorla , Joseph Salowey , sean+ietf@sn3rd.com, xavier.bonnetain@inria.fr, tls@ietf.org Content-Type: multipart/alternative; boundary="001a1145a244a2a07005650c435c" Archived-At: Subject: Re: [TLS] [Technical Errata Reported] RFC7905 (5251) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 23:30:37 -0000 --001a1145a244a2a07005650c435c Content-Type: text/plain; charset="UTF-8" On Thu, Feb 1, 2018 at 5:59 AM, RFC Errata System wrote: > Original Text > ------------- > Poly1305 is designed to ensure that forged messages are rejected with > a probability of 1-(n/2^107), where n is the maximum length of the > input to Poly1305. In the case of (D)TLS, this means a maximum > forgery probability of about 1 in 2^93. > > Corrected Text > -------------- > Poly1305 is designed to ensure that forged messages are rejected with > a probability of 1-(n/2^106), where n is the maximum length of the > input to Poly1305. In the case of (D)TLS, this means a maximum > forgery probability of about 1 in 2^92. > I'm not sure that this errata report is correct. The full formula is beyond email HTML to express, but see the "Security Guarantee" section of https://cr.yp.to/mac/poly1305-20050329.pdf The section seems to be talking about blind forgeries, so C = 0. D = 1 because this is a per-attempt measure. Then we have 8*L/16 on the top of the fraction, which is 1/2 * L (where L = byte length of a message). If we multiply top and bottom by two, we get L / 2^107. For (D)TLS, with a maximum encrypted plaintext length of ~2^14, that gives 2^{-93}. Cheers AGL --001a1145a244a2a07005650c435c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 1, 2018 at 5:59 AM, RFC Errata System <rfc-editor@rfc-edit= or.org> wrote:
Original Text
-------------
=C2=A0 =C2=A0Poly1305 is designed to ensure that forged messages are reject= ed with
=C2=A0 =C2=A0a probability of 1-(n/2^107), where n is the maximum length of= the
=C2=A0 =C2=A0input to Poly1305.=C2=A0 In the case of (D)TLS, this means a m= aximum
=C2=A0 =C2=A0forgery probability of about 1 in 2^93.

Corrected Text
--------------
=C2=A0 =C2=A0Poly1305 is designed to ensure that forged messages are reject= ed with
=C2=A0 =C2=A0a probability of 1-(n/2^106), where n is the maximum length of= the
=C2=A0 =C2=A0input to Poly1305.=C2=A0 In the case of (D)TLS, this means a m= aximum
=C2=A0 =C2=A0forgery probability of about 1 in 2^92.
<= br>
I'm not sure that this errata report is correct.

The full formula is beyond email HTML to express, but see = the "Security Guarantee" section of=C2=A0=C2=A0https://cr.yp.to/mac/poly1305-20050329= .pdf

The section seems to be talking about bli= nd forgeries, so C =3D 0. D =3D 1 because this is a per-attempt measure. Th= en we have 8*L/16 on the top of the fraction, which is 1/2 * L (where L =3D= byte length of a message). If we multiply top and bottom by two, we get L = / 2^107. For (D)TLS, with a maximum encrypted plaintext length of ~2^14, th= at gives 2^{-93}.


Cheers
=
AGL
--001a1145a244a2a07005650c435c-- From xavier.bonnetain@inria.fr Mon Feb 12 16:22:47 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F7C12708C for ; Mon, 12 Feb 2018 16:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 k9hZy_wneipY for ; Mon, 12 Feb 2018 16:22:45 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 08625126DFF for ; Mon, 12 Feb 2018 16:22:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.46,504,1511823600"; d="scan'208,217";a="254558689" Received: from zmbs6.inria.fr ([128.93.142.19]) by mail3-relais-sop.national.inria.fr with ESMTP; 13 Feb 2018 01:22:42 +0100 Date: Tue, 13 Feb 2018 01:22:42 +0100 (CET) From: Xavier Bonnetain To: Adam Langley Cc: RFC Errata System , Wan-Teh Chang , Nikos Mavrogiannopoulos , Joachim =?iso-8859-1?Q?Str=F6mbergson?= , Simon Josefsson , Kathleen Moriarty , Eric Rescorla , Joseph Salowey , sean+ietf@sn3rd.com, tls@ietf.org Message-ID: <1245150098.5877048.1518481362605.JavaMail.zimbra@inria.fr> In-Reply-To: References: <20180201135947.77809B819EE@rfc-editor.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5877047_470151573.1518481362603" X-Originating-IP: [89.3.82.105] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF58 (Linux)/8.0.9_GA_6191) Thread-Topic: RFC7905 (5251) Thread-Index: G+tE9ts2TJRuTVNv+K8w/FZbuHsHBA== Archived-At: X-Mailman-Approved-At: Mon, 12 Feb 2018 22:22:29 -0800 Subject: Re: [TLS] [Technical Errata Reported] RFC7905 (5251) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2018 00:35:38 -0000 ------=_Part_5877047_470151573.1518481362603 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable ----- Mail original ----- > De: "Adam Langley" > =C0: "RFC Errata System" > Cc: "Wan-Teh Chang" , "Nikos Mavrogiannopoulos" > , "Joachim Str=F6mbergson" , "Simon > Josefsson" , "Kathleen Moriarty" > , "Eric Rescorla" , "Jose= ph > Salowey" , sean+ietf@sn3rd.com, "xavier bonnetain" > , tls@ietf.org > Envoy=E9: Mardi 13 F=E9vrier 2018 00:30:11 > Objet: Re: [Technical Errata Reported] RFC7905 (5251) > On Thu, Feb 1, 2018 at 5:59 AM, RFC Errata System < rfc-editor@rfc-editor= .org > > wrote: > > Original Text >=20 > > ------------- >=20 > > Poly1305 is designed to ensure that forged messages are rejected with >=20 > > a probability of 1-(n/2^107), where n is the maximum length of the >=20 > > input to Poly1305. In the case of (D)TLS, this means a maximum >=20 > > forgery probability of about 1 in 2^93. >=20 > > Corrected Text >=20 > > -------------- >=20 > > Poly1305 is designed to ensure that forged messages are rejected with >=20 > > a probability of 1-(n/2^106), where n is the maximum length of the >=20 > > input to Poly1305. In the case of (D)TLS, this means a maximum >=20 > > forgery probability of about 1 in 2^92. >=20 > I'm not sure that this errata report is correct. > The full formula is beyond email HTML to express, but see the "Security > Guarantee" section of https://cr.yp.to/mac/poly1305-20050329.pdf > The section seems to be talking about blind forgeries, so C =3D 0. D =3D = 1 > because this is a per-attempt measure. Then we have 8*L/16 on the top of = the > fraction, which is 1/2 * L (where L =3D byte length of a message). If we > multiply top and bottom by two, we get L / 2^107. For (D)TLS, with a maxi= mum > encrypted plaintext length of ~2^14, that gives 2^{-93}. > Cheers > AGL If we are in the situation C =3D 0, D =3D 1 and L=3D2^{14} for (D)TLS, the = forgery probability may indeed not be affected (and may even be smaller). H= owever, the explanation "Poly1305 is designed to ensure that forged message= s are rejected with a probability of 1-(n/2^107), where n is the maximum le= ngth of the input to Poly1305." is presenting Poly1305 as slightly stronger= than it really is (and there is an attack with success probability 2^{-106= } with C=3D1, D=3D1, L=3D1, as the hashing key r has 106 effective bits).= =20 Regards,=20 Xavier=20 ------=_Part_5877047_470151573.1518481362603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
De: "Adam Langley" <agl@google.com>= ;
=C0: "RFC Errata System" <rfc-editor@rfc-editor.org>
<= b>Cc: "Wan-Teh Chang" <wtc@google.com>, "Nikos Mavrogiannopoulos"= <nmav@redhat.com>, "Joachim Str=F6mbergson" <joachim@secworks.se&= gt;, "Simon Josefsson" <simon@josefsson.org>, "Kathleen Moriarty" <= ;Kathleen.Moriarty.ietf@gmail.com>, "Eric Rescorla" <ekr@rtfm.com>= , "Joseph Salowey" <joe@salowey.net>, sean+ietf@sn3rd.com, "xavier bo= nnetain" <xavier.bonnetain@inria.fr>, tls@ietf.org
Envoy=E9: Mardi 13 F=E9vrier 2018 00:30:11
Objet: Re: [Technical Errata R= eported] RFC7905 (5251)

On Thu, Feb 1, 2018 at 5:59 AM, RFC E= rrata System <rfc-editor@rfc-editor.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">Original Text
-------------
   Poly1305 is designed to ensure that forged messages are reject= ed with
   a probability of 1-(n/2^107), where n is the maximum length of= the
   input to Poly1305.  In the case of (D)TLS, this means a m= aximum
   forgery probability of about 1 in 2^93.

Corrected Text
--------------
   Poly1305 is designed to ensure that forged messages are reject= ed with
   a probability of 1-(n/2^106), where n is the maximum length of= the
   input to Poly1305.  In the case of (D)TLS, this means a m= aximum
   forgery probability of about 1 in 2^92.
<= br>
I'm not sure that this errata report is correct.
The full formula is beyond email HTML to express, but see the = "Security Guarantee" section of  https://cr.yp.to/mac/poly1305-2005= 0329.pdf

The section = seems to be talking about blind forgeries, so C =3D 0. D =3D 1 because this= is a per-attempt measure. Then we have 8*L/16 on the top of the fraction, = which is 1/2 * L (where L =3D byte length of a message). If we multiply top= and bottom by two, we get L / 2^107. For (D)TLS, with a maximum encrypted = plaintext length of ~2^14, that gives 2^{-93}.

Cheers

AGL
If we are in the situation C =3D 0, D =3D 1 and L=3D= 2^{14} for (D)TLS, the forgery probability may indeed not be affected (and = may even be smaller). However, the explanation "Poly1305 is designed to ens= ure that forged messages are rejected with a probability of 1-(n/2^107), wh= ere n is the maximum length of the input to Poly1305." is presenting Poly13= 05 as slightly stronger than it really is (and there is an attack with succ= ess probability 2^{-106} with C=3D1, D=3D1, L=3D1, as the hashing key r has= 106 effective bits).

Regards,
Xavier

------=_Part_5877047_470151573.1518481362603-- From nobody Tue Feb 13 09:08:29 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14B5126CE8; Tue, 13 Feb 2018 09:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Pj1893aFGr0T; Tue, 13 Feb 2018 09:08:20 -0800 (PST) Received: from mail-pl0-x234.google.com (mail-pl0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5187512D853; Tue, 13 Feb 2018 09:07:55 -0800 (PST) Received: by mail-pl0-x234.google.com with SMTP id f4so6919560plr.10; Tue, 13 Feb 2018 09:07:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7RVnq8g2/ZkMAhsOGv1x98TUiaIXL4+6eRampIvQWHs=; b=njJ3Kh+oJs/pP05r2hvF36gi29C8M3VauOEC8vihHnb2LoaaMoDCavCEAfLabgJHry x0O1P4pdSM+Ty0H+RWpV1RI9gM9iwlrGRf4eoRZXn++756oe6WR5WqxLyChbAFVpVPUv LM4QOzeZRjYn00WzoTLnpzrZcx4fNSwQRf0QtE+eTEiDqVOhP+PbORrCy0vTpJHNeEHs B2f8pHBYZ1hwEVDqII23Z5rHS03lD/C8ENB9l8MTEP3qdCRSPx19dy6Uhll/ypR5E/lv Iqk799O4rnuK8JbRc9vedc2tOLHHCrRVUggGo2FDZMHYD9vj5GPmaSn8GFgWnCwazYLw G0kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7RVnq8g2/ZkMAhsOGv1x98TUiaIXL4+6eRampIvQWHs=; b=dcVV533vbUOPyqMdt0clw81igG3FcSN6tcV6CAV7rQ/IRxGX+/0jrSQno8yz1WjKiX NaAxZ0pTbfjmpTU3AjlU6oDUQBbK51/Zu4ovqP+Iyb1oOzECW1Z7YvFxNwh0q38kdyhF NQrwgLpvPFoPM/4vgbJ/nKyIDNGn/V4e2AxijvXhYyVFylOrz3WzF9N0tMPZyNcdxytj 79O/CIFxIhM2cw7pKbDB6kn5Zfhrv+VJPdAv9nqJe27HAQUWlM7YuO+9+aDSPXWPqf+T DyHCd4uazlZGuQ9bDqGuMUtbadBOqNTFGCAwa7ikaYlsgJHBEcKR/Viiz2ENfr/LvTSb y8+Q== X-Gm-Message-State: APf1xPCHCIcFg2/8qIBXOOYLL2p1zdkPeiQvtZEtZlf7nxlrFGCSLODS v0z5IFDTm3PmjUU8hn1FLfkRG0+1YQSU7biLjxI= X-Google-Smtp-Source: AH8x224hIR7G7Cj8BykQ5DD8zH9VbG9/HfoQqE7BTwwehFdTqPzRqilzyLhX6JQ+i3OYwN0ROvgXi3IX+tUWQDG5Ugo= X-Received: by 2002:a17:902:6041:: with SMTP id a1-v6mr1687087plt.225.1518541674614; Tue, 13 Feb 2018 09:07:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.186.143 with HTTP; Tue, 13 Feb 2018 09:07:14 -0800 (PST) In-Reply-To: References: <151800968634.4877.12510609339415982154.idtracker@ietfa.amsl.com> <4c90bb83-5ba1-8193-df67-38e25f76caf8@nlnetlabs.nl> From: Kathleen Moriarty Date: Tue, 13 Feb 2018 12:07:14 -0500 Message-ID: To: Shumon Huque Cc: Willem Toorop , tls-chairs , draft-ietf-tls-dnssec-chain-extension@ietf.org, =?UTF-8?Q?Mirja_K=C3=BChlewind?= , TLS WG , Joseph Salowey , The IESG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-dnssec-chain-extension-06=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2018 17:08:24 -0000 On Thu, Feb 8, 2018 at 9:32 AM, Shumon Huque wrote: > On Thu, Feb 8, 2018 at 4:51 AM, Willem Toorop wrote= : >> >> Op 08-02-18 om 03:27 schreef Shumon Huque: >> > On Wed, Feb 7, 2018 at 8:21 AM, Mirja K=C3=BChlewind > > > wrote: >> > >> > Mirja K=C3=BChlewind has entered the following ballot position for >> > draft-ietf-tls-dnssec-chain-extension-06: No Objection >> > >> > >> > ---------------------------------------------------------------------- >> > COMMENT: >> > >> > ---------------------------------------------------------------------- >> > >> > Two minor, mostly editorial comments: >> > >> > 1) Intro (sec 2): " It also provides the >> > ability to avoid potential problems with TLS clients being unab= le >> > to >> > look up DANE records because of an interfering or broken >> > middlebox on >> > the path between the client and a DNS server." >> > Is that actually a well-known problem (can you provide a reference= ?) >> > >> > >> > Some folks (at Google and NLnet Labs if I recall; maybe others) have >> > done >> > measurements to show this is an actual problem -- for a relatively sma= ll >> > but >> > still non-trivial fraction of clients. We'll try to see if we can dig = up >> > specific >> > references to documents that could be cited. >> >> I wouldn't call it a relatively small fraction :) DNSSEC is severely >> hampered for end-entities by broken infrastructure in many different >> ways. Sometimes an upstream resolver can be used for positive DNSSEC >> answers (i.e. existing records), but not for non-existent or wildcard >> answers, because it simply doesn't forward the NSEC(3) proof for it. >> >> >> >> The last measurements we at NLnet Labs did was in July 2015: >> >> Gorj=C3=B3n, Xavier Torrent, and Willem Toorop. >> "Discovery method for a DNSSEC validating stub resolver." >> (2015) >> >> https://nlnetlabs.nl/pub/os3-2015-rp2-xavier-torrent-gorjon.pdf >> >> Measurements were done with RIPE Atlas, with at the time +-8200 probes. >> At the time only 56% of probes received enough DNSSEC data from their >> upstreams to be able to perform DNSSEC validation for both positive and >> non-existent answers (required for DANE). > > > Ah, thanks. I'd forgotten that it was so high! > > I think my "relatively small" comment was recalling an earlier study (I > think by > Google) that saw a breakage of around ~ 5%, but I think that was just > measuring > the ability to lookup and obtain less common RR types and did not measure > ability > to perform full DNSSEC validation. What's the behavior when the middlebox is a proxy, let's say existing a managed network? I presume from from section 3.1 that this negotiation doesn't work in that instance unless sites configured for this are not subject to the proxy as is often done for financial site access from corporate networks. It would be good to know if it does work and that is addressed with the text Mirja calls out for her #1 question. Having this clarified could be helpful. Thanks. > > Shumon. > --=20 Best regards, Kathleen From nobody Tue Feb 13 14:50:17 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDF712D835; Tue, 13 Feb 2018 14:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 AMRWJSSXeY4Q; Tue, 13 Feb 2018 14:50:08 -0800 (PST) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91DD0127137; Tue, 13 Feb 2018 14:50:08 -0800 (PST) Received: by mail-ot0-x22a.google.com with SMTP id 73so18749528oti.12; Tue, 13 Feb 2018 14:50:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YwEFBRbk9BpVkx9HbYlsK5B5u6LnJntBWk9S3y/KW/A=; b=nC3aDZog15OyuPZjnOnga0PgZlxj9c6kXq2sBaN6TQr0uWwyHTp9/R1EMqvOYI1piH 79Vneo0QXSjKpsCN3G2dU9D4apUBNaEWdT9S5Snj5ejYKKHRGhSWYyRuly7+f0io7TTJ 6HXg7w79cQG6BNYvL/FOS4pcQKJxDQmG7XwIs3H/y+h1EjkJm6GS1YDSDAjwgMr74zNm hap4JfN3egQf5XhsUOZOr/tVqaBhVhFH5PuIwhDA0EAwguatzQrzzCuv0d7fiX+CG6m1 mllr6wYrNUy0e85YqYIJ3Q5hTpit4iFscPH2zMEGnLdHJMXDIrkyxfFNHUsOOp7V7HdP yyIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YwEFBRbk9BpVkx9HbYlsK5B5u6LnJntBWk9S3y/KW/A=; b=Nr/9IXtiiClvUtX+BEVd7U/x/yrYMEKNEck6+xQtFwpr4eSuVX/YeUbFVuZnXew2xP bX6c+m/uGBIs8uCbiOlFhef9G+SrISCvbYBQCtnJ5MAJYeeRwSupRktHSh8m0k7cbFHY PkKGv6fbpsTcYHCmzo4+UZTxECNTCmIRiOhftRTaqPIh/1M3VM+GO5kJ6ThH7zkLYMeB /2be2JhyTHhY0tCpUe9vNe7vpoeTAH7gsXPeQxgn3TfI8zOVoKlL7kC9i1C7vgjRcDm5 DFe4wreDr44PiyBbB4v7X++wTZkcFaQqmZUEUNSXtEUFUUAmZxSCCUa+HzCNo3qxvgQM t9HQ== X-Gm-Message-State: APf1xPDaOrvSpj3j7IK4ETUyFcWLnhVvfKwV+M3N0gp9kOfPArX695Dw /873aIRc9YovuYr1ZfEWFTTQTaSiZGGuHlWCw5U= X-Google-Smtp-Source: AH8x225EKH70PO8PFFXn6oHDcphUtS0Kf0eSanHX6WKprrikGZaMmrascx07+N/MZTzyQhGCTsULILcb332jzPsL2jc= X-Received: by 10.157.113.205 with SMTP id z13mr2260564otj.71.1518562207835; Tue, 13 Feb 2018 14:50:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.196 with HTTP; Tue, 13 Feb 2018 14:50:07 -0800 (PST) In-Reply-To: References: <151800968634.4877.12510609339415982154.idtracker@ietfa.amsl.com> <4c90bb83-5ba1-8193-df67-38e25f76caf8@nlnetlabs.nl> From: Martin Thomson Date: Wed, 14 Feb 2018 09:50:07 +1100 Message-ID: To: Kathleen Moriarty Cc: Shumon Huque , draft-ietf-tls-dnssec-chain-extension@ietf.org, The IESG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , tls-chairs , TLS WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-dnssec-chain-extension-06=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2018 22:50:10 -0000 On Wed, Feb 14, 2018 at 4:07 AM, Kathleen Moriarty wrote: > What's the behavior when the middlebox is a proxy, let's say existing > a managed network? I presume from from section 3.1 that this > negotiation doesn't work in that instance unless sites configured for > this are not subject to the proxy as is often done for financial site > access from corporate networks. It would be good to know if it does > work and that is addressed with the text Mirja calls out for her #1 > question. Having this clarified could be helpful. If there is a MitM, then this extension simply isn't negotiated. That's pretty well understood. I don't see why that requires special mention. From nobody Tue Feb 13 15:15:56 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B40126D74 for ; Tue, 13 Feb 2018 15:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 PgJdSSwnuvFm for ; Tue, 13 Feb 2018 15:15:54 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E391B1271DF for ; Tue, 13 Feb 2018 15:15:53 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id l9so5377716qtj.9 for ; Tue, 13 Feb 2018 15:15:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=44CzsFTdXLlkhFrxGkpmRm82IQPmlo7r1mOc6ljAKzs=; b=GtfOcZp91o8H38pKfN8pFwYFQjF0z9r8L7vK+ML0qtVvpxtEXsjuz5VKcFHqNTsQxS ReFUIPpzGRBbF5Vdr0xyHxxtrDG/TFfOUAg60j6MGf0QvolPcumlZcCkDyyYvpuZoXOx hzIlFdBODdPhlBnm4dNgDxIrgir1lIRbDqIaA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=44CzsFTdXLlkhFrxGkpmRm82IQPmlo7r1mOc6ljAKzs=; b=CHJTt4CtnCbZ3i6YJcJG9k/0iaB9Aeo+b5QGX7iJBXvGHkEo+prn8qVCQ0EeMkkWZl CtfuPlUEH1H9hcxuiiGwFStEmcHjgWaOhraJhU4ggTwlpPdlucsXgZzRiqopnCYC+kIp HL59biNBfUlIWZDCXXBlDne4NHeWgGh4wcnf4dp8JYI/PQnaMSk+gsNVJUHyTLV62fyi JggwNEAXHMZsESSjLgo9aQBUGSIlo1GmDwXkpvZcCN8w6apXKyLuAS50WERnuqELtRRx JOYezsd/Yus5qEN4TkeR+19iACjSLWBuXx5i1I4savCxOek+kmZ4GIE+E6HX+MoviLZQ KJmA== X-Gm-Message-State: APf1xPAByn9E/1CTplCyREBF3D98dO/IqJKbwdhkJAjQlUJW2oAh0KvH GBxmy+6SdOk9mEfhLU29WoOp5+21qZI= X-Google-Smtp-Source: AH8x226F1IjR37pYFYMaX1GxA0gRdRIWj4mr3AaEbHIf8ZZf70qYgPULB0vzZWDS1NMbbz7hl00Erg== X-Received: by 10.200.17.1 with SMTP id c1mr4854632qtj.150.1518563752706; Tue, 13 Feb 2018 15:15:52 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id n23sm2169578qtl.39.2018.02.13.15.15.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Feb 2018 15:15:52 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 13 Feb 2018 18:15:48 -0500 References: <0BD40460-F194-4A2B-8E7C-4FD2D084111B@sn3rd.com> To: "" In-Reply-To: <0BD40460-F194-4A2B-8E7C-4FD2D084111B@sn3rd.com> Message-Id: X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Recommended yes->no for max_fragment_length extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2018 23:15:56 -0000 Just a reminder ... > On Feb 7, 2018, at 15:33, Sean Turner wrote: >=20 > All, >=20 > Prior to pushing draft-ietf-tls-record-limit [0] to the IESG, the WG = needs to confirm that draft-ietf-tls-record-limit should change = max_fragment_length [1] from =E2=80=9CYes=E2=80=9D in our soon to be = created Recommended column (see [2]) to a =E2=80=9CNo=E2=80=9D. Please = indicate by 2359 UTC on 14 Feb whether you are for or against this = change; and if you are against please indicate why. >=20 > spt >=20 > [0] https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ > [1] https://datatracker.ietf.org/doc/rfc6066/ > [2] = https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ From nobody Wed Feb 14 01:20:06 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA8C126D73 for ; Wed, 14 Feb 2018 01:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001] autolearn=no autolearn_force=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 W3RPFDskmfTk for ; Wed, 14 Feb 2018 01:20:03 -0800 (PST) Received: from garfield.picty.org (garfield.picty.org [82.231.235.137]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7F19126B6D for ; Wed, 14 Feb 2018 01:20:02 -0800 (PST) Received: from [127.0.0.1] (unknown [80.12.43.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by garfield.picty.org (Postfix) with ESMTPSA id 25B06A2 for ; Wed, 14 Feb 2018 10:20:00 +0100 (CET) To: tls@ietf.org References: <151696190108.24397.6150515497869897080@ietfa.amsl.com> From: Olivier Levillain Message-ID: <2829c71e-d97a-ccd6-6252-b6b5439e6c70@ssi.gouv.fr> Date: Wed, 14 Feb 2018 10:19:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <151696190108.24397.6150515497869897080@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: fr-FR Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 09:20:05 -0000 Hi list, Le 26/01/2018 à 11:18, internet-drafts@ietf.org a écrit : > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Layer Security WG of the IETF. > > Title : Transport Layer Security (TLS) Certificate Compression > Authors : Alessandro Ghedini > Victor Vasiliev > Filename : draft-ietf-tls-certificate-compression-02.txt > Pages : 7 > Date : 2018-01-26 I am sorry I am late in the process of commenting this draft, but I have a question about the CompressedCertificate message: why does it contain an uncompressed_length field? What is the point of this field which can not be trusted? If the idea is to give a hint of how long a certificate is, we already know that. Since the whole goal of this draft is to reduce the size of the message, I would strongly suggest this field be removed. It is too much a temptation to be considered as a reliable information for shaky implementations. Best regards, Olivier Levillain From nobody Wed Feb 14 07:32:19 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C856124C27 for ; Wed, 14 Feb 2018 07:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 Fz1WUclb7359 for ; Wed, 14 Feb 2018 07:32:15 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A84931200C1 for ; Wed, 14 Feb 2018 07:32:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id E80C54F83E; Wed, 14 Feb 2018 17:32:12 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id lV6Sep3hg01F; Wed, 14 Feb 2018 17:32:12 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id F086D73; Wed, 14 Feb 2018 17:32:09 +0200 (EET) Date: Wed, 14 Feb 2018 17:32:09 +0200 From: Ilari Liusvaara To: Olivier Levillain Cc: tls@ietf.org Message-ID: <20180214153209.GA14576@LK-Perkele-VII> References: <151696190108.24397.6150515497869897080@ietfa.amsl.com> <2829c71e-d97a-ccd6-6252-b6b5439e6c70@ssi.gouv.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2829c71e-d97a-ccd6-6252-b6b5439e6c70@ssi.gouv.fr> User-Agent: Mutt/1.9.3 (2018-01-21) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 15:32:18 -0000 On Wed, Feb 14, 2018 at 10:19:58AM +0100, Olivier Levillain wrote: > Hi list, > > Le 26/01/2018 à 11:18, internet-drafts@ietf.org a écrit : > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Transport Layer Security WG of the IETF. > > > > Title : Transport Layer Security (TLS) Certificate Compression > > Authors : Alessandro Ghedini > > Victor Vasiliev > > Filename : draft-ietf-tls-certificate-compression-02.txt > > Pages : 7 > > Date : 2018-01-26 > > > I am sorry I am late in the process of commenting this draft, but I have > a question about the CompressedCertificate message: why does it contain > an uncompressed_length field? To know beforehand how much memory to allocate so one is able to perform oneshot decompression. > What is the point of this field which can not be trusted? If the idea is > to give a hint of how long a certificate is, we already know that. The compression ratio can vary. > Since the whole goal of this draft is to reduce the size of the message, > I would strongly suggest this field be removed. It is too much a > temptation to be considered as a reliable information for shaky > implementations. It actaully makes writing solid decompressors easier. At least if the decompressor API is at least as good as zlib. If you know the sizes up front, you can do the decompression in one shot, and check that the availables are zero afterwards. Compare this with messing with variable-sized buffers. The chances of mistake are greatly increased if one has to resize buffers. -Ilari From nobody Thu Feb 15 05:10:57 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 234F212711E; Thu, 15 Feb 2018 05:10:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151870025109.7537.10984901071376435386@ietfa.amsl.com> Date: Thu, 15 Feb 2018 05:10:51 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-iana-registry-updates-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 13:10:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : IANA Registry Updates for TLS and DTLS Authors : Joe Salowey Sean Turner Filename : draft-ietf-tls-iana-registry-updates-04.txt Pages : 18 Date : 2018-02-15 Abstract: This document describes a number of changes to (D)TLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the (D)TLS-related registries undertaken as part of the TLS1.3 development process. This document updates many (D)TLS RFCs (see updates header). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-04 https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-updates-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-iana-registry-updates-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 Thu Feb 15 05:12:48 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C2512420B for ; Thu, 15 Feb 2018 05:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 lIYnRw4aDdRC for ; Thu, 15 Feb 2018 05:12:36 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D2E212DA00 for ; Thu, 15 Feb 2018 05:12:36 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id f18so11755298qth.11 for ; Thu, 15 Feb 2018 05:12:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=//VR0E3K2Cdz5bs1iocvXdsye8xsjzcbR8QTl3Zjf+0=; b=QivAHz/Qwoo/rbj1HSEc27yvltDPXoiSjVZg+Ce7Y0Wb890ojC36XTED7+Jp2rewsZ 27+yPtqslikiRkYsxMJpUkEvPn/gDL7JkxcchPR01PIhK5Np1DNH7skWaMF/bQ+8eKoJ ISrnlyPrBY76WRYg6IMv6vZzC+aFdJuizWvao= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=//VR0E3K2Cdz5bs1iocvXdsye8xsjzcbR8QTl3Zjf+0=; b=mhTmVi+TnsvSgNEkY39fWblGX47qsWaidb72LN1rPRQ/Uxfz3qLX2VhOnzPIpxMK2l qGa9hI+kCdOjgDgSXrGNSNfMbhMf7+HJ5Fr211TwpnqvAlMaPFH8fx9ulBdDNwKCt4Vx 8oOusTSYmwBvmzpzQ9+QGySf9pWa4fGYAOHjJUKpH/qdbMVbkNi1QxUzgkvWGLfTXgox ogQfZ0vAtXwO4brJM11mmjTl3pNXtjwWIDHTI2kjeW9WkXHmm2x0IT+Vxy6g/DM9PnYT AVR80rL4hBqtv8kassdLYBt/+WaTV/o6VQt4JVcM355Y14Zsu41RZv0qOs1do8U9e23w zcNw== X-Gm-Message-State: APf1xPB6FgmQ4J8JcCtempUraaovX+J6DPXyc9Jd1N+PnfiysDBw8F4D 5ZFdujg4orQwz/JSJXlKwG3A6Q== X-Google-Smtp-Source: AH8x226L+bmY4cdBg5wySKl1Gu7IttJQ7J9hEEhnjJsuIFNst+2lteFdbfEDYSpvx2NiIiu52ugGhw== X-Received: by 10.200.5.75 with SMTP id c11mr3900595qth.47.1518700355287; Thu, 15 Feb 2018 05:12:35 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id h5sm10488657qkd.61.2018.02.15.05.12.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Feb 2018 05:12:34 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: <151870025109.7537.10984901071376435386@ietfa.amsl.com> Date: Thu, 15 Feb 2018 08:12:33 -0500 Cc: "" Content-Transfer-Encoding: quoted-printable Message-Id: References: <151870025109.7537.10984901071376435386@ietfa.amsl.com> To: Kathleen Moriarty , Stephen Farrell X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-iana-registry-updates-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 13:12:44 -0000 Kathleen and Stephen, This version incorporates the WGLC issues. The authors believe this is = now ready for IETF LC. spt > On Feb 15, 2018, at 08:10, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Layer Security WG of the = IETF. >=20 > Title : IANA Registry Updates for TLS and DTLS > Authors : Joe Salowey > Sean Turner > Filename : draft-ietf-tls-iana-registry-updates-04.txt > Pages : 18 > Date : 2018-02-15 >=20 > Abstract: > This document describes a number of changes to (D)TLS IANA = registries > that range from adding notes to the registry all the way to changing > the registration policy. These changes were mostly motivated by WG > review of the (D)TLS-related registries undertaken as part of the > TLS1.3 development process. This document updates many (D)TLS RFCs > (see updates header). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-04 > = https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-updates= -04 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-iana-registry-updates-0= 4 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Thu Feb 15 05:18:59 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B8D12DA00 for ; Thu, 15 Feb 2018 05:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 bB2gyZJvkPyf for ; Thu, 15 Feb 2018 05:18:55 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 507B112420B for ; Thu, 15 Feb 2018 05:18:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CF617BE73; Thu, 15 Feb 2018 13:18:52 +0000 (GMT) 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 JRedg8BfRrrv; Thu, 15 Feb 2018 13:18:52 +0000 (GMT) Received: from [134.226.62.152] (cswireless62-152.scss.tcd.ie [134.226.62.152]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8B98FBE64; Thu, 15 Feb 2018 13:18:52 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1518700732; bh=ZPXquXhLcFNz25RFUCfaX+A1zg8AN0dtCDKmrcgsM70=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=rOpyORcVbqjGoWvdBvO7lqlLJ9BvLx0imTWRU6bgtXOk9jO0UNOkwrwkfYJxvld/g eNYwYmjGMBKm7SkvDxvpFl3e4mA9QlqFDxdM0f9Q2MNjDF0nlDt25Nk6bBl5Pn7eoI 4QNqWJQ4nwbH5B7YKZmacH+kodgDbW240nkP101g= To: Sean Turner , Kathleen Moriarty Cc: "" References: <151870025109.7537.10984901071376435386@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: <1275a445-ff88-919b-17cb-8ad952a0d670@cs.tcd.ie> Date: Thu, 15 Feb 2018 13:18:50 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VMiZtcAfw4tgKdz6FxT2ZYNe3Q34wGcBz" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-iana-registry-updates-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 13:18:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VMiZtcAfw4tgKdz6FxT2ZYNe3Q34wGcBz Content-Type: multipart/mixed; boundary="gfm6HORgz3sRyIN22X6Wj2nMQj9mEH5Ix"; protected-headers="v1" From: Stephen Farrell To: Sean Turner , Kathleen Moriarty Cc: "" Message-ID: <1275a445-ff88-919b-17cb-8ad952a0d670@cs.tcd.ie> Subject: Re: I-D Action: draft-ietf-tls-iana-registry-updates-04.txt References: <151870025109.7537.10984901071376435386@ietfa.amsl.com> In-Reply-To: --gfm6HORgz3sRyIN22X6Wj2nMQj9mEH5Ix Content-Type: multipart/mixed; boundary="------------A4F35BBBEDBE0E94BFF25574" Content-Language: en-GB This is a multi-part message in MIME format. --------------A4F35BBBEDBE0E94BFF25574 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 15/02/18 13:12, Sean Turner wrote: > Kathleen and Stephen, >=20 > This version incorporates the WGLC issues. The authors believe this is= now ready for IETF LC. As shepherd, I concur that this seems to address all the issues raised as per list discussion. This is a clearly non-crazy update:-) Cheers, S. >=20 > spt >=20 >> On Feb 15, 2018, at 08:10, internet-drafts@ietf.org wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >> This draft is a work item of the Transport Layer Security WG of the IE= TF. >> >> Title : IANA Registry Updates for TLS and DTLS >> Authors : Joe Salowey >> Sean Turner >> Filename : draft-ietf-tls-iana-registry-updates-04.txt >> Pages : 18 >> Date : 2018-02-15 >> >> Abstract: >> This document describes a number of changes to (D)TLS IANA registrie= s >> that range from adding notes to the registry all the way to changing= >> the registration policy. These changes were mostly motivated by WG >> review of the (D)TLS-related registries undertaken as part of the >> TLS1.3 development process. This document updates many (D)TLS RFCs >> (see updates header). >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/= >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-tls-iana-registry-updates-04 >> https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-upd= ates-04 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-iana-registry-updat= es-04 >> >> >> Please note that it may take a couple of minutes from the time of subm= ission >> 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/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 --=20 PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-) --------------A4F35BBBEDBE0E94BFF25574 Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------A4F35BBBEDBE0E94BFF25574-- --gfm6HORgz3sRyIN22X6Wj2nMQj9mEH5Ix-- --VMiZtcAfw4tgKdz6FxT2ZYNe3Q34wGcBz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJahYi6AAoJEFqy+vF7Fyvq0HYP/03duD4cGVFidJmwRigVBYCO KGm+iq6shqHB++JGtsfCUpPL26ofiB56e0coBO7nJWgrjaWX7406C99xfmmclOsB sFI5m+RfcWzJcW1NXuUVRiKNns12esUbMhq4bRxlcH8oTVUtDX3mwSdyeQBD6GWx cWAoqs6bf/wEDO6vTpBG+X2oKUW10RSHRiN9EaJzgQHNgUZxnt9F6icUIwzJVBZD EFFP+V9Iv8szWOylSdlCkClJQPPpchXXg+AuEiUhFEDy1n8NrzFUH5SPPVs/egc1 sxtG/EaaP9nL4oHN3IzIGkmmBCHbl5+BfFhWlqlQzpaw1r07jST+eC7O1e2l8HgJ IbElUPHUx8WmD+S86smfEMdinYhaPxYHMjswlETmVZD08Jtn4f7uuAvBUsigNmP3 7xyZgYXO58boiiT1w5agXh3Zt/lOPe35NbevgP56gVOti/Q9YGTL10kswoRe+M2d bG2ltydUHMy476tw7R2B7vLopBfuWzhYPgR9ONppyYsXjhFKnznHsXIoEuarvqtr +BXri1DQFU6eBan3h73B8ixEmBqzXSpGcZBryc0B0Y/7NLWEhcvl1glTN5cGcUxw yl+K1cwdhlxTqCgHk5zfKKSeeCwFD5Vdi1dgsbrNc7osbR0SYy9mG5tlSyLbWM2q rIXih/J/lwrkq6mKQVRf =1nWb -----END PGP SIGNATURE----- --VMiZtcAfw4tgKdz6FxT2ZYNe3Q34wGcBz-- From nobody Thu Feb 15 05:36:05 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151AE12DA04 for ; Thu, 15 Feb 2018 05:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 HOqnkOw5QQFz for ; Thu, 15 Feb 2018 05:36:01 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25B5512420B for ; Thu, 15 Feb 2018 05:36:01 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id x27so11851473qtm.12 for ; Thu, 15 Feb 2018 05:36:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=fci3puuE9dwNdUoKQYZ4vkQJw78XLCn4/iWzG3iLjAs=; b=aEfs7DLvU7tdUBU1zEqoyH0Bk4rUVYa9z5yyBjALlEAkpcBglAWxPr6ijpRBNeCsn0 wYQDb4KFh6vttdO6U4SilSPrL1/INek9cW9CtxHWbUW3xpunia2F22Mk00VOJZiMjure ywrnNO1SOTfCe1FPrMd9OT8z4JVRti0q2rzXc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=fci3puuE9dwNdUoKQYZ4vkQJw78XLCn4/iWzG3iLjAs=; b=VEZUOTdZuxmTsEyomraOAt4plnZFHZUdl8sDTMydtSBbvzcKtyft92xXle+83Z9aG5 +9BHpG2TqVuwrByzgMu7x68uC+x3NFyxcjA1Or+qj+mmI4vGfkKPOWtglbnoy4E1fZZv /TVV58tfCky8V4tZS25uBrnZwerkaz3UNtGFAKjFqraoDVt0N7q4oYeoCcpHnJa1U9s5 zpAw63ZQJFD/OtchLbb2EOlXAskxG2iXpNXuLVDMd4K4t7Boq/j7qBN1xeqBRQn8oMd1 BXDOfQvKDdj0hbNfLUou1Gt9DD5lD4OzcLolequ9/W2Q8IC/N7Rzir9Ju/QGQyXXDyRF xKww== X-Gm-Message-State: APf1xPDoJblKMnz7idUMR8eaxNQXw0B7+0En6igq85GzwIFT9nOKGvuj yfyRGDQAyOZDPxqDGCKeKgx69PQNQzo= X-Google-Smtp-Source: AH8x226CTycCYMEXtk3pBysokuOWeaWOvsyTRuDOd02t2dlr7T2RwPHnbi7xousSOHvEQcuSXl0udA== X-Received: by 10.200.36.37 with SMTP id c34mr4256802qtc.38.1518701759983; Thu, 15 Feb 2018 05:35:59 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id d127sm4056090qkg.11.2018.02.15.05.35.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Feb 2018 05:35:59 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 15 Feb 2018 08:35:58 -0500 References: <0BD40460-F194-4A2B-8E7C-4FD2D084111B@sn3rd.com> To: "" , Martin Thomson In-Reply-To: <0BD40460-F194-4A2B-8E7C-4FD2D084111B@sn3rd.com> Message-Id: X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Recommended yes->no for max_fragment_length extension? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 13:36:03 -0000 There were a few yeses and no nos. I=E2=80=9Dm going to go ahead and = declare this rough consensus, with the thought that if there are those = who object there is still time during the IETF LC. Martin - please spin a new version incorporating PR#14 to address this = issue. Once I see a new version I=E2=80=99ll push it towards Kathleen. spt > On Feb 7, 2018, at 15:33, Sean Turner wrote: >=20 > All, >=20 > Prior to pushing draft-ietf-tls-record-limit [0] to the IESG, the WG = needs to confirm that draft-ietf-tls-record-limit should change = max_fragment_length [1] from =E2=80=9CYes=E2=80=9D in our soon to be = created Recommended column (see [2]) to a =E2=80=9CNo=E2=80=9D. Please = indicate by 2359 UTC on 14 Feb whether you are for or against this = change; and if you are against please indicate why. >=20 > spt >=20 > [0] https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ > [1] https://datatracker.ietf.org/doc/rfc6066/ > [2] = https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ From nobody Thu Feb 15 05:50:21 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC13B12420B; Thu, 15 Feb 2018 05:50:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151870261978.7622.15219442852417727221@ietfa.amsl.com> Date: Thu, 15 Feb 2018 05:50:19 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-tls13-24.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 13:50:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : The Transport Layer Security (TLS) Protocol Version 1.3 Author : Eric Rescorla Filename : draft-ietf-tls-tls13-24.txt Pages : 155 Date : 2018-02-15 Abstract: This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-tls13-24 https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-24 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-24 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 Thu Feb 15 05:53:21 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969D512DA3E for ; Thu, 15 Feb 2018 05:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 wgOxtREjJIFd for ; Thu, 15 Feb 2018 05:53:10 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 215A012DA1C for ; Thu, 15 Feb 2018 05:53:10 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id u6so11920293qtg.13 for ; Thu, 15 Feb 2018 05:53:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=YycHiBrJ8LYlVORbzPgguIG2QzqH0Q3fNfyqWC/42fc=; b=YQ4eCaSe8LVDHhmXWsiI7cUmJVWFbyuihWZZ23KBJ7Lot2vYETpG+nJR3ebPhv4LCE lLLC7XT032gloUDBZGl9ewFlFOmhAHlKmjCFFusjJtqUpkNAGSYPvp+s8hOaERcvFaHC YXCzV7EpEFQ4IZnRTLqKj1w5lkz7489Ljt9zM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=YycHiBrJ8LYlVORbzPgguIG2QzqH0Q3fNfyqWC/42fc=; b=gpqvx/C/JBD2Cl/MDWL6KQz3biV1FqmtINAEyf63ZsAoG3gYaemkm3Ier0phBpvHB3 azqW9s8lv2zaZ4ahQ+Tm1HAz92Nzj8D+mBdruwBiZeNE9xDbrNpMXfulpbuw7jYi3tqf WPfz1HDV0cK3Pa1YFUzxA58GsUGLV8wR/Mx7nWOzNILUBIpWpOXFjKuiqgCoVUwDeMNJ o4/Fp9xkM9Zl6dvA0m42foMnA11iu02Qk4Jr3HHaWLa4z/ajTnfJ1Exu+b8fSCeVbMm7 g7KNXFzVFAfTPe4vY4WbfSkiS+XnQdyR2PgYkXcA2w/htKXfgcg8ybzdzFA+VMFaDnvY hHiA== X-Gm-Message-State: APf1xPDdQhRlkuyMcKGAPtaAETRyRzimCP0ygSikoPjBEs2yl8Vn3IhG mSRQhwo1C3H7PcUA8kKifYil+2/icW4= X-Google-Smtp-Source: AH8x225P7ydm7pu7dYIsXhjyrgGewDRA6bYuxpiHbRvBCN3YC55vI22uxqzEy+RGdgbgazxkwsvnOg== X-Received: by 10.200.20.13 with SMTP id k13mr4413279qtj.137.1518702789065; Thu, 15 Feb 2018 05:53:09 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id u71sm7745858qki.51.2018.02.15.05.53.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Feb 2018 05:53:08 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 15 Feb 2018 08:53:07 -0500 References: <151870261978.7622.15219442852417727221@ietfa.amsl.com> To: "" In-Reply-To: <151870261978.7622.15219442852417727221@ietfa.amsl.com> Message-Id: <4FD1B8E2-DCB7-457D-ACB8-22CABF8ED032@sn3rd.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-tls13-24.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 13:53:14 -0000 This version resolves all outstanding WGLC comments. I will shortly = move the draft to =E2=80=9CPublication Requested=E2=80=9D, which will = pass it to Kathleen for her review and subsequently IETF LC. spt > On Feb 15, 2018, at 08:50, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Layer Security WG of the = IETF. >=20 > Title : The Transport Layer Security (TLS) Protocol = Version 1.3 > Author : Eric Rescorla > Filename : draft-ietf-tls-tls13-24.txt > Pages : 155 > Date : 2018-02-15 >=20 > Abstract: > This document specifies version 1.3 of the Transport Layer Security > (TLS) protocol. TLS allows client/server applications to = communicate > over the Internet in a way that is designed to prevent = eavesdropping, > tampering, and message forgery. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-tls13-24 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-24 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-tls13-24 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Feb 15 05:54:38 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 463E612DA07; Thu, 15 Feb 2018 05:54:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sean Turner To: X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Cc: Sean Turner , iesg-secretary@ietf.org, tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org Message-ID: <151870287628.7541.593435688547795665.idtracker@ietfa.amsl.com> Date: Thu, 15 Feb 2018 05:54:36 -0800 Archived-At: Subject: [TLS] Publication has been requested for draft-ietf-tls-tls13-24 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 13:54:36 -0000 Sean Turner has requested publication of draft-ietf-tls-tls13-24 as Proposed Standard on behalf of the TLS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ From nobody Thu Feb 15 07:45:45 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C5712DA4F; Thu, 15 Feb 2018 07:45:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sean Turner To: X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Cc: iesg-secretary@ietf.org, stephen.farrell@cs.tcd.ie, Stephen Farrell , tls-chairs@ietf.org, tls@ietf.org Message-ID: <151870954331.7416.14346127437240741646.idtracker@ietfa.amsl.com> Date: Thu, 15 Feb 2018 07:45:43 -0800 Archived-At: Subject: [TLS] Publication has been requested for draft-ietf-tls-iana-registry-updates-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 15:45:43 -0000 Sean Turner has requested publication of draft-ietf-tls-iana-registry-updates-04 as Proposed Standard on behalf of the TLS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ From nobody Thu Feb 15 07:46:56 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AA5127978 for ; Thu, 15 Feb 2018 07:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 6qaZCNX0GKMd for ; Thu, 15 Feb 2018 07:46:53 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE5F4126BF6 for ; Thu, 15 Feb 2018 07:46:52 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id d26so136339qtj.4 for ; Thu, 15 Feb 2018 07:46:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xFZtNa3i3x3qFIa/Joj8lLjw9zRRPwMD27xaS7A5VwA=; b=c+ORKBmXMpbxJJy9EcHMf+CxRTzdpApkNo4V3HxykzKNWBBMF8Qsn9X60rFe1gNlxy dBVjSHtGilzt/MdlQyFpXqjqEMLFxz3Gm+hPhH4ErZIuYtyMgIMYT8rbYCcAfadpjLAl aqqpVPeM6tapdnAzxZ+mTn8a7B6VOMspfvlWw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xFZtNa3i3x3qFIa/Joj8lLjw9zRRPwMD27xaS7A5VwA=; b=cCTtbKFC7bM5V7GrLzKdawc0vrSy9vtR5EjS+xsX4DzxIgY3rdEbUV25ivT/IFZLvL oYcxf2fvAk3PqfIA82W6E4EH6YNxGKEhpEcrynshOUaLLhhJ0awKgAq8n2RWA/JcunTi ntnjksLeU8cmcZPKrGbo5taslZJ3Zb19YASvFMrM5a9Ec9fwhV1H+nn9SpC4Xt82BSlP /hJxXAAjqWGYcENTnJSBt+mwJnePBravtOw/3DhoAgZUNCG/QR8zY9LS9YvyZlSJDoMP DgvzfgJyHfciSoy8+rKTYkL4oLfwOGwJZENgkFtyoMNVM4aLwDyfKVtIozKmPecGcQjR RvRA== X-Gm-Message-State: APf1xPALMMlFqZle21hzkRWpZMsNgqEikAXyjIZRnJ3ClUI1JK0U/bGX VBwmGdR97x/bP7v+tbCdyrYVYZetZqE= X-Google-Smtp-Source: AH8x225ZRryeMuCazr1CB80BzrYkkGRZyvmNO7lamdSmoMXEh0EQvV1GA+4ybmsAZstX+9ZUmmckuA== X-Received: by 10.200.44.154 with SMTP id 26mr4930938qtw.214.1518709611889; Thu, 15 Feb 2018 07:46:51 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id h200sm5811848qke.66.2018.02.15.07.46.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Feb 2018 07:46:51 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: <151870954331.7416.14346127437240741646.idtracker@ietfa.amsl.com> Date: Thu, 15 Feb 2018 10:46:49 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <151870954331.7416.14346127437240741646.idtracker@ietfa.amsl.com> To: "" X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Publication has been requested for draft-ietf-tls-iana-registry-updates-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 15:46:55 -0000 Note that I pushed the button after I asked Kathleen. spt > On Feb 15, 2018, at 10:45, Sean Turner wrote: >=20 > Sean Turner has requested publication of = draft-ietf-tls-iana-registry-updates-04 as Proposed Standard on behalf = of the TLS working group. >=20 > Please verify the document's state at = https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ >=20 From nobody Thu Feb 15 11:46:20 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7359124D68 for ; Thu, 15 Feb 2018 11:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 kKsKxcV9XL_X for ; Thu, 15 Feb 2018 11:46:17 -0800 (PST) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7354B120227 for ; Thu, 15 Feb 2018 11:46:17 -0800 (PST) Received: by mail-pg0-x22c.google.com with SMTP id f6so578139pgs.10 for ; Thu, 15 Feb 2018 11:46:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=VBfu2Vyg0hStjlUHwsRHKoVwjESPicG62GdRWsZLagA=; b=kA7GYRfhLZ257rC3SPJw9xeTQ3H1uUtPzJ1ByT0oroXJgSrqOZ4JtsXKjPWuhpsdWT pnuthVEy3ZOijIsF0Oqr73/YHWoTzhO0htiJO12NEbr9Tb47Fg3U16uc7N9Vjkvioigr O8FV+OwmCCN37uWKuwLl/b00mOVm0ieN4c1+PgIKza3dP6N625JeQ6CK/QFV5RUzfJpF QjtZeO0KL2E26TMXCe5jdVhOJ7nhYc3/rndbH9AImtP6s6GJTFAXf1pGLqWt4u7b3UgL Dd0na/9wklKPbauyWv8ZX2Wsu+9JUSHwXskz1gVSj7OB2svt/ua9QNQVkZ/OeyboH+S1 cTQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=VBfu2Vyg0hStjlUHwsRHKoVwjESPicG62GdRWsZLagA=; b=QP8r5n4l96WCj8FxOpItj27WgwHjLgxtZY9LD1eggRuy1lQ68pOB4kfKfNGxKjMDRy RRQC8u/D5NJCzqwKfUq2V59b8t+q5AYmXnGzk265QJVNK+szmylTK3FNnMq4WBlW/nOT DqOEX3yhu7i0J3BaJDJo/V0f9ifCBj+292/rss9ECG+gDptjqv5Ajcx/cR82c6+nYhX9 GohjnchIMuES2+EaK+XQxpZh9DumBeMRo9JNx3FbKiDHxRtM6abd+kQabhXFi/y7pSQM DeKOnXbOSQBez9Vycevt9qK46gikxVVSeRlDtO9kfVDRXnfwNab/dWylAgcSqVwMZq+m MMdw== X-Gm-Message-State: APf1xPCkHCGOqYHUu3sFYpyOASAzRWKo+MUcBArVys1bjDkBZt15WevJ OPjBfrCVXkDNMa2APo1A9EGNMjRJoEHJ/YPLNpU= X-Google-Smtp-Source: AH8x2251eAOkuA9jmAYBdrJiucWmzIMB/V51uQUistY0OoHkHGqMbPU5ScchhifV3ZZeXzVhK1VgG3ksH5cVRH82Qyg= X-Received: by 10.99.123.74 with SMTP id k10mr3076163pgn.217.1518723976865; Thu, 15 Feb 2018 11:46:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.186.143 with HTTP; Thu, 15 Feb 2018 11:45:36 -0800 (PST) From: Kathleen Moriarty Date: Thu, 15 Feb 2018 14:45:36 -0500 Message-ID: To: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 19:46:19 -0000 Hello, Thanks for all the hard work on TLS 1.3. The chairs have handed off the document for IETF last call and I'll start that shortly. There are some idnits that were just caught and are queued up for the next version - an unnecessary reference is removed. There are also a 6 RFCs obsoleted that are not referenced in the abstract and that should be addressed prior to IESG review. The improved discussion on 0-RTT is much appreciated. -- Best regards, Kathleen From nobody Thu Feb 15 12:02:28 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57C212946D for ; Thu, 15 Feb 2018 12:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 uGhXzTIZBubn for ; Thu, 15 Feb 2018 12:02:25 -0800 (PST) Received: from mail-pl0-x22b.google.com (mail-pl0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4714412D7EA for ; Thu, 15 Feb 2018 12:02:25 -0800 (PST) Received: by mail-pl0-x22b.google.com with SMTP id f4so426522plr.10 for ; Thu, 15 Feb 2018 12:02:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ksr04Kp3GEmw+4+aTPAW4QOI+1u1KPPz89FjVdVK9wo=; b=nRlf5vEkF9GcYFYcX+KL5vo8NO6y72Jm2pV64a9yyoSAmPnGSKHL+CGLztq/g+5dlo 6O8CiXR/OaWFOx1/EpId6acbL27srBfKqFDUxXZOO4O1yI9GCek3dZBGptmKBsWIvlCu VGqO/V+WzpCv1lpJlyjgLB91MU4vDIVpThDXSTYq/Rx9pLNGuFiJmnPG07kz/RY4fK0w 9Xw7FK39s9kNkaCWZenjVkAhjk2hzqfaFz3weUamu3mjnO3NXxkNU9uqlC24rGAl4idc m5llZXALrRh2enQy5fQTJ7BK1pt0qqg8iN49EvZAU02DavJDHQTyE03SqaZjzmXfoz5F 19Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ksr04Kp3GEmw+4+aTPAW4QOI+1u1KPPz89FjVdVK9wo=; b=gnXX0LxPGcASCx0lzyZ83LPMO8+2Hl5UubLvZdGvm50OOv/XDpNhLu4gFEuUIIubYU K9H/ZlJbdcvVOPOuiTvyMcDX08hPY3XTiKoGJyKHLXmD5M+0RYSXDkAtGNEIknTfajiv NRJIKIOvXFW4i+Sh3/uRpvFfmMws+Goznvo0Htt3zHSYCt+6TwMjjNLhErmyKNShNiMb JWuKX9zQa1BldEx9hvkjbthEDVffBeRHdG1gKHzlNmTC6crtUFqnxjurSWttGJeRatwU tuUK3wpYkRjFrSe8+guBBg7DrKF+VTmNF3sEEQpSeMlNlnifUtGDebSAQHJ3f3DeWkqj 6UHA== X-Gm-Message-State: APf1xPCt2hXlnr5IZ2J8fU9R7yKmTRfxvQAmMfmECNSFK+j7iDjUw7+u UQpQFwKHG0ougugAb5ndoNasPddM80WkzVRMXEqL7w== X-Google-Smtp-Source: AH8x224Ph7nQwFq0AaeHsPF7QK2TiApAU/68IFKebm3tfbZ3zCgyuPVajdBL5nHOE3K59FmcBSZH8Xrdp36F5WQnVOc= X-Received: by 2002:a17:902:6041:: with SMTP id a1-v6mr3506948plt.225.1518724944642; Thu, 15 Feb 2018 12:02:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.186.143 with HTTP; Thu, 15 Feb 2018 12:01:44 -0800 (PST) In-Reply-To: References: From: Kathleen Moriarty Date: Thu, 15 Feb 2018 15:01:44 -0500 Message-ID: To: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 20:02:27 -0000 On Thu, Feb 15, 2018 at 2:45 PM, Kathleen Moriarty wrote: > Hello, > > Thanks for all the hard work on TLS 1.3. The chairs have handed off > the document for IETF last call and I'll start that shortly. There > are some idnits that were just caught and are queued up for the next > version - an unnecessary reference is removed. > > There are also a 6 RFCs obsoleted that are not referenced in the > abstract and that should be addressed prior to IESG review. I see Sean just added this to the shepherd report, so this should be fine. Please note that ID-nits complains about the obsoleted/ updated RFCs not being listed in the abstract. This is intentional because the abstract is now a concise and comprehensive overview and is free form citations, as per RFC7322. > > The improved discussion on 0-RTT is much appreciated. > > -- > > Best regards, > Kathleen -- Best regards, Kathleen From nobody Thu Feb 15 13:12:16 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A99E412D831; Thu, 15 Feb 2018 13:12:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk CC: tls@ietf.org, Kathleen.Moriarty.ietf@gmail.com, tls-chairs@ietf.org, draft-ietf-tls-iana-registry-updates@ietf.org, Stephen Farrell , stephen.farrell@cs.tcd.ie Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151872913465.7464.15939171695893457090.idtracker@ietfa.amsl.com> Date: Thu, 15 Feb 2018 13:12:14 -0800 Archived-At: Subject: [TLS] Last Call: (IANA Registry Updates for TLS and DTLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 21:12:15 -0000 The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'IANA Registry Updates for TLS and DTLS' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-03-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a number of changes to (D)TLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the (D)TLS-related registries undertaken as part of the TLS1.3 development process. This document updates many (D)TLS RFCs (see updates header). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc5878: Transport Layer Security (TLS) Authorization Extensions (Experimental - IETF stream) From nobody Thu Feb 15 13:13:49 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDD912D830; Thu, 15 Feb 2018 13:13:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-tls-tls13@ietf.org, Sean Turner , Kathleen.Moriarty.ietf@gmail.com, tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151872922818.7492.15112829041576036922.idtracker@ietfa.amsl.com> Date: Thu, 15 Feb 2018 13:13:48 -0800 Archived-At: Subject: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 21:13:48 -0000 The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'The Transport Layer Security (TLS) Protocol Version 1.3' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-03-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2900/ The document contains these normative downward references. See RFC 3967 for additional information: rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2 (Informational - IETF stream) From nobody Thu Feb 15 16:17:57 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD09124235; Thu, 15 Feb 2018 16:17:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151874027633.4949.1894983442577856508@ietfa.amsl.com> Date: Thu, 15 Feb 2018 16:17:56 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-record-limit-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 00:17:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Record Size Limit Extension for Transport Layer Security (TLS) Author : Martin Thomson Filename : draft-ietf-tls-record-limit-02.txt Pages : 8 Date : 2018-02-15 Abstract: An extension to Transport Layer Security (TLS) is defined that allows endpoints to negotiate the maximum size of protected records that each will send the other. This replaces the maximum fragment length extension defined in RFC 6066. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-record-limit-02 https://datatracker.ietf.org/doc/html/draft-ietf-tls-record-limit-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-record-limit-02 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 Thu Feb 15 16:33:55 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C43C12426E for ; Thu, 15 Feb 2018 16:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 7bXyyufxyj47 for ; Thu, 15 Feb 2018 16:33:50 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E930124235 for ; Thu, 15 Feb 2018 16:33:50 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id s198so1939963qke.5 for ; Thu, 15 Feb 2018 16:33:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=l6XCAHJN1VIKvVEpZZQezmT/QbU61hXt2vYxCCzQT6Y=; b=nOBgS3P8KOt7qlxoGSAZCKEBXkbOvTjuPJdodS8X8laRffMZvEFHJ7PPsPkzxp014l +f6X+iAx7neRuhcbfHngqAcvUBmOUZ8V8yiMnpK28SG//UftQPRsgtjDQ+pnKL3kqzf9 rrlLHauaj+zoGI5wAcBrNqsBNK242p81p7D/g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=l6XCAHJN1VIKvVEpZZQezmT/QbU61hXt2vYxCCzQT6Y=; b=fYPMC5QregJG+2fid5VclJsZWHyn61Ll2WBKutCM7svgjHHFN+p+aDdsguYXI0VYe2 opssyPiBSxED0J/AOgy/943hMwV1N5qkPLPe5XGq3FG/Cw+qb5wQBFcTjBs/iNXkCYe3 51Hr7A8BowvX4/C9IWdTwbdi5VYOCDppA1kOXaqfX1X1CAOCegcInPusVPwZ5qZaHC44 JQbPtuT6SafympxKuU/Jw99laF+ldZFCaDVS9z4Tkz4tSQoFa+Huc1Sut9X29senC/Ct yBQaxVqexIvdfQUCnyBgC0WhI8ieGUCPlhucSp9LITS+ajn9mkuGJGB7jzZ8ZOVJrHzy FOiw== X-Gm-Message-State: APf1xPBeSwUBveXSyQhpvbdgNtT0SKJdHoMplHeVazoE4lvC8kq+NmeK 1B8a6jwL4UcUQw32Wb9L0a9Jd2rqtkU= X-Google-Smtp-Source: AH8x226vADsXdZixmr+ypL1B9LcUibO8/faghq3vqNCtUVf+R/4PaiYZD4XnDoSaQ3riPlK7Ge2Amg== X-Received: by 10.55.97.66 with SMTP id v63mr6814109qkb.266.1518741229320; Thu, 15 Feb 2018 16:33:49 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id r34sm11568554qtd.48.2018.02.15.16.33.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Feb 2018 16:33:48 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 15 Feb 2018 19:33:45 -0500 References: <151874027633.4949.1894983442577856508@ietfa.amsl.com> To: "" In-Reply-To: <151874027633.4949.1894983442577856508@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-record-limit-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 00:33:52 -0000 This version incorporates all WGLC comments. I=E2=80=99ll be submitting = this to the IESG for publication shortly. spt > On Feb 15, 2018, at 19:17, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Layer Security WG of the = IETF. >=20 > Title : Record Size Limit Extension for Transport = Layer Security (TLS) > Author : Martin Thomson > Filename : draft-ietf-tls-record-limit-02.txt > Pages : 8 > Date : 2018-02-15 >=20 > Abstract: > An extension to Transport Layer Security (TLS) is defined that = allows > endpoints to negotiate the maximum size of protected records that > each will send the other. >=20 > This replaces the maximum fragment length extension defined in RFC > 6066. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-record-limit-02 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-record-limit-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-record-limit-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Feb 15 16:34:41 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A736C126CD8; Thu, 15 Feb 2018 16:34:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sean Turner To: X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Cc: Sean Turner , iesg-secretary@ietf.org, tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org Message-ID: <151874127967.4985.13053070019507710259.idtracker@ietfa.amsl.com> Date: Thu, 15 Feb 2018 16:34:39 -0800 Archived-At: Subject: [TLS] Publication has been requested for draft-ietf-tls-record-limit-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 00:34:40 -0000 Sean Turner has requested publication of draft-ietf-tls-record-limit-02 as Proposed Standard on behalf of the TLS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ From nobody Thu Feb 15 18:04:31 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBB9126CF6; Thu, 15 Feb 2018 18:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com 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 QdsZSRRJebSY; Thu, 15 Feb 2018 18:04:27 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-oln040092007054.outbound.protection.outlook.com [40.92.7.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34774124235; Thu, 15 Feb 2018 18:04:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FJsDSPrj/dmtIdVrG/V/fXy4xmW0ucy3U3NYESA4vrk=; b=bzwlw4zJa1xooJWsXkxJcTgOSTmtXxgg9zS4qChgIN5olXxiGtXxI+hSYWfv9grvQhC/WsNPM3D8PpGF6YB0v5wVSuhs+Co7xyuOWDlX47NMWSNdpA4BtTk/LbDYTFLX/eJkrJJmadDcGijsCgGVn9RQj4Z0IF/maoOAAkp8pyzvM0oKwvQ037nZYBWpp/3TKJuokBkPaeBqETQLXwsrhsqDBg7Jqvyar5O9EwsKdY1i4z3/eR33qWJ2vbBJ5I5s/Nn55X3seFuBR9Pi8+HO0T/PiJbUJGpeiGqWDUswm3S/GxHlzXNJTM1DXHKll7iwc8K9eG5JrtOs4IvP+LaVBQ== Received: from BY2NAM03FT063.eop-NAM03.prod.protection.outlook.com (10.152.84.56) by BY2NAM03HT015.eop-NAM03.prod.protection.outlook.com (10.152.85.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.19; Fri, 16 Feb 2018 02:04:26 +0000 Received: from MWHPR1801MB2061.namprd18.prod.outlook.com (10.152.84.52) by BY2NAM03FT063.mail.protection.outlook.com (10.152.85.182) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.19 via Frontend Transport; Fri, 16 Feb 2018 02:04:26 +0000 Received: from MWHPR1801MB2061.namprd18.prod.outlook.com ([10.164.205.38]) by MWHPR1801MB2061.namprd18.prod.outlook.com ([10.164.205.38]) with mapi id 15.20.0506.020; Fri, 16 Feb 2018 02:04:26 +0000 From: Yuhong Bao To: IETF-Announce , "ietf@ietf.org" CC: "draft-ietf-tls-tls13@ietf.org" , "tls-chairs@ietf.org" , "tls@ietf.org" Thread-Topic: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard Thread-Index: AQHTpqIt+txVsOg+PUGOtdxaCCYGLKOmR2xX Date: Fri, 16 Feb 2018 02:04:26 +0000 Message-ID: References: <151872922818.7492.15112829041576036922.idtracker@ietfa.amsl.com> In-Reply-To: <151872922818.7492.15112829041576036922.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:0B172FDC057079B89C6EE665C4F62DFFB76FEB114429E0EBBC025E66EC147312; UpperCasedChecksum:E24DE1802F45149F8E6A0A8D85811426334ADC602D6BD9A4C9BB40CBF94020CA; SizeAsReceived:7508; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [/xa8925nZAmkVMFY2RIfUHFS79KOtzty5VmWKNHdOB0FMCtpOKsFP3z6E6GNer4M] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2NAM03HT015; 6:t2JsSuAsPXZi0MpQkDPrD3de+3USS8tavMM6sghNHk+QkKYECsSuv/tmZSVBlR1ifZMotOR7kGdvQSAgo7YPerUYwqRLBqSgb0PK66+UrJNIgeDqf1b6FlbVFVRqOQYWdDKaWizJijdEdBzIUS3rwPkjEIUeHm2LaOpxuf0w44QbLchzX60pn+kUoymwf2qiMMDzhDWXFqCjphXXNyO1n79zaQZ6kKfrY1i1aWzue4gBf5+bk2A9uKBqUwJ16qGUqgRQoLaBVovOluNDuUMgnI8IkEndK00s1hoCY1iF5ICgNWA4wi5JwBUVtcL+zF6Ptq8RKgmFlVezy/hLqi9YA5lTcvOvXTT9fBG2jf11ygU=; 5:+LDbiBzgZXSuKAzoSfzBIrx1qZsTYYtnD/6yZ0rzO8ytbeSkH2H4xslciBoSQCFDeNxMLWbB76Sy5T+ze7uABBwV3EskHNoExzR4nNNN1+53kcgw+T8tdrzbIXddYHUN+nJdOqUyyid+OiIOlDs+hCI+jCTQD02PhfdohCQYRv4=; 24:sTZ7zKvPR+I3R+Hhk347nDX0yPwe13a9//Glyr4wRwQUb0wJ1MfR4isGEfsJOfot/qQamEBulVORlJ1jcJZJPWeKh/nstkSjNAsbUJRVxsI=; 7:+yqsMInHRKla9PlXKINptROBsf9OKcac38FhruS4AjGN0UFCxWoyoxAQL+YDDLsgv2R5is4MzjWPOoMjDPntR0s2jWiTlN2v/FGq2ly4HuIv5CxSr1FoAstkGi5IQZv9QrRJtLMDLawZGZaBPyl4H2cBJ1T9Ohrr6GPj/YuZ94f9h1PxaLypPF8M0n2oPVl2zkl/7Ed/ssukckJuDF7RTzBsHFOjTsjKEMm2teTsf7th7x1YbicLBz2dVzUCgpKB x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:BY2NAM03HT015; x-ms-traffictypediagnostic: BY2NAM03HT015: x-ms-office365-filtering-correlation-id: 9233e99a-ede0-47ee-b453-08d574e19b1d x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:BY2NAM03HT015; BCL:0; PCL:0; RULEID:; SRVR:BY2NAM03HT015; x-forefront-prvs: 0585417D7B x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:BY2NAM03HT015; H:MWHPR1801MB2061.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9233e99a-ede0-47ee-b453-08d574e19b1d X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2018 02:04:26.1203 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2NAM03HT015 Archived-At: Subject: Re: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 02:04:29 -0000 I wonder what is IESG's opinion on the TLS arms race with middleboxes. Yes, I am talking about moving the version number in the ServerHello. ________________________________________ From: TLS on behalf of The IESG Sent: Thursday, February 15, 2018 1:13:48 PM To: IETF-Announce Cc: draft-ietf-tls-tls13@ietf.org; tls-chairs@ietf.org; tls@ietf.org Subject: [TLS] Last Call: (The Transport Laye= r Security (TLS) Protocol Version 1.3) to Proposed Standard The IESG has received a request from the Transport Layer Security WG (tls) = to consider the following document: - 'The Transport Layer Security (TLS) Protocol Version 1.3' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-03-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning = of the Subject line to allow automated sorting. Abstract This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2900/ The document contains these normative downward references. See RFC 3967 for additional information: rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2 (Informat= ional - IETF stream) _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Fri Feb 16 05:11:17 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC991127286 for ; Fri, 16 Feb 2018 05:11:13 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 QHbl92mvQfWq for ; Fri, 16 Feb 2018 05:11:10 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04F59127275 for ; Fri, 16 Feb 2018 05:11:09 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id q18so3680052qtl.3 for ; Fri, 16 Feb 2018 05:11:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=sJBypmK+3ZTJslIkByypqJ7k11EzNABAcY6+PkhbU6g=; b=aRbalfp0D//BAviKagfftAO7ZTNEjqRIruDTjehQs0e4AMk4ppXj5gFZpmFJan/4B8 OewJJj0VRlqWJ5MKQNUqO0sQ3fLqO1JhrzyQ9FX90gY47Imek4FqECa49u6PElHSve8M kwO6JIrmoN+zefdupKXPyCxmXCtmpBOhvRWh8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=sJBypmK+3ZTJslIkByypqJ7k11EzNABAcY6+PkhbU6g=; b=dORzWy+2gNXCYW6+VNMceEFG0Hk7tMdD5F2mtNkJJ0s2EHGC0wzI1FAjoQ5R1chC4+ yAY05vU9LvU4F2VrW6p3woMUeACVUsYn7RgPRWjCah19nUTIU5P/a4PlWz2VRIiBQg25 ce1yu2ANfYdKCbe+D0fCueeUMzmTnUxcQdz4J3LBO+ckeEo5/eF4afhU9BlF7SThJ9Bi eiroFpPQHj78Ot03zTtDTAhtF5OPr5CgM6IroN/zqGh3hnfwbs0GhN5Yc7asV6LWX4jQ lW94tz0/SVk3PnuNcO654mDJBOj4rsYOzdj6vKaRZBaAO/aZzLvp0VTpIy3FFuTr8wlb GIRg== X-Gm-Message-State: APf1xPAxH4c7+IeIZvXxpGLAZ3IxIxUkbSy298TSXJ0d44PUZ6IO1apJ B6ChmmLQRbiKpFXWI27eGVmr5jXI/44= X-Google-Smtp-Source: AH8x224NRKXuRlhFQfvuNKwwDHziFPo7YHu51DrlHP2n9uxglUeuJWpbumU34x5BliRQekWmnB0wdg== X-Received: by 10.200.53.137 with SMTP id k9mr9925882qtb.37.1518786668806; Fri, 16 Feb 2018 05:11:08 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id l41sm13914251qtc.22.2018.02.16.05.11.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Feb 2018 05:11:07 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 16 Feb 2018 08:11:06 -0500 References: <151872922818.7492.15112829041576036922.idtracker@ietfa.amsl.com> To: "" In-Reply-To: <151872922818.7492.15112829041576036922.idtracker@ietfa.amsl.com> Message-Id: <6A289FC0-CF1F-4FC4-AA19-99A254564CD7@sn3rd.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 13:11:14 -0000 For those not steeped in IETF process, the IETF LC is two weeks. IETF = LC also kicks off the directorate review process; we are likely to = receive General Area and Transport Areas as well as our own Security = Directorate review; you can see the reviews on this page = (https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/) just look for = =E2=80=9CReviews=E2=80=9D before the draft=E2=80=99s contents in the = metadata. We will address these comments as we get them and substantive = changes are brought back to the WG. Kathleen has also gone ahead and placed the draft on the 2018-03-08 IESG = telechat. So, it is likely that in early March IESG ballot positions = (i.e., discusses and comments) will start rolling in then; if you are = curious, you can read up on some of this at: = https://www.ietf.org/blog/discuss-criteria-iesg-review/?primary_topic=3D7&= . There may be an additional version of the draft published prior to the = IESG review to address IETF LC issues (the IESG likes to see as clean a = copy as is possible) and there may also be another version published = after the IESG telechat to address points raised by the IESG. There=E2=80=99s more after the IESG, but I can fill in those blanks when = we get there. spt=20 > On Feb 15, 2018, at 16:13, The IESG wrote: >=20 >=20 > The IESG has received a request from the Transport Layer Security WG = (tls) to > consider the following document: - 'The Transport Layer Security (TLS) > Protocol Version 1.3' > as Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits = final > comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2018-03-01. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the = beginning of > the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > This document specifies version 1.3 of the Transport Layer Security > (TLS) protocol. TLS allows client/server applications to = communicate > over the Internet in a way that is designed to prevent = eavesdropping, > tampering, and message forgery. >=20 >=20 >=20 >=20 > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ >=20 > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ballot/ >=20 > The following IPR Declarations may be related to this I-D: >=20 > https://datatracker.ietf.org/ipr/2900/ >=20 >=20 >=20 > The document contains these normative downward references. > See RFC 3967 for additional information:=20 > rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2 = (Informational - IETF stream) >=20 >=20 >=20 From nobody Fri Feb 16 05:56:18 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C83412D887; Fri, 16 Feb 2018 05:56:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rich Salz To: Cc: ietf@ietf.org, draft-ietf-tls-tls13.all@ietf.org, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151878937218.4977.11435268279455285944@ietfa.amsl.com> Date: Fri, 16 Feb 2018 05:56:12 -0800 Archived-At: Subject: [TLS] Secdir last call review of draft-ietf-tls-tls13-24 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 13:56:12 -0000 Reviewer: Rich Salz Review result: Ready I have discovered an elegant little proof that shows TLS 1.3 is not secure, unfortunately I do not have the room to fit it in this textbox. I will send email tomorrow... No, seriously, this protocol has been designed with the help of world-class cryptographers and academics. It has been analyzed with verification tools. It has been tweaked as necessary to get around middlebox ossification. It is available in two highly popular browsers and at least one widely-used open source toolkit. This document is READY. From nobody Fri Feb 16 09:06:43 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A9A126BFD; Fri, 16 Feb 2018 09:06:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-tls-tls13@ietf.org, Sean Turner , Kathleen.Moriarty.ietf@gmail.com, tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151880080195.1349.14035524657942875385.idtracker@ietfa.amsl.com> Date: Fri, 16 Feb 2018 09:06:41 -0800 Archived-At: Subject: [TLS] UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 17:06:42 -0000 The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'The Transport Layer Security (TLS) Protocol Version 1.3' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-03-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2900/ The document contains these normative downward references. See RFC 3967 for additional information: rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2 (Informational - IETF stream) rfc6962: Certificate Transparency (Experimental - IETF stream) rfc6979: Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) (informational - Independent Stream) rfc7539: ChaCha20 and Poly1305 for IETF Protocols (Informational - IRTF stream) rfc7748: Elliptic Curves for Security (Informational - IRTF stream) rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2 (Informational - IETF stream) rfc8032: Edwards-Curve Digital Signature Algorithm (EdDSA) (Informational - IRTF stream) From nobody Fri Feb 16 09:21:40 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87315126B7E for ; Fri, 16 Feb 2018 09:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 xW3RRI-EcgHO for ; Fri, 16 Feb 2018 09:21:37 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B410124C27 for ; Fri, 16 Feb 2018 09:21:37 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id l23so4640348qkk.11 for ; Fri, 16 Feb 2018 09:21:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=/uI5HDcFjhi97nEScqhm+GwEj+ESTvURaa03d8OefF8=; b=bZp6fsUovsiAqBAK1HLhRlCl8fbLvFc3lmV4BNnCiBibkxbwdB/pZmGIRNxO1q/rEf DKRwAPiTc0S3TnZ61aYp9aL/vttvTNuPat/oo5QHzkQ2NSvomIMCdBEyDylRXJ1VVDce iVUo7pT3LHv4kEhzMesBTr9rIByDpPHpPzf+M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=/uI5HDcFjhi97nEScqhm+GwEj+ESTvURaa03d8OefF8=; b=q0RgqvPft9U/5BvUlYrpoen9AvcMeIYDPakQoohsTuMLFgpeLxINDwSw3aWtWdomCf Or/KmoUqlM+y6UVVyFhaYPeuFb5zxM2wpgdRlXtuhhxrs+qleSJ3Dpw7qvP8XetkTxz8 zP4KaNBHp1HOS29nyNqvu8eJoPhOm1azXnU2RDf7qSibxxtQzd4wxLRQQ3J9ln6rAE5C sK9/TaoQ85P4G+zRNkjaQHXEb4PXtFYoVp6bUCZO+HtBmgw+WTpehk/6usmdzNR2loQ0 KoEsuePWEmttSAxpusIz5yG0XZWC11AU/cFMcgOdjDrp8IzyRd2lYn30XUYbJq45pYNS XEEQ== X-Gm-Message-State: APf1xPBEVytPXxNthYp9mi5KZLFe3ZiCI61osh9YD848TgpnxQ12u+pn whYj+dX/8nPPJ/dbTk3pTqFqvnUCCrU= X-Google-Smtp-Source: AH8x226a9QcFL+IF7KNRyrw/3s0//cittXCEjoZi4qlbs8LCHs9lWWZa3Q4641mSwBG70RJzWPtWZg== X-Received: by 10.55.8.145 with SMTP id 139mr10902260qki.83.1518801696226; Fri, 16 Feb 2018 09:21:36 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id v22sm12961537qkl.24.2018.02.16.09.21.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Feb 2018 09:21:35 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 16 Feb 2018 12:21:34 -0500 References: <151880080195.1349.14035524657942875385.idtracker@ietfa.amsl.com> To: "" In-Reply-To: <151880080195.1349.14035524657942875385.idtracker@ietfa.amsl.com> Message-Id: <8A8213B0-F2C4-4C46-B858-09FB4EF608E3@sn3rd.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 17:21:40 -0000 The difference here is that this LC includes all of the downrefs = according to the process described in [0]. Including the downward = references to non-stardards track RFCs will ensure we=E2=80=99re not = delayed due to process issues. Most of these are as a result of how we = publish algorithm drafts, i.e., from the CFRG through through the IRTF = stream, and none are a surprise. spt [0] https://tools.ietf.org/html/bcp97 > On Feb 16, 2018, at 12:06, The IESG wrote: >=20 >=20 > The IESG has received a request from the Transport Layer Security WG = (tls) to > consider the following document: - 'The Transport Layer Security (TLS) > Protocol Version 1.3' > as Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits = final > comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2018-03-02. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the = beginning of > the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > This document specifies version 1.3 of the Transport Layer Security > (TLS) protocol. TLS allows client/server applications to = communicate > over the Internet in a way that is designed to prevent = eavesdropping, > tampering, and message forgery. >=20 >=20 >=20 >=20 > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ >=20 > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ballot/ >=20 > The following IPR Declarations may be related to this I-D: >=20 > https://datatracker.ietf.org/ipr/2900/ >=20 >=20 >=20 > The document contains these normative downward references. > See RFC 3967 for additional information:=20 > rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2 = (Informational - IETF stream) > rfc6962: Certificate Transparency (Experimental - IETF stream) > rfc6979: Deterministic Usage of the Digital Signature Algorithm (DSA) > and Elliptic Curve Digital Signature Algorithm (ECDSA) (informational > - Independent Stream) > rfc7539: ChaCha20 and Poly1305 for IETF Protocols (Informational - = IRTF stream) > rfc7748: Elliptic Curves for Security (Informational - IRTF stream) > rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2 = (Informational - IETF stream) > rfc8032: Edwards-Curve Digital Signature Algorithm (EdDSA) = (Informational - IRTF stream) >=20 >=20 From nobody Fri Feb 16 13:20:12 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB3412D7E5 for ; Fri, 16 Feb 2018 13:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 qHoyJKsHDO1d for ; Fri, 16 Feb 2018 13:20:08 -0800 (PST) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF57D126BF0 for ; Fri, 16 Feb 2018 13:20:06 -0800 (PST) Received: by mail-pg0-x22a.google.com with SMTP id w17so3384988pgv.6 for ; Fri, 16 Feb 2018 13:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=E4SWuUhe01F+WmoBbrF6OBS8z5IVGsHp0laj7QRWB7Y=; b=Fgs3yNR97zkQPaNRP+HvFHyNzeiL1CqkXdJHGAf0nzwbGI+hs7dkAfvuYFzsZjdoE6 xI4dt4DwcBmsB4Fg2yXgcdOMIAzLCPYQimLQtgMr4FlITSrgomEcJMVHiyiAPlDecqna jyxGZPtVuPDnEC9RuJzC/VystKX1GITwVHtCt6UAy0xwOM+wNMYMgkK5Jzj/zowDxyas 4CEo6UZC+dw2X34KIwU/t6+CdqvRJz/yiitMEp2llMAmwzKjy7q7JiVqturi/S1BUsPg UHMHcIHdvUZEFCKOO5eogv1FP+lLXwLxuHMAInPBjIEJfMX4iq9n/giaLlx1HkdyJ14D YxTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=E4SWuUhe01F+WmoBbrF6OBS8z5IVGsHp0laj7QRWB7Y=; b=rCDWlugkXatWuHau92u/m6rxAh2ZldktHu/IVMWrjgI62MfPjB7ZT95ybcJIuRmqlD BtiG2AaJeb2bFrYKL3nj7F1xyVso0zV0Nh3CQYlijbQVY07+hSn7fz+PAgtt23lzJtS4 T+zkusuqI3eOzpkr1nnpHgzhebMXH6fO4eByHADtm7lH4J3oare0HiPfhJwKqAoJ7vvC ix7+Nq7ZiaW5cYMEBuJTwA7CqDaieAKmqWolwPSEN4NcBwcgFSNacm1pZt7jzvqRILcx LTbZ8kLb5BjeY5L+osxSbQafD6QNw+CcVCYyRKr2sNmWuZDWpEquqS3gT5JatfOn/LI0 RxRA== X-Gm-Message-State: APf1xPAu7K32Z/ZZDl9YcHCH1nzk1QhKeJmF8fAKZlKnmNHcY5Yv2cQ4 9isyeR+aHj6sumIA2fhhw8kpJj9qzkF6WsBhnTLXjA== X-Google-Smtp-Source: AH8x225XMD0Xw/iQdt+7aInKu8h4qxJvMlIVua4z5xryMukUdhO2nZRowzokquyDtVdWXqsGD978Jx1p+bZvnUoIGPQ= X-Received: by 10.99.116.18 with SMTP id p18mr6093171pgc.77.1518816006336; Fri, 16 Feb 2018 13:20:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.229.67 with HTTP; Fri, 16 Feb 2018 13:19:25 -0800 (PST) From: Kathleen Moriarty Date: Fri, 16 Feb 2018 16:19:25 -0500 Message-ID: To: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] AD review of draft-ietf-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 21:20:10 -0000 Hello, Thanks for your work on draft-ietf-tls-record-limit. I just requested IETF last call, so that should start soon. The draft looks ready to go, I'm just wondering if you could add in text into the introduction to state the level of constrained device this is intended to help? If text is added, this can be addressed with an updated document after all other IETF last call comments are addressed. I placed the document on the March 8th telechat. Thank you. -- Best regards, Kathleen From nobody Sun Feb 18 16:09:20 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A85F1241F3 for ; Sun, 18 Feb 2018 16:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ef8MH02bC5tc for ; Sun, 18 Feb 2018 16:09:16 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9805212008A for ; Sun, 18 Feb 2018 16:09:16 -0800 (PST) Received: by mail-oi0-x234.google.com with SMTP id j79so2293768oib.12 for ; Sun, 18 Feb 2018 16:09:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lUGuh8xAyvplS/HOvWIvpK3Fc/Z0Hknl33i1DzahcPc=; b=udjC7jH9dl87GXXE0yCcRZE2fUP6uOJHs9cYW2KqV+HioEY0Haw64uT86ooRgKXCzV mPIgroWzRogRUsKM0448hmIuvMeeHnNJsZkMyqPXVbdz4qxCmyX1Agpw/kAQPYcMCuGM 0eq287yG95h9ppHitlZb395+IxmtQp0t70SbDPsSyt4VWvEXLlAPiYeDZKzcRy/qigvt v56eRMSFTmqk7xqCzyhcnCMtK28PVK8RV/QGY9qLxj5V5yXrYRqqRovvf/QztI4/GVTi hbkwFV6B+TNiAi4eYYp2MiRAr8MthGK+ARzCG1ct9E3HZHMwi9uWn6acVEpRxdnSJZlI JqWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lUGuh8xAyvplS/HOvWIvpK3Fc/Z0Hknl33i1DzahcPc=; b=FryGRfftGf1edeYXNFf6gWhdGSEwYZULAfWD9YQ0m6XrXeycwWXYG6XR4fwh9N5miK WZFuEjZQ2D66nM7Gtg75R3uykolaNHRLwXiiBRgI/1/iOynuvXUHJIkmthNG6AZ1rPMj 8vMeSTwvnhBlrU0srbwmoxJL2Mmqhoc8LfDi24SfWIhr3cz+4AfcWR+0P2ONVg2qTZCt I/wAyoeF+eD1va2eRJi5zdw/9ZYP3WapMaAT1o7OgNkCOXPwqLecfrD5J7BNZbz11CPw jxPfu/a/ofNODMkdjR0Q+RDM4/bKY/Kkd4s5cF3QlXewhW8cbmGLBKp0y894gYfivSvD 1agg== X-Gm-Message-State: APf1xPB3Sg15CEDwjP3SXtrx6qKn50gox0Vydz4Wts9E8kpfWvg3PNEc EHWPJV9rVv2Tt9Try538oeHLOpxWkUH9+KUER7A= X-Google-Smtp-Source: AH8x227V/5iGD0pGoEyKzJ9pCi2hRsijwxJaPaDltQ7MeeBg+toOoebJy5Su49apbPTQZwXBc4GsixeHKAZabsRwxKk= X-Received: by 10.202.94.196 with SMTP id s187mr8711673oib.144.1518998955751; Sun, 18 Feb 2018 16:09:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.196 with HTTP; Sun, 18 Feb 2018 16:09:15 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Mon, 19 Feb 2018 11:09:15 +1100 Message-ID: To: Kathleen Moriarty Cc: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] AD review of draft-ietf-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 00:09:18 -0000 I don't think that this targets a particular class of device, or that it is appropriate to label it as such. Ideally, every implementation deploys this. If the RFC cites 7228 and points at C1 (for example), that potentially gives the impression that it is *only* for those things. That's not the intent. The intent is to avoid further fragmentation of the ecosystem. That's just my prejudice though, I don't find these taxonomies to be especially helpful, other than in codifying design constraints. For this, I'd prefer the design constraint to be simply "could it run TLS". On Sat, Feb 17, 2018 at 8:19 AM, Kathleen Moriarty wrote: > Hello, > > Thanks for your work on draft-ietf-tls-record-limit. I just requested > IETF last call, so that should start soon. The draft looks ready to > go, I'm just wondering if you could add in text into the introduction > to state the level of constrained device this is intended to help? > > If text is added, this can be addressed with an updated document after > all other IETF last call comments are addressed. I placed the > document on the March 8th telechat. > > Thank you. > > > > -- > > Best regards, > Kathleen > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Feb 19 02:14:59 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C389E126D05; Mon, 19 Feb 2018 02:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 r_h-lljAbIkZ; Mon, 19 Feb 2018 02:14:56 -0800 (PST) Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8C0F126CF9; Mon, 19 Feb 2018 02:14:56 -0800 (PST) Received: by mail-ot0-x233.google.com with SMTP id 38so882512otg.1; Mon, 19 Feb 2018 02:14:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DKnokio8fMiFe6bUYG7n4dBZbp4lhIVUTCdmf0/zkjY=; b=PxIsZFvxtl32yw620vnsBADkcg5tbbcIknKlnnJxSnYcgBKYXFtcf5nQFi4U8MpIo+ MtUxJw92felc/qWjVYLnB+6eDw5chiHaF0Zzd9yGTuDKaNoLZW9KfARHdzqauUkn+fem cPMXRRJkbWBculIckAkzWxt3Wuyl9b+acfyFIQHTcj/L+P5Xb43nZQnFJQ1GAa/su9Wc 3sPWnR4qVsGj9a8zeuxsQ+oySvKLlolfbolx1/nFiwDL8QX4hlz/aZ+6I1E8oJzu40S1 hII0ZTsHv9FfzmKonz0wVgnf8rcgn0lPmqgHkQCARVTwz9rQ0PcfE8YTOmZptD+mkWM0 M/Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DKnokio8fMiFe6bUYG7n4dBZbp4lhIVUTCdmf0/zkjY=; b=bArNOsREk9bI42S8g5Wk+LzXszsxvU2fgDGnng6wycLXEFfDfxQjaJcK1eXifamFEZ +BOsRbDhbpN/CIxsoT+lxWuyK1ncXOkU0M3iMkSPdew713UeW3h54kxfXV7CKjrZJj9O YVwmMreASIYMZQZXtga/z4QN4xctI+tcsMzWze9Luho4+UrB4tgRP+wOzUnIX6BBCSrM 1lv2vOObflVqmZ1Zurp95KU4FcoEP20rfhbCtcJ9fl+bzTU6T39XZXaiu50tiSxfVG92 t6fMfmD6W/2mpsjMUac/+mxT4bTG1sxwgj4jntZooPoWAeKE4SCJ5fxtIy9Nt/rSlemc qKpg== X-Gm-Message-State: APf1xPBByVa4ekbxsQwzK9lf0s/KRjCb3PWmbmlrhP+ZzLnV2v6MlmAA 5hyNkgEWLxVW2V1G2ZCq8bS0Yxej2JyLLoU1hS8zwcR8 X-Google-Smtp-Source: AH8x226lr3DkMzEDwermoTXGGahH1Zbqxkcmvz2xZ+YVCtbSYRp3nJ+qtTTluDs0FLEWNXEPzTH35MgRNzByhqFJqiE= X-Received: by 10.157.12.229 with SMTP id o34mr7775394otd.352.1519035295851; Mon, 19 Feb 2018 02:14:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.16.85 with HTTP; Mon, 19 Feb 2018 02:14:54 -0800 (PST) In-Reply-To: <008b01d3a94e$1cc174e0$56445ea0$@augustcellars.com> References: <008b01d3a94e$1cc174e0$56445ea0$@augustcellars.com> From: Martin Thomson Date: Mon, 19 Feb 2018 21:14:54 +1100 Message-ID: To: Jim Schaad , "" Cc: draft-ietf-tls-record-limit@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Mail regarding draft-ietf-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 10:14:58 -0000 (+tls@) This is a good question Jim and one that I thought through during implementation, but failed to capture in the doc. Basically, there is no way to validate the extension if the client includes an unknown version of TLS or an extension that it doesn't understand. A client can know because it should understand the protocol as negotiated. The text currently says "an endpoint MUST NOT send a value higher than the protocol-defined maximum record size unless explicitly allowed by such a future version or extension" I think that we should add "A server MUST NOT enforce this restriction; a client might advertise a higher limit that is enabled by an extension or version the server does not understand." Does that make sense? On Mon, Feb 19, 2018 at 5:51 PM, Jim Schaad wrote: > I was looking at this document relative to a specific question for Kathleen, > and I had one thing that I would like you to look at and see if you think it > is clear enough. > > I have a server that is TLS 1.2, a client that is TLS 1.2 & 1.3. It sends > a hello w/ and extension value of 2^14+1. It is not completely clear to me > that the server should accept this as a legal value and compute the min of > it and the maximum 1.2 value as the value to use when sending messages to > the client rather than producing an error message because the value is too > large. > > Jim > > From nobody Mon Feb 19 06:53:12 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A82C1276AF for ; Mon, 19 Feb 2018 06:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 fCc8pLcy4dK3 for ; Mon, 19 Feb 2018 06:53:08 -0800 (PST) Received: from mail-pl0-x230.google.com (mail-pl0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1234120724 for ; Mon, 19 Feb 2018 06:53:08 -0800 (PST) Received: by mail-pl0-x230.google.com with SMTP id x18so194446pln.0 for ; Mon, 19 Feb 2018 06:53:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=alDIgR1PQ79vHRKwJwApz3rDd2LMF0VHZOajFi8m3OI=; b=LIxVMC2RfEiJHqRSLk/SKbSE21q/Va8+0l1Y5frNMKdjooGJiECnfDJPvBo+Oi4iRh FcjD4AoEH+DFGgBxsSWrLvnapGPKsXi6SDCxtYVVmEt0K8GaI76yG21HcrCOR21OPLLh SFaN6vNU//alv1IG0wafAdBzO0vkEooXvviJCJEHYNkuYUPqLny5CvpYAiSZh1uJ/I4/ b8Quf9LH6FwtGIb8b+9o2/K31bXbC7ZgJGc+mFd0RVO+6fqoGYtRw05rN1kaVvtUpYub RwsauZhHdOiRhkcW4Llr/m7BK3X4dF+tg7HQMprEwcHrZS8OO0cq4LrW71OTuNA/aU4z rTIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=alDIgR1PQ79vHRKwJwApz3rDd2LMF0VHZOajFi8m3OI=; b=bRVK/BqvPn+wICtBA2QNJ97Kp/ztc6y2wZ2QnBoez324XhtFlTB01I29NZwsVF7Kce jZ1+p30fZgV9ED61UOtSSQdymO1xTzucwUHbLjM9J7n4NVYkk1+RCPL7xScb8qL5pKrE rN7cIPQtLqzfQniexTzPe/s/srzRs/xqXt3TW2S/y47xICI06D2HYWYiPFlQr/qnoQME SJX9ewiNoml/LoaurxeoPhVg8y0I4+zJDsb9u9Z97DgY4peP6fZ9scbREgdUjDvgKrvV pOhtEjkPaKgm/ctAOT2xJ6KEqrzKdy0KaIVpkBo/5pBSnF3ezLfGiwUAsHgjfVBacGbW OwnA== X-Gm-Message-State: APf1xPB0ksyy2yiCaXtHEdNiwTxI3AtiPfcr7TKbbW1eeiNZ+Og4KOk9 sv+/vBL8+lOqYV0SOA5dVOqKWr4eQHVIj35xaHI= X-Google-Smtp-Source: AH8x2261rSWqtyaQ5MFPM6od232XJH2R++rxEatEybxztu68PRAZNp+17B6WoJi21Za3HgNFsDapD0XH+ZVVfDQuTRc= X-Received: by 2002:a17:902:2845:: with SMTP id e63-v6mr14270540plb.438.1519051988361; Mon, 19 Feb 2018 06:53:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.229.67 with HTTP; Mon, 19 Feb 2018 06:52:27 -0800 (PST) In-Reply-To: References: From: Kathleen Moriarty Date: Mon, 19 Feb 2018 09:52:27 -0500 Message-ID: To: Martin Thomson Cc: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] AD review of draft-ietf-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 14:53:10 -0000 Hi Martin, Thanks for your response. I just wanted to check on this and not hold up the draft in the process. Thanks for also addressing Jim's question. Best regards, Kathleen On Sun, Feb 18, 2018 at 7:09 PM, Martin Thomson wrote: > I don't think that this targets a particular class of device, or that > it is appropriate to label it as such. Ideally, every implementation > deploys this. If the RFC cites 7228 and points at C1 (for example), > that potentially gives the impression that it is *only* for those > things. That's not the intent. The intent is to avoid further > fragmentation of the ecosystem. > > That's just my prejudice though, I don't find these taxonomies to be > especially helpful, other than in codifying design constraints. For > this, I'd prefer the design constraint to be simply "could it run > TLS". > > On Sat, Feb 17, 2018 at 8:19 AM, Kathleen Moriarty > wrote: >> Hello, >> >> Thanks for your work on draft-ietf-tls-record-limit. I just requested >> IETF last call, so that should start soon. The draft looks ready to >> go, I'm just wondering if you could add in text into the introduction >> to state the level of constrained device this is intended to help? >> >> If text is added, this can be addressed with an updated document after >> all other IETF last call comments are addressed. I placed the >> document on the March 8th telechat. >> >> Thank you. >> >> >> >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls -- Best regards, Kathleen From nobody Mon Feb 19 07:50:55 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64DDD12785F; Mon, 19 Feb 2018 07:50:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 xmfoh1dmkEuz; Mon, 19 Feb 2018 07:50:52 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 5F58C12783A; Mon, 19 Feb 2018 07:50:52 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1JFm9pG009377; Mon, 19 Feb 2018 15:50:37 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=CTzTNOjtVeGGTzkx7EfwbgOT5pZgnAYmLcUqNp1+IE0=; b=FUQzVZHwsGuuQTghDfTgO18y4hr8Dvf0/VPDyZZq+OhqU1PZXMUZ12oneipAT2BVMeWu KKi3GpXlOAPtHWvKbJlTLQzkJs8zg/1FqNbYPdu9PFI1Y8VFF4g4iEliAnt15xb+GsQd PCLcJvmdHwHUF8C8Wh17pu7LM9e+gB47GxaaC9fHKYUQG6CJ7edRjY0AgsVZIk1jlwCa pqbBkiipSVg0iGzE8MONaH8KwGYqpuawdL98B4/N5gJTZuT4uP9SV2MMJGgl0IaA9J2r E6YFto2TL2oaAwhGDIeEXnJJMU2/X2BUFWJ0ebhGvhqWHG5jH91uikXpbKAGlqCHV3yZ 7A== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2g6cwy5q53-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Feb 2018 15:50:36 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w1JFkdY8011194; Mon, 19 Feb 2018 10:50:36 -0500 Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint1.akamai.com with ESMTP id 2g6gky5ug1-1; Mon, 19 Feb 2018 10:50:36 -0500 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id F242832EB3; Mon, 19 Feb 2018 15:50:35 +0000 (GMT) To: Martin Thomson , Jim Schaad , "" Cc: draft-ietf-tls-record-limit@ietf.org References: <008b01d3a94e$1cc174e0$56445ea0$@augustcellars.com> From: Benjamin Kaduk Message-ID: <5d328448-83df-e07c-3241-c7427a9cc4ad@akamai.com> Date: Mon, 19 Feb 2018 09:50:35 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-19_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=938 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802190196 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-19_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=971 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802190196 Archived-At: Subject: Re: [TLS] Mail regarding draft-ietf-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 15:50:54 -0000 On 02/19/2018 04:14 AM, Martin Thomson wrote: > (+tls@) > > This is a good question Jim and one that I thought through during > implementation, but failed to capture in the doc. > > Basically, there is no way to validate the extension if the client > includes an unknown version of TLS or an extension that it doesn't > understand. A client can know because it should understand the > protocol as negotiated. > > The text currently says "an endpoint MUST NOT send a value higher than > the protocol-defined maximum record size unless explicitly allowed by > such a future version or extension" I think that we should add "A > server MUST NOT enforce this restriction; a client might advertise a > higher limit that is enabled by an extension or version the server > does not understand." > > Does that make sense? Mostly.  I am not sure that that exact phrasing is great, though, as we do want the server to enforce the restriction *as written*, i.e., taking into account that the client may know better than the server if a newer version and/or extension is in use.  So, maybe something like "Receiving a larger value is not necessarily cause for a server to abort the handshake, given this possibility". -Ben > > On Mon, Feb 19, 2018 at 5:51 PM, Jim Schaad wrote: >> I was looking at this document relative to a specific question for Kathleen, >> and I had one thing that I would like you to look at and see if you think it >> is clear enough. >> >> I have a server that is TLS 1.2, a client that is TLS 1.2 & 1.3. It sends >> a hello w/ and extension value of 2^14+1. It is not completely clear to me >> that the server should accept this as a legal value and compute the min of >> it and the maximum 1.2 value as the value to use when sending messages to >> the client rather than producing an error message because the value is too >> large. >> >> Jim >> >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Feb 19 07:58:58 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F24A0124BAC; Mon, 19 Feb 2018 07:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 vbK3sxaM5BUx; Mon, 19 Feb 2018 07:58:48 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B496120721; Mon, 19 Feb 2018 07:58:48 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id m19so6020305pgn.1; Mon, 19 Feb 2018 07:58:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=DKITJGbuSfFybmJFVTurTa/oc7jtnLkjdG5QeW0X0fc=; b=L9mNSQ1pcifD18/zQDlpbm5fGlL8/AaiegvIoP+iY5bhquKhGKypW/W2cixmRpKonv tdfM7NAxOjvE80nFMxPd+jWO71fb1fdzcEZLwcrvtcBP1tlj6dRmURpj4Vg7IHQQ591L uCsL9Y9RVoCsu9Sq0XkVgRHEzUw0fKkA1AcCMp6F7OYnsAvy43WOQ8V5DnZqUgtDR2h2 Ixu+uqs3LEHrEe7VIU8CWWGdNH8yquCPprPa7FEeNscGOnqdj7j2b8hprpFEPyr/k8G+ aaucnLOeEaXJqIzpgkBQy1AxnGydImei3izHoDIRPyR7lTirPmukzdFERYX5aWpxVl4V msjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=DKITJGbuSfFybmJFVTurTa/oc7jtnLkjdG5QeW0X0fc=; b=aRWyaGWm/EJjMb0toGbHqnke/kGgHzPr9+aRb8r4Jvbm6ZoXCjAMop7nil0ZsUWQXB v+qS5pNYDaMEDcjju+Mbm5cUbqZaXMVH/jsDXWZcYY1dfi2TeM+DQUx1x80BxrDITIFW +QsPtEdEyyn5AKr9EdhF3kU4FPfFVS3DFQHYebuDIQxEENs7FPZaFeh8Ks6xJFVfrpkX NdlRjHIzYfXf3j0M6JKZ8JW8lBUD+OEnLqqB+5Ud9Y8On1+REe1XR/ttyrbtMk10pa2r TyXC7q0TojMXvwGNRtJiejAKJvsK6Kvl+kDPHNmBj8JSa8pD+o2WxVfGFm72wbh442pS JnIw== X-Gm-Message-State: APf1xPA1cLPoMGBOFNSKr1hDrNtuPARRI9EeKQx6ggvG22cmgagXIEuK uOL9kZNE3TjVZbozFeVUuaIuLRvI2hPN/QCBzsQ= X-Google-Smtp-Source: AH8x226dQGv1M5esrB8drz87rCw8t4c/wLRWStG9cnS0gvOv5QwqScwVlO5o4KYgVLRYyW1eTZ7ynD5m/Oi+ecqCgps= X-Received: by 10.99.111.130 with SMTP id k124mr4396974pgc.236.1519055927735; Mon, 19 Feb 2018 07:58:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.229.67 with HTTP; Mon, 19 Feb 2018 07:58:07 -0800 (PST) From: Kathleen Moriarty Date: Mon, 19 Feb 2018 10:58:07 -0500 Message-ID: To: Yuhong Bao Cc: IETF-Announce , "ietf@ietf.org" , "draft-ietf-tls-tls13@ietf.org" , "tls-chairs@ietf.org" , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 15:58:50 -0000 Dear Yuhong, As the sponsoring Area Director, my job is to take the draft forward as was determined by working group consensus. Like Stephen, I'm also not particularly happy about the choice to leave in 0-RTT, but I have to support it as a WG decision. Whatever the version number in the ServerHello decision is from the WG, I will support that decision. The ServerHello decision doesn't really fall into the, "arms race" as you put it. More on that in another thread. Best regards, Kathleen On Thu, Feb 15, 2018 at 9:04 PM, Yuhong Bao wrote: > I wonder what is IESG's opinion on the TLS arms race with middleboxes. > Yes, I am talking about moving the version number in the ServerHello. > > ________________________________________ > From: TLS on behalf of The IESG > Sent: Thursday, February 15, 2018 1:13:48 PM > To: IETF-Announce > Cc: draft-ietf-tls-tls13@ietf.org; tls-chairs@ietf.org; tls@ietf.org > Subject: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard > > > The IESG has received a request from the Transport Layer Security WG (tls) to > consider the following document: - 'The Transport Layer Security (TLS) > Protocol Version 1.3' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2018-03-01. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the beginning of > the Subject line to allow automated sorting. > > Abstract > > > This document specifies version 1.3 of the Transport Layer Security > (TLS) protocol. TLS allows client/server applications to communicate > over the Internet in a way that is designed to prevent eavesdropping, > tampering, and message forgery. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ballot/ > > The following IPR Declarations may be related to this I-D: > > https://datatracker.ietf.org/ipr/2900/ > > > > The document contains these normative downward references. > See RFC 3967 for additional information: > rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2 (Informational - IETF stream) > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Best regards, Kathleen From nobody Mon Feb 19 08:00:43 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98AFB127909; Mon, 19 Feb 2018 08:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ioXtMMgrNQBP; Mon, 19 Feb 2018 08:00:33 -0800 (PST) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A165F129C53; Mon, 19 Feb 2018 08:00:33 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id i3so2305669pfe.5; Mon, 19 Feb 2018 08:00:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=u1hv3eH5BRQwXKaTDtzNOnTT5znTuq5WRsMLd2lFrE0=; b=PfdONWCrfgGeBUW+uU9VD1hLPXVaafzLA6oTT1mpFsMdVR3pzgMm/X7p2ESp+X/UVg IxGO7lYTPN66ZDEcXXeGK3gGNlqUVK2BqBRBjohKZyZHQBZynB+B4jXwUAq3MpajFkhM wSO0pGTYZxHXKfW8s4JMLG5uW+wJkyanbH73rjm7Wwn30+VH/ecL53vOad9WitKETLhH 8W1+Aetw9CtgVZyAjg8rh1oiLFqi2hKopamecpK2JrKw+69tuPZ2ZretMnCwghv574Wy b4v4sKaoHyNENR8O7/rGjeGBOf1q/ICjt9U/bZ2vvMRmDuPxFSwZzH4rWup+qDUw67NJ yNiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=u1hv3eH5BRQwXKaTDtzNOnTT5znTuq5WRsMLd2lFrE0=; b=nWA1bwAzmlD7C1ARRviC4ygsYUOMjC+pxD5fm0WTOL7OWAPUPNvgmYSLsogjD1/tGV 5vQ3NVU9d0Aeynq59fYUAREBb4tVO1ia7PSv0gVC6YJhChpwRIIg0hKEm6DJtho7go5t m55VOZ6h/GnrMxFjZl92axfV46hbQ6cKn8JZxBNgzchh8+xfBW7gX8CoQ146dTPz2OhX 2YhEFz2ewTUdnQtSZQ2dUPHpTNpivqh70s0TEbWPgV6Egs/FRxyMFNOWQ6Dp31wDIWYp 8TI88KwNgvhqsV2tYMOfJ3IAfYT8V+1NeQJK5oDUhQ4xVAM8z6S4mDSOKmpsZu00t8Lb 0BBg== X-Gm-Message-State: APf1xPBmN1XuPZCvZ021xwfjeE+eK3+FWsmGWc+kBUV2gMY4DlIYU4Yk hy3p524TzBSpw3+AptnnFb7prb6+CJG6DUjE1TZDfw== X-Google-Smtp-Source: AH8x225hG1uECM1t6P7KLRrHWQT1nCglKmDcNzpC2oYWjxDw4v79Feu3pLRL7bWYwqtYSa3UfMTRVZJPmxLt3+PZWeQ= X-Received: by 10.99.111.130 with SMTP id k124mr4400605pgc.236.1519056033114; Mon, 19 Feb 2018 08:00:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.229.67 with HTTP; Mon, 19 Feb 2018 07:59:52 -0800 (PST) From: Kathleen Moriarty Date: Mon, 19 Feb 2018 10:59:52 -0500 Message-ID: To: Yuhong Bao Cc: IETF-Announce , "ietf@ietf.org" , "draft-ietf-tls-tls13@ietf.org" , "tls-chairs@ietf.org" , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] Middlebox "arms race" WAS: Re: Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 16:00:37 -0000 Dear Yuhong, My personal opinion in the "arms race" (your phrasing, not mine), no AD hat on (as that one is to support the WG decision), is that it will continue until we really hear each other out and think more on the problems the other side is trying to solve. Perhaps there are ways to meet all or at least some of the goals in other ways. If we don't work together to understand the challenges, we'll never make progress and remain in this arms race. I also think that if you push on e2e in protocol design without listening to the other side, protocols may not enjoy the deployment percentages that you'd like to see, adoption could be hindered. Many of the operators have expressed that they would like to see e2e and are fully supportive of privacy goals, but are trying to figure out other ways to accomplish tasks. Logging from applications has been found to be lacking by many operators, if this could be improved on the application side, then a shift to use end point monitoring becomes more practical. From the draft I have been working on (toward the goal of increasing adoption of e2e protocols), "The Effect of Pervasive Encryption on Operators", the following logging types have been called out as being deficient: Service providers typically use only headers at layers 2,3, and 4 "packet tracing and inspection along the service path provides operators the visibility to continue to diagnose problems reported both internally and by their customers. Logging of service path upon exit for routing overlay protocols will assist with policy management and troubleshooting capabilities for traffic flows on encrypted networks. Protocol trace logging and protocol data unit (PDU) logging should also be considered to improve visibility to monitor and troubleshoot application level traffic." Within the enterprise (where they already own all the data), logging at a more granular level for application debugging will assist with a transition to rely more on end points for diagnostics. Interactions between applications an databases has been called out as an issue that could be improved with enhanced logs on transactions, queries, etc. Fraud detection does rely on transaction monitoring already, but banks are using network based tools as well for this and other incident detection (data exfiltration, etc.). In this case, pattern detection is really helpful and that might include variances in sizes of packets, destinations, times of transactions, types of data accessed (by who, when), etc. Some of this can still be done on the network with encrypted traffic streams. I personally think e2e would get further ahead in the arms race if they spent time working to solve these other issues with operators so that monitoring could move to the end point or closer to it. Yoav has said it on list before, vendors of middleboxes often update quickly. My interpretation of that is continuing to alter the protocol to break middleboxes won't work as a strategy to disrupt many middleboxes. Solving customer problems will have a much greater impact toward improving deployment in my personal opinion. Much of this debate is about control anyway - application vs. network - and not about privacy. Many operators also support the goal of privacy for end users. Best regards, Kathleen On Mon, Feb 19, 2018 at 10:58 AM, Kathleen Moriarty wrote: > Dear Yuhong, > > As the sponsoring Area Director, my job is to take the draft forward > as was determined by working group consensus. Like Stephen, I'm also > not particularly happy about the choice to leave in 0-RTT, but I have > to support it as a WG decision. Whatever the version number in the > ServerHello decision is from the WG, I will support that decision. > The ServerHello decision doesn't really fall into the, "arms race" as > you put it. More on that in another thread. > > Best regards, > Kathleen > > On Thu, Feb 15, 2018 at 9:04 PM, Yuhong Bao wrote: >> I wonder what is IESG's opinion on the TLS arms race with middleboxes. >> Yes, I am talking about moving the version number in the ServerHello. >> >> ________________________________________ >> From: TLS on behalf of The IESG >> Sent: Thursday, February 15, 2018 1:13:48 PM >> To: IETF-Announce >> Cc: draft-ietf-tls-tls13@ietf.org; tls-chairs@ietf.org; tls@ietf.org >> Subject: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard >> >> >> The IESG has received a request from the Transport Layer Security WG (tls) to >> consider the following document: - 'The Transport Layer Security (TLS) >> Protocol Version 1.3' >> as Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits final >> comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2018-03-01. Exceptionally, comments may be >> sent to iesg@ietf.org instead. In either case, please retain the beginning of >> the Subject line to allow automated sorting. >> >> Abstract >> >> >> This document specifies version 1.3 of the Transport Layer Security >> (TLS) protocol. TLS allows client/server applications to communicate >> over the Internet in a way that is designed to prevent eavesdropping, >> tampering, and message forgery. >> >> >> >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ >> >> IESG discussion can be tracked via >> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ballot/ >> >> The following IPR Declarations may be related to this I-D: >> >> https://datatracker.ietf.org/ipr/2900/ >> >> >> >> The document contains these normative downward references. >> See RFC 3967 for additional information: >> rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2 (Informational - IETF stream) >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > > > -- > > Best regards, > Kathleen -- Best regards, Kathleen From nobody Mon Feb 19 08:32:07 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1D5120713; Mon, 19 Feb 2018 08:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 gCZxQhtxmvzM; Mon, 19 Feb 2018 08:32:03 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38AF71201F8; Mon, 19 Feb 2018 08:32:03 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 19 Feb 2018 08:30:15 -0800 From: Jim Schaad To: 'Martin Thomson' , CC: References: <008b01d3a94e$1cc174e0$56445ea0$@augustcellars.com> In-Reply-To: Date: Mon, 19 Feb 2018 08:31:53 -0800 Message-ID: <00a401d3a99f$28679e90$7936dbb0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQIj8Qn+aH0ker1+WmRwus+Llm0/1QMa1TzpovKFBoA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [TLS] Mail regarding draft-ietf-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 16:32:05 -0000 Martin, I think that the wording I would prefer would be along the lines of=20 A server MUST NOT error on the value of the extension when a higher TLS = version is requested. The server MUST use the minimum of the requested = value and the maximum value for the TLS version negotiated. A server = MAY error if a the value of the extension is exceeded for the version of = TLS requested. > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: Monday, February 19, 2018 2:15 AM > To: Jim Schaad ; > Cc: draft-ietf-tls-record-limit@ietf.org > Subject: Re: Mail regarding draft-ietf-tls-record-limit >=20 > (+tls@) >=20 > This is a good question Jim and one that I thought through during > implementation, but failed to capture in the doc. >=20 > Basically, there is no way to validate the extension if the client = includes an > unknown version of TLS or an extension that it doesn't understand. A = client > can know because it should understand the protocol as negotiated. >=20 > The text currently says "an endpoint MUST NOT send a value higher than = the > protocol-defined maximum record size unless explicitly allowed by such = a > future version or extension" I think that we should add "A server = MUST NOT > enforce this restriction; a client might advertise a higher limit that = is enabled > by an extension or version the server does not understand." >=20 > Does that make sense? >=20 >=20 > On Mon, Feb 19, 2018 at 5:51 PM, Jim Schaad > wrote: > > I was looking at this document relative to a specific question for > > Kathleen, and I had one thing that I would like you to look at and = see > > if you think it is clear enough. > > > > I have a server that is TLS 1.2, a client that is TLS 1.2 & 1.3. = It sends > > a hello w/ and extension value of 2^14+1. It is not completely = clear > > to me that the server should accept this as a legal value and = compute > > the min of it and the maximum 1.2 value as the value to use when > > sending messages to the client rather than producing an error = message > > because the value is too large. > > > > Jim > > > > From nobody Mon Feb 19 09:18:39 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF749127873; Mon, 19 Feb 2018 09:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 XjnOkK9i-_sx; Mon, 19 Feb 2018 09:18:36 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF29D1243F6; Mon, 19 Feb 2018 09:18:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 2F49B375E9; Mon, 19 Feb 2018 19:18:32 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id n7fleE1x99kR; Mon, 19 Feb 2018 19:18:31 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id AB32B28C; Mon, 19 Feb 2018 19:18:27 +0200 (EET) Date: Mon, 19 Feb 2018 19:18:27 +0200 From: Ilari Liusvaara To: Jim Schaad Cc: 'Martin Thomson' , tls@ietf.org, draft-ietf-tls-record-limit@ietf.org Message-ID: <20180219171827.GA28597@LK-Perkele-VII> References: <008b01d3a94e$1cc174e0$56445ea0$@augustcellars.com> <00a401d3a99f$28679e90$7936dbb0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <00a401d3a99f$28679e90$7936dbb0$@augustcellars.com> User-Agent: Mutt/1.9.3 (2018-01-21) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Mail regarding draft-ietf-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 17:18:38 -0000 On Mon, Feb 19, 2018 at 08:31:53AM -0800, Jim Schaad wrote: > Martin, > > I think that the wording I would prefer would be along the lines of > > A server MUST NOT error on the value of the extension when a higher > TLS version is requested. The server MUST use the minimum of the > requested value and the maximum value for the TLS version negotiated. > A server MAY error if a the value of the extension is exceeded for > the version of TLS requested. You need to consider the case where there is some unknown-to-server extension that happens to alter the limit. -Ilari From nobody Mon Feb 19 09:27:25 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 710B2129502; Mon, 19 Feb 2018 09:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 eftp3FvjRz3S; Mon, 19 Feb 2018 09:27:23 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D48CA1243F6; Mon, 19 Feb 2018 09:27:22 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 19 Feb 2018 09:25:35 -0800 From: Jim Schaad To: CC: 'Martin Thomson' , , References: <008b01d3a94e$1cc174e0$56445ea0$@augustcellars.com> <00a401d3a99f$28679e90$7936dbb0$@augustcellars.com> <20180219171827.GA28597@LK-Perkele-VII> In-Reply-To: <20180219171827.GA28597@LK-Perkele-VII> Date: Mon, 19 Feb 2018 09:27:14 -0800 Message-ID: <00ae01d3a9a6$e3757f70$aa607e50$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQIj8Qn+aH0ker1+WmRwus+Llm0/1QMa1TzpAZp39z4CjXJtMqLRVYlg X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [TLS] Mail regarding draft-ietf-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 17:27:24 -0000 > -----Original Message----- > From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com] > Sent: Monday, February 19, 2018 9:18 AM > To: Jim Schaad > Cc: 'Martin Thomson' ; tls@ietf.org; = draft-ietf- > tls-record-limit@ietf.org > Subject: Re: [TLS] Mail regarding draft-ietf-tls-record-limit >=20 > On Mon, Feb 19, 2018 at 08:31:53AM -0800, Jim Schaad wrote: > > Martin, > > > > I think that the wording I would prefer would be along the lines of > > > > A server MUST NOT error on the value of the extension when a higher > > TLS version is requested. The server MUST use the minimum of the > > requested value and the maximum value for the TLS version = negotiated. > > A server MAY error if a the value of the extension is exceeded for = the > > version of TLS requested. >=20 > You need to consider the case where there is some unknown-to-server > extension that happens to alter the limit. I am not sure how, as a that server, I could possibly do that. I can't = act on something I don't understand. Jim >=20 >=20 > -Ilari From nobody Mon Feb 19 09:50:55 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84349124319; Mon, 19 Feb 2018 09:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 Es3-gMvJmFbQ; Mon, 19 Feb 2018 09:50:51 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 462E41241F5; Mon, 19 Feb 2018 09:50:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id D59B249BDB; Mon, 19 Feb 2018 19:50:48 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id mmllGvNdAjzC; Mon, 19 Feb 2018 19:50:48 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id F3A0D72; Mon, 19 Feb 2018 19:50:43 +0200 (EET) Date: Mon, 19 Feb 2018 19:50:43 +0200 From: Ilari Liusvaara To: Jim Schaad Cc: 'Martin Thomson' , tls@ietf.org, draft-ietf-tls-record-limit@ietf.org Message-ID: <20180219175043.GA28923@LK-Perkele-VII> References: <008b01d3a94e$1cc174e0$56445ea0$@augustcellars.com> <00a401d3a99f$28679e90$7936dbb0$@augustcellars.com> <20180219171827.GA28597@LK-Perkele-VII> <00ae01d3a9a6$e3757f70$aa607e50$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <00ae01d3a9a6$e3757f70$aa607e50$@augustcellars.com> User-Agent: Mutt/1.9.3 (2018-01-21) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Mail regarding draft-ietf-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 17:50:54 -0000 On Mon, Feb 19, 2018 at 09:27:14AM -0800, Jim Schaad wrote: > > > > -----Original Message----- > > From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com] > > Sent: Monday, February 19, 2018 9:18 AM > > To: Jim Schaad > > Cc: 'Martin Thomson' ; tls@ietf.org; draft-ietf- > > tls-record-limit@ietf.org > > Subject: Re: [TLS] Mail regarding draft-ietf-tls-record-limit > > > > On Mon, Feb 19, 2018 at 08:31:53AM -0800, Jim Schaad wrote: > > > Martin, > > > > > > I think that the wording I would prefer would be along the lines of > > > > > > A server MUST NOT error on the value of the extension when a higher > > > TLS version is requested. The server MUST use the minimum of the > > > requested value and the maximum value for the TLS version negotiated. > > > A server MAY error if a the value of the extension is exceeded for the > > > version of TLS requested. > > > > You need to consider the case where there is some unknown-to-server > > extension that happens to alter the limit. > > I am not sure how, as a that server, I could possibly do that. I can't > act on something I don't understand. Because the server can not know the semantics of unknown extensions, it has to assume any such can alter the maximum limit. Of course, when it comes to that, the server could just not error on too large limits regardless of other extensions. -Ilari From nobody Mon Feb 19 09:56:04 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF6A124319; Mon, 19 Feb 2018 09:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 U4ypUN8dkVzH; Mon, 19 Feb 2018 09:56:00 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7932D1241F5; Mon, 19 Feb 2018 09:56:00 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 19 Feb 2018 09:54:13 -0800 From: Jim Schaad To: CC: 'Martin Thomson' , , References: <008b01d3a94e$1cc174e0$56445ea0$@augustcellars.com> <00a401d3a99f$28679e90$7936dbb0$@augustcellars.com> <20180219171827.GA28597@LK-Perkele-VII> <00ae01d3a9a6$e3757f70$aa607e50$@augustcellars.com> <20180219175043.GA28923@LK-Perkele-VII> In-Reply-To: <20180219175043.GA28923@LK-Perkele-VII> Date: Mon, 19 Feb 2018 09:55:51 -0800 Message-ID: <00b001d3a9aa$e3700460$aa500d20$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQIj8Qn+aH0ker1+WmRwus+Llm0/1QMa1TzpAZp39z4CjXJtMgFPrUKCAXzf5qeiuvjhcA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [TLS] Mail regarding draft-ietf-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 17:56:02 -0000 > -----Original Message----- > From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com] > Sent: Monday, February 19, 2018 9:51 AM > To: Jim Schaad > Cc: 'Martin Thomson' ; tls@ietf.org; = draft-ietf- > tls-record-limit@ietf.org > Subject: Re: [TLS] Mail regarding draft-ietf-tls-record-limit >=20 > On Mon, Feb 19, 2018 at 09:27:14AM -0800, Jim Schaad wrote: > > > > > > > -----Original Message----- > > > From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com] > > > Sent: Monday, February 19, 2018 9:18 AM > > > To: Jim Schaad > > > Cc: 'Martin Thomson' ; tls@ietf.org; > > > draft-ietf- tls-record-limit@ietf.org > > > Subject: Re: [TLS] Mail regarding draft-ietf-tls-record-limit > > > > > > On Mon, Feb 19, 2018 at 08:31:53AM -0800, Jim Schaad wrote: > > > > Martin, > > > > > > > > I think that the wording I would prefer would be along the lines > > > > of > > > > > > > > A server MUST NOT error on the value of the extension when a > > > > higher TLS version is requested. The server MUST use the = minimum > > > > of the requested value and the maximum value for the TLS version > negotiated. > > > > A server MAY error if a the value of the extension is exceeded = for > > > > the version of TLS requested. > > > > > > You need to consider the case where there is some = unknown-to-server > > > extension that happens to alter the limit. > > > > I am not sure how, as a that server, I could possibly do that. I > > can't act on something I don't understand. >=20 > Because the server can not know the semantics of unknown extensions, = it has > to assume any such can alter the maximum limit. Of course, when it = comes to > that, the server could just not error on too large limits regardless = of other > extensions. But if the server does not understand the new extension, then it would = not be returned to the client so that the client would understand how = the server decided on what the maximum value that it is going to use for = the client is. The client can then abort the connection if it does not = like the new limit. However, I think that this would only affect the = MAY in the proposed text. Jim >=20 >=20 > -Ilari From nobody Mon Feb 19 10:06:29 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 680FA124319; Mon, 19 Feb 2018 10:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 B0u-JKy40icw; Mon, 19 Feb 2018 10:06:26 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 6400A12420B; Mon, 19 Feb 2018 10:06:26 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1JI4AgT000976; Mon, 19 Feb 2018 18:06:17 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=sGX1UwKMoxi3OUH0fnVvw7Tl3JZkJ7cT07si4WzYtMA=; b=NYIiqx8Wx5SZ3L8IFJtbXqT+/07is0PlEYY9InqAD1lxSY8j4iQgYNt07A6TtYNaBHKm MkXwxUVJFcDnWtJNPPTwiKRNCOvuEzBRgfV9y4uftL1mDvBZBrhHZpwZk0cGCh//r8bi CMjsT4KqhPPcoklqfHPJ6cDgmSxfJaZFkPjSwZFAz0I99mi/lAEUgLanT2JkBGZ2CV8T miaNVcwxj31Y1J1dfbr9ZY4Ag4mdC1s/p2tLbLRhumpQbagxTMN/cnjZ7iVOHgCLQHSo Ps8gTfiBaesXip2BVCU2N7PxZchPx+9x6Q23XD9SY/cULUU7WBrv1iRH8MdIGkC/Ohkd 8g== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050093.ppops.net-00190b01. with ESMTP id 2g6chqf66y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Feb 2018 18:06:15 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w1JI16Jv003513; Mon, 19 Feb 2018 13:06:14 -0500 Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint2.akamai.com with ESMTP id 2g6gmep4tc-1; Mon, 19 Feb 2018 13:06:14 -0500 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id EAAF3338BB; Mon, 19 Feb 2018 18:06:13 +0000 (GMT) To: Jim Schaad , ilariliusvaara@welho.com Cc: draft-ietf-tls-record-limit@ietf.org, tls@ietf.org References: <008b01d3a94e$1cc174e0$56445ea0$@augustcellars.com> <00a401d3a99f$28679e90$7936dbb0$@augustcellars.com> <20180219171827.GA28597@LK-Perkele-VII> <00ae01d3a9a6$e3757f70$aa607e50$@augustcellars.com> <20180219175043.GA28923@LK-Perkele-VII> <00b001d3a9aa$e3700460$aa500d20$@augustcellars.com> From: Benjamin Kaduk Message-ID: Date: Mon, 19 Feb 2018 12:06:13 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <00b001d3a9aa$e3700460$aa500d20$@augustcellars.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-19_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=466 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802190222 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-19_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=445 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802190223 Archived-At: Subject: Re: [TLS] Mail regarding draft-ietf-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 18:06:27 -0000 On 02/19/2018 11:55 AM, Jim Schaad wrote: > >> -----Original Message----- >> From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com] >> Sent: Monday, February 19, 2018 9:51 AM >> To: Jim Schaad >> Cc: 'Martin Thomson' ; tls@ietf.org; draft-ietf- >> tls-record-limit@ietf.org >> Subject: Re: [TLS] Mail regarding draft-ietf-tls-record-limit >> >> On Mon, Feb 19, 2018 at 09:27:14AM -0800, Jim Schaad wrote: >>> >>>> -----Original Message----- >>>> From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com] >>>> Sent: Monday, February 19, 2018 9:18 AM >>>> To: Jim Schaad >>>> Cc: 'Martin Thomson' ; tls@ietf.org; >>>> draft-ietf- tls-record-limit@ietf.org >>>> Subject: Re: [TLS] Mail regarding draft-ietf-tls-record-limit >>>> >>>> >>>> You need to consider the case where there is some unknown-to-server >>>> extension that happens to alter the limit. >>> I am not sure how, as a that server, I could possibly do that. I >>> can't act on something I don't understand. >> Because the server can not know the semantics of unknown extensions, it has >> to assume any such can alter the maximum limit. Of course, when it comes to >> that, the server could just not error on too large limits regardless of other >> extensions. > But if the server does not understand the new extension, then it would not be returned to the client so that the client would understand how the server decided on what the maximum value that it is going to use for the client is. The client can then abort the connection if it does not like the new limit. However, I think that this would only affect the MAY in the proposed text. > > Consider the hypothetical case where we define an extension my_mtu_is_absurd, that lets you send 2**16-1-byte records, so the client sends that extension as well as a record_size_limit extension including the 2**16-1-byte value.  A server that does not know about my_mtu_is_absurd might say "this value 2**16-1 is way too big; I'm going to abort", and that's the behavior that we're trying to prevent. -Ben From nobody Mon Feb 19 10:23:56 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABE31204DA; Mon, 19 Feb 2018 10:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 x0_2zlZppPX8; Mon, 19 Feb 2018 10:23:52 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 194A91201F2; Mon, 19 Feb 2018 10:23:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 75E243C8F4; Mon, 19 Feb 2018 20:23:49 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id vNEMzX1O830A; Mon, 19 Feb 2018 20:23:47 +0200 (EET) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id A129279; Mon, 19 Feb 2018 20:23:43 +0200 (EET) Date: Mon, 19 Feb 2018 20:23:43 +0200 From: Ilari Liusvaara To: Jim Schaad Cc: 'Martin Thomson' , tls@ietf.org, draft-ietf-tls-record-limit@ietf.org Message-ID: <20180219182343.GA28980@LK-Perkele-VII> References: <008b01d3a94e$1cc174e0$56445ea0$@augustcellars.com> <00a401d3a99f$28679e90$7936dbb0$@augustcellars.com> <20180219171827.GA28597@LK-Perkele-VII> <00ae01d3a9a6$e3757f70$aa607e50$@augustcellars.com> <20180219175043.GA28923@LK-Perkele-VII> <00b001d3a9aa$e3700460$aa500d20$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <00b001d3a9aa$e3700460$aa500d20$@augustcellars.com> User-Agent: Mutt/1.9.3 (2018-01-21) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Mail regarding draft-ietf-tls-record-limit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 18:23:54 -0000 On Mon, Feb 19, 2018 at 09:55:51AM -0800, Jim Schaad wrote: > > > > -----Original Message----- > > From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com] > > Sent: Monday, February 19, 2018 9:51 AM > > To: Jim Schaad > > Cc: 'Martin Thomson' ; tls@ietf.org; draft-ietf- > > tls-record-limit@ietf.org > > Subject: Re: [TLS] Mail regarding draft-ietf-tls-record-limit > > > > Because the server can not know the semantics of unknown extensions, it has > > to assume any such can alter the maximum limit. Of course, when it comes to > > that, the server could just not error on too large limits regardless of other > > extensions. > > But if the server does not understand the new extension, then it would > not be returned to the client so that the client would understand how > the server decided on what the maximum value that it is going to use for > the client is. The client can then abort the connection if it does not > like the new limit. However, I think that this would only affect the > MAY in the proposed text. Suppose client supports large-records extension that allows records up to 65535 bytes, but the server does not know about this extension. Then ClientHello which has record size limit of 65519 and the extension MUST NOT cause an abort, because such ClientHello is fully valid. This would be very unusual requirement. So better to specify that the server MUST accept overly large values, internally truncating to the negotiated protocol maximums or implementation maximums, whichever is smaller. The server to client direction is different matter. Client always understands all server extensions (there is a requirement to abort otherwise) so it knows what is the maximum possible record size for the negotiated protocol and can check that. However, it must still internally trunccate that to implementation maximums. Also, the values are capability advertisments, so the server value can be larger or smaller than the client value. Following is fully legal and well-defined in TLS 1.3: Client: maximum-record-size=1025 (do not send me more than 1024 bytes of record plaintext). Server: maximum-record-size=16385 (understood, send me any size you like within protocol limits). -Ilari From nobody Mon Feb 19 11:13:50 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A77126C0F for ; Mon, 19 Feb 2018 11:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.com 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 DCCaqICSr7Pr for ; Mon, 19 Feb 2018 11:13:46 -0800 (PST) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0E09124BFA for ; Mon, 19 Feb 2018 11:13:45 -0800 (PST) Received: by mail-yb0-x233.google.com with SMTP id v135-v6so3169706ybe.2 for ; Mon, 19 Feb 2018 11:13:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lrJQsq/53eA9bboOiOJoG0W6KaoIUstIZBShcmDqPu4=; b=lRmgnvLYP31Er5h4j2a8uwxQDt65IjqbMAiR6Riwf/bI9lZlNPOC6Tf7h9RATSCIcS NsEdNyRrnFCJVD+X9LVYazvDqnrs7B5BlcItAK6aSoUzRggGw3s7bep2wP56vWGsklj7 DkwOCPb0qNMhsLZIzdisXdtayjqeIHBsyvEaNU2Lt6w0R+SS6MWtJY4XB9YSiUykGIIT PpBzhkBI1koUt900jNnP+i9YEzCKOHJawtobXJF1tvbJ2ZzNdKrjbiodou+b5eZRW823 py6tVXKru/Ef8Ho2g3mL6jZrZSxrqjJBsptqua2z/+1qcSPQGw/YLO/AVuFzmG4G1cg3 Klpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lrJQsq/53eA9bboOiOJoG0W6KaoIUstIZBShcmDqPu4=; b=H2sL8XQnGimZks1hRIRe+FzuOjKHPCOvlpUkNlA9+L3/GGOwQW9U08qc3nMfOMhNwC 9BbMaBkOeJEp3iL7ZH9Gq2Jgmu18XpPWWReSI0N5HVtAxC54ZzdDeJsjR/b8hpld0GKP FLrzgyPmLvqjEJPVT4/UzBtsSf6gTC/gvinF5S89VuhTc03/9dThRPmkomJAHZv0a2rx 0LX3knKXcMPMhr1y9hKESnOAb+cJjivryKjiF3eG+fzuKM1Cx9h4UUkOjYYUojeNN/4m VbATrO6a3zSo1Xa07lHYe71PeKgZYaF1ZiKSH98/LPBW0kfca7+CAgMIVZ0EhFzna4YH TtNQ== X-Gm-Message-State: APf1xPBvFKRl2s2o/nykszUadwEbRkM7Gtmckadwlu2S7KYseBHU3USt RYeTFMCc8A40soyl+C3h1hYgBwCOf323P/82yXjhVA== X-Google-Smtp-Source: AH8x225MJQmpu7uq/DCFAita+CRlWs7Ih+LBQ6TM+Fh0fyF3i4ozbeA/b886MX/jP708ODRMxoDsLo8Rqca+81xz6zE= X-Received: by 10.37.174.92 with SMTP id g28mr7501521ybe.269.1519067624880; Mon, 19 Feb 2018 11:13:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.116.8 with HTTP; Mon, 19 Feb 2018 11:13:44 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Mon, 19 Feb 2018 11:13:44 -0800 Message-ID: To: Kathleen Moriarty Cc: Yuhong Bao , "tls@ietf.org" , "draft-ietf-tls-tls13@ietf.org" , "ietf@ietf.org" , IETF-Announce , "tls-chairs@ietf.org" Content-Type: multipart/alternative; boundary="f403045ecde02bd3b80565957eaa" Archived-At: Subject: Re: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 19:13:49 -0000 --f403045ecde02bd3b80565957eaa Content-Type: text/plain; charset="UTF-8" Since this IETF-LC/IESG process is a good chance to get a sanity check, I'd like to boil down what I think are the nits and risks with 0-RTT, and if others want to weigh in they can. I'll state my own position at the bottom. Broadly, I think there are three issues with 0-RTT: 1) The TLS 1.3 draft allows for 0-RTT data, including things like requests and headers, to be replayed by attackers. 2) 0-RTT data, again including requests and headers, has no cryptographic guarantee of forward-secrecy and will likely be protected by symmetric session ticket encryption keys (STEK) that can be used quite broadly with no limits on re-use, rotation, and rely on vendors being able to share and revoke keys frequently and securely. Basically: If a vendors STEK is compromised, than an unbounded number of end-user requests and headers can be decrypted. This obviously defeats the goal of achieving forward secrecy. 3) While no working attack has been found, some cryptographers and protocol experts believe that the 0-RTT exchange is overly-complex and a source of risk. Kenny Paterson made the most prominent statement ( http://bristolcrypto.blogspot.com/2017/03/pkc-2017-kenny-paterson-accepting-bets.html ), but I've heard it echoed at several IACR events. It is definitely true that 0-RTT resumption complicates the TLS state machine and creates unusual conditions such as needing to restart messaging sequences. The TLS-WG was chartered with "aiming for one roundtrip for a full handshake and one or zero roundtrip for repeated handshakes. The aim is also to maintain current security features" ( https://datatracker.ietf.org/wg/tls/charter/). But with these 3 issues, there is a clearly a trade-off between security (the S in TLS) and speed. Issue 3 is matter of judgment; my personal judgement is that we will see implementation bugs due to state machine complexity, but there's no evidence that the cryptographic and protocol semantics are not robust. With regards to issues 1, and 2, the latest TLS draft makes it possible to achieve both of these aims. Through the use of single-use session tickets, it is possible to provide anti-replay and forward-secrecy properties for 0-RTT data. I'm grateful for the changes that were introduced for this. At the same time though, most vendors have stated that they don't plan to do that and instead have designed around limited replay time windows, non-transactional strike registers, and non-forward secure tickets. This is what I expect to see deployed, and already see with some TLS1.3 deployment experiments. TLS1.3 could be more restrictive here; limiting the size of session tickets to smaller than the size of session state would effectively forbid any kind of session encoding which would force the issue, but several vendors are against it because it doesn't align with current practices and it incurs the cost of server-size caching. For balance, in the last year I have heard from most vendors that they do plan to implement some anti-replay mitigation though, beyond the simple time-windowing, which goes a way to protecting users from throttle limits. I am disappointed by the unfortunate preference for cost-saving over robust security. Good cryptography usually costs money, or else we'd still be using RC4. I do think that we will see security and correctness issues due to replays interacting with non-idempotent services and throttling configurations. While it's true that browsers can be made to replay requests already, there are many web and non-HTTP services that are certainly not tolerant of replays. Secondly, I think that it is inevitable that vendor security compromises will disclose troves of user requests, passwords, credit cards to decryption; but this is perhaps more of a nation-state-adversary level risk. Some more detail on attacks related to issues 1/ and 2/ is available in the security review of 0-RTT data: https://github.com/tlswg/tls13-spec/issues/1001 . After all of that, here's my own position: I strongly support the current TLS1.3 draft progressing to RFC status. I work at Amazon, where one of our leadership principles is "Disagree and Commit" (https://www.amazon.jobs/principles); the idea is that it's important to make yourself heard, but also to move forward and not be endlessly bogged down. I've been vocal about 0-RTT risks, and certainly heard and understood, and those concerns have been reflected in generous changes to the draft. I'm happy that it's possible to build a forward-secret, non-repayable 0-RTT implementation and that's what I'm doing. I wish everyone else would too, but that's not consensus; others have a different weighting for the trade-offs between speed, security and cost and those views are also legitimate. But my more important reason for supporting is that overall TLS1.3 is much much better than TLS1.2, including in regards to forward-secrecy, which is now guaranteed for all non-0RTT data. I still believe that it will meaningfully increase the overall security posture for the internet, and I'm super excited to get it out and for users to be getting the benefits. TLS has always been a bit of a mess, it's not as clean as something designed by a single voice focused on modern cryptographic best-practices, but 1.3 does a lot of good cleaning up. Shipping 1.3 doesn't mean things can't be improved further, and delay inflicts 1.2 and lower versions on users for even longer. So let's go! On Mon, Feb 19, 2018 at 7:58 AM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Dear Yuhong, > > As the sponsoring Area Director, my job is to take the draft forward > as was determined by working group consensus. Like Stephen, I'm also > not particularly happy about the choice to leave in 0-RTT, but I have > to support it as a WG decision. Whatever the version number in the > ServerHello decision is from the WG, I will support that decision. > The ServerHello decision doesn't really fall into the, "arms race" as > you put it. More on that in another thread. > > Best regards, > Kathleen > > On Thu, Feb 15, 2018 at 9:04 PM, Yuhong Bao > wrote: > > I wonder what is IESG's opinion on the TLS arms race with middleboxes. > > Yes, I am talking about moving the version number in the ServerHello. > > > > ________________________________________ > > From: TLS on behalf of The IESG < > iesg-secretary@ietf.org> > > Sent: Thursday, February 15, 2018 1:13:48 PM > > To: IETF-Announce > > Cc: draft-ietf-tls-tls13@ietf.org; tls-chairs@ietf.org; tls@ietf.org > > Subject: [TLS] Last Call: (The Transport > Layer Security (TLS) Protocol Version 1.3) to Proposed Standard > > > > > > The IESG has received a request from the Transport Layer Security WG > (tls) to > > consider the following document: - 'The Transport Layer Security (TLS) > > Protocol Version 1.3' > > as Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > final > > comments on this action. Please send substantive comments to the > > ietf@ietf.org mailing lists by 2018-03-01. Exceptionally, comments may > be > > sent to iesg@ietf.org instead. In either case, please retain the > beginning of > > the Subject line to allow automated sorting. > > > > Abstract > > > > > > This document specifies version 1.3 of the Transport Layer Security > > (TLS) protocol. TLS allows client/server applications to communicate > > over the Internet in a way that is designed to prevent eavesdropping, > > tampering, and message forgery. > > > > > > > > > > The file can be obtained via > > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ > > > > IESG discussion can be tracked via > > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ballot/ > > > > The following IPR Declarations may be related to this I-D: > > > > https://datatracker.ietf.org/ipr/2900/ > > > > > > > > The document contains these normative downward references. > > See RFC 3967 for additional information: > > rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2 > (Informational - IETF stream) > > > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > -- > > Best regards, > Kathleen > > -- Colm --f403045ecde02bd3b80565957eaa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Since this IETF-LC/IESG process is a g= ood chance to get a sanity check, I'd like to boil down what I think ar= e the nits and risks with 0-RTT, and if others want to weigh in they can. I= 'll state my own position at the bottom.

Broad= ly, I think there are three issues with 0-RTT:

=C2= =A0 =C2=A01) The TLS 1.3 draft allows for 0-RTT data, including things like= requests and headers, to be replayed by attackers.

=C2=A0 =C2=A02) 0-RTT data, again including requests and headers, has no = cryptographic guarantee of forward-secrecy and will likely be protected by = symmetric session ticket encryption keys (STEK) that can be used quite broa= dly with no limits on re-use, rotation, and rely on vendors being able to s= hare and revoke keys frequently and securely. Basically: If a vendors STEK = is compromised, than an unbounded number of end-user requests and headers c= an be decrypted. This obviously defeats the goal of achieving forward secre= cy.=C2=A0

=C2=A0 3) While no working attack has be= en found, some cryptographers and protocol experts believe that the 0-RTT e= xchange is overly-complex and a source of risk. Kenny Paterson made the mos= t prominent statement ( http://bristolcrypto.blogspo= t.com/2017/03/pkc-2017-kenny-paterson-accepting-bets.html ), but I'= ve heard it echoed at several IACR events. It is definitely true that 0-RTT= resumption complicates the TLS state machine and creates unusual condition= s such as needing to restart messaging sequences.=C2=A0

The TLS-WG was chartered with "aiming for one roundtrip for a fu= ll handshake and one or zero roundtrip for repeated handshakes. The aim is = also to maintain current security features" (https://datatracker.ietf.org/wg/tls/charter= /).=C2=A0 But with these 3 issues, there is a clearly a trade-off betwe= en security (the S in TLS) and speed.=C2=A0

Issue = 3 is matter of judgment; my personal judgement is that we will see implemen= tation bugs due to state machine complexity, but there's no evidence th= at the cryptographic and protocol semantics are not robust.=C2=A0

With regards to issues 1, and 2, the latest TLS draft makes= it possible to achieve both of these aims. Through the use of single-use s= ession tickets, it is possible to provide anti-replay and forward-secrecy p= roperties for 0-RTT data. I'm grateful for the changes that were introd= uced for this. =C2=A0

At the same time though, mos= t vendors have stated that they don't plan to do that and instead have = designed around limited replay time windows, non-transactional strike regis= ters, and non-forward secure tickets. This is what I expect to see deployed= , and already see with some TLS1.3 deployment experiments.=C2=A0 TLS1.3 cou= ld be more restrictive here; limiting the size of session tickets to smalle= r than the size of session state would effectively forbid any kind of sessi= on encoding which would force the issue, but several vendors are against it= because it doesn't align with current practices and it incurs the cost= of server-size caching. For balance, in the last year I have heard from mo= st vendors that they do plan to implement some anti-replay mitigation thoug= h, beyond the simple time-windowing, which goes a way to protecting users f= rom throttle limits.

I am disappointed by the unfo= rtunate preference for cost-saving over robust security. Good cryptography = usually costs money, or else we'd still be using RC4. I do think that w= e will see security and correctness issues due to replays interacting with = non-idempotent services and throttling configurations. While it's true = that browsers can be made to replay requests already, there are many web an= d non-HTTP services that are certainly not tolerant of replays. Secondly, I= think that it is inevitable that vendor security compromises will disclose= troves of user requests, passwords, credit cards to decryption; but this i= s perhaps more of a nation-state-adversary level risk. Some more detail on = attacks related to issues 1/ and 2/ is available in the security review of = 0-RTT data: htt= ps://github.com/tlswg/tls13-spec/issues/1001 .=C2=A0


After all of that, here's my own position:
<= div>
I strongly support the current TLS1.3 draft progressing = to RFC status. I work at Amazon, where one of our leadership principles is = "Disagree and Commit" (https://www.amazon.jobs/principles); the idea is that it's imp= ortant to make yourself heard, but also to move forward and not be endlessl= y bogged down. I've been vocal about 0-RTT risks, and certainly heard a= nd understood, and those concerns have been reflected in generous changes t= o the draft. I'm happy that it's possible to build a forward-secret= , non-repayable 0-RTT implementation and that's what I'm doing. I w= ish everyone else would too, but that's not consensus; others have a di= fferent weighting for the trade-offs between speed, security and cost and t= hose views are also legitimate.=C2=A0

But my more = important reason for supporting is that overall TLS1.3 is much much better = than TLS1.2, including in regards to forward-secrecy, which is now guarante= ed for all non-0RTT data. I still believe that it will meaningfully increas= e the overall security posture for the internet, and I'm super excited = to get it out and for users to be getting the benefits. TLS has always been= a bit of a mess, it's not as clean as something designed by a single v= oice focused on modern cryptographic best-practices, but 1.3 does a lot of = good cleaning up. Shipping 1.3 doesn't mean things can't be improve= d further, and delay inflicts 1.2 and lower versions on users for even long= er. So let's go!


On Mon, Feb 19, 2018 at 7:58 AM, Kathlee= n Moriarty <kathleen.moriarty.ietf@gmail.com>= wrote:
Dear Yuhong,

As the sponsoring Area Director, my job is to take the draft forward
as was determined by working group consensus.=C2=A0 Like Stephen, I'm a= lso
not particularly happy about the choice to leave in 0-RTT, but I have
to support it as a WG decision.=C2=A0 Whatever the version number in the ServerHello decision is from the WG, I will support that decision.
The ServerHello decision doesn't really fall into the, "arms race&= quot; as
you put it.=C2=A0 More on that in another thread.

Best regards,
Kathleen

On Thu, Feb 15, 2018 at 9:04 PM, Yuhong Bao <yuhongbao_386@hotmail.com> wrote:
> I wonder what is IESG's opinion on the TLS arms race with middlebo= xes.
> Yes, I am talking about moving the version number in the ServerHello.<= br> >
> ________________________________________
> From: TLS <tls-bounces@ietf= .org> on behalf of The IESG <iesg-secretary@ietf.org>
> Sent: Thursday, February 15, 2018 1:13:48 PM
> To: IETF-Announce
> Cc: draft-ietf-tls-tl= s13@ietf.org; tls-chairs@ietf.or= g; tls@ietf.org
> Subject: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt> (= The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standa= rd
>
>
> The IESG has received a request from the Transport Layer Security WG (= tls) to
> consider the following document: - 'The Transport Layer Security (= TLS)
> Protocol Version 1.3'
>=C2=A0 =C2=A0<draft-ietf-tls-tls13-24.txt> as Proposed Standard >
> The IESG plans to make a decision in the next few weeks, and solicits = final
> comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 20= 18-03-01. Exceptionally, comments may be
> sent to iesg@ietf.org instead. In= either case, please retain the beginning of
> the Subject line to allow automated sorting.
>
> Abstract
>
>
>=C2=A0 =C2=A0 This document specifies version 1.3 of the Transport Laye= r Security
>=C2=A0 =C2=A0 (TLS) protocol.=C2=A0 TLS allows client/server applicatio= ns to communicate
>=C2=A0 =C2=A0 over the Internet in a way that is designed to prevent ea= vesdropping,
>=C2=A0 =C2=A0 tampering, and message forgery.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/dra= ft-ietf-tls-tls13/
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/= doc/draft-ietf-tls-tls13/ballot/
>
> The following IPR Declarations may be related to this I-D:
>
>=C2=A0 =C2=A0 https://datatracker.ietf.org/ipr/2900/<= /a>
>
>
>
> The document contains these normative downward references.
> See RFC 3967 for additional information:
>=C2=A0 =C2=A0 =C2=A0rfc8017: PKCS #1: RSA Cryptography Specifications V= ersion 2.2 (Informational - IETF stream)
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



--

Best regards,
Kathleen




--
Colm
--f403045ecde02bd3b80565957eaa-- From nobody Mon Feb 19 11:50:08 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AB2126C19; Mon, 19 Feb 2018 11:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 Os-k-6LHymyM; Mon, 19 Feb 2018 11:50:04 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 1E4CB1204DA; Mon, 19 Feb 2018 11:50:04 -0800 (PST) X-AuditID: 1209190e-2bfff70000000dde-34-5a8b2a6a0e12 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id FF.3D.03550.A6A2B8A5; Mon, 19 Feb 2018 14:50:02 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w1JJo1Mg001874; Mon, 19 Feb 2018 14:50:02 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w1JJnvNI014196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Feb 2018 14:49:59 -0500 Date: Mon, 19 Feb 2018 13:49:57 -0600 From: Benjamin Kaduk To: Colm =?iso-8859-1?Q?MacC=E1rthaigh?= Cc: "draft-ietf-tls-tls13@ietf.org" , "ietf@ietf.org" , "tls-chairs@ietf.org" , "tls@ietf.org" Message-ID: <20180219194957.GL54688@kduck.kaduk.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOKsWRmVeSWpSXmKPExsUixCmqrZul1R1lMPO4gcWXpt2MFju7L7Ja PNs4n8VizokbLBafzncxOrB6XF+0m9VjyZKfTAFMUVw2Kak5mWWpRfp2CVwZC1tfMhas0a3o WreBtYHxjnIXIyeHhICJxKbpRxi7GLk4hAQWM0ks/3oIytnIKHFs11dmCOcqk8SLm1/ZQVpY BFQlXm06xQxiswmoSDR0XwazRQRsJM51NjOBNDALnGaUOP/6ABuIIyzQwyjxqHUBWBUv0MJf HzZA7ZjOKHFg/VN2iISgxMmZT1hAbGYBHYmdW+8AdXMA2dISy/9xQITlJZq3zgabwykQKDFh 8z9WEFtUQFlib98h9gmMgrOQTJqFZNIshEmzkExawMiyilE2JbdKNzcxM6c4NVm3ODkxLy+1 SNdYLzezRC81pXQTIzj0Jfl2ME5q8D7EKMDBqMTDu+NWV5QQa2JZcWXuIUZJDiYlUd4Ule4o Ib6k/JTKjMTijPii0pzU4kOMEhzMSiK8OSJAOd6UxMqq1KJ8mJQ0B4uSOK+7iXaUkEB6Yklq dmpqQWoRTFaGg0NJgneNJlCjYFFqempFWmZOCUKaiYMTZDgP0HCwGt7igsTc4sx0iPwpRmOO Gy9etzFz/Nq0t5NZiCUvPy9VSpx3O0ipAEhpRmke3DRQ+pLI3l/zilEc6Dlh3osaQFU8wNQH N+8V0ComoFWrRTpBVpUkIqSkGhhPr5lucYQpIqlS4Rxv1MFjzbkiYQo8/DFWry1j2qSdT54J j/9RemVjFjOnxqNuo5Vsrd9v7BQqq3nadPRapUDvLN9D2cpxOazHDtUJzCnZ+2pR9Vy5qeW7 lzGamXqFm33P/88l+fpy/8a6pVGH/prckfRRP1vk9/xntfj+vrI+H20TiY3HViuxFGckGmox FxUnAgBwIIPrOgMAAA== Archived-At: Subject: Re: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 19:50:07 -0000 Hi Colm, On Mon, Feb 19, 2018 at 11:13:44AM -0800, Colm MacCárthaigh wrote: > Since this IETF-LC/IESG process is a good chance to get a sanity check, I'd > like to boil down what I think are the nits and risks with 0-RTT, and if > others want to weigh in they can. I'll state my own position at the bottom. Thanks for this summary and review; I think it's well-said. > Broadly, I think there are three issues with 0-RTT: > [...] > At the same time though, most vendors have stated that they don't plan to > do that and instead have designed around limited replay time windows, > non-transactional strike registers, and non-forward secure tickets. This is > what I expect to see deployed, and already see with some TLS1.3 deployment > experiments. TLS1.3 could be more restrictive here; limiting the size of I don't disagree. It might be helpful to have a conslidated list of references for the vendor statements, so we can get a more clear picture of where to set our expectations. Though of course I do not insist that you assemble one, and I do not want my comment to be seen as detracting from your review overall. > session tickets to smaller than the size of session state would effectively > forbid any kind of session encoding which would force the issue, but > several vendors are against it because it doesn't align with current > practices and it incurs the cost of server-size caching. For balance, in > the last year I have heard from most vendors that they do plan to implement > some anti-replay mitigation though, beyond the simple time-windowing, which > goes a way to protecting users from throttle limits. > [...] > > But my more important reason for supporting is that overall TLS1.3 is much > much better than TLS1.2, including in regards to forward-secrecy, which is > now guaranteed for all non-0RTT data. I still believe that it will > meaningfully increase the overall security posture for the internet, and > I'm super excited to get it out and for users to be getting the benefits. > TLS has always been a bit of a mess, it's not as clean as something > designed by a single voice focused on modern cryptographic best-practices, > but 1.3 does a lot of good cleaning up. Shipping 1.3 doesn't mean things > can't be improved further, and delay inflicts 1.2 and lower versions on > users for even longer. So let's go! Well said! -Benjamin > > On Mon, Feb 19, 2018 at 7:58 AM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > > Dear Yuhong, > > > > As the sponsoring Area Director, my job is to take the draft forward > > as was determined by working group consensus. Like Stephen, I'm also > > not particularly happy about the choice to leave in 0-RTT, but I have > > to support it as a WG decision. Whatever the version number in the > > ServerHello decision is from the WG, I will support that decision. > > The ServerHello decision doesn't really fall into the, "arms race" as > > you put it. More on that in another thread. > > > > Best regards, > > Kathleen > > > > On Thu, Feb 15, 2018 at 9:04 PM, Yuhong Bao > > wrote: > > > I wonder what is IESG's opinion on the TLS arms race with middleboxes. > > > Yes, I am talking about moving the version number in the ServerHello. > > > > > > ________________________________________ > > > From: TLS on behalf of The IESG < > > iesg-secretary@ietf.org> > > > Sent: Thursday, February 15, 2018 1:13:48 PM > > > To: IETF-Announce > > > Cc: draft-ietf-tls-tls13@ietf.org; tls-chairs@ietf.org; tls@ietf.org > > > Subject: [TLS] Last Call: (The Transport > > Layer Security (TLS) Protocol Version 1.3) to Proposed Standard > > > > > > > > > The IESG has received a request from the Transport Layer Security WG > > (tls) to > > > consider the following document: - 'The Transport Layer Security (TLS) > > > Protocol Version 1.3' > > > as Proposed Standard > > > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final > > > comments on this action. Please send substantive comments to the > > > ietf@ietf.org mailing lists by 2018-03-01. Exceptionally, comments may > > be > > > sent to iesg@ietf.org instead. In either case, please retain the > > beginning of > > > the Subject line to allow automated sorting. > > > > > > Abstract > > > > > > > > > This document specifies version 1.3 of the Transport Layer Security > > > (TLS) protocol. TLS allows client/server applications to communicate > > > over the Internet in a way that is designed to prevent eavesdropping, > > > tampering, and message forgery. > > > > > > > > > > > > > > > The file can be obtained via > > > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ > > > > > > IESG discussion can be tracked via > > > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ballot/ > > > > > > The following IPR Declarations may be related to this I-D: > > > > > > https://datatracker.ietf.org/ipr/2900/ > > > > > > > > > > > > The document contains these normative downward references. > > > See RFC 3967 for additional information: > > > rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2 > > (Informational - IETF stream) > > > > > > > > > > > > _______________________________________________ > > > TLS mailing list > > > TLS@ietf.org > > > https://www.ietf.org/mailman/listinfo/tls > > > > > > _______________________________________________ > > > TLS mailing list > > > TLS@ietf.org > > > https://www.ietf.org/mailman/listinfo/tls > > > > > > > > -- > > > > Best regards, > > Kathleen > > > > > > > -- > Colm From nobody Mon Feb 19 12:01:19 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F02A120724; Mon, 19 Feb 2018 12:01:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151907047808.18617.1048302597180379365@ietfa.amsl.com> Date: Mon, 19 Feb 2018 12:01:18 -0800 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-sni-encryption-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 20:01:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : SNI Encryption in TLS Through Tunneling Authors : Christian Huitema Eric Rescorla Filename : draft-ietf-tls-sni-encryption-01.txt Pages : 22 Date : 2018-02-19 Abstract: This draft describes the general problem of encryption of the Server Name Identification (SNI) parameter. The proposed solutions hide a Hidden Service behind a Fronting Service, only disclosing the SNI of the Fronting Service to external observers. The draft starts by listing known attacks against SNI encryption, discusses the current "co-tenancy fronting" solution, and then presents two potential TLS layer solutions that might mitigate these attacks. The first solution is based on TLS in TLS "quasi tunneling", and the second solution is based on "combined tickets". These solutions only require minimal extensions to the TLS protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-01 https://datatracker.ietf.org/doc/html/draft-ietf-tls-sni-encryption-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-sni-encryption-01 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 Feb 19 12:08:13 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C99120724 for ; Mon, 19 Feb 2018 12:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 fbDN-Dl7VgHG for ; Mon, 19 Feb 2018 12:08:09 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 743441200B9 for ; Mon, 19 Feb 2018 12:08:02 -0800 (PST) Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx16.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1enrim-00034d-5Z for tls@ietf.org; Mon, 19 Feb 2018 21:07:34 +0100 Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1enrih-0002wH-Cv for tls@ietf.org; Mon, 19 Feb 2018 15:07:31 -0500 Received: (qmail 32401 invoked from network); 19 Feb 2018 20:07:12 -0000 Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.56.42.184]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 19 Feb 2018 20:07:12 -0000 References: <151907047824.18617.12401651429483540579.idtracker@ietfa.amsl.com> To: "tls@ietf.org" From: Christian Huitema X-Forwarded-Message-Id: <151907047824.18617.12401651429483540579.idtracker@ietfa.amsl.com> Message-ID: Date: Mon, 19 Feb 2018 12:07:08 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <151907047824.18617.12401651429483540579.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------31822C63211B967E36163092" Content-Language: en-US X-Originating-IP: 168.144.250.190 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: ham X-AntiSpamCloud-Outgoing-Evidence: Combined (0.08) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5jylDVNV0U15wbcIDwe2eH1602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO5IcVwV4jjVcAOtIXxgohGFVMZsRZacTbJPGp/MBC6BxjJlVnovIa5v9pF3N/Q0gD0h5 mNm/WjPqhYqCeBiCKwzwNnO0oYiZjOnC1Xa7kCO2yyXX9TDPPlZ/jtxvfoBfVPvRa7MR4hgRIg8N 1QlY4G4/E7SMkAew92PUfpE24E7riSGt4Ko2sv7hY6P0Yu3OA+AIcPc2JG++Fh0y/kogNkMJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+Uz0sPgnp Ak2KA2vJwMd1uVIcMSgqtcKbU9La+AHiCFDnINtKVoUnVVMer0Qph9Fbpl8rF453rlG/1n4zSXbJ jyhOIYE4lDmb2NVqBXfxmgJRF7qS0dVOqm13ITdqVygNoAqqfLwzSyIm3DACsHeASWj55Nl155o2 Oe/0FuVZZmVzxAG+DjqL5QSEyTpqxgd+hoJiRUJS+7Nru8G8qObMBABriH3x3J15D78KylFpBEPm uAjNqfS+9DfhdG35lF41D/7Rwl5fb+U9Gl2IOh9znrOpesPVKexaScd+AzecZkTQ+XNr4QUyZNz0 uLvRKYxZQqF/LoUsSniF4plClx3amd6NjTPBYKXxsKTCOMI9bb8ERpFEqF2lExBUp1VMiBudCD+g btQwKEiK+sEGzrnReDF9mE6flINXEXJL2r3PrBjLoydbuOy1i9SfmYgxBbq3mdySlZou9qHIGOZD EEo7O+Pd3ebmKuucUVzXcVqfEwQXQ+sESjyASrM/THMyWUoiolU4x0KD113J1SYnBP2uKg== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: [TLS] Fwd: New Version Notification for draft-ietf-tls-sni-encryption-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 20:08:11 -0000 This is a multi-part message in MIME format. --------------31822C63211B967E36163092 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit The main change in the new version of this draft is the addition of "multi-protocol" requirements. Namely, hiding the SNI should also work for protocols like DTLS or QUIC. Then, it would be nice if we could also hide the ALPN, but that's somewhat less critical. After all, we could run every application over h2... -- Christian Huitema -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-tls-sni-encryption-01.txt Date: Mon, 19 Feb 2018 12:01:18 -0800 From: internet-drafts@ietf.org To: Christian Huitema , Eric Rescorla A new version of I-D, draft-ietf-tls-sni-encryption-01.txt has been successfully submitted by Christian Huitema and posted to the IETF repository. Name: draft-ietf-tls-sni-encryption Revision: 01 Title: SNI Encryption in TLS Through Tunneling Document date: 2018-02-18 Group: tls Pages: 22 URL: https://www.ietf.org/internet-drafts/draft-ietf-tls-sni-encryption-01.txt Status: https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/ Htmlized: https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-tls-sni-encryption-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-sni-encryption-01 Abstract: This draft describes the general problem of encryption of the Server Name Identification (SNI) parameter. The proposed solutions hide a Hidden Service behind a Fronting Service, only disclosing the SNI of the Fronting Service to external observers. The draft starts by listing known attacks against SNI encryption, discusses the current "co-tenancy fronting" solution, and then presents two potential TLS layer solutions that might mitigate these attacks. The first solution is based on TLS in TLS "quasi tunneling", and the second solution is based on "combined tickets". These solutions only require minimal extensions to the TLS protocol. 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. The IETF Secretariat --------------31822C63211B967E36163092 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

The main change in the new version of this draft is the addition of "multi-protocol" requirements. Namely, hiding the SNI should also work for protocols like DTLS or QUIC. Then, it would be nice if we could also hide the ALPN, but that's somewhat less critical. After all, we could run every application over h2...

-- Christian Huitema



-------- Forwarded Message --------
Subject: New Version Notification for draft-ietf-tls-sni-encryption-01.txt
Date: Mon, 19 Feb 2018 12:01:18 -0800
From: internet-drafts@ietf.org
To: Christian Huitema <huitema@huitema.net>, Eric Rescorla <ekr@rtfm.com> 


A new version of I-D, draft-ietf-tls-sni-encryption-01.txt
has been successfully submitted by Christian Huitema and posted to the
IETF repository.

Name:		draft-ietf-tls-sni-encryption
Revision:	01
Title:		SNI Encryption in TLS Through Tunneling
Document date:	2018-02-18
Group:		tls
Pages:		22
URL:            https://www.ietf.org/internet-drafts/draft-ietf-tls-sni-encryption-01.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/
Htmlized:       https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-tls-sni-encryption-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-sni-encryption-01

Abstract:
   This draft describes the general problem of encryption of the Server
   Name Identification (SNI) parameter.  The proposed solutions hide a
   Hidden Service behind a Fronting Service, only disclosing the SNI of
   the Fronting Service to external observers.  The draft starts by
   listing known attacks against SNI encryption, discusses the current
   "co-tenancy fronting" solution, and then presents two potential TLS
   layer solutions that might mitigate these attacks.
   The first solution is based on TLS in TLS "quasi tunneling", and the
   second solution is based on "combined tickets".  These solutions only
   require minimal extensions to the TLS protocol.

                                                                                  


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.

The IETF Secretariat
--------------31822C63211B967E36163092-- From nobody Mon Feb 19 12:32:25 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4FB1205D3; Mon, 19 Feb 2018 12:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 lO9MgDFuOQ-X; Mon, 19 Feb 2018 12:32:21 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7C8C1200B9; Mon, 19 Feb 2018 12:32:21 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id 17so2579134pfw.11; Mon, 19 Feb 2018 12:32:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Ny09NFf8KpOBog/u/Ae4r8927O+Ruf8xjde755gc4+w=; b=g0y1MwINxbyxC3x7RYaehSf3SwXzX9M46gkMBiX7IdGBmTyThxzpew0/Q4upUpU+zq +HDUwJtPwzfHqhYCnAAgo7n7ZjVeMwwa30k95KC1YCPyjMyDEhSWrOqfxjh+fUkeeaO2 dj9Tm3VdUm/eABwZPEH8eXNHaHplBLejfNkzfA+suHu0kqT6TU5TllCxDyPsU08oCS9n 2CsZ8OJpo3r79MzHo7Rcv8dj/zh1Zg0YJ1NwaKcuNLcVxcrCIZ2UscKT/dTSQ84aaY4J 67xSnG9VtHN4tgt2ioZ8Yhzef6GJ17SUWtOaBUVoEyrYNGXTKi7aPe6O8k0yxE6qGSjP VgSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Ny09NFf8KpOBog/u/Ae4r8927O+Ruf8xjde755gc4+w=; b=Pns1YBDHrr0MSOp4193erKsG/gZbqau/o91gRkECtfjTh31U+XTZP+opMjaLd/fZJQ H6puRquMj0bzgTtnWoTuD5bpEczpS3vbI7MKviyCmDuIIVWRdcK2rAp0PwOYvfqAsvrO EjJ5ghzmwByXANZVQmE6CcNZu5VR4/Zvgn9KDe1NCh/8bPiFfpYA3V8Hw6GnZWj04KdN 1ZdrCXQHiO+AuJPakXcEsiZyu9WukghrCFSGX9uYdOe1lEdjb4RXgMDa7UVQi+CIppXk pg1VydjZVK5OnHZGLQi4jim0UMMkyUB/0k1DUz+SKwn6W5GwEDzaUfDxKgo37xwcnD3f tKOg== X-Gm-Message-State: APf1xPC+MXDzjJSjhy5JHItqRHxTFVpheKE2mjk0+HfE/V0nJSfEmrhv SDHHqcQBlbEnqPCf7LMLUDK+DS8OYjNcpOBkkiA= X-Google-Smtp-Source: AH8x2246mvIp4Gn36WwQ6bZ6iZ9w3NwbjwR9I+xUIxjvNCst1dpL/sZ+100HH5OlbRlPBn6PADrcvfQtIpzBeHCvXR8= X-Received: by 10.99.111.130 with SMTP id k124mr4944302pgc.236.1519072341239; Mon, 19 Feb 2018 12:32:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.229.67 with HTTP; Mon, 19 Feb 2018 12:31:40 -0800 (PST) In-Reply-To: <20180219194957.GL54688@kduck.kaduk.org> References: <20180219194957.GL54688@kduck.kaduk.org> From: Kathleen Moriarty Date: Mon, 19 Feb 2018 15:31:40 -0500 Message-ID: To: Benjamin Kaduk Cc: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= , "tls@ietf.org" , "draft-ietf-tls-tls13@ietf.org" , "ietf@ietf.org" , "tls-chairs@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 20:32:24 -0000 On Mon, Feb 19, 2018 at 2:49 PM, Benjamin Kaduk wrote: > Hi Colm, > > On Mon, Feb 19, 2018 at 11:13:44AM -0800, Colm MacC=C3=A1rthaigh wrote: >> Since this IETF-LC/IESG process is a good chance to get a sanity check, = I'd >> like to boil down what I think are the nits and risks with 0-RTT, and if >> others want to weigh in they can. I'll state my own position at the bott= om. > > Thanks for this summary and review; I think it's well-said. Yes, agreed and also thank you for your work on this important topic to improve the security for 0-RTT and implementing the mitigation techniques. > >> Broadly, I think there are three issues with 0-RTT: >> > [...] >> At the same time though, most vendors have stated that they don't plan t= o >> do that and instead have designed around limited replay time windows, >> non-transactional strike registers, and non-forward secure tickets. This= is >> what I expect to see deployed, and already see with some TLS1.3 deployme= nt >> experiments. TLS1.3 could be more restrictive here; limiting the size o= f > > I don't disagree. It might be helpful to have a conslidated list of > references for the vendor statements, so we can get a more clear > picture of where to set our expectations. Though of course I do not > insist that you assemble one, and I do not want my comment to be > seen as detracting from your review overall. And this can and should be done separate from the draft publication process. I'm pretty sure that's what Ben intended as we don't want to hold this up any more. > >> session tickets to smaller than the size of session state would effectiv= ely >> forbid any kind of session encoding which would force the issue, but >> several vendors are against it because it doesn't align with current >> practices and it incurs the cost of server-size caching. For balance, in >> the last year I have heard from most vendors that they do plan to implem= ent >> some anti-replay mitigation though, beyond the simple time-windowing, wh= ich >> goes a way to protecting users from throttle limits. >> > [...] >> >> But my more important reason for supporting is that overall TLS1.3 is mu= ch >> much better than TLS1.2, including in regards to forward-secrecy, which = is >> now guaranteed for all non-0RTT data. I still believe that it will >> meaningfully increase the overall security posture for the internet, and >> I'm super excited to get it out and for users to be getting the benefits= . >> TLS has always been a bit of a mess, it's not as clean as something >> designed by a single voice focused on modern cryptographic best-practice= s, >> but 1.3 does a lot of good cleaning up. Shipping 1.3 doesn't mean things >> can't be improved further, and delay inflicts 1.2 and lower versions on >> users for even longer. So let's go! > > Well said! Agreed. I didn't mean to kick off a new thread on this, I was just using it as an example of where I'll uphold the WG decision and support it fully in IESG discussions in my role as AD. Thanks again for your and others work to improve the 0-RTT situation! Best regards, Kathleen > > -Benjamin > >> >> On Mon, Feb 19, 2018 at 7:58 AM, Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com> wrote: >> >> > Dear Yuhong, >> > >> > As the sponsoring Area Director, my job is to take the draft forward >> > as was determined by working group consensus. Like Stephen, I'm also >> > not particularly happy about the choice to leave in 0-RTT, but I have >> > to support it as a WG decision. Whatever the version number in the >> > ServerHello decision is from the WG, I will support that decision. >> > The ServerHello decision doesn't really fall into the, "arms race" as >> > you put it. More on that in another thread. >> > >> > Best regards, >> > Kathleen >> > >> > On Thu, Feb 15, 2018 at 9:04 PM, Yuhong Bao >> > wrote: >> > > I wonder what is IESG's opinion on the TLS arms race with middleboxe= s. >> > > Yes, I am talking about moving the version number in the ServerHello= . >> > > >> > > ________________________________________ >> > > From: TLS on behalf of The IESG < >> > iesg-secretary@ietf.org> >> > > Sent: Thursday, February 15, 2018 1:13:48 PM >> > > To: IETF-Announce >> > > Cc: draft-ietf-tls-tls13@ietf.org; tls-chairs@ietf.org; tls@ietf.org >> > > Subject: [TLS] Last Call: (The Transpo= rt >> > Layer Security (TLS) Protocol Version 1.3) to Proposed Standard >> > > >> > > >> > > The IESG has received a request from the Transport Layer Security WG >> > (tls) to >> > > consider the following document: - 'The Transport Layer Security (TL= S) >> > > Protocol Version 1.3' >> > > as Proposed Standard >> > > >> > > The IESG plans to make a decision in the next few weeks, and solicit= s >> > final >> > > comments on this action. Please send substantive comments to the >> > > ietf@ietf.org mailing lists by 2018-03-01. Exceptionally, comments m= ay >> > be >> > > sent to iesg@ietf.org instead. In either case, please retain the >> > beginning of >> > > the Subject line to allow automated sorting. >> > > >> > > Abstract >> > > >> > > >> > > This document specifies version 1.3 of the Transport Layer Securi= ty >> > > (TLS) protocol. TLS allows client/server applications to communi= cate >> > > over the Internet in a way that is designed to prevent eavesdropp= ing, >> > > tampering, and message forgery. >> > > >> > > >> > > >> > > >> > > The file can be obtained via >> > > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ >> > > >> > > IESG discussion can be tracked via >> > > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ballot/ >> > > >> > > The following IPR Declarations may be related to this I-D: >> > > >> > > https://datatracker.ietf.org/ipr/2900/ >> > > >> > > >> > > >> > > The document contains these normative downward references. >> > > See RFC 3967 for additional information: >> > > rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2 >> > (Informational - IETF stream) >> > > >> > > >> > > >> > > _______________________________________________ >> > > TLS mailing list >> > > TLS@ietf.org >> > > https://www.ietf.org/mailman/listinfo/tls >> > > >> > > _______________________________________________ >> > > TLS mailing list >> > > TLS@ietf.org >> > > https://www.ietf.org/mailman/listinfo/tls >> > >> > >> > >> > -- >> > >> > Best regards, >> > Kathleen >> > >> > >> >> >> -- >> Colm > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 Best regards, Kathleen From nobody Mon Feb 19 14:05:01 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F4C126BF6; Mon, 19 Feb 2018 14:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 wQfdUx27Wu8k; Mon, 19 Feb 2018 14:04:56 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74E22129502; Mon, 19 Feb 2018 14:04:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A784CBE4C; Mon, 19 Feb 2018 22:04:46 +0000 (GMT) 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 LaYG13xT9mN9; Mon, 19 Feb 2018 22:04:41 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0A80BBDCC; Mon, 19 Feb 2018 22:04:41 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1519077881; bh=ZnibS3jXG5UZgyaRX2YNaBT5XhuVreznIenryZhOgL0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=zSwfRZjLT0qaimR89OqYtYcnMFyYSjmklOPtl8OVmkhYu3ip01XnMQq7TDPRy6DP1 aEDI0rplQBdXeexzxllDy2ulNMD8CgthY/d4qtZe2AS6Lb+KapU1bVkacyVF5b/nHI 8ASjZZaWatH6JZUUZPE85VcxVvaesWLq4tk35VE0= To: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= , Kathleen Moriarty Cc: "draft-ietf-tls-tls13@ietf.org" , "ietf@ietf.org" , "tls-chairs@ietf.org" , "tls@ietf.org" References: From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: <4e408208-f306-acd9-5e4f-f0558f087bed@cs.tcd.ie> Date: Mon, 19 Feb 2018 22:04:40 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jlEL1L6Vn4dUVZi4UPZBCJhNuaKPR7m53" Archived-At: Subject: Re: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 22:05:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jlEL1L6Vn4dUVZi4UPZBCJhNuaKPR7m53 Content-Type: multipart/mixed; boundary="BV6RnOb9BOnVBwAyoYqejF8tafV2hKI6C"; protected-headers="v1" From: Stephen Farrell To: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= , Kathleen Moriarty Cc: "draft-ietf-tls-tls13@ietf.org" , "ietf@ietf.org" , "tls-chairs@ietf.org" , "tls@ietf.org" Message-ID: <4e408208-f306-acd9-5e4f-f0558f087bed@cs.tcd.ie> Subject: Re: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard References: In-Reply-To: --BV6RnOb9BOnVBwAyoYqejF8tafV2hKI6C Content-Type: multipart/mixed; boundary="------------288F847C9A80FD96CCB81FE0" Content-Language: en-GB This is a multi-part message in MIME format. --------------288F847C9A80FD96CCB81FE0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Just on the 0-RTT thing: As a non-fan of 0-RTT I agree with Colm's conclusion. (Nicely argued too btw.) I do believe we'll live to regret 0-RTT when implementation issues and unsuitable application uses emerge over time but neither that nor general dislike of 0-RTT are IMO sufficient reasons to hold TLS 1.3 at this point, given the benefits of other aspects of TLS 1.3. In addition, the fact of 0-RTT as an (in practice) unavoidable part of TLS 1.3 and the implications of that were previously raised with both the IESG and IAB in a fair amount of detail, (about 1.5-2 years ago maybe but the issues are the same) and IIRC at an IETF plenary as well, so this has been rehearsed before the IETF already, even if not during a formal IETF LC. Cheers, S. On 19/02/18 19:13, Colm MacC=C3=A1rthaigh wrote: > Since this IETF-LC/IESG process is a good chance to get a sanity check,= I'd > like to boil down what I think are the nits and risks with 0-RTT, and i= f > others want to weigh in they can. I'll state my own position at the bot= tom. >=20 > Broadly, I think there are three issues with 0-RTT: >=20 > 1) The TLS 1.3 draft allows for 0-RTT data, including things like > requests and headers, to be replayed by attackers. >=20 > 2) 0-RTT data, again including requests and headers, has no > cryptographic guarantee of forward-secrecy and will likely be protected= by > symmetric session ticket encryption keys (STEK) that can be used quite > broadly with no limits on re-use, rotation, and rely on vendors being a= ble > to share and revoke keys frequently and securely. Basically: If a vendo= rs > STEK is compromised, than an unbounded number of end-user requests and > headers can be decrypted. This obviously defeats the goal of achieving > forward secrecy. >=20 > 3) While no working attack has been found, some cryptographers and > protocol experts believe that the 0-RTT exchange is overly-complex and = a > source of risk. Kenny Paterson made the most prominent statement ( > http://bristolcrypto.blogspot.com/2017/03/pkc-2017-kenny-paterson-accep= ting-bets.html > ), but I've heard it echoed at several IACR events. It is definitely tr= ue > that 0-RTT resumption complicates the TLS state machine and creates unu= sual > conditions such as needing to restart messaging sequences. >=20 > The TLS-WG was chartered with "aiming for one roundtrip for a full > handshake and one or zero roundtrip for repeated handshakes. The aim is= > also to maintain current security features" ( > https://datatracker.ietf.org/wg/tls/charter/). But with these 3 issues= , > there is a clearly a trade-off between security (the S in TLS) and spee= d. >=20 > Issue 3 is matter of judgment; my personal judgement is that we will se= e > implementation bugs due to state machine complexity, but there's no > evidence that the cryptographic and protocol semantics are not robust. >=20 > With regards to issues 1, and 2, the latest TLS draft makes it possible= to > achieve both of these aims. Through the use of single-use session ticke= ts, > it is possible to provide anti-replay and forward-secrecy properties fo= r > 0-RTT data. I'm grateful for the changes that were introduced for this.= >=20 > At the same time though, most vendors have stated that they don't plan = to > do that and instead have designed around limited replay time windows, > non-transactional strike registers, and non-forward secure tickets. Thi= s is > what I expect to see deployed, and already see with some TLS1.3 deploym= ent > experiments. TLS1.3 could be more restrictive here; limiting the size = of > session tickets to smaller than the size of session state would effecti= vely > forbid any kind of session encoding which would force the issue, but > several vendors are against it because it doesn't align with current > practices and it incurs the cost of server-size caching. For balance, i= n > the last year I have heard from most vendors that they do plan to imple= ment > some anti-replay mitigation though, beyond the simple time-windowing, w= hich > goes a way to protecting users from throttle limits. >=20 > I am disappointed by the unfortunate preference for cost-saving over ro= bust > security. Good cryptography usually costs money, or else we'd still be > using RC4. I do think that we will see security and correctness issues = due > to replays interacting with non-idempotent services and throttling > configurations. While it's true that browsers can be made to replay > requests already, there are many web and non-HTTP services that are > certainly not tolerant of replays. Secondly, I think that it is inevita= ble > that vendor security compromises will disclose troves of user requests,= > passwords, credit cards to decryption; but this is perhaps more of a > nation-state-adversary level risk. Some more detail on attacks related = to > issues 1/ and 2/ is available in the security review of 0-RTT data: > https://github.com/tlswg/tls13-spec/issues/1001 . >=20 >=20 > After all of that, here's my own position: >=20 > I strongly support the current TLS1.3 draft progressing to RFC status. = I > work at Amazon, where one of our leadership principles is "Disagree and= > Commit" (https://www.amazon.jobs/principles); the idea is that it's > important to make yourself heard, but also to move forward and not be > endlessly bogged down. I've been vocal about 0-RTT risks, and certainly= > heard and understood, and those concerns have been reflected in generou= s > changes to the draft. I'm happy that it's possible to build a > forward-secret, non-repayable 0-RTT implementation and that's what I'm > doing. I wish everyone else would too, but that's not consensus; others= > have a different weighting for the trade-offs between speed, security a= nd > cost and those views are also legitimate. >=20 > But my more important reason for supporting is that overall TLS1.3 is m= uch > much better than TLS1.2, including in regards to forward-secrecy, which= is > now guaranteed for all non-0RTT data. I still believe that it will > meaningfully increase the overall security posture for the internet, an= d > I'm super excited to get it out and for users to be getting the benefit= s. > TLS has always been a bit of a mess, it's not as clean as something > designed by a single voice focused on modern cryptographic best-practic= es, > but 1.3 does a lot of good cleaning up. Shipping 1.3 doesn't mean thing= s > can't be improved further, and delay inflicts 1.2 and lower versions on= > users for even longer. So let's go! >=20 >=20 > On Mon, Feb 19, 2018 at 7:58 AM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: >=20 >> Dear Yuhong, >> >> As the sponsoring Area Director, my job is to take the draft forward >> as was determined by working group consensus. Like Stephen, I'm also >> not particularly happy about the choice to leave in 0-RTT, but I have >> to support it as a WG decision. Whatever the version number in the >> ServerHello decision is from the WG, I will support that decision. >> The ServerHello decision doesn't really fall into the, "arms race" as >> you put it. More on that in another thread. >> >> Best regards, >> Kathleen >> >> On Thu, Feb 15, 2018 at 9:04 PM, Yuhong Bao >> wrote: >>> I wonder what is IESG's opinion on the TLS arms race with middleboxes= =2E >>> Yes, I am talking about moving the version number in the ServerHello.= >>> >>> ________________________________________ >>> From: TLS on behalf of The IESG < >> iesg-secretary@ietf.org> >>> Sent: Thursday, February 15, 2018 1:13:48 PM >>> To: IETF-Announce >>> Cc: draft-ietf-tls-tls13@ietf.org; tls-chairs@ietf.org; tls@ietf.org >>> Subject: [TLS] Last Call: (The Transpor= t >> Layer Security (TLS) Protocol Version 1.3) to Proposed Standard >>> >>> >>> The IESG has received a request from the Transport Layer Security WG >> (tls) to >>> consider the following document: - 'The Transport Layer Security (TLS= ) >>> Protocol Version 1.3' >>> as Proposed Standard >>> >>> The IESG plans to make a decision in the next few weeks, and solicits= >> final >>> comments on this action. Please send substantive comments to the >>> ietf@ietf.org mailing lists by 2018-03-01. Exceptionally, comments ma= y >> be >>> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of >>> the Subject line to allow automated sorting. >>> >>> Abstract >>> >>> >>> This document specifies version 1.3 of the Transport Layer Securit= y >>> (TLS) protocol. TLS allows client/server applications to communic= ate >>> over the Internet in a way that is designed to prevent eavesdroppi= ng, >>> tampering, and message forgery. >>> >>> >>> >>> >>> The file can be obtained via >>> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ >>> >>> IESG discussion can be tracked via >>> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ballot/ >>> >>> The following IPR Declarations may be related to this I-D: >>> >>> https://datatracker.ietf.org/ipr/2900/ >>> >>> >>> >>> The document contains these normative downward references. >>> See RFC 3967 for additional information: >>> rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2 >> (Informational - IETF stream) >>> >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >> >> >> >> -- >> >> Best regards, >> Kathleen >> >> >=20 >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --=20 PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-) --------------288F847C9A80FD96CCB81FE0 Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------288F847C9A80FD96CCB81FE0-- --BV6RnOb9BOnVBwAyoYqejF8tafV2hKI6C-- --jlEL1L6Vn4dUVZi4UPZBCJhNuaKPR7m53 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJai0n4AAoJEFqy+vF7FyvqRFkQAM5IvDa8GxBz/28883Skg9Gc 1BzAzOMv7/zBjDyYuwvr8RpIzfBE5w99mGW7wRxlbtGZ/JZMrOP0hAWBhR0EFQEv CmxN64QysqrOCS1tNKuEVPhbwyaop73wZIDn1vZMiF4Vno4WgN5YMW5jjZTA6L69 HiRFUynZHMM3H5VytbvVA0KErdrLf/Edb5TUHa+MUa46VKiMLXc/z/KHD4l2/N4g JY0mqUpr0Z74d70JyBe0JgILqfZAttYbYrdb7d0NwVHUcEGf+uAyq+CiprJPpTBv fUjS5wRUuHWvgr9/zZXACM6+/pdPiY/y6fgdfFGjmDIt5J5TqwwyilTGzzZ5ufF2 Cqvs3fEKy74n/ZHFbAEKSG/OdJf5h5AeiJD+fTttOcgrINc8U701n33t0CQQS8YU ovKefLd8CDx64xT/SePpN9oVchKhYbeuIhb8ET9RS7hSQC9Zf+ymuMI8P49ro2I3 LrkhywLb99qolm59mM+SbS9xzeLxhXkm1SeuFi5SkNb67dgt6l6WjJUX5T7yxAPs y3gwE4dJoNEq21dAWKkzc0eSw4dE7d2EaSCFzO1Sjl39VwL4FKOJtKFJsVAhwJo5 dLsGXvU+Qx955LXkySL51Yura7MACjma2G8P1pGxKbwj+FU3QVCrOxoowAZ7598P PRPNJLVw3ZeeEbO0Q6uh =2dXb -----END PGP SIGNATURE----- --jlEL1L6Vn4dUVZi4UPZBCJhNuaKPR7m53-- From nobody Mon Feb 19 14:58:40 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B832126CC4; Mon, 19 Feb 2018 14:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Nayh7asyDy01; Mon, 19 Feb 2018 14:58:36 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECCF9126BFD; Mon, 19 Feb 2018 14:58:35 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id d26so14200480qtk.10; Mon, 19 Feb 2018 14:58:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Sjix5KW/TOoi5gV2yzMod1yr5o+I4bxUyjab9o7igDU=; b=DiyLXcTO0/FcfiJt4TEqIUSsN/NJCDBZMtj3YeD7GYdNSjx2kOaVBysW6QYN24GGKk nIkFUqjs/zrYrGakDRgxX8dldX1p49NEkBh1oPLF8ty7tDrGz0FFHP7ZKjQNjl9IH0U/ e/ez+4x9L3Rxi+qb1XeUII9Xu9b8br0KpQvpP18ULRDMqinNfVZRi7zlQCsickAevDHW PHdN6/uUdLZ0YQXFCig5VEzPrj/OY6Ll6WvYOrpvAfrLT7ZcL6JOP68kYiOZztBqtNBe ITkXIPvx693TAPutX4v4qvMuvtbEKa5sWqlTKt0bCQcp4/+f1YYxJzLv2kr29zpq7YAw 5cYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Sjix5KW/TOoi5gV2yzMod1yr5o+I4bxUyjab9o7igDU=; b=G/imT0tyK0fZW8En8NlFcRaxJxJJOSlI5qMDakyYu2RiJin6ofEQmdq3IyFt+MU0TZ pIhMDo4i7GFpYiT0FFeypfbvoxrWIMRC/G1+2DiyffHhnDOnVlzEHIfLrpPWEMzLo/LK UsVEOKmRewQ2VozB8ieCH29u1xpQt2PTH21YpAcYKndgraeMGa5GvoUH5q/1Ijw58QnE qF/18ZeIQgICOOPgyOiu8kuaS+Y3JIxWkgby3DC9kLHe9cJ30ITF9OE3E5dNWlB7JxCB 9JM+GJ2eajoUmqYqMRBGSFMwK7P1lMSwoKiD1hctbhs8Oa1pqKIRk4m7U/TdRJDoaCSj MQmQ== X-Gm-Message-State: APf1xPBx1EJec6idCS/ZW8hR2noZREqkpMQCFnbDg+pBY1/0NX4/2h1k IC4UqbJA43va3A3hkdBWSOSnVst5 X-Google-Smtp-Source: AH8x224DYht0XgKBmkLvDsjeDAbTaSMUkzo886JwSCfKyuPB2SoOB/X8WIieYSKBpTK9xjsNWjdbFw== X-Received: by 10.200.50.251 with SMTP id a56mr27137198qtb.13.1519081114675; Mon, 19 Feb 2018 14:58:34 -0800 (PST) Received: from [192.168.1.219] (209-6-112-84.s338.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.112.84]) by smtp.gmail.com with ESMTPSA id g8sm16397291qth.73.2018.02.19.14.58.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Feb 2018 14:58:33 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (15D60) In-Reply-To: <4e408208-f306-acd9-5e4f-f0558f087bed@cs.tcd.ie> Date: Mon, 19 Feb 2018 17:58:32 -0500 Cc: =?utf-8?Q?Colm_MacC=C3=A1rthaigh?= , "draft-ietf-tls-tls13@ietf.org" , "ietf@ietf.org" , "tls-chairs@ietf.org" , "tls@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6B37A1DD-89AB-4978-82BA-F912A1F0EC07@gmail.com> References: <4e408208-f306-acd9-5e4f-f0558f087bed@cs.tcd.ie> To: Stephen Farrell Archived-At: Subject: Re: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 22:58:39 -0000 Sent from my mobile device > On Feb 19, 2018, at 5:04 PM, Stephen Farrell w= rote: >=20 >=20 > Just on the 0-RTT thing: >=20 > As a non-fan of 0-RTT I agree with Colm's conclusion. (Nicely > argued too btw.) >=20 > I do believe we'll live to regret 0-RTT when implementation > issues and unsuitable application uses emerge over time but > neither that nor general dislike of 0-RTT are IMO sufficient > reasons to hold TLS 1.3 at this point, given the benefits of > other aspects of TLS 1.3. >=20 +1 on all of the above. > In addition, the fact of 0-RTT as an (in practice) unavoidable > part of TLS 1.3 and the implications of that were previously > raised with both the IESG and IAB in a fair amount of detail, > (about 1.5-2 years ago maybe but the issues are the same) and > IIRC at an IETF plenary as well, so this has been rehearsed > before the IETF already, even if not during a formal IETF LC. Agreed. =20 Thank you, Kathleen=20 >=20 > Cheers, > S. >=20 >> On 19/02/18 19:13, Colm MacC=C3=A1rthaigh wrote: >> Since this IETF-LC/IESG process is a good chance to get a sanity check, I= 'd >> like to boil down what I think are the nits and risks with 0-RTT, and if >> others want to weigh in they can. I'll state my own position at the botto= m. >>=20 >> Broadly, I think there are three issues with 0-RTT: >>=20 >> 1) The TLS 1.3 draft allows for 0-RTT data, including things like >> requests and headers, to be replayed by attackers. >>=20 >> 2) 0-RTT data, again including requests and headers, has no >> cryptographic guarantee of forward-secrecy and will likely be protected b= y >> symmetric session ticket encryption keys (STEK) that can be used quite >> broadly with no limits on re-use, rotation, and rely on vendors being abl= e >> to share and revoke keys frequently and securely. Basically: If a vendors= >> STEK is compromised, than an unbounded number of end-user requests and >> headers can be decrypted. This obviously defeats the goal of achieving >> forward secrecy. >>=20 >> 3) While no working attack has been found, some cryptographers and >> protocol experts believe that the 0-RTT exchange is overly-complex and a >> source of risk. Kenny Paterson made the most prominent statement ( >> http://bristolcrypto.blogspot.com/2017/03/pkc-2017-kenny-paterson-accepti= ng-bets.html >> ), but I've heard it echoed at several IACR events. It is definitely true= >> that 0-RTT resumption complicates the TLS state machine and creates unusu= al >> conditions such as needing to restart messaging sequences. >>=20 >> The TLS-WG was chartered with "aiming for one roundtrip for a full >> handshake and one or zero roundtrip for repeated handshakes. The aim is >> also to maintain current security features" ( >> https://datatracker.ietf.org/wg/tls/charter/). But with these 3 issues, >> there is a clearly a trade-off between security (the S in TLS) and speed.= >>=20 >> Issue 3 is matter of judgment; my personal judgement is that we will see >> implementation bugs due to state machine complexity, but there's no >> evidence that the cryptographic and protocol semantics are not robust. >>=20 >> With regards to issues 1, and 2, the latest TLS draft makes it possible t= o >> achieve both of these aims. Through the use of single-use session tickets= , >> it is possible to provide anti-replay and forward-secrecy properties for >> 0-RTT data. I'm grateful for the changes that were introduced for this. >>=20 >> At the same time though, most vendors have stated that they don't plan to= >> do that and instead have designed around limited replay time windows, >> non-transactional strike registers, and non-forward secure tickets. This i= s >> what I expect to see deployed, and already see with some TLS1.3 deploymen= t >> experiments. TLS1.3 could be more restrictive here; limiting the size of= >> session tickets to smaller than the size of session state would effective= ly >> forbid any kind of session encoding which would force the issue, but >> several vendors are against it because it doesn't align with current >> practices and it incurs the cost of server-size caching. For balance, in >> the last year I have heard from most vendors that they do plan to impleme= nt >> some anti-replay mitigation though, beyond the simple time-windowing, whi= ch >> goes a way to protecting users from throttle limits. >>=20 >> I am disappointed by the unfortunate preference for cost-saving over robu= st >> security. Good cryptography usually costs money, or else we'd still be >> using RC4. I do think that we will see security and correctness issues du= e >> to replays interacting with non-idempotent services and throttling >> configurations. While it's true that browsers can be made to replay >> requests already, there are many web and non-HTTP services that are >> certainly not tolerant of replays. Secondly, I think that it is inevitabl= e >> that vendor security compromises will disclose troves of user requests, >> passwords, credit cards to decryption; but this is perhaps more of a >> nation-state-adversary level risk. Some more detail on attacks related to= >> issues 1/ and 2/ is available in the security review of 0-RTT data: >> https://github.com/tlswg/tls13-spec/issues/1001 . >>=20 >>=20 >> After all of that, here's my own position: >>=20 >> I strongly support the current TLS1.3 draft progressing to RFC status. I >> work at Amazon, where one of our leadership principles is "Disagree and >> Commit" (https://www.amazon.jobs/principles); the idea is that it's >> important to make yourself heard, but also to move forward and not be >> endlessly bogged down. I've been vocal about 0-RTT risks, and certainly >> heard and understood, and those concerns have been reflected in generous >> changes to the draft. I'm happy that it's possible to build a >> forward-secret, non-repayable 0-RTT implementation and that's what I'm >> doing. I wish everyone else would too, but that's not consensus; others >> have a different weighting for the trade-offs between speed, security and= >> cost and those views are also legitimate. >>=20 >> But my more important reason for supporting is that overall TLS1.3 is muc= h >> much better than TLS1.2, including in regards to forward-secrecy, which i= s >> now guaranteed for all non-0RTT data. I still believe that it will >> meaningfully increase the overall security posture for the internet, and >> I'm super excited to get it out and for users to be getting the benefits.= >> TLS has always been a bit of a mess, it's not as clean as something >> designed by a single voice focused on modern cryptographic best-practices= , >> but 1.3 does a lot of good cleaning up. Shipping 1.3 doesn't mean things >> can't be improved further, and delay inflicts 1.2 and lower versions on >> users for even longer. So let's go! >>=20 >>=20 >> On Mon, Feb 19, 2018 at 7:58 AM, Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com> wrote: >>=20 >>> Dear Yuhong, >>>=20 >>> As the sponsoring Area Director, my job is to take the draft forward >>> as was determined by working group consensus. Like Stephen, I'm also >>> not particularly happy about the choice to leave in 0-RTT, but I have >>> to support it as a WG decision. Whatever the version number in the >>> ServerHello decision is from the WG, I will support that decision. >>> The ServerHello decision doesn't really fall into the, "arms race" as >>> you put it. More on that in another thread. >>>=20 >>> Best regards, >>> Kathleen >>>=20 >>> On Thu, Feb 15, 2018 at 9:04 PM, Yuhong Bao >>> wrote: >>>> I wonder what is IESG's opinion on the TLS arms race with middleboxes. >>>> Yes, I am talking about moving the version number in the ServerHello. >>>>=20 >>>> ________________________________________ >>>> From: TLS on behalf of The IESG < >>> iesg-secretary@ietf.org> >>>> Sent: Thursday, February 15, 2018 1:13:48 PM >>>> To: IETF-Announce >>>> Cc: draft-ietf-tls-tls13@ietf.org; tls-chairs@ietf.org; tls@ietf.org >>>> Subject: [TLS] Last Call: (The Transport >>> Layer Security (TLS) Protocol Version 1.3) to Proposed Standard >>>>=20 >>>>=20 >>>> The IESG has received a request from the Transport Layer Security WG >>> (tls) to >>>> consider the following document: - 'The Transport Layer Security (TLS) >>>> Protocol Version 1.3' >>>> as Proposed Standard >>>>=20 >>>> The IESG plans to make a decision in the next few weeks, and solicits >>> final >>>> comments on this action. Please send substantive comments to the >>>> ietf@ietf.org mailing lists by 2018-03-01. Exceptionally, comments may >>> be >>>> sent to iesg@ietf.org instead. In either case, please retain the >>> beginning of >>>> the Subject line to allow automated sorting. >>>>=20 >>>> Abstract >>>>=20 >>>>=20 >>>> This document specifies version 1.3 of the Transport Layer Security >>>> (TLS) protocol. TLS allows client/server applications to communicate= >>>> over the Internet in a way that is designed to prevent eavesdropping,= >>>> tampering, and message forgery. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> The file can be obtained via >>>> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ >>>>=20 >>>> IESG discussion can be tracked via >>>> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ballot/ >>>>=20 >>>> The following IPR Declarations may be related to this I-D: >>>>=20 >>>> https://datatracker.ietf.org/ipr/2900/ >>>>=20 >>>>=20 >>>>=20 >>>> The document contains these normative downward references. >>>> See RFC 3967 for additional information: >>>> rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2 >>> (Informational - IETF stream) >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>>=20 >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>=20 >>>=20 >>>=20 >>> -- >>>=20 >>> Best regards, >>> Kathleen >>>=20 >>>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 >=20 > --=20 > PGP key change time for me. > New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. > NewWithOld sigs in keyservers. > Sorry if that mucks something up;-) > <0x7B172BEA.asc> From nobody Mon Feb 19 17:48:11 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF31512D777; Mon, 19 Feb 2018 17:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 tNF1tzOOd7jI; Mon, 19 Feb 2018 17:48:00 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 084E712D72F; Mon, 19 Feb 2018 17:47:59 -0800 (PST) X-AuditID: 1209190f-fedff70000001288-f5-5a8b7e4d6276 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id F1.2E.04744.D4E7B8A5; Mon, 19 Feb 2018 20:47:57 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w1K1lu6h012473; Mon, 19 Feb 2018 20:47:56 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w1K1lq3m016437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Feb 2018 20:47:54 -0500 Date: Mon, 19 Feb 2018 19:47:52 -0600 From: Benjamin Kaduk To: Kathleen Moriarty Cc: Colm =?iso-8859-1?Q?MacC=E1rthaigh?= , "tls@ietf.org" , "draft-ietf-tls-tls13@ietf.org" , "ietf@ietf.org" , "tls-chairs@ietf.org" Message-ID: <20180220014751.GN54688@kduck.kaduk.org> References: <20180219194957.GL54688@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKKsWRmVeSWpSXmKPExsUixCmqretb1x1lsPOZicWXpt2MFju7L7Ja PNs4n8WiYWe+xZwTN1gsPp3vYnRg87i+aDerx85Zd9k9liz5yRTAHMVlk5Kak1mWWqRvl8CV 0X1nAUvBMtaKtSfkGxh7WboYOTkkBEwkNm3sBLK5OIQEFjNJtD/vYINwNjJKbPi5kBXCucok 8WfBb6YuRg4OFgFVieZNqSDdbAIqEg3dl5lBbBEBC4k1zd/AmpkF+pgkmtoWM4M4wgI9jBKP WheAVfEC7bvf1scMMbWTSaL5yxd2iISgxMmZT8COYhbQkrjx7yXYNmYBaYnl/zhATE6BQIlL s2JAKkQFlCX29h1in8AoMAtJ8ywkzbMQmhcwMq9ilE3JrdLNTczMKU5N1i1OTszLSy3SNdHL zSzRS00p3cQIDmtJ/h2Mcxq8DzEKcDAq8fDuuNUVJcSaWFZcmXuIUZKDSUmUN0WlO0qILyk/ pTIjsTgjvqg0J7X4EKMEB7OSCG+OCFCONyWxsiq1KB8mJc3BoiTO626iHSUkkJ5YkpqdmlqQ WgSTleHgUJLgFaoFahQsSk1PrUjLzClBSDNxcIIM5wEazgVSw1tckJhbnJkOkT/FaMzRtvJJ GzPHjRev25iFWPLy81KlxHmlQEoFQEozSvPgpoFSk0T2/ppXjOJAzwnzHq8BquIBpjW4ea+A VjEBrVot0gmyqiQRISXVwFjl09T821lUwrBoif9cvrumjqG+bw/U8Dy9lPFVWfTC9u2165+1 /ri7e/vyiT7qmxVmVDKXOB3jrAx741cgKBq+kPeUAkvy4SUv3/9MVpR2yeW/0P27Jv/Qlv3K nz+tvdT7RLRuH3fa9x+1XtMTVIydfxjOddz5b8/u1OObQ4/2Z5x7tLbJ8I4SS3FGoqEWc1Fx IgCnMqAMKAMAAA== Archived-At: Subject: Re: [TLS] Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 01:48:03 -0000 On Mon, Feb 19, 2018 at 03:31:40PM -0500, Kathleen Moriarty wrote: > On Mon, Feb 19, 2018 at 2:49 PM, Benjamin Kaduk wrote: > > > > I don't disagree. It might be helpful to have a conslidated list of > > references for the vendor statements, so we can get a more clear > > picture of where to set our expectations. Though of course I do not > > insist that you assemble one, and I do not want my comment to be > > seen as detracting from your review overall. > > And this can and should be done separate from the draft publication > process. I'm pretty sure that's what Ben intended as we don't want to > hold this up any more. Right. -Ben From nobody Tue Feb 20 02:44:49 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01FE412D775; Tue, 20 Feb 2018 02:44:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dan Romascanu To: Cc: tls@ietf.org, ietf@ietf.org, draft-ietf-tls-iana-registry-updates.all@ietf.org, dromasca@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151912347695.29703.11473433478669184845@ietfa.amsl.com> Date: Tue, 20 Feb 2018 02:44:37 -0800 Archived-At: Subject: [TLS] Opsdir last call review of draft-ietf-tls-iana-registry-updates-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 10:44:37 -0000 Reviewer: Dan Romascanu Review result: Has Issues I am the assigned OPS-DIR reviewer for this draft. The OPS DIrectorate reviews a great part of the IETF documents being processed by the IESG for the OPS ADs. Please treat with these comments as with all other IETF LC comments. Please wait for direction from your document shepherd or AD before posting a new version of the draft. This document which updates several TLS and DTLS RFCs describes a number of changes to TLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. This is not a protocol or a protocol update document, thus a full OPS-DIR review conforming to RFC 5706 is not needed. From an operational point of view this document is important, as operators may need to refer to IANA registries in their daily work of ensuring functionality and maintaining networks where TLS and DTLS are used. The document is Ready from an OPS-DIR perspective, with a few minor issues. The issues listed below are useful for all categories of users of this document: implementers, operators, end users. None is them is major, but it would be good to be addressed before the document approval. 1. The document adds a Recommended column to many of the TLS registries. The rationale and meaning of a parameter being or not being Recommended are detailed in Section 6. It would be useful from an operator perspective to add to the registries where the Recommended column is added a text similar to the one in Section 6, that explains the rationale and the meaning. Something on the lines of: * 'If a parameter is marked as Recommended, implementations should support it. Adding a recommended parameter to a registry or updating a parameter to recommended status requires standards action. Not all parameters defined in standards track documents need to be marked as recommended. If an item is not marked as Recommended it does not necessarily mean that it is flawed, rather, it indicates that either the item has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases.' 2. Also Section 6. All sections that add Recommended columns need to also modify the References column in order to add a reference to this document. 3. Section 14. IANA shall update the reference for this registry to also refer this document. 4. Section 18. s/ Criteria that SHOULD be applied by the Designated Experts includes determining whether the proposed registration duplicates existing functionality/Criteria that SHOULD be applied by the Designated Experts includes determining whether the proposed registration does not duplicate existing functionality/ From nobody Tue Feb 20 09:06:43 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7436412D945; Tue, 20 Feb 2018 09:06:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-tls-record-limit@ietf.org, Sean Turner , Kathleen.Moriarty.ietf@gmail.com, tls@ietf.org, sean@sn3rd.com, tls-chairs@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151914640147.4790.2746568731719624721.idtracker@ietfa.amsl.com> Date: Tue, 20 Feb 2018 09:06:41 -0800 Archived-At: Subject: [TLS] Last Call: (Record Size Limit Extension for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 17:06:41 -0000 The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Record Size Limit Extension for Transport Layer Security (TLS)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-03-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract An extension to Transport Layer Security (TLS) is defined that allows endpoints to negotiate the maximum size of protected records that each will send the other. This replaces the maximum fragment length extension defined in RFC 6066. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Feb 20 11:50:52 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5456E12DA51; Tue, 20 Feb 2018 11:50:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stewart Bryant To: Cc: tls@ietf.org, ietf@ietf.org, draft-ietf-tls-iana-registry-updates.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151915624732.3939.12189669437030269709@ietfa.amsl.com> Date: Tue, 20 Feb 2018 11:50:47 -0800 Archived-At: Subject: [TLS] Genart last call review of draft-ietf-tls-iana-registry-updates-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 19:50:47 -0000 Reviewer: Stewart Bryant Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-tls-iana-registry-updates-05 Reviewer: Stewart Bryant Review Date: 2018-02-20 IETF LC End Date: 2018-03-01 IESG Telechat date: 2018-03-08 Summary: A well written document that is difficult to check and easy to make a mistake with. There are a tiny number of editorial matters. The matter of the semantics of Recommended = no may need to further thought and clarification. Major issues: None Minor issues: I think convention is to list the documents being updated in the Abstract, but cannot find any formal guidance. ====== If an item is marked as not recommended it does not necessarily mean SB> Do you mean "marked as not recommended" or "not marked as recommended". ======= SB> I am worried about the semantics of Recommended = no. SB> Presumably there are three states: recommended, not recommended, SB> and silent/don't know/don't care/not yet. Which of these SB> states does Recommended = no represent? Nits/editorial comments: Abstract This document describes a number of changes to (D)TLS IANA registries SB> TLS is not a well known abbreviation and so needs expanding ======== This document instructs IANA to make changes to a number of (D)TLS- SB> TLS needs expanding From nobody Wed Feb 21 03:46:41 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABA4126CF6 for ; Wed, 21 Feb 2018 03:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01] autolearn=ham autolearn_force=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 Sd5rdt-PA_TE for ; Wed, 21 Feb 2018 03:46:39 -0800 (PST) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43BB212426E for ; Wed, 21 Feb 2018 03:46:39 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8232E7C6A0 for ; Wed, 21 Feb 2018 11:46:38 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4220F2026E03 for ; Wed, 21 Feb 2018 11:46:35 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Wed, 21 Feb 2018 12:46:30 +0100 Message-ID: <8306658.5F4S3bOxA1@pintsize.usersys.redhat.com> In-Reply-To: <151880080195.1349.14035524657942875385.idtracker@ietfa.amsl.com> References: <151880080195.1349.14035524657942875385.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4434139.M75dIATD6A"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Wed, 21 Feb 2018 11:46:38 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Wed, 21 Feb 2018 11:46:38 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: [TLS] Future interoperability issues for HRR for new extensions; Was: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 11:46:40 -0000 --nextPart4434139.M75dIATD6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 16 February 2018 18:06:41 CET The IESG wrote: > The IESG has received a request from the Transport Layer Security WG (tls) > to consider the following document: - 'The Transport Layer Security (TLS) > Protocol Version 1.3' > as Proposed Standard Section 4.1.2 currently states that the only changes allowed to the second= =20 ClientHello message (in HelloRetryRequest case) are: - replacing key_share - removing early_data - adding cookie - updating pre_shared_key - adding, removing or changing padding What about extensions undefined now? What if in the future we have another= =20 extension like the PSK extension that needs to be updated for the second=20 ClientHello? Do we accept that the above list is set in stone and will never change (exc= ept=20 for new protocol versions), requiring all future extensions to also require= =20 the same extension payload for first and second ClientHello? =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart4434139.M75dIATD6A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlqNXBYACgkQkqjRuAHS 9fUB9xAAkQUnrEem7sG02ZfsYR8CUSbc1tWOUIkcfv/rFU2X6DOGUnhMEuhs+OjV rrKsWf304NTnYTFLe1x22swGh+PXLV07zEhWQj9yQhGVEVNvzGYJUieRPJ5l2Tp/ 4tDLjZ/t54IiM1rXC5incObL2hu9H+tajTMIFSym7IZk20A4X40YGw6HEBtluG5a oljeq92JfaxHYPZBGzTqOJb8O2FbhpXhD7g+k4KqQSqRKRpSrQ2f0HBNQkh6LGB7 KRwKKdTC9ku5eo8p3bGwQFCBnWrN7wh1wOwPpRvqxE0n21C9rLTc7aQPC4xEZqSo iIgaIRq9exsRPBnZ7087mOPJIEE7y2Dw3Uoc6/QKHeJQTds6Zf8WYxoVNLU/1p3f NrQYTBI8W33dBpc386FRVpPS4fLT6gVCd6+OLFfwi8mihrGdwa2a0FYPNsaEAPjg Rh3zCIjL46J5pWs33iZ2nFnMw5pATLv0OXP1EraYqanMvQfne34FV1NiThknBerH caL+s5MzZT6Izx9l89X1rXtqcgP/ajvQarYCLFLEcFmeQVK427EQPWQeCVUZt03B 9KmPMLuiJFgp5nPl0vYq2+vpso56cIClOJ/eiuo0zvKsvGXvBAp3n+qXGlcQDJIH 6XCTqElzcNv4frFBvGzMi0OFyx3BS4pUOee2Md0QSCG5jc2iUxw= =49tY -----END PGP SIGNATURE----- --nextPart4434139.M75dIATD6A-- From nobody Wed Feb 21 05:46:24 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B1A12778D; Wed, 21 Feb 2018 05:46:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke?= To: Cc: tls@ietf.org, ietf@ietf.org, draft-ietf-tls-record-limit.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151922077388.9603.11906306194638042902@ietfa.amsl.com> Date: Wed, 21 Feb 2018 05:46:13 -0800 Archived-At: Subject: [TLS] Opsdir telechat review of draft-ietf-tls-record-limit-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 13:46:14 -0000 Reviewer: Éric Vyncke Review result: Has Nits Reviewer: Eric Vyncke Review results: has nits Hello Martin, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. The document is about an extension to TLS (record_size_limit) allowing endpoints to negotiate the maximum size of protected records. The document also deprecates a previous extension max_fragment_length. The different scenarios (whether endpoints support this option or not) as well as behavior of future versions of TLS are specified. Section 5 also describes the behavior when endpoints use the proposed and the deprecated TLS options. Nits in section 5: "MUST ignore *and* "max_fragment_length"" This is a short document and IMHO all operational issues are well documented and correct. -éric From nobody Wed Feb 21 06:11:03 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71691126D05 for ; Wed, 21 Feb 2018 06:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 LaIITRGF34ub for ; Wed, 21 Feb 2018 06:11:01 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 79A32127077 for ; Wed, 21 Feb 2018 06:11:01 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1LE8I0P011506; Wed, 21 Feb 2018 14:11:01 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=srmZ8FhZQK8rnYHWe+pMNEfC3LbYI/2nzXo888bPcSQ=; b=naGoCKTYixy9evHsK4uep+yjME2b/UoeFVEf4Bij75yg3aiGuO9bYz3psoH5sxT3YeOq TRlDDCVYxE6HFJcvQDZ1FmkA54+AZB0SLacl0sJ5NbYUv9hZZZXWGo6aknOANdGpfHcA 5L8sLSS+avMBgUP4WF2N3p43NiGbQU1vfgV+PuDLe7re/F/mqy7/0ziP3ufD1Ny5wr3p 7Tlsxoll9KvJlJ92YdA5uyFgvE2mFuAeNNAmWrZlhJhHCPayAJ+xPHPp622PLMyvtr1/ 0Kqsqrfsn+I65psgrbv1s6lDM6a4J3L0Xa56Gmb+41C+YEesE4TxGp27vbfgBCMdwZp3 1A== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050095.ppops.net-00190b01. with ESMTP id 2g6ct6w8e3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Feb 2018 14:11:01 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w1LE5YZ6000439; Wed, 21 Feb 2018 09:11:00 -0500 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint4.akamai.com with ESMTP id 2g6gm1jh8x-1; Wed, 21 Feb 2018 09:11:00 -0500 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id B46E3827E7; Wed, 21 Feb 2018 14:10:59 +0000 (GMT) To: Hubert Kario , tls@ietf.org References: <151880080195.1349.14035524657942875385.idtracker@ietfa.amsl.com> <8306658.5F4S3bOxA1@pintsize.usersys.redhat.com> From: Benjamin Kaduk Message-ID: Date: Wed, 21 Feb 2018 08:10:59 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <8306658.5F4S3bOxA1@pintsize.usersys.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-21_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802210171 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-21_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 lowpriorityscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802210172 Archived-At: Subject: Re: [TLS] Future interoperability issues for HRR for new extensions; Was: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 14:11:02 -0000 On 02/21/2018 05:46 AM, Hubert Kario wrote: > On Friday, 16 February 2018 18:06:41 CET The IESG wrote: >> The IESG has received a request from the Transport Layer Security WG (tls) >> to consider the following document: - 'The Transport Layer Security (TLS) >> Protocol Version 1.3' >> as Proposed Standard > Section 4.1.2 currently states that the only changes allowed to the second > ClientHello message (in HelloRetryRequest case) are: > - replacing key_share > - removing early_data > - adding cookie > - updating pre_shared_key > - adding, removing or changing padding > > What about extensions undefined now? What if in the future we have another > extension like the PSK extension that needs to be updated for the second > ClientHello? > > Do we accept that the above list is set in stone and will never change (except > for new protocol versions), requiring all future extensions to also require > the same extension payload for first and second ClientHello? > It seems to me that such a hypothetical future extension could include a signaling value in the HRR to indicate that the server understands the new extension, and the semantics of the extension defined such that when the server understands the extension the client may change its value between ClientHello1 and ClientHello2. This might be slightly inefficient if the extension's information flow is only from client to server, but I think it would be a compatible way to allow an extension value to change after HRR. -Ben From nobody Wed Feb 21 06:13:34 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7C6127077; Wed, 21 Feb 2018 06:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01] autolearn=ham autolearn_force=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 o7knxAzB9hPZ; Wed, 21 Feb 2018 06:13:32 -0800 (PST) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E611C127444; Wed, 21 Feb 2018 06:13:31 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id ECF264015190; Wed, 21 Feb 2018 14:13:30 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.34.247.178]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8D6FE213AEE2; Wed, 21 Feb 2018 14:13:28 +0000 (UTC) From: Hubert Kario To: draft-ietf-tls-tls13@ietf.org Cc: tls@ietf.org Date: Wed, 21 Feb 2018 15:13:27 +0100 Message-ID: <1545738.SpB3f87gQo@pintsize.usersys.redhat.com> In-Reply-To: <151880080195.1349.14035524657942875385.idtracker@ietfa.amsl.com> References: <151880080195.1349.14035524657942875385.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3648164.nWFfT0Uno3"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Wed, 21 Feb 2018 14:13:30 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Wed, 21 Feb 2018 14:13:30 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: [TLS] external PSK identity enumeration Re: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 14:13:33 -0000 --nextPart3648164.nWFfT0Uno3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 16 February 2018 18:06:41 CET The IESG wrote: > The IESG has received a request from the Transport Layer Security WG (tls) > to consider the following document: - 'The Transport Layer Security (TLS) > Protocol Version 1.3' > as Proposed Standard The current draft states that if the server recognises an identity but is=20 unable to verify corresponding binder, it "MUST abort the handshake" at the same time, they "SHOULD select as single PSK and validate solely the= =20 binder that corresponds to that PSK" (Page 60, draft-ietf-tls-tls13-24). That allows for trivial enumeration of externally established identities - = the=20 attacker just needs to send to the server a list of identity guesses, with= =20 random data as binders, if the server recognises any identity it will abort= =20 connection, if it doesn't, it will continue to a non-PSK handshake. Behaviour like this is generally considered a vulnerability: https://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2003-0190 https://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2006-5229 I was wondering if the document shouldn't recommend ignoring any and all=20 identities for which binders do not verify to prevent this kind of attack. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart3648164.nWFfT0Uno3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlqNfocACgkQkqjRuAHS 9fWU9w/+O/l3JBIU3xnFp5vsBahy7dL3eHW07KKZslxqG2urg7In6QW7k/NBrDYZ JHYT6uoCi/jApuCtRHRr/g2bqwPzjOJ3Z8a0iQv4NpL6sX00PT+fQZaYDEe+QZN4 RVv52YPZTdFN8+awyh0vhAmXtFu8IN+S0qjM7bh9YKvIUrcko0u48Q49LyKYEd8N oRf9cI0c/MdALaxFxk8IVusPwfcZwJDZI9Cg4LOvv4NVkzz1aURVV1+rrewwYbPO OnBS/bHJ8XxjwdpjOtrMYQpsy82+RLgzUDAkI1RT5hke8vPPai4vi/yZUbFplvqS 7ZWqds+6LbBuKgjTf6aOuYz3SrI33riyMmyxTdVf+6I25pK8MjGer+ZSobspAQc4 oYXHyfHRbGOjizKo3/9qrmJQq/MbuTtfqOQEKz2pU8cOASKlqCdb4MLNmy1gkBGh Ga+3uTRPNHsMMbUVk82BULpvMyO/IEKoNcfp2I3Z6fjDaRIOFPwuMwsZjO43jlK9 6Vb1qNw9ydO6Is8+xTnepJ93b2MKPbMBzB2V13hCBpxNRrLyX3o0pFxG3ElQX94s GXNzYhb7q44am5D81V+lXLI/iv+TqV/60UEjnExx/F6opiVcfurYbrTMWzUKqNrw FGyx6dYMdrg/yQtYeF0fkdta3v3S3Y2oClLu7eo5Rd3cjhMQrqo= =/w53 -----END PGP SIGNATURE----- --nextPart3648164.nWFfT0Uno3-- From nobody Wed Feb 21 06:21:10 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 758E21275AB for ; Wed, 21 Feb 2018 06:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 fpMle5LoJP9c for ; Wed, 21 Feb 2018 06:21:06 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E451241F3 for ; Wed, 21 Feb 2018 06:21:06 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id a9so2053823qtj.8 for ; Wed, 21 Feb 2018 06:21:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+zFUKLmFtSbzC0d6bq/bY2MIenE5pD8MKgCwLhnS6UU=; b=hVixwjEOWMn12UXJpYy3j4zYDqvNQeTyutjxtuNVJZEkNaxBVyhsgNUAZRkZsasBB/ u2frE1rKAFllWQGSMDVGYsu8DjcZ7+nJihu1sVXLRGLWkYJgugkHNIS1RRLi6Q/Bz1tb GNqFDO9VkK3IOzeRl7Nu6rr9llqkMurfDoB072ZDQE8V18KzBWfBKvGC2qVvxapPtWug 6mFtnrGD64wkMWsasJlxkNQ7KxjW+3CAC/bjm85Z95mm9glWDk466Hwz5isE6kDllaiH E1nyhaIfJ/s5Azvvfr5CBgKUoYz/DzkD5s2Sr0AYtQ2PNF2ydDMZ2tGHXI4hHtmUdX9z tZrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+zFUKLmFtSbzC0d6bq/bY2MIenE5pD8MKgCwLhnS6UU=; b=X393EcBQmMGNOZyeSRwBRjhUx85Kw50bHVZnVfPdynF3swe9F04NaYHmKvgjH4H17O dC6rPLMoUnRMtNTOmpqOiSmGF8c0TqGEb3pyPbZ3JLNSCZr5uMFtCBdxXrDQYCnFUycv 42CzakvScj92NFFE+LRi/IbBJQlrgxeS6W56Ur/ckIEvq2jClasel0GvxMc9O/F/+a+b wiI8eNXATQIfvHffeFW01iB1odzaDOFS2HX5HIjl14qb+Fh9ErE4GFHBf+gxPrwZCUrX aK8GNHnrw4JfBKr7sQbwA5pjJ6agpPogBn+WjDzCfBau+wjkKJE/1jSFpFVkL32diemw VVaQ== X-Gm-Message-State: APf1xPCVoywQRqBVxJkKmOoEqVQY8odegQTtABe0uVjO4ZeM8RPIjj0X PrbZxscJeullXrgcFf0dpFf0+YUkneli+ySRc/MaMQ== X-Google-Smtp-Source: AH8x226J8QVQpC2q6wrgfb4zqHS6jB4WzToDkMA0VaNoysiQ/jBwo5L4crkANrM7uR0U7G2XZQNxrJTTje5x9oU88dU= X-Received: by 10.237.44.99 with SMTP id f90mr5628778qtd.80.1519222865186; Wed, 21 Feb 2018 06:21:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.176 with HTTP; Wed, 21 Feb 2018 06:20:24 -0800 (PST) In-Reply-To: References: <151880080195.1349.14035524657942875385.idtracker@ietfa.amsl.com> <8306658.5F4S3bOxA1@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Wed, 21 Feb 2018 06:20:24 -0800 Message-ID: To: Benjamin Kaduk Cc: Hubert Kario , "" Content-Type: multipart/alternative; boundary="94eb2c06375a36ecd50565b9a3f8" Archived-At: Subject: Re: [TLS] Future interoperability issues for HRR for new extensions; Was: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 14:21:08 -0000 --94eb2c06375a36ecd50565b9a3f8 Content-Type: text/plain; charset="UTF-8" On Wed, Feb 21, 2018 at 6:10 AM, Benjamin Kaduk wrote: > On 02/21/2018 05:46 AM, Hubert Kario wrote: > > On Friday, 16 February 2018 18:06:41 CET The IESG wrote: > >> The IESG has received a request from the Transport Layer Security WG > (tls) > >> to consider the following document: - 'The Transport Layer Security > (TLS) > >> Protocol Version 1.3' > >> as Proposed Standard > > Section 4.1.2 currently states that the only changes allowed to the > second > > ClientHello message (in HelloRetryRequest case) are: > > - replacing key_share > > - removing early_data > > - adding cookie > > - updating pre_shared_key > > - adding, removing or changing padding > > > > What about extensions undefined now? What if in the future we have > another > > extension like the PSK extension that needs to be updated for the second > > ClientHello? > > > > Do we accept that the above list is set in stone and will never change > (except > > for new protocol versions), requiring all future extensions to also > require > > the same extension payload for first and second ClientHello? > > > > It seems to me that such a hypothetical future extension could include a > signaling value in the HRR to indicate that the server understands the > new extension, and the semantics of the extension defined such that when > the server understands the extension the client may change its value > between ClientHello1 and ClientHello2. > > This might be slightly inefficient if the extension's information flow > is only from client to server, but I think it would be a compatible way > to allow an extension value to change after HRR. > Yes. Also, there's not really any good reason to change an extension that is not mentioned in HRR. -Ekr > -Ben > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c06375a36ecd50565b9a3f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Feb 21, 2018 at 6:10 AM, Benjamin Kaduk <<= a href=3D"mailto:bkaduk@akamai.com" target=3D"_blank">bkaduk@akamai.com= > wrote:
On 02= /21/2018 05:46 AM, Hubert Kario wrote:
> On Friday, 16 February 2018 18:06:41 CET The IESG wrote:
>> The IESG has received a request from the Transport Layer Security = WG (tls)
>> to consider the following document: - 'The Transport Layer Sec= urity (TLS)
>> Protocol Version 1.3'
>>=C2=A0 =C2=A0<draft-ietf-tls-tls13-24.txt> as Proposed Standa= rd
> Section 4.1.2 currently states that the only changes allowed to the se= cond
> ClientHello message (in HelloRetryRequest case) are:
>=C2=A0 - replacing key_share
>=C2=A0 - removing early_data
>=C2=A0 - adding cookie
>=C2=A0 - updating pre_shared_key
>=C2=A0 - adding, removing or changing padding
>
> What about extensions undefined now? What if in the future we have ano= ther
> extension like the PSK extension that needs to be updated for the seco= nd
> ClientHello?
>
> Do we accept that the above list is set in stone and will never change= (except
> for new protocol versions), requiring all future extensions to also re= quire
> the same extension payload for first and second ClientHello?
>

It seems to me that such a hypothetical future extension could inclu= de a
signaling value in the HRR to indicate that the server understands the
new extension, and the semantics of the extension defined such that when the server understands the extension the client may change its value
between ClientHello1 and ClientHello2.

This might be slightly inefficient if the extension's information flow<= br> is only from client to server, but I think it would be a compatible way
to allow an extension value to change after HRR.

<= /div>
Yes. Also, there's not really any good reason to change an ex= tension that is not
mentioned in HRR.

-E= kr


-Ben

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--94eb2c06375a36ecd50565b9a3f8-- From nobody Wed Feb 21 06:22:43 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1D312D77E for ; Wed, 21 Feb 2018 06:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 IMGNxXkq8DYq for ; Wed, 21 Feb 2018 06:22:39 -0800 (PST) Received: from mail-qt0-x241.google.com (mail-qt0-x241.google.com [IPv6:2607:f8b0:400d:c0d::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78A5312D778 for ; Wed, 21 Feb 2018 06:22:39 -0800 (PST) Received: by mail-qt0-x241.google.com with SMTP id d26so2072309qtj.4 for ; Wed, 21 Feb 2018 06:22:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zumiiiHUY7zPelPg7a+jFM7WAGoxrqQZvoVRO8Wb3Jw=; b=HrdUTao+jdsQwM7kN6bnBDT++TiY2Ln0By/UvfJWZhXGyvtNd3Esn3vO+MtKKJd/1T Dbs6Xctr6l8nttzZq8TcnaxFYuOQv36umJy0CRVgaB8x/217T7pgwkPKbhvc8inIwa/T tzCUxdsrNkGsehwpzVK5nlxRhZ6RVQab7NWTRCVTvPTw8/uEYswsxvCQvI73PdtGy/Yk IzK3p11rHVt2IxNOn12WK3lPOee+3fF63SePwidhuTdb9kA87RIuIG07SLE01toaYcfo onnJYLJStqUXxc4o7e3EtyPwz/KPUQkbWjDGlsAXGpPZNbgRPDz6TtuRQM8IQOcrYocb baLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zumiiiHUY7zPelPg7a+jFM7WAGoxrqQZvoVRO8Wb3Jw=; b=ssUUWH/IttrHsV0W9F1VTRFd1JFZg+pgIFONuvtmWKnlMoVIid/lxsrMdgd0Gw8xdt hnHf6PKOAdqDwDzTjcqHEMcqgND8Uhj11tsyqqhdwrTV76fed5zFqVGl17uyiIauzVSM c2Ni9PE5t4xjUIKKtEyEMynGa4glKdIxDCO7GguMcP4cr0MM3wHqi3jWwyGuNLsAUQxP +z9ZP0oQBK/3i4rLNegNn/artOW0dvCQ6gBn8Zt7+/OimElNf1G54ML4EsV7d1S5kdGV kgjKNfzauFmTyJgIllwaQMscgbVYgF+H7IwREtW+BblYoiL0lhNx8vXdVCa1GV5F/UUi vo0w== X-Gm-Message-State: APf1xPAzhPJfne3ExqRpYv3N8ovzOTI1PdCVHMjfUC22Sr7BJxeFzAT1 nf+fFp/thwXMsqOCsDjORfNcLkUqmHr4vrpeICSaYQ== X-Google-Smtp-Source: AH8x227QY4U9Z2wJpZL3WkMIeBx6d+k0q5aF4oHwmiti4GmKJ8yM/+Z8HgyKsihWfxSRgVCBNrtkRwAcheVSpAUZzh8= X-Received: by 10.200.13.9 with SMTP id q9mr5570741qti.133.1519222958547; Wed, 21 Feb 2018 06:22:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.176 with HTTP; Wed, 21 Feb 2018 06:21:58 -0800 (PST) In-Reply-To: <1545738.SpB3f87gQo@pintsize.usersys.redhat.com> References: <151880080195.1349.14035524657942875385.idtracker@ietfa.amsl.com> <1545738.SpB3f87gQo@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Wed, 21 Feb 2018 06:21:58 -0800 Message-ID: To: Hubert Kario Cc: draft-ietf-tls-tls13@ietf.org, "" Content-Type: multipart/alternative; boundary="089e0822b6a4c77bee0565b9a8db" Archived-At: Subject: Re: [TLS] external PSK identity enumeration Re: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 14:22:42 -0000 --089e0822b6a4c77bee0565b9a8db Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 21, 2018 at 6:13 AM, Hubert Kario wrote: > On Friday, 16 February 2018 18:06:41 CET The IESG wrote: > > The IESG has received a request from the Transport Layer Security WG > (tls) > > to consider the following document: - 'The Transport Layer Security (TL= S) > > Protocol Version 1.3' > > as Proposed Standard > > The current draft states that if the server recognises an identity but is > unable to verify corresponding binder, it "MUST abort the handshake" > Which text are you referring to here? -Ekr at the same time, they "SHOULD select as single PSK and validate solely the > binder that corresponds to that PSK" > (Page 60, draft-ietf-tls-tls13-24). > > That allows for trivial enumeration of externally established identities = - > the > attacker just needs to send to the server a list of identity guesses, wit= h > random data as binders, if the server recognises any identity it will abo= rt > connection, if it doesn't, it will continue to a non-PSK handshake. > > Behaviour like this is generally considered a vulnerability: > https://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2003-0190 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2006-5229 > > I was wondering if the document shouldn't recommend ignoring any and all > identities for which binders do not verify to prevent this kind of attack= . > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --089e0822b6a4c77bee0565b9a8db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Feb 21, 2018 at 6:13 AM, Hubert Kario <hkario@redhat.com&g= t; wrote:
On Friday, 16 February 2= 018 18:06:41 CET The IESG wrote:
> The IESG has received a request from the Transport Layer Security WG (= tls)
> to consider the following document: - 'The Transport Layer Securit= y (TLS)
> Protocol Version 1.3'
>=C2=A0 =C2=A0<draft-ietf-tls-tls13-24.txt> as Proposed Standard
The current draft states that if the server recognises an identity but is unable to verify corresponding binder, it "MUST abort the handshake&qu= ot;

Which text are you referring to her= e?

-Ekr

at the same time, they "SHOULD select as single PSK and validate solel= y the
binder that corresponds to that PSK"
(Page 60, draft-ietf-tls-tls13-24).

That allows for trivial enumeration of externally established identities - = the
attacker just needs to send to the server a list of identity guesses, with<= br> random data as binders, if the server recognises any identity it will abort=
connection, if it doesn't, it will continue to a non-PSK handshake.

Behaviour like this is generally considered a vulnerability:
https://cve.mitre.org/cgi-bin/cve= name.cgi?name=3DCVE-2003-0190
https://cve.mitre.org/cgi-bin/cve= name.cgi?name=3DCVE-2006-5229

I was wondering if the document shouldn't recommend ignoring any and al= l
identities for which binders do not verify to prevent this kind of attack.<= br> --
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech Republic=
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--089e0822b6a4c77bee0565b9a8db-- From nobody Wed Feb 21 06:23:36 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1190126D05; Wed, 21 Feb 2018 06:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01] autolearn=ham autolearn_force=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 9JFyoeLZI8Q0; Wed, 21 Feb 2018 06:23:33 -0800 (PST) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CCD91241F3; Wed, 21 Feb 2018 06:23:33 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B0F7640744C6; Wed, 21 Feb 2018 14:23:32 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTP id 37E7710A970B; Wed, 21 Feb 2018 14:23:32 +0000 (UTC) From: Hubert Kario To: ietf@ietf.org Cc: draft-ietf-tls-tls13@ietf.org, tls@ietf.org Date: Wed, 21 Feb 2018 15:23:31 +0100 Message-ID: <1668935.r1rRzccTBq@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart89371004.WSkUPXqrWn"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Wed, 21 Feb 2018 14:23:32 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Wed, 21 Feb 2018 14:23:32 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: [TLS] external PSK identity enumeration Re: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 14:23:35 -0000 --nextPart89371004.WSkUPXqrWn Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" (fixing missed ietf@ietf.org) On Friday, 16 February 2018 18:06:41 CET The IESG wrote: > The IESG has received a request from the Transport Layer Security WG (tls) > to consider the following document: - 'The Transport Layer Security (TLS) > Protocol Version 1.3' > as Proposed Standard The current draft states that if the server recognises an identity but is=20 unable to verify corresponding binder, it "MUST abort the handshake" at the same time, they "SHOULD select as single PSK and validate solely the= =20 binder that corresponds to that PSK" (Page 60, draft-ietf-tls-tls13-24). That allows for trivial enumeration of externally established identities - = the=20 attacker just needs to send to the server a list of identity guesses, with= =20 random data as binders, if the server recognises any identity it will abort= =20 connection, if it doesn't, it will continue to a non-PSK handshake. Behaviour like this is generally considered a vulnerability: https://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2003-0190 https://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2006-5229 I was wondering if the document shouldn't recommend ignoring any and all=20 identities for which binders do not verify to prevent this kind of attack. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart89371004.WSkUPXqrWn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlqNgOMACgkQkqjRuAHS 9fWpbw/+MHxJogoEtn0XqU3IKnOyWjXhZ1HmrEAYDVx/MpdMtHOtf17gscsFXJFY NSfJRQadpzaztWiUgO4dxTcDeDrEMNu/2DVfkQIEDJ//OcoamtPBBJOO9QOkGHjm gEXTmVqMgYITQO4MQXMODFp7pdv31QaunSbrrY0R5fzp3oaehdLHo+wFrsdgKu73 SV+TkRwqIXGmWT2ePIBUH+GsjXhYZycEIOuKD2q6u77HXUNtMA02M0SetkhId4Gb iqEFQxC4Ds9mXim1HYm62REf35gGlhiSD9oHpjQWItZWM1XVg9LtwW6+GI7sI8io kC93osUOKedhNyYHJN4glmFkCwKBuTamwCv/wcdxo9hy1sjERXD+X4kroNT17QMm eTuPrRhQyyFW2s1UnoYIPyTI1UMStNFUuL58lPddjkWzSTzvhS3PB++2xacHrpUP dk3/vReS03JdnNVNfsVdIqaFGq5DWXAKSC3mThD2cjkQz+EPwMqe/Tbu2VMPUCeL yKhqwpw+0JrXmY+O3UVY7Ly/yB/TsjF12gssWdU9DCIruubRE/7lrbzqsW4lEQQw TXD1jcszTUh89E5pIZS3LAxY+uiRabXqOEpkZIW4CFQRufsgmmkAjP25B9E2gFuz GJxUNoVz0Rbkpc6o7N//adjuecZ/a3XXzcHxomQAiOK44hVr8sk= =NAFE -----END PGP SIGNATURE----- --nextPart89371004.WSkUPXqrWn-- From nobody Wed Feb 21 06:26:48 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1F1126D05; Wed, 21 Feb 2018 06:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01] autolearn=ham autolearn_force=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 rjSOPRFbkoqf; Wed, 21 Feb 2018 06:26:45 -0800 (PST) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2DB81241F3; Wed, 21 Feb 2018 06:26:44 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3623FFB640; Wed, 21 Feb 2018 14:26:44 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTP id 77BFC213AEE2; Wed, 21 Feb 2018 14:26:43 +0000 (UTC) From: Hubert Kario To: Eric Rescorla Cc: draft-ietf-tls-tls13@ietf.org, "" , ietf@ietf.org Date: Wed, 21 Feb 2018 15:26:42 +0100 Message-ID: <21708133.DmTAOkxbDk@pintsize.usersys.redhat.com> In-Reply-To: References: <151880080195.1349.14035524657942875385.idtracker@ietfa.amsl.com> <1545738.SpB3f87gQo@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1850902.Jp56FTomI8"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Wed, 21 Feb 2018 14:26:44 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Wed, 21 Feb 2018 14:26:44 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] external PSK identity enumeration Re: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 14:26:46 -0000 --nextPart1850902.Jp56FTomI8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 21 February 2018 15:21:58 CET Eric Rescorla wrote: > On Wed, Feb 21, 2018 at 6:13 AM, Hubert Kario wrote: > > On Friday, 16 February 2018 18:06:41 CET The IESG wrote: > > > The IESG has received a request from the Transport Layer Security WG > >=20 > > (tls) > >=20 > > > to consider the following document: - 'The Transport Layer Security > > > (TLS) > > > Protocol Version 1.3' > > >=20 > > > as Proposed Standard > >=20 > > The current draft states that if the server recognises an identity but = is > > unable to verify corresponding binder, it "MUST abort the handshake" >=20 > Which text are you referring to here? Section 4.2.11: Prior to accepting PSK key establishment, the server MUST validate the corresponding binder value (see Section 4.2.11.2 below). If this value is not present or does not validate, the server MUST abort the handshake. Servers SHOULD NOT attempt to validate multiple binders; rather they SHOULD select a single PSK and validate solely the binder that corresponds to that PSK. =20 > -Ekr >=20 > at the same time, they "SHOULD select as single PSK and validate solely t= he >=20 > > binder that corresponds to that PSK" > > (Page 60, draft-ietf-tls-tls13-24). > >=20 > > That allows for trivial enumeration of externally established identitie= s - > > the > > attacker just needs to send to the server a list of identity guesses, w= ith > > random data as binders, if the server recognises any identity it will > > abort > > connection, if it doesn't, it will continue to a non-PSK handshake. > >=20 > > Behaviour like this is generally considered a vulnerability: > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2003-0190 > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2006-5229 > >=20 > > I was wondering if the document shouldn't recommend ignoring any and all > > identities for which binders do not verify to prevent this kind of atta= ck. > > -- > > Regards, > > Hubert Kario > > Senior Quality Engineer, QE BaseOS Security team > > Web: www.cz.redhat.com > > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart1850902.Jp56FTomI8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlqNgaIACgkQkqjRuAHS 9fXb1Q/9EuywA3unWKvWuy/7WTT1HYrRP2QspNrulNL0TG7Vqldkw16MKTcb29lW MrbovllQbgL0LafLqrU9+kAIVlmrQNYlBUhsrdPOj/qcqawisu8ANP0HJfLx8gY+ CUrkvIqPKyrOR4o6FRPQWdm1AH4uVJI27wq7DWBHNUp4+w8wk4cXRPBd/l1f0xvi YX44A3T7V7XymtrTUaCbbcIZyUwofkn99GQmt8GpRgWw5d0MowPxvo3NoSnWSZN5 ZaNkb4rDHZgAdRAid0WzIT+Xqzmq/lcrgpCs/0FGRvBsNws/BEou9xwbqcNwSJTx +baBgQe6bt7dnP/KAVsVpD7lO4LTvx6rEFVUo1IHa6RV42tmhurEu1QmBSG6nngM QqBApCZSJpZMDyC6AhktBk1fd7MRnjNvTfuBnB7AJu2I7Yka0t2KZQ2PRPWy5zEF AoVPSwOKs/mrKxLxdj5HeFq8rb4bDTgtbtiTbfST8/hY4I/luCqUJn0Vl6z0wPK9 dXnZXkJm55QfsUBnE9zBbSVdTPpBUY1u1MS5qQ+URIzvHehgh8PI3eVPiXA6rocw LAy16nMJF1xNFkZEwgCmG7jz8jjNbci9Yaxm1Q+pvGJ8T5gPIJ5I+ejISslXUMWo u7p4bXcTHAE+gZEVLaG0FQS9GS1ic9dFJcMTKzAy5hi64U5fAes= =BjXr -----END PGP SIGNATURE----- --nextPart1850902.Jp56FTomI8-- From nobody Wed Feb 21 06:32:24 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C18127599 for ; Wed, 21 Feb 2018 06:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 2T3hLkmMB3RZ for ; Wed, 21 Feb 2018 06:32:17 -0800 (PST) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0EC81275AB for ; Wed, 21 Feb 2018 06:32:14 -0800 (PST) Received: by mail-qk0-x243.google.com with SMTP id d206so2159262qkb.3 for ; Wed, 21 Feb 2018 06:32:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IBH3XBpOAMJUcwvsjzj834VgYZdXPyh1GGmPMhY5+XA=; b=RDXfE3CgQTnSHs4GHlq+A6MdMMh0ucPocqCa66D8W2tsFOQyzRmDpma+mw0oTK8bg2 lDydo1K3JwAah/cDRlgHBD6N4Blx+w2AGQN5SXczPL60bI0Kh/MDNDxQiDQRHEwXQhDN rFTbE1fpVHaRodifWXGpqD/YmS57jfkc0VpzdsZST+u04Do93TlkS7M5OsaTT0taxQXi RXWPZiL3KucIAuLhAy3DVByrnQQfMdiM+ybE+/xngVWIFzL3otAboymTim0OE8wq5UJI bfJE13JeX9R4W4IDRKdq8MS8+OOJlU/vOURXn5LL1JIyespaykbzMQ9YqVQQ682+hC3+ 59WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IBH3XBpOAMJUcwvsjzj834VgYZdXPyh1GGmPMhY5+XA=; b=MsFN4odBOaVBKIJd7rHc1TRFH/Zy3FJ63AXt6pVFFHHcwfJaygctgzlrAVP2MVJyjS qHLNj/EFYGjeqf+aDkdg7jTMEETUQulUd+Vz5/FcCY5RjcM5OYx1poumVNX0ryQun7zi PPrdAIgGkUyjP9zcIyi4t8Eq66lFlftjG6d4JGVzrl7DN6U5NhHKSA166upb9RoSqsVt 85vEzWkYoEILBF6pXNJw3t4VbMukv46cxq9cIYKqwElaL2bUE5YDfOaaHPP7805cJxiu CRJ/A7y/GTf381LSJxHsMiqXo7zARwDmInwvtveB41Bx5S021QPT2XcdOwlozktXF5sF ATxA== X-Gm-Message-State: APf1xPCXh2cydatYHZziiwj16CRvZgjs4E6uEcFDPyODgUnqWTVyuHIL dvZeUDe1nY32io8dOeyXtJ9G1E1FxSVpoJUI9rgvfA== X-Google-Smtp-Source: AG47ELu8fMB0hUidykbcWwS0pspLFf7+1wVHSnyhBx6ACnawM/SrNKaByLcXRfq9pEsduCgOKL96Ef1J5c6nxD2+5m4= X-Received: by 10.55.137.132 with SMTP id l126mr5571388qkd.15.1519223533983; Wed, 21 Feb 2018 06:32:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.176 with HTTP; Wed, 21 Feb 2018 06:31:33 -0800 (PST) In-Reply-To: <21708133.DmTAOkxbDk@pintsize.usersys.redhat.com> References: <151880080195.1349.14035524657942875385.idtracker@ietfa.amsl.com> <1545738.SpB3f87gQo@pintsize.usersys.redhat.com> <21708133.DmTAOkxbDk@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Wed, 21 Feb 2018 06:31:33 -0800 Message-ID: To: Hubert Kario Cc: draft-ietf-tls-tls13@ietf.org, "" , IETF discussion list Content-Type: multipart/alternative; boundary="94eb2c072d761414530565b9cb80" Archived-At: Subject: Re: [TLS] external PSK identity enumeration Re: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 14:32:19 -0000 --94eb2c072d761414530565b9cb80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable i think your general point is sound here, but I'll nitpick the statement that "if the server recognises an identity but is unable to verify corresponding binder". 1. The server only picks one identity so you if you send A, B, and C and yo= u get an abort, you don't know if it recognized one or all. 2. The server can *recognize* the identity but ignore it (say it's a ticket that's too old) With that said, I think it would probably be safe to say you must ignore an identity where the binder doesn't validate, but I'd like to hear from cryptographers on this one. Thanks, -Ekr On Wed, Feb 21, 2018 at 6:26 AM, Hubert Kario wrote: > On Wednesday, 21 February 2018 15:21:58 CET Eric Rescorla wrote: > > On Wed, Feb 21, 2018 at 6:13 AM, Hubert Kario wrote= : > > > On Friday, 16 February 2018 18:06:41 CET The IESG wrote: > > > > The IESG has received a request from the Transport Layer Security W= G > > > > > > (tls) > > > > > > > to consider the following document: - 'The Transport Layer Security > > > > (TLS) > > > > Protocol Version 1.3' > > > > > > > > as Proposed Standard > > > > > > The current draft states that if the server recognises an identity bu= t > is > > > unable to verify corresponding binder, it "MUST abort the handshake" > > > > Which text are you referring to here? > > Section 4.2.11: > > Prior to accepting PSK key establishment, the server MUST validate > the corresponding binder value (see Section 4.2.11.2 below). If this > value is not present or does not validate, the server MUST abort the > handshake. Servers SHOULD NOT attempt to validate multiple binders; > rather they SHOULD select a single PSK and validate solely the binder > that corresponds to that PSK. > > > -Ekr > > > > at the same time, they "SHOULD select as single PSK and validate solely > the > > > > > binder that corresponds to that PSK" > > > (Page 60, draft-ietf-tls-tls13-24). > > > > > > That allows for trivial enumeration of externally established > identities - > > > the > > > attacker just needs to send to the server a list of identity guesses, > with > > > random data as binders, if the server recognises any identity it will > > > abort > > > connection, if it doesn't, it will continue to a non-PSK handshake. > > > > > > Behaviour like this is generally considered a vulnerability: > > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2003-0190 > > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2006-5229 > > > > > > I was wondering if the document shouldn't recommend ignoring any and > all > > > identities for which binders do not verify to prevent this kind of > attack. > > > -- > > > Regards, > > > Hubert Kario > > > Senior Quality Engineer, QE BaseOS Security team > > > Web: www.cz.redhat.com > > > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republi= c > > > _______________________________________________ > > > TLS mailing list > > > TLS@ietf.org > > > https://www.ietf.org/mailman/listinfo/tls > > > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic > --94eb2c072d761414530565b9cb80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
i think your general point is sound here, but I'll nit= pick the statement that=C2=A0
"if the se= rver recognises an identity but is=C2=A0un= able to verify corresponding binder".

= 1. The server only picks one identity so you if you send A, B, and C and yo= u
get an abort, you don't know if it recognized one or all.
2. The server can *recognize* the identity but ignore it (say it&#= 39;s a ticket that's
too old)

With t= hat said, I think it would probably be safe to say you must ignore an ident= ity
where the binder doesn't validate, but I'd like to he= ar from cryptographers on this
one.

Than= ks,
-Ekr


On Wed, Feb 21, 2018 at 6:26 AM, Hubert Kar= io <hkario@redhat.com> wrote:
On Wednesday, 21 February 2018 15:21:58 CET Eric Resco= rla wrote:
> On Wed, Feb 21, 2018 at 6:13 AM, Hubert Kario <hkario@redhat.com> wrote:
> > On Friday, 16 February 2018 18:06:41 CET The IESG wrote:
> > > The IESG has received a request from the Transport Layer Sec= urity WG
> >
> > (tls)
> >
> > > to consider the following document: - 'The Transport Lay= er Security
> > > (TLS)
> > > Protocol Version 1.3'
> > >
> > >=C2=A0 =C2=A0<draft-ietf-tls-tls13-24.txt> as Proposed = Standard
> >
> > The current draft states that if the server recognises an identit= y but is
> > unable to verify corresponding binder, it "MUST abort the ha= ndshake"
>
> Which text are you referring to here?

Section 4.2.11:

=C2=A0 =C2=A0Prior to accepting PSK key establishment, the server MUST vali= date
=C2=A0 =C2=A0the corresponding binder value (see Section 4.2.11.2 below).= =C2=A0 If this
=C2=A0 =C2=A0value is not present or does not validate, the server MUST abo= rt the
=C2=A0 =C2=A0handshake.=C2=A0 Servers SHOULD NOT attempt to validate multip= le binders;
=C2=A0 =C2=A0rather they SHOULD select a single PSK and validate solely the= binder
=C2=A0 =C2=A0that corresponds to that PSK.

> -Ekr
>
> at the same time, they "SHOULD select as single PSK and validate = solely the
>
> > binder that corresponds to that PSK"
> > (Page 60, draft-ietf-tls-tls13-24).
> >
> > That allows for trivial enumeration of externally established ide= ntities -
> > the
> > attacker just needs to send to the server a list of identity gues= ses, with
> > random data as binders, if the server recognises any identity it = will
> > abort
> > connection, if it doesn't, it will continue to a non-PSK hand= shake.
> >
> > Behaviour like this is generally considered a vulnerability:
> > https://cve.mitre.org/cgi-bi= n/cvename.cgi?name=3DCVE-2003-0190
> > https://cve.mitre.org/cgi-bi= n/cvename.cgi?name=3DCVE-2006-5229
> >
> > I was wondering if the document shouldn't recommend ignoring = any and all
> > identities for which binders do not verify to prevent this kind o= f attack.
> > --
> > Regards,
> > Hubert Kario
> > Senior Quality Engineer, QE BaseOS Security team
> > Web: www.cz.redhat.com
> > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czec= h Republic
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls


--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech Republic=

--94eb2c072d761414530565b9cb80-- From nobody Wed Feb 21 07:52:49 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1CF612D7F4; Wed, 21 Feb 2018 07:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 zO3uFpWuhyjl; Wed, 21 Feb 2018 07:52:40 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E776124B17; Wed, 21 Feb 2018 07:52:40 -0800 (PST) Received: by mail-io0-x22b.google.com with SMTP id 30so2612955iog.2; Wed, 21 Feb 2018 07:52:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mM2Yl5HWRdrz1OM25KeQ/+rNRDnB4y4Ip81fQDFC2uk=; b=BQtvX76mkjH5k9XHUjuayDQ547ln2htQmOx/ELtRirStU41bjM8pcKD3dUxOJWOA6Z IZ1EQbxcgzfwMQY5lU9u4tQ0x2N7RC5Ab/FP02HhRurZD3y5E1gurRQayRzWn9vjc7kD BpFmXkKpqscEfpQZQPXpyR+F3soBUzqd8zQufV1zM83WJi3NRxXLnsWh8B+AYB9XWAhX I6TgztLbZ4H22SWbyII7VnX4YxVOFx0Sxr0xrp6+DZegv27BbfJu2U4WOYKXV7OwNiSc potpDppkr+t5jtaya5xSQq9VDlqnZF/vB9y/pr6IZq0rD5ncWlw1CTERj6l+dyk9693B jf6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mM2Yl5HWRdrz1OM25KeQ/+rNRDnB4y4Ip81fQDFC2uk=; b=DCkg92mdKkABcKkTflflzMz/nsWo+1PugPYFW7eTFAIFlRkKia2X/4wdU9k5oMFdTR 5EL4SEE2N0voQvP0QMyHuCrPxkeKCYKDrrbz6lCG8QtyZ8E2VojLSf0CPTQK/ieEOpvn Fp2A03OlMRJr3ryqvCw3vr8eSH7j2wP2q03rhQ/+eyHvNEbt3eS0E1mMF49CZY3Aiyh3 7vlc0ou8a52FOzQ3RWT67v8UC03gDIsehYYcShZW7n0dLI+64VXe2c92kxnkFTl29lsU zjRdYneUbpaMK1Az4zpyPyyCcoNagWgdmhB0srY/AtYVFsHn18a0mxvNRmS1pF4aDhd9 K0Jw== X-Gm-Message-State: APf1xPBy1RIhNMPyqIiFY15Y1PpEfDoW+xNmyIOEcdW9mFmj94DRRD/K sjs3EB9Yy0YrcKzKZusJ77nwtdge6h5RfGnH/BGMX/aC X-Google-Smtp-Source: AG47ELuMI2ggHRlvT7lUgQ5lQ5A89qz1L6yyDoXonr6PKd1Wjk2gzyxXCSK01aKRf6OfL6qG9JHj+cVpKahd686HieU= X-Received: by 10.107.48.209 with SMTP id w200mr4583987iow.128.1519228359103; Wed, 21 Feb 2018 07:52:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.201.198 with HTTP; Wed, 21 Feb 2018 07:52:38 -0800 (PST) In-Reply-To: References: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com> From: Shumon Huque Date: Wed, 21 Feb 2018 10:52:38 -0500 Message-ID: To: Eric Rescorla Cc: The IESG , draft-ietf-tls-dnssec-chain-extension@ietf.org, Joseph Salowey , tls-chairs , TLS WG Content-Type: multipart/alternative; boundary="001a1146325ead8a580565baeaa3" Archived-At: Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 15:52:43 -0000 --001a1146325ead8a580565baeaa3 Content-Type: text/plain; charset="UTF-8" Sorry for my belated follow-up. Was temporarily overwhelmed by the day job .. On Thu, Feb 8, 2018 at 9:49 AM, Eric Rescorla wrote: > On Thu, Feb 8, 2018 at 6:18 AM, Shumon Huque wrote: > > > > IMPORTANT: I'm not sure that this is actually sufficient to allow an > > > independent implementation without referring to the other documents. I > > > mean, I think I pretty clearly can't validate this chain from the > > > above. > > > > We could add an explicit reference here to the DNS protocol document(s) > > and sections within them that define the canonical form of domain > > names (RFC 4034, Section 6 probably is the best reference), or even > > excerpt the relevant text from that document. Would this satisfy your > > concern? > > > > Well, and remove your text about it being possible to implement solely from > this > document. Yes, I agree, we need to remove that. > It's not the algorithm. I don't believe this document is sufficient to > parse the > structure. Okay, got it. For people that have already implemented this, I think there has been an implicit understanding that the format of the chain data is a sequence of concatenated wire format RRs exactly as they appear in a DNS message section (with one injunction against doing DNS name compression). I'll write some text to make this more explicit and describe the format in more detail with references to the appropriate DNS specs. This is also the format that is readily generated and consumed by some DNS libraries and the Intro section of this document has the following assumption: "... (assuming that the data will be prepared and consumed by a DNS-specific library) ..." > > Similarly, although I think this is enough to break apart the > > > RRSETs into RRs, it doesn't tell me how to separate the RRSETs from > > > each other. I think you need to either make this a lot more complete > > > or alternately stop saying it's sufficient. > > > > We can add some text about this. Basically the client would scan the chain > > reading RRs and group adjacent RRs that share the same RR name, type, and > > class into a distinct RRset. > > > > I'd have to review your text to know if it was sufficient. Ok. I'm working on text for this .. > > > > * With PKIX-EE and PKIX-TA modes, the standard PKIX revocation mechanisms > > need to be consulted and honored. > > > > Well, neither of these modes is useful here, as an attacker will simply > ignore the > extension. Just to confirm, I assume the attacker here is an entity attempting to impersonate the TLS server (with presumably valid PKIX credentials). If so, yes it can trivially ignore the extension, but this is the case for any DANE usage mode (not just the PKIX constraining ones). As discussed in Section 8, the protocol as currently specified really only allows opportunistic DANE authentication, unless some mechanism external to TLS is employed to mandate DANE usage. (The protocol could be extended to require TLS servers to also provide a DNSSEC proof that they don't have a signed TLSA record, but that could only be deployed in a TLS application system where all servers supported this extension). > On your last case, "cert validates but DANE does not", I assume > > you mean the cert validates via PKIX but not DANE? I'm not sure this > > is explicitly discussed in any other DANE document but presumably > > if DANE is being used, DANE must validate. > > > > Why would that be so? This only is useful in DANE-EE and DANE-TA modes in > the first place, and so there is a possibilityt aht PKIX is valid. I think Viktor's earlier reply to this thread goes into detail about possible client behaviors here and what we might recommend (which seems reasonable to me). I'll follow-up there. > > 3.1. Protocol, TLS 1.2 > > > You should probably provide some guidance about whether the server > > should still > > > provide the whole X.509 chain to the client. I believe with these > > semantics, > > > the server cannot tell which DANE mode the client wants and therefore > > has to > > > provide the entire chain. > > > > Sure, we can elaborate. > > > > The DANE mode to be used is advertised by the server in its TLSA record(s), > > so the server already knows whether it needs to return the X.509 chain. > > If the TLSA RRset has only DANE-EE, then only the end-entity certificate > > needs to be returned. If DANE-TA, then only the chain from the TA cert to > > the > > EE needs to be returned. If using the PKIX modes, then yes, the entire > > X.509 > > chain has to be sent. > > > > The problem is that the client is the decider about what it wants to > accept, not > the server. My comment was about what DANE mode choices the server is offering to the client. Certainly, the client can decide whether it wants to use DANE or not, and whether it wants to fallback to PKIX. The protocol should probably not be proscriptive here, and allow different TLS applications (or configurations of such applications) to make choices. But maybe there are some general recommendations to be made. One additional comment about PKIX fallback on DANE failure: If a server is using DANE-EE or DANE-TA, it has the ability to send back a much shorter Certificate message - just the EE certificate for the former, and typically a very short X.509 chain for the latter. But this means that for fallback to PKIX, the client would have to start a new handshake omitting the dnssec_chain extension. For efficient fallback within the same handshake, the server would always have to send back the full PKIX X.509 chain. Maybe that's what we need to recommend for servers that support both DANE and traditional PKIX. > > > > The purpose of the MUST NOT sentence here is to prevent clients from > > using the TLS server to lookup arbitrary domain names. > > > > OK. Well, perhaps some better text is needed here. Fair enough. I'll propose some new text to make this clear. > > Servers receiving a "dnssec_chain" extension in the ClientHello, and > > > which are capable of being authenticated via DANE, SHOULD return a > > > serialized authentication chain in the extension block of the > > > Why is this a SHOULD where the corresponding reqt for TLS 1.2 and below > > is a > > > MAY? > > > > They should clearly be consistent. My preference would be "SHOULD" for > > both. > > > > That's a WG decision. Ok. Let me know how you want to handle this question. I'd be happy to send a separate note to the WG list about it. > > > . DNSKEY > > > RRSIG(. DNSKEY) > > > How does this differ from the algorithm that you would use in response > > to the > > > TLSA query? > > > > Sorry, I don't follow your comment here. Differ from what? Can you > > elaborate? > > > > You provided an algorithm for how to construct responses. How is it > different from the > algorithm that the name server would use to respond to a query for the > TLSA record. Well, the algorithm the DNS server (specifically a DNSSEC aware resolver) uses is the DNS iterative resolution algorithm - the TLS server would just treat that as a blackbox (unless it implemented its own resolver). I think the more important question is how the TLS server issues a sequence of queries to the resolver to obtain the data it needs to construct the dnssec chain, and then extracts the corresponding RRsets from the responses to those queries. Section 4 (paragraphs 4 through 6) describe that process. Again, we could go into more detail here, but we were working with the assumption in the intro ( ".. the data will be prepared and consumed by a DNS-specific library.") > > > the draft is adopted by the WG, the authors expect to make an early > > > allocation request as specified in [RFC7120]. > > > Do you want this to be marked RECOMMENDED? > > > > In response to Mirja's earlier comment, I think we are taking out this > > sentence. > > > > You're still registering the code point, so you need to determine if it's > RECOMMENDED or not. Sorry for being dense - this protocol requires a new codepoint. Do we need to say we RECOMMEND that a new code point be registered? Or are you asking that we RECOMMEND that IANA allocates our preferred extension type value (53)? Shumon. --001a1146325ead8a580565baeaa3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorr= y for my belated follow-up. Was temporarily overwhelmed by the
day job ..


On Thu, Feb 8= , 2018 at 9:49 AM, Eric Rescorla <ekr@rt= fm.com> wrote:
> On Thu, Feb 8, 2= 018 at 6:18 AM, Shumon Huque <shuque= @gmail.com> wrote:
>
> > > IMPORTANT: I'm not sure that this is= actually sufficient to allow an
> > = > independent implementation without referring to the other documents. I=
> > > mean, I think I pretty clea= rly can't validate this chain from the
= > > > above.
> >
> > We could add an explicit reference here to t= he DNS protocol document(s)
> > and s= ections within them that define the canonical form of domain
> > names (RFC 4034, Section 6 probably is the best= reference), or even
> > excerpt the = relevant text from that document. Would this satisfy your
> > concern?
> &g= t;
>
>= ; Well, and remove your text about it being possible to implement solely fr= om
> this
> document.

Yes, I agree, we need to remove that.


> It's not the algorithm. I don't believe this document is = sufficient to
> parse the
> structure.


Okay, got = it. For people that have already implemented this, I think
there has been an implicit understanding that the format o= f the chain
data is a sequence of concatena= ted wire format RRs exactly as they appear
= in a DNS message section (with one injunction against doing DNS name
<= div class=3D"gmail_extra">compression). I'll write some text to make th= is more explicit and describe
the format in= more detail with references to the appropriate DNS specs.

This is also the form= at that is readily generated and consumed by some
DNS libraries and the Intro section of this document has the followi= ng
assumption: "... (assuming that the= data will be prepared and consumed
by a DN= S-specific library) ..."


> > Simi= larly, although I think this is enough to break apart the
> > > RRSETs into RRs, it doesn't tell me how= to separate the RRSETs from
> > >= each other. I think you need to either make this a lot more complete
=
> > > or alternately stop saying it'= ;s sufficient.
> >
> > We can add some text about this. Basically the clie= nt would scan the chain
> > reading R= Rs and group adjacent RRs that share the same RR name, type, and
> > class into a distinct RRset.
> >
>
> I'd have to review your text to know if it w= as sufficient.

Ok. I'm working on text for this ..

> >
> > * With PKIX-EE and PKIX-TA modes, the standard PKIX rev= ocation mechanisms
> >=C2=A0 =C2=A0ne= ed to be consulted and honored.
> >
>
> We= ll, neither of these modes is useful here, as an attacker will simply
=
> ignore the
= > extension.

Just to confirm, I assume the attacker here is an entity attempti= ng
to impersonate the TLS server (with pres= umably valid PKIX credentials).
If so, yes = it can trivially ignore the extension, but this is the case
for any DANE usage mode (not just the PKIX constraining on= es).

A= s discussed in Section 8, the protocol as currently specified really
<= div class=3D"gmail_extra">only allows opportunistic DANE authentication, un= less some mechanism
external to TLS is empl= oyed to mandate DANE usage. (The protocol could
be extended to require TLS servers to also provide a DNSSEC proof that=
they don't have a signed TLSA record, = but that could only be deployed
in a TLS ap= plication system where all servers supported this extension).


> On your last case, "cert validates but DANE doe= s not", I assume
> > you mean th= e cert validates via PKIX but not DANE? I'm not sure this
> > is explicitly discussed in any other DANE docu= ment but presumably
> > if DANE is be= ing used, DANE must validate.
> >
>
> Why = would that be so? This only is useful in DANE-EE and DANE-TA modes in
=
> the first place, and so there is a possibil= ityt aht PKIX is valid.

I think Viktor's earlier reply to this thread goes in= to detail about possible=C2=A0
client behav= iors here and what we might recommend (which seems reasonable=C2=A0
to me). I'll follow-up there.


> > 3.1.=C2=A0 Protocol, TLS 1.2
> > > You should probably provide some guidance about= whether the server
> > should still<= /div>
> > > provide the whole X.509 chai= n to the client. I believe with these
> = > semantics,
> > > the server c= annot tell which DANE mode the client wants and therefore
> > has to
> >= > provide the entire chain.
> >
> > Sure, we can elaborate.
> >
> > T= he DANE mode to be used is advertised by the server in its TLSA record(s),<= /div>
> > so the server already knows wheth= er it needs to return the X.509 chain.
>= > If the TLSA RRset has only DANE-EE, then only the end-entity certific= ate
> > needs to be returned. If DANE= -TA, then only the chain from the TA cert to
> > the
> > EE needs to be re= turned. If using the PKIX modes, then yes, the entire
> > X.509
> > chain = has to be sent.
> >
>
> The problem is t= hat the client is the decider about what it wants to
> accept, not
> the server.=

My co= mment was about what DANE mode choices the server is offering to
the client. Certainly, the client can decide whether = it wants to use
DANE or not, and whether it= wants to fallback to PKIX. The protocol
sh= ould probably not be proscriptive here, and allow different TLS
applications (or configurations of such applications) = to make choices.
But maybe there are some g= eneral recommendations to be made.

One additional comment about PKIX fallback on = DANE failure: If a
server is using DANE-EE = or DANE-TA, it has the ability to send back
a much shorter Certificate message - just the EE certificate for the
=
former, and typically a very short X.509 chain f= or the latter. But
this means that for fall= back to PKIX, the client would have to start
a new handshake omitting the dnssec_chain extension. For efficient
<= div class=3D"gmail_extra">fallback within the same handshake, the server wo= uld always have to
send back the full PKIX = X.509 chain. Maybe that's what we need to
recommend for servers that support both DANE and traditional PKIX.
=


<= div class=3D"gmail_extra">> >
> &g= t; The purpose of the MUST NOT sentence here is to prevent clients from
> > using the TLS server to lookup arbit= rary domain names.
> >
>
> OK. Well, perha= ps some better text is needed here.

Fair enough. I'll propose some new text t= o make this clear.


> >=C2=A0 =C2=A0 Se= rvers receiving a "dnssec_chain" extension in the ClientHello, an= d
> > >=C2=A0 =C2=A0 which are cap= able of being authenticated via DANE, SHOULD return a
> > >=C2=A0 =C2=A0 serialized authentication chain in t= he extension block of the
> > > Wh= y is this a SHOULD where the corresponding reqt for TLS 1.2 and below
=
> > is a
&= gt; > > MAY?
> >
> > They should clearly be consistent. My preferenc= e would be "SHOULD" for
> >= both.
> >
>
> That's a WG decision.

Ok. Let= me know how you want to handle this question. I'd be happy to
send a separate note to the WG list about it.
=


<= div class=3D"gmail_extra">> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 . DNSKEY
> > >=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RRSIG(. DNSKEY)
> > > How does this differ from the algorithm tha= t you would use in response
> > to th= e
> > > TLSA query?
> >
> > Sorry= , I don't follow your comment here. Differ from what? Can you
> > elaborate?
> >
>
> You provided an algorithm for how to construct responses. How is = it
> different from the
> algorithm that the=C2=A0 name server would=C2=A0 use = to respond to a query for the
> TLSA rec= ord.

W= ell, the algorithm the DNS server (specifically a DNSSEC aware=C2=A0
<= div class=3D"gmail_extra">resolver) uses is the DNS iterative resolution al= gorithm - the TLS server=C2=A0
would just t= reat that as a blackbox (unless it implemented its own resolver).

I think the mor= e important question is how the TLS server issues a
sequence of queries to the resolver to obtain the data it needs to= construct=C2=A0
the dnssec chain, and then= extracts the corresponding RRsets from the=C2=A0
responses to those queries.

Section 4 (paragraphs 4 through 6) describe th= at process. Again, we could=C2=A0
go into m= ore detail here, but we were working with the assumption in the=C2=A0
=
intro ( ".. the data will be prepared and c= onsumed by a DNS-specific library.")
<= br>

&g= t; > >=C2=A0 =C2=A0 the draft is adopted by the WG, the authors expec= t to make an early
> > >=C2=A0 =C2= =A0 allocation request as specified in [RFC7120].
> > > Do you want this to be marked RECOMMENDED?
> >
> > I= n response to Mirja's earlier comment, I think we are taking out this
> > sentence.
> >
>
> You're still registering the code point, so you need t= o determine if it's
> RECOMMENDED or= not.

= Sorry for being dense - this protocol requires a new codepoint. Do we=C2=A0=
need to say we RECOMMEND that a new code p= oint be registered?

Or are you asking that we RECOMMEND that IANA allocates our p= referred
extension type value (53)?

Shumon.
=

--001a1146325ead8a580565baeaa3-- From nobody Wed Feb 21 07:57:41 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA57124B17; Wed, 21 Feb 2018 07:57:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 fgzhbVw-eENV; Wed, 21 Feb 2018 07:57:32 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0A4A12D7F8; Wed, 21 Feb 2018 07:57:32 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id v6so1491880iog.7; Wed, 21 Feb 2018 07:57:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2NN8EtCbjTVpsXrBBDUcmo3Npo1rhIfP72to1Qtztzw=; b=vcps4FrzmjHXdL2yYRmwhTsvL/yYgNjfU85tLdqAPhZP72sSqi52v7I+p069QNP4DN H+LgXRsJd/XbXBCeFIkKXGCMXTyvaXsNrKcrhen4h0s89oSsZ2y4JRB3VvFrwE/1GRB2 HEsTkfkQyRKjcwe449d4Yt9kA3dN5cZ34CxhJLusPVs3co5DYx9tBqH8BT36IHTopeVd cRlvlS6UFyz9jJfVcJ4/ARrC0v2eYANbDFOmZymjdWtAJBIEW2DdWlUjGfoPRtRVducH lyEtOBSqrV+P4pjigVLlyP/wMFV3BJv/30z6uJuSCTKcTSIhvrb+0GLMN9Wr7usUK/gy UKww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2NN8EtCbjTVpsXrBBDUcmo3Npo1rhIfP72to1Qtztzw=; b=chChhlUmJGF/EuWry5132R4O3R3Ac1Ax3h3++ojaV1RPQPM3y51DcMc58gkYJd4OQH +eTHIcIxoP/CVRmX64tmwtoTg1vTwF2f32AYWYfKYdcjURvbACK1hwz1Z/rn8HteD3dj JO5peSmlAT4W3Jzf2p00H0LFAFwDHJW1PyPLuxGu1KgAEgoanp0INFfhNr+2usik2oWO /ZuVKex8F18aCOo7XKea78L32PmMDgp885L2+947kmU4GCf+e0iBAoqFkWzIAjrKtlv3 K9UCOa7JNqlT1+nxRbIUMUXs1d1kVbgFg/KHL3LSkI1SsOgTYM8S3/6yVliNDCxZ7Fs2 Oo9g== X-Gm-Message-State: APf1xPAKtda2wDFzougbujKY9AsBDSe40lEtydta4g5TJxU9px2gqyh/ v3BCEIfFv0/YlQimS+65a9tpntQaUKCdIJ+X2rY= X-Google-Smtp-Source: AH8x227gD+k1IVjipo4X2frZ5Hq+FNkCeWY0JdFk7Tx4c1MYSAJkMA/RQWELARuCJQHK9+xTuaXOzfeKZg+P8RGw95Q= X-Received: by 10.107.53.231 with SMTP id k100mr5094746ioo.292.1519228652149; Wed, 21 Feb 2018 07:57:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.201.198 with HTTP; Wed, 21 Feb 2018 07:57:31 -0800 (PST) In-Reply-To: References: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com> From: Shumon Huque Date: Wed, 21 Feb 2018 10:57:31 -0500 Message-ID: To: Viktor Dukhovni Cc: Eric Rescorla , TLS WG , draft-ietf-tls-dnssec-chain-extension@ietf.org, The IESG , tls-chairs Content-Type: multipart/alternative; boundary="001a1144a15824df950565bafce0" Archived-At: Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 15:57:34 -0000 --001a1144a15824df950565bafce0 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 8, 2018 at 11:35 AM, Viktor Dukhovni wrote: > > > Summary as I see it: > > * Mandatory DANE: > MUST Refuse absence of TLSA RRs or failure > of PKIX-TA(0) and PKIX-EE(1). Must fail when no TLSA RRs > are cache and the server does not present the extension. > > * "Opportunistic DANE": MAY refuse failed PKIX-TA(0) and PKIX(1) > if caching replies, and SHOULD attempt to refresh cache before > expiration to reduce opportunity for downgrades. Non-caching > clients don't really gain security by refusing valid PKIX on > DANE failure, and MAY choose to continue. > This seems reasonable to me too. Shumon --001a1144a15824df950565bafce0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 8, 2018 at 11:35 AM, Viktor Dukhovni <ietf-dane@dukhovni.org= > wrote:

Summary as I see it:

=C2=A0 * Mandatory DANE:
=C2=A0 MUST Refuse absence of TLSA RRs or failure
=C2=A0 =C2=A0 of PKIX-TA(0) and PKIX-EE(1).=C2=A0 Must fail when no TLSA RR= s
=C2=A0 =C2=A0 are cache and the server does not present the extension.

=C2=A0 * "Opportunistic DANE": MAY refuse failed PKIX-TA(0) and P= KIX(1)
=C2=A0 =C2=A0 if caching replies, and SHOULD attempt to refresh cache befor= e
=C2=A0 =C2=A0 expiration to reduce opportunity for downgrades.=C2=A0 Non-ca= ching
=C2=A0 =C2=A0 clients don't really gain security by refusing valid PKIX= on
=C2=A0 =C2=A0 DANE failure, and MAY choose to continue.

This seems reasonable to me too.

= Shumon

--001a1144a15824df950565bafce0-- From nobody Wed Feb 21 08:00:35 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B553A12E89D; Wed, 21 Feb 2018 08:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ahr2zoYFBGON; Wed, 21 Feb 2018 08:00:27 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2988712E8AC; Wed, 21 Feb 2018 08:00:27 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id m22so2609034iob.12; Wed, 21 Feb 2018 08:00:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Nm5c4pCNhKyB0JvWlvKUpTou/yU4bfvjsag3n6UoEfA=; b=eFsi8lH4O2XGO5WRCzcH3ZKjGujtBbIoqm6B0Nn+NcUFjJCvMfMPACaUb2CBAmh+lB gyU9RTBn/hBdlyQjWtlnWsltKYhHItB/1RxSTWIaszV3LobKWTwTjkUcmMX/jKMhDcA9 WaQGP4pXyqLEnscZceIZaEbvV3eaoxZEf8+ChUIkiACclo/+HcvWsxJoDQGygiPO+5V4 LT7/5YSK52H+HC564I7kDdKrs3nc4gX2Z4c4UkzYQx5j2EjTZi9PCWWRIO/xIhUjZRmL sCkegsHVhqxxkqR/wJCZhzqaYShWD69wnyYR4P8zm+FYYon/aNqKu+258PEdrAYV9QCT SLLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Nm5c4pCNhKyB0JvWlvKUpTou/yU4bfvjsag3n6UoEfA=; b=To/HxMdI4l4W138/wnt3cdoarf/vXt42BN1M74/EKgKA7F6DaZyQbeDwKNpVQ6fRmJ upW86FNwUozcASk8K+uetd9/IhgujlHv93KPtqCOn7I6aut6FOoEThLMx2dgfJR7yTpz 1oFuLk2Z66kW/SaNSBwbsTYAKwHvLpSdjGj0y7ltyCym9t1N3ZEQ+MxhQbLY0yps2vRD 7CKfyVFdO1t+5v09EyY0BGd0Kj6TVMTymy+tZppehtAH/IrEtdko5Mvsa148wShGnHZe RB9tQ5EJ697Jld+EaMgpfswqt7t+qm7E4rpb22Qe5oHDElerTXnFIT5ZHcoGREVUeD3j fUqQ== X-Gm-Message-State: APf1xPA/FT22G1pQtxdFNBMm/OL7UkOEEv6q7mCmuVH88K2HtO/kMG0Y J8BhCAEEv3FN5ChcDTBlUq2izqmXS+QDxXRT+zQ= X-Google-Smtp-Source: AH8x226VtGsi5QRZUXsYgrsoKGJYxShZRtO8MFpuyG28dEj54r2hO2bgbrQnMmdjpo6D3KCu6BMna94Zo5vcW+WAsYA= X-Received: by 10.107.53.231 with SMTP id k100mr5106763ioo.292.1519228826055; Wed, 21 Feb 2018 08:00:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.201.198 with HTTP; Wed, 21 Feb 2018 08:00:25 -0800 (PST) In-Reply-To: References: <151800968634.4877.12510609339415982154.idtracker@ietfa.amsl.com> <4c90bb83-5ba1-8193-df67-38e25f76caf8@nlnetlabs.nl> From: Shumon Huque Date: Wed, 21 Feb 2018 11:00:25 -0500 Message-ID: To: Martin Thomson Cc: Kathleen Moriarty , draft-ietf-tls-dnssec-chain-extension@ietf.org, The IESG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , tls-chairs , TLS WG Content-Type: multipart/alternative; boundary="001a1144a15882838d0565bb06ff" Archived-At: Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-dnssec-chain-extension-06=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 16:00:29 -0000 --001a1144a15882838d0565bb06ff Content-Type: text/plain; charset="UTF-8" On Tue, Feb 13, 2018 at 5:50 PM, Martin Thomson wrote: > On Wed, Feb 14, 2018 at 4:07 AM, Kathleen Moriarty > wrote: > > What's the behavior when the middlebox is a proxy, let's say existing > > a managed network? I presume from from section 3.1 that this > > negotiation doesn't work in that instance unless sites configured for > > this are not subject to the proxy as is often done for financial site > > access from corporate networks. It would be good to know if it does > > work and that is addressed with the text Mirja calls out for her #1 > > question. Having this clarified could be helpful. > > If there is a MitM, then this extension simply isn't negotiated. > That's pretty well understood. I don't see why that requires special > mention. > Yeah, I agree Martin .. this is the same as with any other extension. Shumon. --001a1144a15882838d0565bb06ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 13, 2018 at 5:50 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On Wed, Feb 14, 2018 at 4:07 AM, Kathleen Moriarty
<kathleen.moriarty.i= etf@gmail.com> wrote:
> What's the behavior when the middlebox is a proxy, let's say e= xisting
> a managed network?=C2=A0 I presume from from section 3.1 that this
> negotiation doesn't work in that instance unless sites configured = for
> this are not subject to the proxy as is often done for financial site<= br> > access from corporate networks.=C2=A0 It would be good to know if it d= oes
> work and that is addressed with the text Mirja calls out for her #1 > question.=C2=A0 Having this clarified could be helpful.

If there is a MitM, then this extension simply isn't negotiated.=
That's pretty well understood.=C2=A0 I don't see why that requires = special
mention.

Yeah, I agree Martin .. this i= s the same as with any other extension.

Shumon.

--001a1144a15882838d0565bb06ff-- From nobody Wed Feb 21 08:05:39 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11EC012D7F8; Wed, 21 Feb 2018 08:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 GHSYVcYLwtz6; Wed, 21 Feb 2018 08:05:36 -0800 (PST) Received: from mail-pl0-x229.google.com (mail-pl0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69F18124B17; Wed, 21 Feb 2018 08:05:36 -0800 (PST) Received: by mail-pl0-x229.google.com with SMTP id 31so1136745ple.9; Wed, 21 Feb 2018 08:05:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=J1UtE0VkWATQjygJTI2v0VnNf87xDvYs/FP8YGHvt5w=; b=bk6i+RPFeKLmv4tHBOGoH9QK/mfj2NWJLlhd4ssNO5IoYwq9KkU50Y7E2aZYCbRjKo w8ZT6T6fRglvYnHmb8Q9iEp3EZNQWGRjz3wYm8utUaTRJO9vb73+Q/cHmFhlgsLjxtLI B9mPrWClmmTIxvwNgYmkdECNSDlqJ6qYCqOEpDnpRiPG2rTpko7iwcFSmLyy5UU3Z3lz LaTY0e6RutNOaG/+eRuEpyH80FPgvhcoSYpQ5fHWx4kzfdt3wJ+qoRW/eCdLxRy9j6cF Ohq4uctTOe/pCjei9j1jyPcUwFnz3c1RxJumB2CvrRVPKHWgXJNpPks5ODqPZCKecMQI RDfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=J1UtE0VkWATQjygJTI2v0VnNf87xDvYs/FP8YGHvt5w=; b=o5j5+q5YHWwzedZn/8ed2PXfH6arcUl9/x1UDg8fMnrX3RFbP0dPOyZ1UYh41nkM+j 4LDih1KLem5ZI2xeKlRA6s0V6DluHpc7QX0P9UTI7nFQ5z/tKs6BZ+VYJwicKbPzhqD9 fRfxJI9qR+JmfF98xFn5FUfzv2+6V42feobl8n8MJEqIaL4OIaxkhuvbFig2dK1U2szy OpvlYnzFbva4E/gycFL14+6TnX+kjRHY7sPsk6IhaMp9QImYNgk9gwGqPNkHGpywh99U I2irISRrtpmLNYskRXRZ7Ju4YBjlQQMKSGWJRry3x/prqYODzbZL8Q1DYQeg9cz3eeBx m3uA== X-Gm-Message-State: APf1xPD8Wk6+Q6XHa1Tl1XCio7IU4yDiC03n6Th/drThuNYiqWCpKfo6 M5hgJMjba6sjAsfg4v4XF+VpYsavp3yzjg8u2Po= X-Google-Smtp-Source: AH8x22622HHH0HckDFv2e45QFqIh/ioSu+EIMw7xOOGD0f6EymlOGM8GEPP7NVqxPUcqua7phNZCl9EEl9ZpuoBrfhw= X-Received: by 2002:a17:902:2845:: with SMTP id e63-v6mr3541265plb.438.1519229135990; Wed, 21 Feb 2018 08:05:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.229.67 with HTTP; Wed, 21 Feb 2018 08:04:55 -0800 (PST) In-Reply-To: References: <151800968634.4877.12510609339415982154.idtracker@ietfa.amsl.com> <4c90bb83-5ba1-8193-df67-38e25f76caf8@nlnetlabs.nl> From: Kathleen Moriarty Date: Wed, 21 Feb 2018 11:04:55 -0500 Message-ID: To: Shumon Huque Cc: Martin Thomson , draft-ietf-tls-dnssec-chain-extension@ietf.org, The IESG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , tls-chairs , TLS WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-dnssec-chain-extension-06=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 16:05:38 -0000 On Wed, Feb 21, 2018 at 11:00 AM, Shumon Huque wrote: > On Tue, Feb 13, 2018 at 5:50 PM, Martin Thomson > wrote: >> >> On Wed, Feb 14, 2018 at 4:07 AM, Kathleen Moriarty >> wrote: >> > What's the behavior when the middlebox is a proxy, let's say existing >> > a managed network? I presume from from section 3.1 that this >> > negotiation doesn't work in that instance unless sites configured for >> > this are not subject to the proxy as is often done for financial site >> > access from corporate networks. It would be good to know if it does >> > work and that is addressed with the text Mirja calls out for her #1 >> > question. Having this clarified could be helpful. >> >> If there is a MitM, then this extension simply isn't negotiated. >> That's pretty well understood. I don't see why that requires special >> mention. > > > Yeah, I agree Martin .. this is the same as with any other extension. OK, I think it is clear in the discussion with 1.2, but wasn't sure if it was clear enough elsewhere and figured it was best to ask. > > Shumon. > -- Best regards, Kathleen From nobody Wed Feb 21 08:07:01 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2606012D870; Wed, 21 Feb 2018 08:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 rekCMnLrJqgk; Wed, 21 Feb 2018 08:06:50 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A3F012D7F8; Wed, 21 Feb 2018 08:06:50 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id b34so2648895ioj.6; Wed, 21 Feb 2018 08:06:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hzd5z9oYQ9YZKHT3pfPnFo/DRRgD+yzzvFHTTv5Cyjc=; b=Spo/61T9GvEM3bPr8YRdgNEBa5vlG3VXnrGR0cIjpFMPGO9sANYiovshI5YUp4o9rf AV81K7zp6T3XjSIx8kT/xABsVSfFjsreMln8fkBdkIik8byrHHJ8pfVET9o1ruKBROCk iElmhMNeQf9nt7xG1LJU9Nu4ftgyk/QflFiRfEGLoIS59/QUx+6cVO5LXsQl55ZGFff/ Y5COn2l07X/nkQsPFFVIo/5KZIarb9VgY9kJAYVBGkmXO13MBqj9hqVjRNveRSzDnIyn 6QnFkmxyyPP/Ctp4DcA81K4JPiz49RyB0S17laQuyT1DFqJqmjsWLvzW7kleR5z7vrY0 EAGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hzd5z9oYQ9YZKHT3pfPnFo/DRRgD+yzzvFHTTv5Cyjc=; b=m70EjvDFysarPkTpsvJl6AsvPrdHajLltkid7UD7zNUO0+uYFinrP5+KW1zjxCFgxk h9+TbuLuFXDDgN1MD9ZqxZVjBhZRnd32ZXOXyeSLLkw2ENptO+++MNiF0HkzzEC3tVEy LFLJt6QvfCUxoCyH2KfxoMU1TyDSQf1Y/02mG3HGxiTNNvjVfVdjJVO2MnVjpDfIGGAW Bnhv8vQOm7zem6eDfsnBSac/Q1/NGX+2VEOZvi17JOdKXbPqCke4otGGk/QOzyOb+/G5 +OKwnLQwkf78Qlw2I534AWg6GHuyi4TUo+8x8dnTpk/EpRjwGzGaVJWr/wp40OLKAhIR d7Nw== X-Gm-Message-State: APf1xPB8YC9XKanZLXCkYF9XlqTcq4RACkpLPhfFlANwKenhHpB6rXrm uZaWf7E2I0mRJruaBdGMv6H7y6GStc/Lh8CfLH/4Tg== X-Google-Smtp-Source: AH8x225KW1uPGffiazUQautXaJ6vS/a3m/SDUolr3tNYw/u09QJk7IRcNIzCoADscJP/1GaX184YIO+B094G9zyFHyc= X-Received: by 10.107.29.205 with SMTP id d196mr4937515iod.18.1519229209616; Wed, 21 Feb 2018 08:06:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.201.198 with HTTP; Wed, 21 Feb 2018 08:06:49 -0800 (PST) In-Reply-To: References: <151802776446.4849.12008167318274714913.idtracker@ietfa.amsl.com> From: Shumon Huque Date: Wed, 21 Feb 2018 11:06:49 -0500 Message-ID: To: Alexey Melnikov Cc: The IESG , draft-ietf-tls-dnssec-chain-extension@ietf.org, Joseph Salowey , tls-chairs , TLS WG Content-Type: multipart/alternative; boundary="001a1140a7445f6a860565bb1d3a" Archived-At: Subject: Re: [TLS] Alexey Melnikov's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 16:06:52 -0000 --001a1140a7445f6a860565bb1d3a Content-Type: text/plain; charset="UTF-8" On Wed, Feb 7, 2018 at 9:05 PM, Shumon Huque wrote: > On Wed, Feb 7, 2018 at 1:22 PM, Alexey Melnikov > wrote: > >> Alexey Melnikov has entered the following ballot position for >> draft-ietf-tls-dnssec-chain-extension-06: Discuss >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I think this is a useful document and I will ballot Yes once my small >> issues are resolved: >> >> 1) In 3.4: >> >> The first RRset in the chain MUST contain the TLSA record set being >> presented. However, if the owner name of the TLSA record set is an >> alias (CNAME or DNAME), then it MUST be preceded by the chain of >> alias records needed to resolve it. DNAME chains should omit >> >> SHOULD? What are the implications if this is not followed? >> > > Ok. I guess we need the upper case word here, yes. > > Implication: If the synthesized CNAME records are included in the chain > then the client will have to ignore them (they aren't signed and thus > can't be > validated) - the signed DNAME record is sufficient for the client to > securely > validate the mapping and continue processing. > > It might make things simpler to just make this a MUST. I would guess this > would not raise any objections from the working group. > A quick follow-up on this. I think we just keep this as a SHOULD. I looked at what an existing DNS library implementation does, and it includes the synthesized CNAME. It's easy enough for the client to just ignore it when validating the chain. Shumon. --001a1140a7445f6a860565bb1d3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 7, 2018 at 9:05 PM, Shumon Huque <shuque@gmail.com> w= rote:
On Wed, Feb 7, 2018 at= 1:22 PM, Alexey Melnikov <aamelnikov@fastmail.fm> wrot= e:
Alexey Melniko= v has entered the following ballot position for
draft-ietf-tls-dnssec-chain-extension-06: Discuss

 -----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

I think this is a useful document and I will ballot Yes once my small issue= s are resolved:

1) In 3.4:

=C2=A0 =C2=A0The first RRset in the chain MUST contain the TLSA record set = being
=C2=A0 =C2=A0presented.=C2=A0 However, if the owner name of the TLSA record= set is an
=C2=A0 =C2=A0alias (CNAME or DNAME), then it MUST be preceded by the chain = of
=C2=A0 =C2=A0alias records needed to resolve it.=C2=A0 DNAME chains should = omit

SHOULD? What are the implications if this is not followed?

Ok. I guess we need the upper case word here, ye= s.

Implication: If the synthesized CNAME records a= re included in the chain
then the client will have to ignore them= (they aren't signed and thus can't be=C2=A0
validated) -= the signed DNAME record is sufficient for the client to securely=C2=A0
validate the mapping and continue processing.

It might make things simpler to just make this a MUST. I would guess thi= s
would not raise any objections from the working group.

A quick follow-up on this. = I think we just keep this as a SHOULD. I looked
at what an existi= ng DNS library implementation does, and it includes the
synthesiz= ed CNAME. It's easy enough for the client to just ignore it when
<= div>validating the chain.

Shumon.

--001a1140a7445f6a860565bb1d3a-- From nobody Wed Feb 21 09:05:57 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6CC12D87F; Wed, 21 Feb 2018 09:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 6nZNTl_Ji47r; Wed, 21 Feb 2018 09:05:54 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E933C127876; Wed, 21 Feb 2018 09:05:53 -0800 (PST) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 8F58F7A3309; Wed, 21 Feb 2018 17:05:52 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 21 Feb 2018 12:05:51 -0500 Cc: draft-ietf-tls-dnssec-chain-extension@ietf.org, The IESG , tls-chairs Content-Transfer-Encoding: quoted-printable Message-Id: References: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com> To: TLS WG X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 17:05:56 -0000 > On Feb 21, 2018, at 10:57 AM, Shumon Huque wrote: >=20 > On Thu, Feb 8, 2018 at 11:35 AM, Viktor Dukhovni = wrote: >=20 > Summary as I see it: >=20 > * Mandatory DANE: MUST Refuse absence of TLSA RRs or failure > of PKIX-TA(0) and PKIX-EE(1). Must fail when no TLSA RRs > are cache and the server does not present the extension. Just to clarify "failure of PKIX-TA(0) and PKIX-EE(1)" is intended to consider failure to satisfy the usual PKIX verification requirements for these certificate usages. Naturally, mandatory DANE can also be satisfied via matching DANE-TA(2) or DANE-EE(3) or fail via broken=0D DANE-TA(2) or DANE-EE(3). >=20 > * "Opportunistic DANE": MAY refuse failed PKIX-TA(0) and PKIX(1) > if caching replies, and SHOULD attempt to refresh cache before > expiration to reduce opportunity for downgrades. Non-caching > clients don't really gain security by refusing valid PKIX on > DANE failure, and MAY choose to continue. >=20 > This seems reasonable to me too. Here too, a client MAY choose to fail when the presented certificate chain fails all the associated (cached or freshly obtained) DANE TLSA records whether these are PKIX-TA/EE, DANE-TA/EE or some mixture. The restricted focus on just PKIX-TA/PKIX-EE is not needed. --=20 Viktor. From nobody Wed Feb 21 09:30:57 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2855C127876; Wed, 21 Feb 2018 09:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 LWBpskL1ncSe; Wed, 21 Feb 2018 09:30:54 -0800 (PST) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2424C1273B1; Wed, 21 Feb 2018 09:30:54 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id o13so3067038ito.2; Wed, 21 Feb 2018 09:30:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T668OB4bFgcdNi/AcJXAjfmYkiOfdDHhmydCFqjNIL8=; b=TgWlrfCfXAzinZL7TK+DcB21tdwrGTB+MlhG48SIRgqxgqMhZVVmbt5axJWu1WWwA5 COET5BHB1A1+Sn0/AGDB5QPk4OBh1Gu6LIGouPBxUI4dAqHpKSoMJ3U6gp+i6SVgGrKa uxmMka/AJLudYdxeXaBeIBzi2gWGZ+kgQ0Qln46tHqdeGpOs2ip0zleY2tZ8dPUrOrfG UMrsbI40E64XcnSzpplrl8T0nnUO7TqIcUynt2QKUvFEtFYKL22GmpivJBOnCOT8xm71 OcMhUd6S0SJ0DlFhTTdZRMk1UcCZFRUPnvFF+uqMNi89le0L5C/LNzQSeZA/LdFhOxbs mGvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T668OB4bFgcdNi/AcJXAjfmYkiOfdDHhmydCFqjNIL8=; b=IoR7ERpXu6FFfVcKudx4viyjUr3cp4+gbUW8iojfP1VNVEAtgXKNtW1/0F1QirkGAS C3rGxqhE6rUCN+5QgBc469xRM/VjUJ6bBRSYqLOYZSdj0WVNnsIg1LB+0Zlh4ZWEozSL Q6pRl0tscF+cYWa8Zd/veOweuSQQ+64Y6yy4x8D8oqVYCoK1k5YQd0PQyBv0N+e/inJm 8kpS1Zu84fudfn2cKTGHd0kJ5KiqNhu7AP5MqsowtQtprMq1rSfzzIGaI+IIhja6cDyV +naC72oGm2Ma6dWwV/XdOUno58vgAWZVZj5UO8fHrBCdFBubR64Kgp+6mqi658We930D 5kOg== X-Gm-Message-State: APf1xPDhbdJPhlDT59NAoIImBckyjE0ssLiSL4jMnQ52tfZrneoOrDiU uhcrewAvYqOwdkk7IJfTZZf5PezfWIkUey29wJU= X-Google-Smtp-Source: AH8x227nj7yg/MwEy4eAPIuS0Tg8ii32mBV9B31HuXIylQo6wy4cVE4G13gzF88y70ncyVZQSeP7HQ45jLDxqUmdzKk= X-Received: by 10.36.74.78 with SMTP id k75mr4145525itb.103.1519234253515; Wed, 21 Feb 2018 09:30:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.201.198 with HTTP; Wed, 21 Feb 2018 09:30:52 -0800 (PST) In-Reply-To: References: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com> From: Shumon Huque Date: Wed, 21 Feb 2018 12:30:52 -0500 Message-ID: To: Viktor Dukhovni Cc: TLS WG , draft-ietf-tls-dnssec-chain-extension@ietf.org, The IESG , tls-chairs Content-Type: multipart/alternative; boundary="001a1145e55e0307db0565bc4a5a" Archived-At: Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 17:30:56 -0000 --001a1145e55e0307db0565bc4a5a Content-Type: text/plain; charset="UTF-8" On Wed, Feb 21, 2018 at 12:05 PM, Viktor Dukhovni wrote: > > > > On Feb 21, 2018, at 10:57 AM, Shumon Huque wrote: > > > > On Thu, Feb 8, 2018 at 11:35 AM, Viktor Dukhovni > wrote: > > > > Summary as I see it: > > > > * Mandatory DANE: MUST Refuse absence of TLSA RRs or failure > > of PKIX-TA(0) and PKIX-EE(1). Must fail when no TLSA RRs > > are cache and the server does not present the extension. > > Just to clarify "failure of PKIX-TA(0) and PKIX-EE(1)" is intended to > consider failure to satisfy the usual PKIX verification requirements > for these certificate usages. Naturally, mandatory DANE can also be > satisfied via matching DANE-TA(2) or DANE-EE(3) or fail via broken > > DANE-TA(2) or DANE-EE(3). > Yup, I understood, but thanks for clarifying ... > > > > * "Opportunistic DANE": MAY refuse failed PKIX-TA(0) and PKIX(1) > > if caching replies, and SHOULD attempt to refresh cache before > > expiration to reduce opportunity for downgrades. Non-caching > > clients don't really gain security by refusing valid PKIX on > > DANE failure, and MAY choose to continue. > > > > This seems reasonable to me too. > > Here too, a client MAY choose to fail when the presented certificate > chain fails all the associated (cached or freshly obtained) DANE TLSA > records whether these are PKIX-TA/EE, DANE-TA/EE or some mixture. > The restricted focus on just PKIX-TA/PKIX-EE is not needed. > Yes, no need to restrict such a policy choice to only the PKIX-* modes. Shumon. --001a1145e55e0307db0565bc4a5a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 21, 2018 at 12:05 PM, Viktor Dukhovni <ietf-dane@dukhovni.org= > wrote:
<= br>
> On Feb 21, 2018, at 10:57 AM, Shumon Huque <shuque@gmail.com> wrote:
>
> On Thu, Feb 8, 2018 at 11:35 AM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
>
> Summary as I see it:
>
>=C2=A0 =C2=A0* Mandatory DANE: MUST Refuse absence of TLSA RRs or failu= re
>=C2=A0 =C2=A0 =C2=A0of PKIX-TA(0) and PKIX-EE(1).=C2=A0 Must fail when = no TLSA RRs
>=C2=A0 =C2=A0 =C2=A0are cache and the server does not present the exten= sion.

Just to clarify "failure of PKIX-TA(0) and PKIX-EE(1)" is = intended to
consider failure to satisfy the usual PKIX verification requirements
for these certificate usages. Naturally, mandatory DANE can also be
satisfied via matching DANE-TA(2) or DANE-EE(3) or fail via broken

DANE-TA(2) or DANE-EE(3).

Yup, I unders= tood, but thanks for clarifying ...
=C2=A0
>
>=C2=A0 =C2=A0* "Opportunistic DANE": MAY refuse failed PKIX-T= A(0) and PKIX(1)
>=C2=A0 =C2=A0 =C2=A0if caching replies, and SHOULD attempt to refresh c= ache before
>=C2=A0 =C2=A0 =C2=A0expiration to reduce opportunity for downgrades.=C2= =A0 Non-caching
>=C2=A0 =C2=A0 =C2=A0clients don't really gain security by refusing = valid PKIX on
>=C2=A0 =C2=A0 =C2=A0DANE failure, and MAY choose to continue.
>
> This seems reasonable to me too.

Here too, a client MAY choose to fail when the presented certificate=
chain fails all the associated (cached or freshly obtained) DANE TLSA
records whether these are PKIX-TA/EE, DANE-TA/EE or some mixture.
The restricted focus on just PKIX-TA/PKIX-EE is not needed.

Yes, no need to restrict such a policy choice to only = the PKIX-* modes.

Shumon.

--001a1145e55e0307db0565bc4a5a-- From nobody Wed Feb 21 09:52:25 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977D712D956 for ; Wed, 21 Feb 2018 09:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 o8QtLGEF1VVN for ; Wed, 21 Feb 2018 09:52:20 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0BEA12D947 for ; Wed, 21 Feb 2018 09:52:19 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id d14so2983790qtg.1 for ; Wed, 21 Feb 2018 09:52:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TaRQAAR3RX+kLFProFDNu5TseHuHAd5fId4sQFvlHM4=; b=wTr3KxwcoLsccTIkeBGu1fVz/STEHZYlO2yrO4Em0q6T1t+k/qJqgrQZ2AxUQvvTgg fh8pa/4B6op28QTJkRIg6nzYCxm2NaAfo8tfyujAz/MHwdCJolGvzcaT+r2dNxgaFhuL AiysHz+i3gzQChyK0Hw9miJ0ZuJ4vRsTkZu7NOpXcoTbfYlCArXWhdEARZ0v8Hvvx+r7 8e0NrKCf2M1+QFMjsKBq+YzXDbhAVgXY6HvWYq0VrcdG46Ij6xw4kEcIhWr2EBV1ObsD 7thVDfmNA/oZjC0Fjrt/hEh8UTRBRorXs5udLXdHCv15QUXORojwSaJ9g3HZ+P+a++Xi FPaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TaRQAAR3RX+kLFProFDNu5TseHuHAd5fId4sQFvlHM4=; b=X9IM9wKIxYdEi4QAPhvsZO2T0jlcPoGQmIdKD7So4TzITY0ANyGaj1CkrzP7Ub0Ml5 04GQrUrYAKI8cRYnWq09W9zWdvagaHOLFryv/hGWXDMRIYBjVR0SxGV23aAzO8dGrkUN F4fGCXLziLhJ/QxqdnnIzbtDHSmSC7MEvZqd+RXf0x5H0OnLdsBede4QYiC3sOCgiYty lCVTMqh4m2xfCdonJy4W7M6C60ZOo3UF8eohVaUOlheWJDpVbcjLTA6b4zwHxsBH1LKt AJaXc7cf044/bCoFL+DcdSOHaxdscEVnmk8J94ZOeVHOtLnoWUFdUtsggGb9ztQmPKt1 vn9g== X-Gm-Message-State: APf1xPBntQlETiyxXKKMudsv8XvOWq2cxKBIu+rKXRczFahnNGOLjk81 j7baqcXmTboWpnukrlN7Mzy+odbjhLl37zwNbQT3KA== X-Google-Smtp-Source: AH8x224plm1a7X82rZ+c/DZL2avhqXvCZmvz0+5G5qT2wNNJwHckMY2JUGSXeNKEFT5d7gRvAuxGhX5xEVbOjYTGwwM= X-Received: by 10.237.32.135 with SMTP id 7mr3451193qtb.287.1519235538653; Wed, 21 Feb 2018 09:52:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.176 with HTTP; Wed, 21 Feb 2018 09:51:38 -0800 (PST) In-Reply-To: References: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Wed, 21 Feb 2018 09:51:38 -0800 Message-ID: To: Shumon Huque Cc: The IESG , draft-ietf-tls-dnssec-chain-extension@ietf.org, Joseph Salowey , tls-chairs , TLS WG Content-Type: multipart/alternative; boundary="94eb2c114ed09cafb20565bc969a" Archived-At: Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 17:52:22 -0000 --94eb2c114ed09cafb20565bc969a Content-Type: text/plain; charset="UTF-8" On Wed, Feb 21, 2018 at 7:52 AM, Shumon Huque wrote: > Sorry for my belated follow-up. Was temporarily overwhelmed by the > day job .. > > > On Thu, Feb 8, 2018 at 9:49 AM, Eric Rescorla wrote: > > On Thu, Feb 8, 2018 at 6:18 AM, Shumon Huque wrote: > > > > > > IMPORTANT: I'm not sure that this is actually sufficient to allow an > > > > independent implementation without referring to the other documents. > I > > > > mean, I think I pretty clearly can't validate this chain from the > > > > above. > > > > > > We could add an explicit reference here to the DNS protocol document(s) > > > and sections within them that define the canonical form of domain > > > names (RFC 4034, Section 6 probably is the best reference), or even > > > excerpt the relevant text from that document. Would this satisfy your > > > concern? > > > > > > > Well, and remove your text about it being possible to implement solely > from > > this > > document. > > Yes, I agree, we need to remove that. > > > > It's not the algorithm. I don't believe this document is sufficient to > > parse the > > structure. > > > Okay, got it. For people that have already implemented this, I think > there has been an implicit understanding that the format of the chain > data is a sequence of concatenated wire format RRs exactly as they appear > in a DNS message section (with one injunction against doing DNS name > compression). I'll write some text to make this more explicit and describe > the format in more detail with references to the appropriate DNS specs. > > This is also the format that is readily generated and consumed by some > DNS libraries and the Intro section of this document has the following > assumption: "... (assuming that the data will be prepared and consumed > by a DNS-specific library) ..." > Sure. I'm not arguing that this is a bad format. It's just a matter of making clear to the user what they have to do to parse it. > > > * With PKIX-EE and PKIX-TA modes, the standard PKIX revocation > mechanisms > > > need to be consulted and honored. > > > > > > > Well, neither of these modes is useful here, as an attacker will simply > > ignore the > > extension. > > Just to confirm, I assume the attacker here is an entity attempting > to impersonate the TLS server (with presumably valid PKIX credentials). > If so, yes it can trivially ignore the extension, but this is the case > for any DANE usage mode (not just the PKIX constraining ones). > Agreed. It's just a less useful form of attack for the DANE modes where you are authenticating with DANE only, as it's basically just a form of DOS. > As discussed in Section 8, the protocol as currently specified really > only allows opportunistic DANE authentication, unless some mechanism > external to TLS is employed to mandate DANE usage. (The protocol could > be extended to require TLS servers to also provide a DNSSEC proof that > they don't have a signed TLSA record, but that could only be deployed > in a TLS application system where all servers supported this extension). > I agree. > > 3.1. Protocol, TLS 1.2 > > > > You should probably provide some guidance about whether the server > > > should still > > > > provide the whole X.509 chain to the client. I believe with these > > > semantics, > > > > the server cannot tell which DANE mode the client wants and therefore > > > has to > > > > provide the entire chain. > > > > > > Sure, we can elaborate. > > > > > > The DANE mode to be used is advertised by the server in its TLSA > record(s), > > > so the server already knows whether it needs to return the X.509 chain. > > > If the TLSA RRset has only DANE-EE, then only the end-entity > certificate > > > needs to be returned. If DANE-TA, then only the chain from the TA cert > to > > > the > > > EE needs to be returned. If using the PKIX modes, then yes, the entire > > > X.509 > > > chain has to be sent. > > > > > > > The problem is that the client is the decider about what it wants to > > accept, not > > the server. > > My comment was about what DANE mode choices the server is offering to > the client. Certainly, the client can decide whether it wants to use > DANE or not, and whether it wants to fallback to PKIX. The protocol > should probably not be proscriptive here, and allow different TLS > applications (or configurations of such applications) to make choices. > But maybe there are some general recommendations to be made. > > One additional comment about PKIX fallback on DANE failure: If a > server is using DANE-EE or DANE-TA, it has the ability to send back > a much shorter Certificate message - just the EE certificate for the > former, and typically a very short X.509 chain for the latter. But > this means that for fallback to PKIX, the client would have to start > a new handshake omitting the dnssec_chain extension. For efficient > fallback within the same handshake, the server would always have to > send back the full PKIX X.509 chain. Maybe that's what we need to > recommend for servers that support both DANE and traditional PKIX. > That would be my proposal, but I think at least you need to provide the kind of analysis you do here. > > > Servers receiving a "dnssec_chain" extension in the ClientHello, and > > > > which are capable of being authenticated via DANE, SHOULD return a > > > > serialized authentication chain in the extension block of the > > > > Why is this a SHOULD where the corresponding reqt for TLS 1.2 and > below > > > is a > > > > MAY? > > > > > > They should clearly be consistent. My preference would be "SHOULD" for > > > both. > > > > > > > That's a WG decision. > > Ok. Let me know how you want to handle this question. I'd be happy to > send a separate note to the WG list about it. > Sorry, I didn't mean to discount your view. I meant that I didn't think it was role to say which one it should be. This is actually a question for the chairs and the AD (Kathleen). If they think the WG decided this, then you can just do "SHOULD". If they think it requires WG consultation, then you should do that Section 4 (paragraphs 4 through 6) describe that process. Again, we could > go into more detail here, but we were working with the assumption in the > intro ( ".. the data will be prepared and consumed by a DNS-specific > library.") > OK. > > > the draft is adopted by the WG, the authors expect to make an early > > > > allocation request as specified in [RFC7120]. > > > > Do you want this to be marked RECOMMENDED? > > > > > > In response to Mirja's earlier comment, I think we are taking out this > > > sentence. > > > > > > > You're still registering the code point, so you need to determine if it's > > RECOMMENDED or not. > > Sorry for being dense - this protocol requires a new codepoint. Do we > need to say we RECOMMEND that a new code point be registered? > > Or are you asking that we RECOMMEND that IANA allocates our preferred > extension type value (53)? > No. There is a column in the code point assignment for IANA that says whether the IETF recommends the use of this extension or whether we're just assigning the code point but don't recommend it. So you need to say which one it is. I assume the WG wants "Recommended" -Ekr > Shumon. > > --94eb2c114ed09cafb20565bc969a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Feb 21, 2018 at 7:52 AM, Shumon Huque <shuque@gmail.com>= wrote:
Sorry for my belated follow-up= . Was temporarily overwhelmed by the
day jo= b ..


On Thu, Feb 8, 2018 a= t 9:49 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> On Thu= , Feb 8, 2018 at 6:18 AM, Shumon Huque <shuque@gmail.com> wrote:
>
>= ; > > IMPORTANT: I'm not sure that this is actually sufficient to= allow an
> > > independent implem= entation without referring to the other documents. I
> > > mean, I think I pretty clearly can't validate = this chain from the
> > > above.
> >
&g= t; > We could add an explicit reference here to the DNS protocol documen= t(s)
> > and sections within them tha= t define the canonical form of domain
> = > names (RFC 4034, Section 6 probably is the best reference), or even
> > excerpt the relevant text from that= document. Would this satisfy your
> >= ; concern?
> >
>
> Well, and remove your t= ext about it being possible to implement solely from
> this
> document.

Yes, I = agree, we need to remove that.


> It's not the algorithm. I don't believe this document is s= ufficient to
> parse the
> structure.

=

Okay= , got it. For people that have already implemented this, I think
there has been an implicit understanding that the for= mat of the chain
data is a sequence of conc= atenated wire format RRs exactly as they appear
in a DNS message section (with one injunction against doing DNS name
compression). I'll write some text to ma= ke this more explicit and describe
the form= at in more detail with references to the appropriate DNS specs.

This is also the = format that is readily generated and consumed by some
DNS libraries and the Intro section of this document has the fol= lowing
assumption: "... (assuming that= the data will be prepared and consumed
by = a DNS-specific library) ..."

Sure. I'm not arguing that this is a bad format. It's just= a matter of making
clear to the user what they have to do to par= se it.

=C2=A0
=
> > * With PKIX-EE and = PKIX-TA modes, the standard PKIX revocation mechanisms
> >=C2=A0 =C2=A0need to be consulted and honored.
> >
>
> Well, neither of these modes is useful he= re, as an attacker will simply
> ignore = the
> extension.

Just to confirm, I ass= ume the attacker here is an entity attempting
to impersonate the TLS server (with presumably valid PKIX credentials).<= /div>
If so, yes it can trivially ignore the exte= nsion, but this is the case
for any DANE us= age mode (not just the PKIX constraining ones).

Agreed. It's just a less useful form of attack f= or the DANE modes where
you are authenticating with DANE only, as= it's basically just a form of DOS.


=
=

As discusse= d in Section 8, the protocol as currently specified really
only allows opportunistic DANE authentication, unless some= mechanism
external to TLS is employed to m= andate DANE usage. (The protocol could
be e= xtended to require TLS servers to also provide a DNSSEC proof that
they don't have a signed TLSA record, but that = could only be deployed
in a TLS application= system where all servers supported this extension).

I agree.
=C2=A0

<= div>
> > 3.1.=C2= =A0 Protocol, TLS 1.2
> > > You sh= ould probably provide some guidance about whether the server
> > should still
&g= t; > > provide the whole X.509 chain to the client. I believe with th= ese
> > semantics,
> > > the server cannot tell which DANE mode the cli= ent wants and therefore
> > has to
> > > provide the entire chain.
> >
> = > Sure, we can elaborate.
> >
> > The DANE mode to be used is advertise= d by the server in its TLSA record(s),
>= > so the server already knows whether it needs to return the X.509 chai= n.
> > If the TLSA RRset has only DAN= E-EE, then only the end-entity certificate
= > > needs to be returned. If DANE-TA, then only the chain from the TA= cert to
> > the
> > EE needs to be returned. If using the PKIX modes, the= n yes, the entire
> > X.509
> > chain has to be sent.
> >
>
> The problem is that the client is the decider about w= hat it wants to
> accept, not
> the server.

=
My comment was about what DANE mode= choices the server is offering to
the clie= nt. Certainly, the client can decide whether it wants to use
DANE or not, and whether it wants to fallback to PKIX. Th= e protocol
should probably not be proscript= ive here, and allow different TLS
applicati= ons (or configurations of such applications) to make choices.
But maybe there are some general recommendations to be m= ade.

One additional comment about PKIX fallback on DANE= failure: If a
server is using DANE-EE or D= ANE-TA, it has the ability to send back
a m= uch shorter Certificate message - just the EE certificate for the
former, and typically a very short X.509 chain for t= he latter. But
this means that for fallback= to PKIX, the client would have to start
a = new handshake omitting the dnssec_chain extension. For efficient
fallback within the same handshake, the server would = always have to
send back the full PKIX X.50= 9 chain. Maybe that's what we need to
r= ecommend for servers that support both DANE and traditional PKIX.

That would be my proposal, but I t= hink at least you need to provide the
kind of analysis you do her= e.



> >=C2=A0 =C2=A0 Servers = receiving a "dnssec_chain" extension in the ClientHello, and
> > >=C2=A0 =C2=A0 which are capable o= f being authenticated via DANE, SHOULD return a
> > >=C2=A0 =C2=A0 serialized authentication chain in the ext= ension block of the
> > > Why is t= his a SHOULD where the corresponding reqt for TLS 1.2 and below
> > is a
> &g= t; > MAY?
> >
> > They should clearly be consistent. My preference woul= d be "SHOULD" for
> > both.=
> >
= >
> That's a WG decision.

Ok. Le= t me know how you want to handle this question. I'd be happy to
send a separate note to the WG list about it.

Sorry, I didn't mean to d= iscount your view. I meant that I didn't think it was
role to= say which one it should be.

This is actually a qu= estion for the chairs and the AD (Kathleen). If they think the
WG= decided this, then you can just do "SHOULD". If they think it re= quires WG
consultation, then you should do that


Section 4 (paragraphs 4 throug= h 6) describe that process. Again, we could=C2=A0
go into more detail here, but we were working with the assumption in= the=C2=A0
intro ( ".. the data will b= e prepared and consumed by a DNS-specific library.")
=

OK.



> > >=C2= =A0 =C2=A0 the draft is adopted by the WG, the authors expect to make an ea= rly
> > >=C2=A0 =C2=A0 allocation = request as specified in [RFC7120].
> >= ; > Do you want this to be marked RECOMMENDED?
> >
> > In response to M= irja's earlier comment, I think we are taking out this
> > sentence.
> &= gt;
>
&g= t; You're still registering the code point, so you need to determine if= it's
> RECOMMENDED or not.

Sorry f= or being dense - this protocol requires a new codepoint. Do we=C2=A0
<= div class=3D"gmail_extra">need to say we RECOMMEND that a new code point be= registered?

Or are you asking that we RECOMMEND that IANA allocates our preferre= d
extension type value (53)?

No. There is a column in the code point= assignment for IANA that says
whether the IETF recommends the us= e of this extension or whether we're
just assigning the code = point but don't recommend it. So you need to say
which one it= is. I assume the WG wants "Recommended"

-Ekr



Shumon.


--94eb2c114ed09cafb20565bc969a-- From nobody Wed Feb 21 10:50:04 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E64124BE8; Wed, 21 Feb 2018 10:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Fh_6gEewYLkA; Wed, 21 Feb 2018 10:49:56 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74C8A124BAC; Wed, 21 Feb 2018 10:49:56 -0800 (PST) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id B3CBA7A3309; Wed, 21 Feb 2018 18:49:49 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 21 Feb 2018 13:49:49 -0500 Cc: tls-chairs , draft-ietf-tls-dnssec-chain-extension@ietf.org, The IESG Content-Transfer-Encoding: quoted-printable Message-Id: References: <151800968634.4877.12510609339415982154.idtracker@ietfa.amsl.com> <4c90bb83-5ba1-8193-df67-38e25f76caf8@nlnetlabs.nl> To: TLS WG X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-dnssec-chain-extension-06=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 18:49:58 -0000 > On Feb 21, 2018, at 11:00 AM, Shumon Huque wrote: >=20 > On Tue, Feb 13, 2018 at 5:50 PM, Martin Thomson = wrote: > On Wed, Feb 14, 2018 at 4:07 AM, Kathleen Moriarty > wrote: >> What's the behavior when the middlebox is a proxy, let's say existing >> a managed network? I presume from from section 3.1 that this >> negotiation doesn't work in that instance unless sites configured for >> this are not subject to the proxy as is often done for financial site >> access from corporate networks. It would be good to know if it does >> work and that is addressed with the text Mirja calls out for her #1 >> question. Having this clarified could be helpful. >=20 > If there is a MitM, then this extension simply isn't negotiated. > That's pretty well understood. I don't see why that requires special > mention. >=20 > Yeah, I agree Martin .. this is the same as with any other extension. Actually, I don't think it is quite the same. This extension may be na=C3=AFvely expected to provide a different peer authentication mechanism than the traditional WebPKI. Users who might expect this extension to protect them from WebPKI compromise via DANE TLSA records, need to understand that such protection only exists when DANE is enforced (mandatory) by the client. The absence of DANE TLSA records, which is downgrade-resistant when the client has access to DNSSEC authenticated denial of existence (makes its own DNSSEC lookups) is no longer downgrade- resistant when delivered via this extension if the client is willing to accept just WebPKI in the (apparent) absence of DANE TLSA records. --=20 Viktor. --=20 Viktor. From nobody Wed Feb 21 11:21:49 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3A612DA06 for ; Wed, 21 Feb 2018 11:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 QkdcnUK-Yi9x for ; Wed, 21 Feb 2018 11:21:40 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 C44CE12DA21 for ; Wed, 21 Feb 2018 11:21:39 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zmnR53wtzz38S; Wed, 21 Feb 2018 20:21:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1519240897; bh=KOn2oD0j1YXwAxAqkv9pgKNv9l3Pdp9VCu2aQ4MOgkY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=q6ja3qXmmkJjWiKFHcp1tzEkb/Ret4T49NBUiP/XE84rHrNZZBFfviQzhIpQLBet3 PPsQvF7d2ZXQdDE81iLSshwcG4p1BJvXTgJkJsbPQUcDQ9W4v1BRZLg0mfGYet8ZRX TUbAOJz6zbrozvp/07frAC7+rxFtcIK1RhjDLDBk= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id w5Sx9lF478As; Wed, 21 Feb 2018 20:21:36 +0100 (CET) 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 mx.nohats.ca (Postfix) with ESMTPS; Wed, 21 Feb 2018 20:21:35 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B4EA3C75; Wed, 21 Feb 2018 14:21:34 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca B4EA3C75 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A8E98414535C; Wed, 21 Feb 2018 14:21:34 -0500 (EST) Date: Wed, 21 Feb 2018 14:21:34 -0500 (EST) From: Paul Wouters To: Viktor Dukhovni cc: TLS WG In-Reply-To: Message-ID: References: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 19:21:44 -0000 On Thu, 8 Feb 2018, Viktor Dukhovni wrote: > For clients that do reject PKIX success based on DANE failure, and > cache obtained TLSA records, it might have been good to recommend > refreshing the TLSA records while the cached data is still valid > (say the smaller of some refresh time or 50% of TTL has expired). > That way, for a client that keeps communicating regularly may be > (partially) protected against downgrades. Perhaps it is too late > to make such a change at this stage in the document's life-cycle. Is it customary for TLS clients that do PKIX validation to check the certificate expiry for long lived TLS connections? I assumed most TLS clients verification is done at the start of the connection only and the connection is then deemed verified until it closes - irrespective of the signature lifetimes of the certificate? Paul From nobody Wed Feb 21 11:48:23 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 489F61289B0; Wed, 21 Feb 2018 11:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 fg-5c7O6P_Mk; Wed, 21 Feb 2018 11:48:15 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 B1956124BAC; Wed, 21 Feb 2018 11:48:14 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zmp1l0dL4z38S; Wed, 21 Feb 2018 20:48:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1519242491; bh=AZvKubPQrITp5c4ndlw5uhJ4TgMCwkhmG1pDuAeWfqw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Qy8HQ8jUR3Ds6BvlkibrgMQRvpa26GHi5fqKq8ATLrOSv4sJuzDp4mDq00jqK4KvO F3Bur1Zk7IiJjJL545oWV4QamboP88aO4Axh75DNP2FHsZnXrgcv91yaylrwiRNutj s8dDk5NnOq6Y5XNQYcG2DkAo83jiLpmIhYGlZi5o= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id qu3DokQRorO5; Wed, 21 Feb 2018 20:48:09 +0100 (CET) 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 mx.nohats.ca (Postfix) with ESMTPS; Wed, 21 Feb 2018 20:48:09 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 45FD5C75; Wed, 21 Feb 2018 14:48:08 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 45FD5C75 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3A688414535C; Wed, 21 Feb 2018 14:48:08 -0500 (EST) Date: Wed, 21 Feb 2018 14:48:08 -0500 (EST) From: Paul Wouters To: Shumon Huque cc: Eric Rescorla , TLS WG , draft-ietf-tls-dnssec-chain-extension@ietf.org, The IESG , tls-chairs In-Reply-To: Message-ID: References: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 19:48:16 -0000 On Wed, 21 Feb 2018, Shumon Huque wrote: > Okay, got it. For people that have already implemented this, I think > there has been an implicit understanding that the format of the chain > data is a sequence of concatenated wire format RRs exactly as they appear > in a DNS message section Note, I would not call it "sequence of concatenated wire format RRs", as it is simply the wireformat of a DNS message. The fact that some parts are concatenated RR's is just part of the wireformat of the DNS reply message. That is, this isn't introducing some new form of concatenated content - it is _just_ a regular DNS wire format message, and the document should not go deeper into its explanation. I noticed some discussion about the ordering of this content. I am not sure why that should be done. DNS doesn't care about the order, and neither should producers or consumers of this extension. DNS has no ordering inside its message. In pseudo code, they should simply: while(not stuck and not empty(RRlist)): stuck = True for each RR in RRlist: if validated_with_cache(RR): add_to_cache(RR) remove_from_RRlist(RR) stuck = False And then the order of RRs doesn't matter. I don't think getting unrelated DNSSEC records would be an issue. TLS has its maximum sizes for the handshake. In fact, it could allow the extension to have some useful data in the case of MX or SRV. (and could be a feature to build a nice resolver over TLS using 1 tor circuit) I'm also not sure about the talking of unsigned CNAME records from DNAME. The above pseudo code (extended with special cases) should be in some DNS library, and that library will know what records to expect unsigned which are proven by the DNAME (or wildcard) synthesis and knows when/if to add it to the validated cache. I don't think that should be explained in this RFC at all. The DNS implementation does not need to be specified in this document and it should just focus on saying that "the DNS message response is validated and upon validation the content can be considered DANE validated". Paul From nobody Wed Feb 21 11:52:13 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0E312DA22 for ; Wed, 21 Feb 2018 11:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 KQDJeErFAs9O for ; Wed, 21 Feb 2018 11:52:11 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 397A712DA21 for ; Wed, 21 Feb 2018 11:52:11 -0800 (PST) Received: from [10.200.0.109] (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 23D547A3309; Wed, 21 Feb 2018 19:52:10 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 21 Feb 2018 14:52:09 -0500 Cc: TLS WG Content-Transfer-Encoding: 7bit Message-Id: <8DD08D1D-47D6-4CF5-B8A0-99FA446132E2@dukhovni.org> References: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com> To: Paul Wouters X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 19:52:12 -0000 > On Feb 21, 2018, at 2:21 PM, Paul Wouters wrote: > >> For clients that do reject PKIX success based on DANE failure, and >> cache obtained TLSA records, it might have been good to recommend >> refreshing the TLSA records while the cached data is still valid >> (say the smaller of some refresh time or 50% of TTL has expired). >> That way, for a client that keeps communicating regularly may be >> (partially) protected against downgrades. Perhaps it is too late >> to make such a change at this stage in the document's life-cycle. > > Is it customary for TLS clients that do PKIX validation to check the > certificate expiry for long lived TLS connections? The text you're responding to is NOT about long-lived TLS connections, rather it addresses the case where the client makes repeated connections frequently enough to benefit from caching previously obtained TLSA records for verifying future connections. In that case it makes sense to "refresh" the TLSA records (include the extension in a new request) even before the previously cached data has expired. > I assumed most TLS clients verification is done at the start of the > connection only and the connection is then deemed verified until it > closes - irrespective of the signature lifetimes of the certificate? Correct, but not applicable to the topic at hand. -- Viktor. From nobody Wed Feb 21 13:31:24 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518EB126C0F for ; Wed, 21 Feb 2018 13:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 x9vJg02ud10L for ; Wed, 21 Feb 2018 13:31:20 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FA311243F6 for ; Wed, 21 Feb 2018 13:31:20 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id k13so3833592qtg.5 for ; Wed, 21 Feb 2018 13:31:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2saW0yrxf8QEDnyeYkI734U5IVPUddMH2lS/RfOUxZw=; b=K2VFwoa8rV2SLirGtfMb9u1fp/bkjL3c1MmDDPgr1THWM8irUFQglfafpZvusYzHCJ RfiFGkESLnOe4avcfengoc6wUtEdSjWgx2EqN273jCPmk9Hwdiu/pqyadBt//qh/8MDG pqZy4Te/AkVi77osXjHudBig/a7hSDM5F/7XbSZ6lm74xqJCTWkuci3jzHpNi4PLj29r KNWU9H+INGeT8LDYDjUr9q5i60ooxdRhhOI0ngqmD3Jl6uw4IE7hIbB9mTTPcnvBPF8O 3qEr8dv263IsptBHKegFJYUmqomgtI5Rv6JPt6b8Z81fpJsF9voy5MC0CZ7f5+uzsssb nfiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2saW0yrxf8QEDnyeYkI734U5IVPUddMH2lS/RfOUxZw=; b=HIbHQQGMhC+xA8n3DHzA1uWHTHnwnE8jQRlHrwdywWKNWYbej+qqQbb4a7XFWNWq0S jfTtRySgNaGIZtWG171/x3ChFvkoEYmoS8z5b4PHo/RwIllJPtDAvAlKj4Uj12ahq8Ga 5HXZRjPV7HBHA8XrPq3BK+iTfU2erxuJugsCWlUebFqyS2hxKBQihjzU1axlGXeZuHO5 pDOAQaBvCVzaQTPE71xp3dtAzLkkGPlfSlN2By+zAiZwPRLPN6noh4tt11lmARTny8HX jArCgU9QhShNHbL1DxY7G+anfdqPWeAoTbHw2TzZ+gXxKJjLLO7tqF06G0oYMOpU+IZh mrRQ== X-Gm-Message-State: APf1xPAFtoY0dl0l4pvYhztxnZTzNp6lH/cMKQ/R28N3aDjum6ZUirxL jruqlALknHPnBZsYy9bs3+7Jw2MPQpsiAE034Ahj4+J0 X-Google-Smtp-Source: AH8x225gxDtW7jxXTTs0H335CTyjsmtDI80U8GxNdiBWg8HQ+I1f8mrID5LBcxzxTs/7/JPCxOhc7R9RZipVEy5zdzE= X-Received: by 10.200.42.177 with SMTP id b46mr7601156qta.321.1519248679431; Wed, 21 Feb 2018 13:31:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.176 with HTTP; Wed, 21 Feb 2018 13:30:38 -0800 (PST) In-Reply-To: References: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Wed, 21 Feb 2018 13:30:38 -0800 Message-ID: To: Paul Wouters Cc: Viktor Dukhovni , TLS WG Content-Type: multipart/alternative; boundary="001a113b0328dd03220565bfa53f" Archived-At: Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 21:31:22 -0000 --001a113b0328dd03220565bfa53f Content-Type: text/plain; charset="UTF-8" On Wed, Feb 21, 2018 at 11:21 AM, Paul Wouters wrote: > On Thu, 8 Feb 2018, Viktor Dukhovni wrote: > > For clients that do reject PKIX success based on DANE failure, and >> cache obtained TLSA records, it might have been good to recommend >> refreshing the TLSA records while the cached data is still valid >> (say the smaller of some refresh time or 50% of TTL has expired). >> That way, for a client that keeps communicating regularly may be >> (partially) protected against downgrades. Perhaps it is too late >> to make such a change at this stage in the document's life-cycle. >> > > Is it customary for TLS clients that do PKIX validation to check the > certificate expiry for long lived TLS connections? > > I assumed most TLS clients verification is done at the start of the > connection only and the connection is then deemed verified until it > closes - irrespective of the signature lifetimes of the certificate? > To the best of my knowledge you are correct. -Ekr > > Paul > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113b0328dd03220565bfa53f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Feb 21, 2018 at 11:21 AM, Paul Wouters <paul@nohats.ca> wrote:
On Thu, 8 Fe= b 2018, Viktor Dukhovni wrote:

For clients that do reject PKIX success based on DANE failure, and
cache obtained TLSA records, it might have been good to recommend
refreshing the TLSA records while the cached data is still valid
(say the smaller of some refresh time or 50% of TTL has expired).
That way, for a client that keeps communicating regularly may be
(partially) protected against downgrades.=C2=A0 Perhaps it is too late
to make such a change at this stage in the document's life-cycle.

 Is it customary for TLS clients that do PKIX validation to check the
certificate expiry for long lived TLS connections?

I assumed most TLS clients verification is done at the start of the
connection only and the connection is then deemed verified until it
closes - irrespective of the signature lifetimes of the certificate?

To the best of my knowledge you are correct.<= /div>

-Ekr
=C2=A0

Paul

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a113b0328dd03220565bfa53f-- From nobody Wed Feb 21 15:17:21 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399C5126579; Wed, 21 Feb 2018 15:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 JyRJXohqzALS; Wed, 21 Feb 2018 15:17:14 -0800 (PST) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94EDE1200E5; Wed, 21 Feb 2018 15:17:11 -0800 (PST) Received: by mail-oi0-x22c.google.com with SMTP id a207so2402335oii.10; Wed, 21 Feb 2018 15:17:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CYdVpaRNfzpi+lWs7IhsWBQEOICK0bx34fLDrPkj16U=; b=CV7N89TO2Kzr9aoI/LSNpghoh66mv6Smre2s35y0yWV+xx0mxB1sM0MhMq6AZXQH+t fNHP/ejr+LIHp9zdwjrvi+lBF5X9oO4S4d6CXZlQX1Yylg21UWPYLdx4cr6mAMJYtVI6 z0HTKE991SBMDrzkueetx6jbINRFeGVCYE11vzVv6v892iy2X2EnxMAoRkvtg7ghtKkr Wsx5ld6ZKjyLHbjuidK9/FXmMtdkzbZ0erBUcqDBou3giDbuLNjM8iFIAkl4ryfP2Ip1 WQYjKHFJMfQJc6cnysLcDVYpHgZJhI1ofpwHQ5WzepDkmwG3wnOHpSzYnRATd6Qgkjed 490w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=CYdVpaRNfzpi+lWs7IhsWBQEOICK0bx34fLDrPkj16U=; b=g1cc2VB6Vxb/zMd4l1XFDuuizQ6qxpKVru0U0jKrAQcZxNpJtSL63VpfuD4Dq12zP7 fam5FhTI1bOj3rwQ7XDFnxJoFwnh9OULcXvXeOgUzsGW2tKDRpS5Uf6OJvhiURsBKwPA gUQOpwv2sIQPdDhuIwlIKBYkkGND3h0VtRRe5o3Z+KrtyO9rq+x+lf4gL9wT9/Zfviu7 JHommaKklgORKO1elDBiGYF4a4XVpgV+bLs8QhAdKskywDyapB+aCG6gcAVFaoUPM5uG FSm3g/6XiKp6XKAviQE1//NkMOje4eI4LbjH2Ohw8S8C6mCNukFaCDUpe5nSbpBEfDvC uzrw== X-Gm-Message-State: APf1xPBOK9WqLQD3Gf/GOw4AA+MIqlBmFG6/dFVH2OyfEbqdARuxZML3 LZidVjFmkbMAy2uJ+m7CpEp15GLE9J7lnht6D453toKe X-Google-Smtp-Source: AH8x227jPRX3XWyEJvbAUJOo0SXVGrPvH64xBIaJ6bWMjAM2G7RAOTjOFZVvHT4uP83u4A+W+VwqiQjsvMwe+Pd/TH0= X-Received: by 10.202.84.132 with SMTP id i126mr3100279oib.295.1519255030911; Wed, 21 Feb 2018 15:17:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.16.85 with HTTP; Wed, 21 Feb 2018 15:17:10 -0800 (PST) In-Reply-To: <151922077388.9603.11906306194638042902@ietfa.amsl.com> References: <151922077388.9603.11906306194638042902@ietfa.amsl.com> From: Martin Thomson Date: Thu, 22 Feb 2018 10:17:10 +1100 Message-ID: To: =?UTF-8?B?w4lyaWMgVnluY2tl?= Cc: ops-dir@ietf.org, "" , ietf@ietf.org, draft-ietf-tls-record-limit.all@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Opsdir telechat review of draft-ietf-tls-record-limit-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 23:17:16 -0000 Thanks =C3=89ric. https://github.com/tlswg/tls-record-limit/pull/16 fixes your nit. On Thu, Feb 22, 2018 at 12:46 AM, =C3=89ric Vyncke wrot= e: > Reviewer: =C3=89ric Vyncke > Review result: Has Nits > > Reviewer: Eric Vyncke > Review results: has nits > > Hello Martin, > > I have reviewed this document as part of the Operational directorate's on= going > effort to review all IETF documents being processed by the IESG. These co= mments > were written with the intent of improving the operational aspects of the = IETF > drafts. > > The document is about an extension to TLS (record_size_limit) allowing > endpoints to negotiate the maximum size of protected records. The documen= t also > deprecates a previous extension max_fragment_length. > > The different scenarios (whether endpoints support this option or not) as= well > as behavior of future versions of TLS are specified. Section 5 also descr= ibes > the behavior when endpoints use the proposed and the deprecated TLS optio= ns. > > Nits in section 5: "MUST ignore *and* "max_fragment_length"" > > This is a short document and IMHO all operational issues are well documen= ted > and correct. > > -=C3=A9ric > > From nobody Wed Feb 21 15:22:46 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAA5126DFF; Wed, 21 Feb 2018 15:22:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 E7Bsx19qUNF2; Wed, 21 Feb 2018 15:22:37 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DC451200E5; Wed, 21 Feb 2018 15:22:37 -0800 (PST) Received: by mail-oi0-x230.google.com with SMTP id a207so2410791oii.10; Wed, 21 Feb 2018 15:22:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=V3XN/wm0ZdCCuznVBbHBJIyMwxOGoRXCBJL/ShKaMk8=; b=Zf1SBR4YPN+tGB4rczSUX9YXXDdNfxSxm509DLTpfURxwWtERDoAGs1QZ1P+tmnyGO PqD/YxB4wAgCnXRVWynDr52Iie6zU9Rt3xc/c6UTFdWvCyX3/RkJi0Cn2XMmyYxIPmy6 DxvQh/cBLGwW4JLann76Vq5BfTZXo10cHXPNqWM1jETjdgLXjXlUuPKcPB5eYV4Kl8QR KHjjaAyD8sckc5Jvy5zq5PHcBhTTjf5xjm2sMY3Dj4TyISnmteKWyy4pkKMoElkxI/92 dBZZcqpCi2BKhnMW/yttgeZRMgNYq2wwpRKclTlBJEuZgChwqB1F4K7hFPvZ79LrC5PB ujnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=V3XN/wm0ZdCCuznVBbHBJIyMwxOGoRXCBJL/ShKaMk8=; b=EBKCMYfyJWf9pgHWZLUztNe+ikbFiegIRAtFbEHNnlJE8OViZAV3bg63h1adYY+/r/ 4XgJlnfNkM2owgDG/4GSgLcaCdS4LU0Y882f6ogz9UNjEUfTikDAFscwpD/o8CM3KBKE fqFEFN9APQ1JHg0BjTSNLnAiX7TB+9E5ip9h/4klujB/VoF5d0iOhGrbq2M8kouQIAzJ FznFarYngyuWJ2c8vKBXTRn3sBhCFNbjicEfo6zClKtM4kZzbmv0ZG1tmM5EzYmlcK3f obR7pLrRwMMDE9zTIFRwvyAsfJHWD7xR9SQDN43NM0LZGk25wKyIgEYAenW1Svom537k rXVg== X-Gm-Message-State: APf1xPAo3o2XkhAVtuhr1px3Wzp45gU8bN42wsXmwJpo/3Kyoy+jlW2J p/nlguu7AjczREqM3FQpy2PGzVpEt0pLAi89Nyg= X-Google-Smtp-Source: AH8x224COxXA3D9HvmGDuWqTRtxyGxTpWy9k8/UIkyilprJTI5NNHigr9GjOURdgDbSNOvAbrMxptxU3dK8uzzoFmyo= X-Received: by 10.202.94.196 with SMTP id s187mr932752oib.144.1519255356444; Wed, 21 Feb 2018 15:22:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.16.85 with HTTP; Wed, 21 Feb 2018 15:22:35 -0800 (PST) In-Reply-To: References: <151880080195.1349.14035524657942875385.idtracker@ietfa.amsl.com> <1545738.SpB3f87gQo@pintsize.usersys.redhat.com> <21708133.DmTAOkxbDk@pintsize.usersys.redhat.com> From: Martin Thomson Date: Thu, 22 Feb 2018 10:22:35 +1100 Message-ID: To: Eric Rescorla Cc: Hubert Kario , draft-ietf-tls-tls13@ietf.org, "" , IETF discussion list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] external PSK identity enumeration Re: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 23:22:39 -0000 I think that the current behavior is fine, but we might add text to suggest that identities be self-authenticating to avoid this sort of enumeration. Note that in common practice, this sort of enumeration would be over an infeasibly large space, it's only where identities are more easily enumerable that it becomes an issue (e.g., "ted" as an identity, rather than a self-encrypted session ticket) On Thu, Feb 22, 2018 at 1:31 AM, Eric Rescorla wrote: > i think your general point is sound here, but I'll nitpick the statement > that > "if the server recognises an identity but is unable to verify correspondi= ng > binder". > > 1. The server only picks one identity so you if you send A, B, and C and = you > get an abort, you don't know if it recognized one or all. > 2. The server can *recognize* the identity but ignore it (say it's a tick= et > that's > too old) > > With that said, I think it would probably be safe to say you must ignore = an > identity > where the binder doesn't validate, but I'd like to hear from cryptographe= rs > on this > one. > > Thanks, > -Ekr > > > On Wed, Feb 21, 2018 at 6:26 AM, Hubert Kario wrote: >> >> On Wednesday, 21 February 2018 15:21:58 CET Eric Rescorla wrote: >> > On Wed, Feb 21, 2018 at 6:13 AM, Hubert Kario wrot= e: >> > > On Friday, 16 February 2018 18:06:41 CET The IESG wrote: >> > > > The IESG has received a request from the Transport Layer Security = WG >> > > >> > > (tls) >> > > >> > > > to consider the following document: - 'The Transport Layer Securit= y >> > > > (TLS) >> > > > Protocol Version 1.3' >> > > > >> > > > as Proposed Standard >> > > >> > > The current draft states that if the server recognises an identity b= ut >> > > is >> > > unable to verify corresponding binder, it "MUST abort the handshake" >> > >> > Which text are you referring to here? >> >> Section 4.2.11: >> >> Prior to accepting PSK key establishment, the server MUST validate >> the corresponding binder value (see Section 4.2.11.2 below). If this >> value is not present or does not validate, the server MUST abort the >> handshake. Servers SHOULD NOT attempt to validate multiple binders; >> rather they SHOULD select a single PSK and validate solely the binder >> that corresponds to that PSK. >> >> > -Ekr >> > >> > at the same time, they "SHOULD select as single PSK and validate solel= y >> > the >> > >> > > binder that corresponds to that PSK" >> > > (Page 60, draft-ietf-tls-tls13-24). >> > > >> > > That allows for trivial enumeration of externally established >> > > identities - >> > > the >> > > attacker just needs to send to the server a list of identity guesses= , >> > > with >> > > random data as binders, if the server recognises any identity it wil= l >> > > abort >> > > connection, if it doesn't, it will continue to a non-PSK handshake. >> > > >> > > Behaviour like this is generally considered a vulnerability: >> > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2003-0190 >> > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2006-5229 >> > > >> > > I was wondering if the document shouldn't recommend ignoring any and >> > > all >> > > identities for which binders do not verify to prevent this kind of >> > > attack. >> > > -- >> > > Regards, >> > > Hubert Kario >> > > Senior Quality Engineer, QE BaseOS Security team >> > > Web: www.cz.redhat.com >> > > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republ= ic >> > > _______________________________________________ >> > > TLS mailing list >> > > TLS@ietf.org >> > > https://www.ietf.org/mailman/listinfo/tls >> >> >> -- >> Regards, >> Hubert Kario >> Senior Quality Engineer, QE BaseOS Security team >> Web: www.cz.redhat.com >> Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic > > From nobody Wed Feb 21 15:31:54 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873DE1277BB for ; Wed, 21 Feb 2018 15:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nerd.ninja 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 FwEhUCPOW4wk for ; Wed, 21 Feb 2018 15:31:51 -0800 (PST) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0313F126C3D for ; Wed, 21 Feb 2018 15:31:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1519255905; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; l=10701; bh=ih9bOBfGXM6uZnZTs2I3LMsUVh8mH/Pcd940pYd5qPk=; b=nL5c6sNBVMSdBWXz7KPwiwEpi0B2h0fneNRe+4Zmqpc9SBS2g+jJKk++MV5lV+0O DV3OSATkjmI3A7Vt3U3WGRuMHIV8xORt6hY2Y8aXBFCsBqDdihcWqFtUEHXCvNqtgLe hB8ZLMeRQYe1eQ6Bb7rpAUNWxZkLk8B0quGK7wVY= Received: from [192.168.123.225] (dynamic-acs-24-112-242-116.zoominternet.net [24.112.242.116]) by mx.zohomail.com with SMTPS id 1519255905151499.2341976568034; Wed, 21 Feb 2018 15:31:45 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Wed, 21 Feb 2018 18:31:42 -0500 From: R du Toit To: Christian Huitema , "tls@ietf.=?UTF-8?B?b3JnwqA=?=" Message-ID: <9C911514-298C-48EB-BF2E-E7AEDF6411F6@nerd.ninja> Thread-Topic: Comments on draft-ietf-tls-sni-encryption-01.txt Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3602082704_289157534" X-ZohoMailClient: External X-ZohoMail: Z_658201841 SPT_1 Z_47369130 SPT_1 SLF_D Archived-At: Subject: [TLS] Comments on draft-ietf-tls-sni-encryption-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 23:31:52 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3602082704_289157534 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I have analyzed the two mechanisms proposed in the draft, with specific foc= us on the impact of middleboxes.=20 =20 Assumptions: The middlebox is deployed inline, between the client and the fronting serve= r, and is allowed to intercept TLS sessions. The middlebox is policy-driven= , and uses SNI as an input in determining whether or not to intercept the se= ssion; the policy must use the SNI of the hidden server. =20 Mechanism #1 : Tunnel ClientHello in 0-RTT early data. (1) Mechanism #1 requires 0-RTT support, but the middlebox would not be vio= lating the TLS 1.3 specification by not implementing 0-RTT.=C2=A0 The middlebox = intercepts all sessions destined to a specific fronting server (F); the iden= tity of F should be public knowledge, but even if it is not, we have to assu= me that the middlebox has a mechanism to decide when to intercept sessions d= estined to F. =20 =20 (2) Assume that the middlebox actually supports PSK and 0-RTT, i.e. TLS int= ercept with PSK/0-RTT support in the session between the client and the midd= lebox, as well as PSK/0-RTT support in the session between the middlebox and= the fronting server. The middlebox will be able to decode ClientHello#2 se= nt in the 0-RTT early data because the client_early_traffic_secret will be k= nown to the middlebox. The middlebox would thus have access to the SNI of t= he hidden server, and would be able to evaluate policy. The middlebox would= have the option to pull out of the session after sending ClientHello#2 to t= he fronting server (re-encrypted with the client_early_traffic_secret shared= between the middlebox and the fronting server). =20 Mechanism #2: Session ticket that can be decoded by Fronting and Hidden ser= ver. (3) Mechanism #2 relies on PSK session resumption support in the middlebox;= this is not guaranteed. =20 (4) The middlebox would not participate or interfere in any of the out-of-b= and channels between the fronting server and the hidden server, which implie= s that the middlebox will not be able to decode the session ticket generated= by the hidden server - but it does not have to. The middlebox would be abl= e to observe the encoded session ticket in the NewSessionTicket message beca= use it intercepts the initial TLS session between the client and the hidden = server (even if mechanism #1 is used for the first session). The middlebox = would thus be able to extract the SNI of the hidden server from the NewSessi= onTicket message and build a mapping of encoded session tickets to hidden se= rvers. TLS sessions (destined to the fronting server) that were not previous= ly intercepted by the middlebox will use PSK identities that are not in the = mapping table - the middlebox would likely force intercept of those sessions= and strip the unknown PSK identities, which would result in a TLS session t= hat terminates on the fronting server, leaving the fronting server without a= ny knowledge of the hidden server. =20 (5) Ignoring middleboxes, in my opinion the infrastructure required for col= laboration between fronting servers and hidden servers (stateful, shared-key= , public-key, or otherwise) would be a practical barrier to entry for most s= erver administrators. =20 =20 --Roelof --B_3602082704_289157534 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

I have analyzed the two mechanisms proposed in the= draft, with specific focus on the impact of middleboxes. 

 =

Assumptio= ns:

The middlebox is deploye= d inline, between the client and the fronting server, and is allowed to inte= rcept TLS sessions.  The middlebox is policy-driven, and uses SNI as an= input in determining whether or not to intercept the session; the policy mu= st use the SNI of the hidden server.

 

Mechanism #1 : Tunnel ClientHello in= 0-RTT early data.

(1) Mecha= nism #1 requires 0-RTT support, but the middlebox would not be violating the= TLS 1.3 specification by not implementing 0-RTT.=C2=A0 The middlebox intercepts= all sessions destined to a specific fronting server (F); the identity of F = should be public knowledge, but even if it is not, we have to assume that th= e middlebox has a mechanism to decide when to intercept sessions destined to= F.  

 

(2) Assume that the middlebox actually supports PSK and 0-RTT, = i.e. TLS intercept with PSK/0-RTT support in the session between the client = and the middlebox, as well as PSK/0-RTT support in the session between the m= iddlebox and the fronting server.  The middlebox will be able to decode= ClientHello#2 sent in the 0-RTT early data because the client_early_traffic= _secret will be known to the middlebox.  The middlebox would thus have = access to the SNI of the hidden server, and would be able to evaluate policy= .  The middlebox would have the option to pull out of the session after= sending ClientHello#2 to the fronting server (re-encrypted with the client_= early_traffic_secret shared between the middlebox and the fronting server).<= o:p>

 = ;

Mechanism #2: Session ticket that can be decoded by Fronting and Hidden s= erver.

(3) Mechanism #2 reli= es on PSK session resumption support in the middlebox; this is not guarantee= d.

&n= bsp;

= (4) The middlebox would not participate or interfere in any of the out-of-ba= nd channels between the fronting server and the hidden server, which implies= that the middlebox will not be able to decode the session ticket generated = by the hidden server - but it does not have to.  The middlebox would be= able to observe the encoded session ticket in the NewSessionTicket message = because it intercepts the initial TLS session between the client and the hid= den server (even if mechanism #1 is used for the first session).  The m= iddlebox would thus be able to extract the SNI of the hidden server from the= NewSessionTicket message and build a mapping of encoded session tickets to = hidden servers. TLS sessions (destined to the fronting server) that were not= previously intercepted by the middlebox will use PSK identities that are no= t in the mapping table - the middlebox would likely force intercept of those= sessions and strip the unknown PSK identities, which would result in a TLS = session that terminates on the fronting server, leaving the fronting server = without any knowledge of the hidden server.

 

(5) Ignoring middleboxes, in my opi= nion the infrastructure required for collaboration between fronting servers = and hidden servers (stateful, shared-key, public-key, or otherwise) would be= a practical barrier to entry for most server administrators.

 

 =

--Roelof

--B_3602082704_289157534-- From nobody Thu Feb 22 01:19:04 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2BBA12E86E; Thu, 22 Feb 2018 01:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 4aBm852fGezk; Thu, 22 Feb 2018 01:19:01 -0800 (PST) Received: from esa2.dyson.c3s2.iphmx.com (esa2.dyson.c3s2.iphmx.com [68.232.133.94]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70680124319; Thu, 22 Feb 2018 01:19:00 -0800 (PST) X-IronPort-SPF: SKIP X-IronPort-AV: E=McAfee;i="5900,7806,8811"; a="30403344" X-IronPort-AV: E=Sophos;i="5.47,377,1515456000"; d="scan'208";a="30403344" Received: from unknown (HELO uk-dlp-smtp-01.dyson.global.corp) ([62.189.202.16]) by esa2.dyson.c3s2.iphmx.com with ESMTP; 22 Feb 2018 09:28:27 +0000 Received: from uk-dlp-smtp-01.dyson.global.corp (uk-dlp-smtp-01.dyson.global.corp [127.0.0.1]) by uk-dlp-smtp-01.dyson.global.corp (Service) with ESMTP id BCD0AFA10; Thu, 22 Feb 2018 07:47:00 +0000 (GMT) Received: from UK-MAL-CAS-01.dyson.global.corp (unknown [10.1.108.2]) by uk-dlp-smtp-01.dyson.global.corp (Service) with ESMTP id A36EAFA02; Thu, 22 Feb 2018 07:47:00 +0000 (GMT) Received: from UK-MAL-CAS-03.dyson.global.corp (10.1.108.111) by UK-MAL-CAS-01.dyson.global.corp (10.1.108.2) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 22 Feb 2018 09:18:45 +0000 Received: from UK-MAL-MBOX-01.dyson.global.corp ([fe80::3975:cbc9:490b:523a]) by UK-MAL-CAS-03.dyson.global.corp ([10.1.108.111]) with mapi id 14.03.0319.002; Thu, 22 Feb 2018 09:18:45 +0000 From: Tony Putman To: Martin Thomson CC: "draft-ietf-tls-tls13@ietf.org" , "" , IETF discussion list Thread-Topic: [TLS] external PSK identity enumeration Re: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard Thread-Index: AQHTqx5FKb1d2DSy/UuxaAWe7a4q2aOu6G0AgAABUgCAAAFbgIAAlF+AgACk6TA= Date: Thu, 22 Feb 2018 09:18:44 +0000 Message-ID: <140080C241BAA1419B58F093108F9EDC10B7F9B4@UK-MAL-MBOX-01.dyson.global.corp> References: <151880080195.1349.14035524657942875385.idtracker@ietfa.amsl.com> <1545738.SpB3f87gQo@pintsize.usersys.redhat.com> <21708133.DmTAOkxbDk@pintsize.usersys.redhat.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.108.27] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [TLS] external PSK identity enumeration Re: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 09:19:02 -0000 Rm9yIGV4dGVybmFsbHkgZXN0YWJsaXNoZWQgUFNLcyAoZXNwZWNpYWxseSBmb3IgSW9UIGRldmlj ZXMpIHRoZSBpZGVudGl0eSBjYW4gYmUgYXMgc2ltcGxlIGFzIGEgc2VyaWFsIG51bWJlciwgZWFz aWx5IGVudW1lcmF0ZWQuIEkgdGhpbmsgaXQgd291bGQgYmUgYSBtaXN0YWtlIHRvIHBsYWNlIHJl cXVpcmVtZW50cyBvbiB0aGUgc3RydWN0dXJlIG9mIHRoZSBpZGVudGl0eSB0byByZXNvbHZlIHRo aXMgKGlmIGl0IG5lZWRzIHJlc29sdmluZyk7IElNSE8gdHJlYXRpbmcgdGhlIHNpdHVhdGlvbiBp biB0aGUgc2FtZSB3YXkgYXMgb25lIHdoaWNoIGRvZXMgbm90IGluY2x1ZGUgYSB2YWxpZCBQU0sg aXMgYmV0dGVyLiBCdXQgSSBhZ3JlZSB3aXRoIEVyaWMgdGhhdCB3ZSBzaG91bGQgaGVhciBmcm9t IGNyeXB0b2dyYXBoZXJzIG9uIHRoaXMuDQotLSBUb255DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIE1hcnRpbiBUaG9tc29uDQpTZW50OiAyMSBGZWJydWFyeSAyMDE4IDIzOjIzDQpUbzogRXJp YyBSZXNjb3JsYQ0KQ2M6IGRyYWZ0LWlldGYtdGxzLXRsczEzQGlldGYub3JnOyA8dGxzQGlldGYu b3JnPjsgSUVURiBkaXNjdXNzaW9uIGxpc3QNClN1YmplY3Q6IFJlOiBbVExTXSBleHRlcm5hbCBQ U0sgaWRlbnRpdHkgZW51bWVyYXRpb24gUmU6IFVQREFURUQgTGFzdCBDYWxsOiA8ZHJhZnQtaWV0 Zi10bHMtdGxzMTMtMjQudHh0PiAoVGhlIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKSBQ cm90b2NvbCBWZXJzaW9uIDEuMykgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCg0KSSB0aGluayB0aGF0 IHRoZSBjdXJyZW50IGJlaGF2aW9yIGlzIGZpbmUsIGJ1dCB3ZSBtaWdodCBhZGQgdGV4dCB0bw0K c3VnZ2VzdCB0aGF0IGlkZW50aXRpZXMgYmUgc2VsZi1hdXRoZW50aWNhdGluZyB0byBhdm9pZCB0 aGlzIHNvcnQgb2YNCmVudW1lcmF0aW9uLiAgTm90ZSB0aGF0IGluIGNvbW1vbiBwcmFjdGljZSwg dGhpcyBzb3J0IG9mIGVudW1lcmF0aW9uDQp3b3VsZCBiZSBvdmVyIGFuIGluZmVhc2libHkgbGFy Z2Ugc3BhY2UsIGl0J3Mgb25seSB3aGVyZSBpZGVudGl0aWVzDQphcmUgbW9yZSBlYXNpbHkgZW51 bWVyYWJsZSB0aGF0IGl0IGJlY29tZXMgYW4gaXNzdWUgKGUuZy4sICJ0ZWQiIGFzIGFuDQppZGVu dGl0eSwgcmF0aGVyIHRoYW4gYSBzZWxmLWVuY3J5cHRlZCBzZXNzaW9uIHRpY2tldCkNCg0KT24g VGh1LCBGZWIgMjIsIDIwMTggYXQgMTozMSBBTSwgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29t PiB3cm90ZToNCj4gaSB0aGluayB5b3VyIGdlbmVyYWwgcG9pbnQgaXMgc291bmQgaGVyZSwgYnV0 IEknbGwgbml0cGljayB0aGUgc3RhdGVtZW50DQo+IHRoYXQNCj4gImlmIHRoZSBzZXJ2ZXIgcmVj b2duaXNlcyBhbiBpZGVudGl0eSBidXQgaXMgdW5hYmxlIHRvIHZlcmlmeSBjb3JyZXNwb25kaW5n DQo+IGJpbmRlciIuDQo+DQo+IDEuIFRoZSBzZXJ2ZXIgb25seSBwaWNrcyBvbmUgaWRlbnRpdHkg c28geW91IGlmIHlvdSBzZW5kIEEsIEIsIGFuZCBDIGFuZCB5b3UNCj4gZ2V0IGFuIGFib3J0LCB5 b3UgZG9uJ3Qga25vdyBpZiBpdCByZWNvZ25pemVkIG9uZSBvciBhbGwuDQo+IDIuIFRoZSBzZXJ2 ZXIgY2FuICpyZWNvZ25pemUqIHRoZSBpZGVudGl0eSBidXQgaWdub3JlIGl0IChzYXkgaXQncyBh IHRpY2tldA0KPiB0aGF0J3MNCj4gdG9vIG9sZCkNCj4NCj4gV2l0aCB0aGF0IHNhaWQsIEkgdGhp bmsgaXQgd291bGQgcHJvYmFibHkgYmUgc2FmZSB0byBzYXkgeW91IG11c3QgaWdub3JlIGFuDQo+ IGlkZW50aXR5DQo+IHdoZXJlIHRoZSBiaW5kZXIgZG9lc24ndCB2YWxpZGF0ZSwgYnV0IEknZCBs aWtlIHRvIGhlYXIgZnJvbSBjcnlwdG9ncmFwaGVycw0KPiBvbiB0aGlzDQo+IG9uZS4NCj4NCj4g VGhhbmtzLA0KPiAtRWtyDQo+DQo+DQo+IE9uIFdlZCwgRmViIDIxLCAyMDE4IGF0IDY6MjYgQU0s IEh1YmVydCBLYXJpbyA8aGthcmlvQHJlZGhhdC5jb20+IHdyb3RlOg0KPj4NCj4+IE9uIFdlZG5l c2RheSwgMjEgRmVicnVhcnkgMjAxOCAxNToyMTo1OCBDRVQgRXJpYyBSZXNjb3JsYSB3cm90ZToN Cj4+ID4gT24gV2VkLCBGZWIgMjEsIDIwMTggYXQgNjoxMyBBTSwgSHViZXJ0IEthcmlvIDxoa2Fy aW9AcmVkaGF0LmNvbT4gd3JvdGU6DQo+PiA+ID4gT24gRnJpZGF5LCAxNiBGZWJydWFyeSAyMDE4 IDE4OjA2OjQxIENFVCBUaGUgSUVTRyB3cm90ZToNCj4+ID4gPiA+IFRoZSBJRVNHIGhhcyByZWNl aXZlZCBhIHJlcXVlc3QgZnJvbSB0aGUgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IFdHDQo+PiA+ ID4NCj4+ID4gPiAodGxzKQ0KPj4gPiA+DQo+PiA+ID4gPiB0byBjb25zaWRlciB0aGUgZm9sbG93 aW5nIGRvY3VtZW50OiAtICdUaGUgVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5DQo+PiA+ID4gPiAo VExTKQ0KPj4gPiA+ID4gUHJvdG9jb2wgVmVyc2lvbiAxLjMnDQo+PiA+ID4gPg0KPj4gPiA+ID4g ICA8ZHJhZnQtaWV0Zi10bHMtdGxzMTMtMjQudHh0PiBhcyBQcm9wb3NlZCBTdGFuZGFyZA0KPj4g PiA+DQo+PiA+ID4gVGhlIGN1cnJlbnQgZHJhZnQgc3RhdGVzIHRoYXQgaWYgdGhlIHNlcnZlciBy ZWNvZ25pc2VzIGFuIGlkZW50aXR5IGJ1dA0KPj4gPiA+IGlzDQo+PiA+ID4gdW5hYmxlIHRvIHZl cmlmeSBjb3JyZXNwb25kaW5nIGJpbmRlciwgaXQgIk1VU1QgYWJvcnQgdGhlIGhhbmRzaGFrZSIN Cj4+ID4NCj4+ID4gV2hpY2ggdGV4dCBhcmUgeW91IHJlZmVycmluZyB0byBoZXJlPw0KPj4NCj4+ IFNlY3Rpb24gNC4yLjExOg0KPj4NCj4+ICAgIFByaW9yIHRvIGFjY2VwdGluZyBQU0sga2V5IGVz dGFibGlzaG1lbnQsIHRoZSBzZXJ2ZXIgTVVTVCB2YWxpZGF0ZQ0KPj4gICAgdGhlIGNvcnJlc3Bv bmRpbmcgYmluZGVyIHZhbHVlIChzZWUgU2VjdGlvbiA0LjIuMTEuMiBiZWxvdykuICBJZiB0aGlz DQo+PiAgICB2YWx1ZSBpcyBub3QgcHJlc2VudCBvciBkb2VzIG5vdCB2YWxpZGF0ZSwgdGhlIHNl cnZlciBNVVNUIGFib3J0IHRoZQ0KPj4gICAgaGFuZHNoYWtlLiAgU2VydmVycyBTSE9VTEQgTk9U IGF0dGVtcHQgdG8gdmFsaWRhdGUgbXVsdGlwbGUgYmluZGVyczsNCj4+ICAgIHJhdGhlciB0aGV5 IFNIT1VMRCBzZWxlY3QgYSBzaW5nbGUgUFNLIGFuZCB2YWxpZGF0ZSBzb2xlbHkgdGhlIGJpbmRl cg0KPj4gICAgdGhhdCBjb3JyZXNwb25kcyB0byB0aGF0IFBTSy4NCj4+DQo+PiA+IC1Fa3INCj4+ ID4NCj4+ID4gYXQgdGhlIHNhbWUgdGltZSwgdGhleSAiU0hPVUxEIHNlbGVjdCBhcyBzaW5nbGUg UFNLIGFuZCB2YWxpZGF0ZSBzb2xlbHkNCj4+ID4gdGhlDQo+PiA+DQo+PiA+ID4gYmluZGVyIHRo YXQgY29ycmVzcG9uZHMgdG8gdGhhdCBQU0siDQo+PiA+ID4gKFBhZ2UgNjAsIGRyYWZ0LWlldGYt dGxzLXRsczEzLTI0KS4NCj4+ID4gPg0KPj4gPiA+IFRoYXQgYWxsb3dzIGZvciB0cml2aWFsIGVu dW1lcmF0aW9uIG9mIGV4dGVybmFsbHkgZXN0YWJsaXNoZWQNCj4+ID4gPiBpZGVudGl0aWVzIC0N Cj4+ID4gPiB0aGUNCj4+ID4gPiBhdHRhY2tlciBqdXN0IG5lZWRzIHRvIHNlbmQgdG8gdGhlIHNl cnZlciBhIGxpc3Qgb2YgaWRlbnRpdHkgZ3Vlc3NlcywNCj4+ID4gPiB3aXRoDQo+PiA+ID4gcmFu ZG9tIGRhdGEgYXMgYmluZGVycywgaWYgdGhlIHNlcnZlciByZWNvZ25pc2VzIGFueSBpZGVudGl0 eSBpdCB3aWxsDQo+PiA+ID4gYWJvcnQNCj4+ID4gPiBjb25uZWN0aW9uLCBpZiBpdCBkb2Vzbid0 LCBpdCB3aWxsIGNvbnRpbnVlIHRvIGEgbm9uLVBTSyBoYW5kc2hha2UuDQo+PiA+ID4NCj4+ID4g PiBCZWhhdmlvdXIgbGlrZSB0aGlzIGlzIGdlbmVyYWxseSBjb25zaWRlcmVkIGEgdnVsbmVyYWJp bGl0eToNCj4+ID4gPiBodHRwczovL2N2ZS5taXRyZS5vcmcvY2dpLWJpbi9jdmVuYW1lLmNnaT9u YW1lPUNWRS0yMDAzLTAxOTANCj4+ID4gPiBodHRwczovL2N2ZS5taXRyZS5vcmcvY2dpLWJpbi9j dmVuYW1lLmNnaT9uYW1lPUNWRS0yMDA2LTUyMjkNCj4+ID4gPg0KPj4gPiA+IEkgd2FzIHdvbmRl cmluZyBpZiB0aGUgZG9jdW1lbnQgc2hvdWxkbid0IHJlY29tbWVuZCBpZ25vcmluZyBhbnkgYW5k DQo+PiA+ID4gYWxsDQo+PiA+ID4gaWRlbnRpdGllcyBmb3Igd2hpY2ggYmluZGVycyBkbyBub3Qg dmVyaWZ5IHRvIHByZXZlbnQgdGhpcyBraW5kIG9mDQo+PiA+ID4gYXR0YWNrLg0KPj4gPiA+IC0t DQo+PiA+ID4gUmVnYXJkcywNCj4+ID4gPiBIdWJlcnQgS2FyaW8NCj4+ID4gPiBTZW5pb3IgUXVh bGl0eSBFbmdpbmVlciwgUUUgQmFzZU9TIFNlY3VyaXR5IHRlYW0NCj4+ID4gPiBXZWI6IHd3dy5j ei5yZWRoYXQuY29tDQo+PiA+ID4gUmVkIEhhdCBDemVjaCBzLnIuby4sIFB1cmt5xYhvdmEgMTE1 LCA2MTIgMDAgIEJybm8sIEN6ZWNoIFJlcHVibGljDQo+PiA+ID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4gPiBUTFMgbWFpbGluZyBsaXN0DQo+ PiA+ID4gVExTQGlldGYub3JnDQo+PiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90bHMNCj4+DQo+Pg0KPj4gLS0NCj4+IFJlZ2FyZHMsDQo+PiBIdWJlcnQgS2FyaW8N Cj4+IFNlbmlvciBRdWFsaXR5IEVuZ2luZWVyLCBRRSBCYXNlT1MgU2VjdXJpdHkgdGVhbQ0KPj4g V2ViOiB3d3cuY3oucmVkaGF0LmNvbQ0KPj4gUmVkIEhhdCBDemVjaCBzLnIuby4sIFB1cmt5xYhv dmEgMTE1LCA2MTIgMDAgIEJybm8sIEN6ZWNoIFJlcHVibGljDQo+DQo+DQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpU TFNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQoK RHlzb24gVGVjaG5vbG9neSBMaW1pdGVkLCBjb21wYW55IG51bWJlciAwMTk1OTA5MCwgVGV0YnVy eSBIaWxsLCBNYWxtZXNidXJ5LCBTTjE2IDBSUCwgVUsuClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRl ZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWUgYW5kIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBp bmZvcm1hdGlvbi4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBw bGVhc2UgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSBpdCwgYW5kIGRvIG5vdCB1 c2UsIGNvcHkgb3IgZGlzY2xvc2UgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1l c3NhZ2Ugb3IgaW4gYW55IGF0dGFjaG1lbnQuCkR5c29uIG1heSBtb25pdG9yIGVtYWlsIHRyYWZm aWMgZGF0YSBhbmQgY29udGVudCBmb3Igc2VjdXJpdHkgJiB0cmFpbmluZy4K From nobody Thu Feb 22 02:49:54 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125BE126B72; Thu, 22 Feb 2018 02:49:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 MVYlaQ8kWa5U; Thu, 22 Feb 2018 02:49:45 -0800 (PST) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9F981242F5; Thu, 22 Feb 2018 02:49:44 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 22D287C81F; Thu, 22 Feb 2018 10:49:44 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTP id 403BE2026E04; Thu, 22 Feb 2018 10:49:39 +0000 (UTC) From: Hubert Kario To: Martin Thomson Cc: Eric Rescorla , draft-ietf-tls-tls13@ietf.org, "" , IETF discussion list Date: Thu, 22 Feb 2018 11:49:33 +0100 Message-ID: <1539403.0ddWoG7Tox@pintsize.usersys.redhat.com> In-Reply-To: References: <151880080195.1349.14035524657942875385.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart12560930.LqIdlgQPAG"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Thu, 22 Feb 2018 10:49:44 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Thu, 22 Feb 2018 10:49:44 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] external PSK identity enumeration Re: UPDATED Last Call: (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 10:49:47 -0000 --nextPart12560930.LqIdlgQPAG Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thursday, 22 February 2018 00:22:35 CET Martin Thomson wrote: > I think that the current behavior is fine, but we might add text to > suggest that identities be self-authenticating to avoid this sort of > enumeration. Note that in common practice, this sort of enumeration > would be over an infeasibly large space, it's only where identities > are more easily enumerable that it becomes an issue (e.g., "ted" as an > identity, rather than a self-encrypted session ticket) that's why the subject is saying "external PSK", and those can be as simple= as=20 "ted", "admin", "mary"... yes, session tickets ("resumption PSK") SHOULD be self-authenticating, if o= nly=20 because non authenticated ciphertext is malleable > On Thu, Feb 22, 2018 at 1:31 AM, Eric Rescorla wrote: > > i think your general point is sound here, but I'll nitpick the statement > > that > > "if the server recognises an identity but is unable to verify > > corresponding > > binder". > >=20 > > 1. The server only picks one identity so you if you send A, B, and C and > > you get an abort, you don't know if it recognized one or all. > > 2. The server can *recognize* the identity but ignore it (say it's a > > ticket > > that's > > too old) > >=20 > > With that said, I think it would probably be safe to say you must ignore > > an > > identity > > where the binder doesn't validate, but I'd like to hear from > > cryptographers > > on this > > one. > >=20 > > Thanks, > > -Ekr > >=20 > > On Wed, Feb 21, 2018 at 6:26 AM, Hubert Kario wrote: > >> On Wednesday, 21 February 2018 15:21:58 CET Eric Rescorla wrote: > >> > On Wed, Feb 21, 2018 at 6:13 AM, Hubert Kario =20 wrote: > >> > > On Friday, 16 February 2018 18:06:41 CET The IESG wrote: > >> > > > The IESG has received a request from the Transport Layer Security > >> > > > WG > >> > >=20 > >> > > (tls) > >> > >=20 > >> > > > to consider the following document: - 'The Transport Layer Secur= ity > >> > > > (TLS) > >> > > > Protocol Version 1.3' > >> > > >=20 > >> > > > as Proposed Standard > >> > >=20 > >> > > The current draft states that if the server recognises an identity > >> > > but > >> > > is > >> > > unable to verify corresponding binder, it "MUST abort the handshak= e" > >> >=20 > >> > Which text are you referring to here? > >>=20 > >> Section 4.2.11: > >> Prior to accepting PSK key establishment, the server MUST validate > >> the corresponding binder value (see Section 4.2.11.2 below). If th= is > >> value is not present or does not validate, the server MUST abort the > >> handshake. Servers SHOULD NOT attempt to validate multiple binders; > >> rather they SHOULD select a single PSK and validate solely the bind= er > >> that corresponds to that PSK. > >> >=20 > >> > -Ekr > >> >=20 > >> > at the same time, they "SHOULD select as single PSK and validate sol= ely > >> > the > >> >=20 > >> > > binder that corresponds to that PSK" > >> > > (Page 60, draft-ietf-tls-tls13-24). > >> > >=20 > >> > > That allows for trivial enumeration of externally established > >> > > identities - > >> > > the > >> > > attacker just needs to send to the server a list of identity guess= es, > >> > > with > >> > > random data as binders, if the server recognises any identity it w= ill > >> > > abort > >> > > connection, if it doesn't, it will continue to a non-PSK handshake. > >> > >=20 > >> > > Behaviour like this is generally considered a vulnerability: > >> > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2003-0190 > >> > > https://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2006-5229 > >> > >=20 > >> > > I was wondering if the document shouldn't recommend ignoring any a= nd > >> > > all > >> > > identities for which binders do not verify to prevent this kind of > >> > > attack. > >> > > -- > >> > > Regards, > >> > > Hubert Kario > >> > > Senior Quality Engineer, QE BaseOS Security team > >> > > Web: www.cz.redhat.com > >> > > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Repu= blic > >> > > _______________________________________________ > >> > > TLS mailing list > >> > > TLS@ietf.org > >> > > https://www.ietf.org/mailman/listinfo/tls > >>=20 > >> -- > >> Regards, > >> Hubert Kario > >> Senior Quality Engineer, QE BaseOS Security team > >> Web: www.cz.redhat.com > >> Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart12560930.LqIdlgQPAG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlqOoD0ACgkQkqjRuAHS 9fXGxg//UqVaOWuWhXULfnuFC4iyV2sp0fM3KDc+vrJX8QzEfNYgL7bmuqsR/w4u iXTGf0jbudck5Y/k+h3wBfW4kWzCV5Do8M/FWqXuKQeAWX2SAN3583olc3yWkDEo LumFOpVRkFMDm8fzuEAi4DdZE2TsVczqP+ioVIR1z/VJ4hHtDedvi2XSlXAkuFMV jArueqlaSa3KIL8hH1LBRVUYLvJ1As5mFY+YLeEK1scaI0nyuUtpS33liyYMzdRz 5jTAAu7ripetAKDBn6steDiu/lqsBd0J3c7SGxGdgiGv4sE/FyUnrUiCocUnoY7v rfkiI2ogI8oc5t/rRAagOz7jtbY4cM9iYi+ePjrrfihGZvxVk82uKXHZL7pUxlH7 +lC7oH4KXN9X9imKHJISCi8AELnJc9vQBKV4yxANVCdsOOtPhf1D0tiBSEESZFhA 8V2P1TlMIqmfEa2sHuOVtM/XXKBToeGG8Q42gi7X+EmEWTY6xK1/y4w8s8ne9Sr6 BlIlwsscElgI4lT3/qUsCA3BleGb7/iJLnSf2SDIteHlRrP17l6qgwbYstqNthY7 EsN+cef+qw8jiwUf257zK7ybMW+6Nkq2XSMEDAP6E+WA97tUE1OBQ+Jvaf6ZMBjw fsUDXhd/X12Pnfa6YjSE7juDmcvF4jvZq8XJm9hPxWWC9Rkzw0o= =MPRq -----END PGP SIGNATURE----- --nextPart12560930.LqIdlgQPAG-- From nobody Thu Feb 22 07:44:55 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23DBB12D7F2; Thu, 22 Feb 2018 07:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 USzc5pSAahD3; Thu, 22 Feb 2018 07:44:52 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E857212741D; Thu, 22 Feb 2018 07:44:51 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id t22so6460649iob.3; Thu, 22 Feb 2018 07:44:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q/pYiT0v1rDqBRiIZ9E5Bda7OGkgMbcD1fXU8zCTFbg=; b=ZxllBV4NSFVYXuCqfaiYKesHFkVx6IZQH4k/9YSctstAI7n8O9DePXr4Nk5tlR+ong ZmDlZzTBaizqV/gnjRDCSHJBKx8U3dErimWsbGG5q91YwhzKFBQ7rgf5Of1nXnTernea jtlrWwGtCgnv2gLOthNuy+cVnPaU4kmzRx43oOI7fjiIX+q0Vv61wlIdfUQMHbMOi7f8 OCNUvDhzWGkroltiYOAaV0GLogcVLpEaXvZ+qUVRTmJaut/+ZX74BJwE9hwtBjSNe8Pc UwlRBe8rXWgBm5ny5iFiYAAwt86n19cxmESpgesnUcg5lvZNhUKBLuuQ5yy6RPji2P9T DCog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q/pYiT0v1rDqBRiIZ9E5Bda7OGkgMbcD1fXU8zCTFbg=; b=hpf1rdGRWREcB9Gl/wSbFHulzSzrI8P1MGPNZoLj4zyAUGcuwfWtTXEmecccSOhjMD oGmELjc/jXj8dMUD/qNa15KWiByt7AwxEa4zWdGQhO/3VZpyDhEp3CzGpJja06wyaY6V bPmT+3ac22wwQJDH0/gHa+YVBN+OUHjKyYIaD8fJZ97fXiR2ByVUQ3uI7pK2e0kl43On LM3IO9hpnS4z15k147ZNAjrk8SQVwfuYhnl0WB4nbJaI3wZoYfES5H3VfzfsDn9+4Vjp ADL5YJtSX82OCt14Qif9uLl5xlG/GPClCUdyZk+AFv4UW6WQJqJPp6ukJ7rFG1veiwcF A15w== X-Gm-Message-State: APf1xPB86OU2XRphbVUqEOp0eJEK3nkf+3yM5ePYMSFvLshfm7CpQy7r VxY/DQxad8OvOyiFB6AMKNsSy0H1JR4bA23+j1A= X-Google-Smtp-Source: AG47ELuweQ63RWoDSEd3ETfSYWF812TcIt6j9BdwdFXQQ7+9cV+A4dp2ej7AOkmMT8E+pFHKTiEnouecGTjkcfluSns= X-Received: by 10.107.137.104 with SMTP id l101mr9275223iod.179.1519314291148; Thu, 22 Feb 2018 07:44:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.201.198 with HTTP; Thu, 22 Feb 2018 07:44:50 -0800 (PST) In-Reply-To: References: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com> From: Shumon Huque Date: Thu, 22 Feb 2018 10:44:50 -0500 Message-ID: To: Paul Wouters Cc: Eric Rescorla , TLS WG , draft-ietf-tls-dnssec-chain-extension@ietf.org, The IESG , tls-chairs Content-Type: multipart/alternative; boundary="001a113eb134a052420565ceeca8" Archived-At: Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 15:44:54 -0000 --001a113eb134a052420565ceeca8 Content-Type: text/plain; charset="UTF-8" On Wed, Feb 21, 2018 at 2:48 PM, Paul Wouters wrote: > On Wed, 21 Feb 2018, Shumon Huque wrote: > > Okay, got it. For people that have already implemented this, I think >> there has been an implicit understanding that the format of the chain >> data is a sequence of concatenated wire format RRs exactly as they appear >> in a DNS message section >> > > Note, I would not call it "sequence of concatenated wire format RRs", as > it is simply the wireformat of a DNS message. The fact that some parts > are concatenated RR's is just part of the wireformat of the DNS reply > message. That is, this isn't introducing some new form of concatenated > content - it is _just_ a regular DNS wire format message, and the > document should not go deeper into its explanation. > It would _not_ be correct to say that this is a "DNS wire format message" - that would mean there is a DNS header section with flags and response codes, and other sections. The chain data structure as currently specified really is concatenated wire-format RRs (as they appear _within_ a DNS message _section_). Let me know if that is unclear in the draft (or my proposed edits). I recall at one point way back there was a discussion about whether the chain data should just be a fully formed DNS message, but I don't believe that idea had much support in the working group (personally I would have been fine with that choice too, if it did have support). > I noticed some discussion about the ordering of this content. I am not > sure why that should be done. DNS doesn't care about the order, and > neither should producers or consumers of this extension. DNS has no > ordering inside its message. > Yes, that is in fact where we ended up, roughly. The draft does currently say that the answer record(s) appear first. And then the authentication chain records follow and that TLS client should be prepared to receive the authentication chain records in any order. Requiring the answer records first seems logical to me - it is what existing libraries do, and also what the EDNS chain query spec does (answer records appear first in the ANSWER section, and DNSSEC authentication chain records appear in the AUTHORITY section in any order). There is some residual wording in the draft about ordering of CNAMEs etc in the answer records part. Assuming the WG agrees, I am fine with relaxing that requirement - that ended up in there because although there is no defined ordering of RRs within a DNS message section, as a practical matter CNAMEs are almost always ordered since there are some DNS queriers that get confused otherwise. This is a new protocol though, so we can be more faithful to the DNS spec. I don't think getting unrelated DNSSEC records would be an issue. TLS > has its maximum sizes for the handshake. In fact, it could allow the > extension to have some useful data in the case of MX or SRV. (and could > be a feature to build a nice resolver over TLS using 1 tor circuit). > The draft currently doesn't address the MX or SRV use case. I suggest that we tackle that in a future version. I'm also not sure about the talking of unsigned CNAME records from > DNAME. The above pseudo code (extended with special cases) should be > in some DNS library, and that library will know what records to expect > unsigned which are proven by the DNAME (or wildcard) synthesis and knows > when/if to add it to the validated cache. I don't think that should be > explained in this RFC at all. The DNS implementation does not need > to be specified in this document and it should just focus on saying > that "the DNS message response is validated and upon validation the > content can be considered DANE validated". Where we ended up, is that WG participants asked for some level of DNSSEC detail to be included in this doc. Shumon. --001a113eb134a052420565ceeca8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 21, 2018 at 2:48 PM, Paul Wouters <paul@nohats.ca> wrot= e:
On Wed, 21 Feb 2018, = Shumon Huque wrote:

Okay, got it. For people that have already implemented this, I think
there has been an implicit understanding that the format of the chain
data is a sequence of concatenated wire format RRs exactly as they appear in a DNS message section

 Note, I would not call it "sequence of concatenated wire format RRs&qu= ot;, as
it is simply the wireformat of a DNS message.
The fact that some parts
are concatenated RR's is just part of the wireformat of the DNS reply message. That is, this isn't introducing some new form of concatenated<= br> content - it is _just_ a regular DNS wire format message, and the
document should not go deeper into its explanation.
It would _not_ be correct to say that this is a "DNS wire= format message" - that=C2=A0
would mean there is a DNS head= er section with flags and response codes,=C2=A0
and other section= s. The chain data structure as currently specified really is=C2=A0
concatenated wire-format RRs (as they appear _within_ a DNS message=C2=A0=
_section_). Let me know if that is unclear in the draft (or my p= roposed edits).

I recall at one point way back the= re was a discussion about whether the chain
data should just be a= fully formed DNS message, but I don't believe that idea
had = much support in the working group (personally I would have been fine with= =C2=A0
that choice too, if it did have support).
=C2=A0=
I noticed some discussion about the ordering of this content. I am not
sure why that should be done. DNS doesn't care about the order, and
neither should producers or consumers of this extension. DNS has no
ordering inside its message.

Yes, that = is in fact where we ended up, roughly.

The draft d= oes currently say that the answer record(s) appear first. And then
the authentication chain records follow and that TLS client should be pre= pared
to receive the authentication chain records in any order.= =C2=A0

Requiring the answer records first seems lo= gical to me - it is what existing=C2=A0
libraries do, and also wh= at the EDNS chain query spec does (answer records=C2=A0
appear fi= rst in the ANSWER section, and DNSSEC authentication chain records
appear in the AUTHORITY section in any order).

T= here is some residual wording in the draft about ordering of CNAMEs etc in<= /div>
the answer records part. Assuming the WG agrees, I am fine with r= elaxing
that requirement - that ended up in there because althoug= h there is no defined
ordering of RRs within a DNS message sectio= n, as a practical matter CNAMEs
are almost always ordered since t= here are some DNS queriers that get confused=C2=A0
otherwise. Thi= s is a new protocol though, so we can be more faithful to the DNS=C2=A0
spec.

I don't think getting unrelated DNSSEC records would be an issue. TLS has its maximum sizes for the handshake. In fact, it could allow the
extension to have some useful data in the case of MX or SRV.=C2=A0 (and cou= ld
be a feature to build a nice resolver over TLS using 1 tor circuit).

The draft currently doesn't address the M= X or SRV use case. I suggest
that we tackle that in a future vers= ion.

I'm also not sure about the talking of unsigned CNAME records from
DNAME. The above pseudo code (extended with special cases) should be
in some DNS library, and that library will know what records to expect
unsigned which are proven by the DNAME (or wildcard) synthesis and knows when/if to add it to the validated cache. I don't think that should be<= br> explained in this RFC at all. The DNS implementation does not need
to be specified in this document and it should just focus on saying
that "the DNS message response is validated and upon validation the content can be considered DANE validated".

=
Where we ended up, is that WG participants asked for some level of DNS= SEC
detail to be included in this doc.

S= humon.

--001a113eb134a052420565ceeca8-- From nobody Thu Feb 22 08:00:05 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228AC12D7F4; Thu, 22 Feb 2018 07:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 d9AyWW0p3TbD; Thu, 22 Feb 2018 07:59:57 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6666512741D; Thu, 22 Feb 2018 07:59:57 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id e7so6525773ioj.1; Thu, 22 Feb 2018 07:59:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nTa68OWoQSWYpfv8028TFTTK/3MJzzzeMYCV4NHAcgs=; b=obpSab7A8/I3Sgn9IgN97uyfzGfoj5rzjsyWQ4RSGEHueAvBnyKfd+0y8e2csE/bZ2 YA7WE0I64xlkC22outMFlooDn5adW9SgtBw7l/2IjqLnUJ4JXwPrm+bCXOwXUOoirwoS Na2Usn3cvJLSNAXfuf3pICOjfc5dm7eafLlCZyEfMmvbNhM6qcyTDIPy96kBPakLFIM9 JUxPO2ZmyPBdYJKw94s50esEwLfXETabGkhyHsGycEjnpfLzIIyNTL0kFlVECBwuQ9qp SJZq8ggabfSQQPGRKzi95p0KuG0xbTcjz2r+mpzTgviBDeaPBQloUPyibh0qkEpUQ8BB s15A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nTa68OWoQSWYpfv8028TFTTK/3MJzzzeMYCV4NHAcgs=; b=jT7t0RurGXMtSxi2W+2Fia9hFGg9SK73TuUsvgydnIEMd48t4XNRMoV6n2VZ/4jnM2 v1+/GgA/DnaoMGtup+dGwQwGpuHyJWKiBSff1oz0FrHL5VoiuWX0RyBgHA+cuFDsCH61 6LpnPC1rx5/r5+aFnEDeKxEIucg0kawdf+cPQXG5TCVEhkN0Dm2vZwq91Bz+6qiDXcOc xS2MHsQHQatiN2QpilSM0cofHiw0rH73A/yfBGKkb3O2xOJ+HyDz3KrRymhffRxULf+d WWp0zP5roJEBhuZkv7UAg4XH1VUJx9uGE09kxppGT08Yv/tRJUc7uqmwfS0UXqfaK+AT g6ng== X-Gm-Message-State: APf1xPBR22cDKRkimelBPCB274sAjFlOlxVGmjjPAyz9Ks1nILon924N bg2N3uXKSHIqhVIKTINUBla971WN1iVPQVpWYqw= X-Google-Smtp-Source: AG47ELsO30tqzVfgaBVpGEPHM8QvYjnxtA9Gtcxg98NUK81ees5UYnk99uZ2aQVXD546j106parevYzlY/kdPwyPh+0= X-Received: by 10.107.137.104 with SMTP id l101mr9337839iod.179.1519315196730; Thu, 22 Feb 2018 07:59:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.201.198 with HTTP; Thu, 22 Feb 2018 07:59:56 -0800 (PST) In-Reply-To: <0FA4B497-4B9A-421B-A9A6-2FEB62D3E41A@dukhovni.org> References: <151800968634.4877.12510609339415982154.idtracker@ietfa.amsl.com> <4c90bb83-5ba1-8193-df67-38e25f76caf8@nlnetlabs.nl> <0FA4B497-4B9A-421B-A9A6-2FEB62D3E41A@dukhovni.org> From: Shumon Huque Date: Thu, 22 Feb 2018 10:59:56 -0500 Message-ID: To: Viktor Dukhovni Cc: TLS WG , tls-chairs , draft-ietf-tls-dnssec-chain-extension@ietf.org, The IESG Content-Type: multipart/alternative; boundary="001a113eb1349a85440565cf22ca" Archived-At: Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-dnssec-chain-extension-06=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 15:59:59 -0000 --001a113eb1349a85440565cf22ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 21, 2018 at 1:49 PM, Viktor Dukhovni wrote: > > > > On Feb 21, 2018, at 11:00 AM, Shumon Huque wrote: > > > > On Tue, Feb 13, 2018 at 5:50 PM, Martin Thomson < > martin.thomson@gmail.com> wrote: > > On Wed, Feb 14, 2018 at 4:07 AM, Kathleen Moriarty > > wrote: > > > What's the behavior when the middlebox is a proxy, let's say existing > > > a managed network? I presume from from section 3.1 that this > > > negotiation doesn't work in that instance unless sites configured for > > > this are not subject to the proxy as is often done for financial site > > > access from corporate networks. It would be good to know if it does > > > work and that is addressed with the text Mirja calls out for her #1 > > > question. Having this clarified could be helpful. > > > > If there is a MitM, then this extension simply isn't negotiated. > > That's pretty well understood. I don't see why that requires special > > mention. > > > > Yeah, I agree Martin .. this is the same as with any other extension. > > Actually, I don't think it is quite the same. I meant same in the sense that if any extension is blocked then it can't be used. What the effect of that is depends obviously on what functionality the extension is providing. The TLS client can at least detec= t such blocking/stripping, and alert the application or fallback to something else. Have other TLS extension specs gone into the details of middlebox impacts? > This extension may > be na=C3=AFvely expected to provide a different peer authentication > mechanism than the traditional WebPKI. Users who might expect this > extension to protect them from WebPKI compromise via DANE TLSA > records, need to understand that such protection only exists when > DANE is enforced (mandatory) by the client. > > The absence of DANE TLSA records, which is downgrade-resistant > when the client has access to DNSSEC authenticated denial of > existence (makes its own DNSSEC lookups) is no longer downgrade- > resistant when delivered via this extension if the client > is willing to accept just WebPKI in the (apparent) absence of DANE > TLSA records. > Some of this is already discussed or at least implicit in the draft. If you want to propose specific text to add or modify, please do so .. Shumon. --001a113eb1349a85440565cf22ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 21, 2018 at 1:49 PM, Viktor Dukhovni <viktor@dukhovni.org&g= t; wrote:


> On Feb 21, 2018, at 11:00 AM, Shumon Huque <shuque@gmail.com> wrote:
>
> On Tue, Feb 13, 2018 at 5:50 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> On Wed, Feb 14, 2018 at 4:07 AM, Kathleen Moriarty
> <kathleen.moria= rty.ietf@gmail.com> wrote:
> > What's the behavior when the middlebox is a proxy, let's = say existing
> > a managed network?=C2=A0 I presume from from section 3.1 that thi= s
> > negotiation doesn't work in that instance unless sites config= ured for
> > this are not subject to the proxy as is often done for financial = site
> > access from corporate networks.=C2=A0 It would be good to know if= it does
> > work and that is addressed with the text Mirja calls out for her = #1
> > question.=C2=A0 Having this clarified could be helpful.
>
> If there is a MitM, then this extension simply isn't negotiated. > That's pretty well understood.=C2=A0 I don't see why that requ= ires special
> mention.
>
> Yeah, I agree Martin .. this is the same as with any other extension.<= br>
Actually, I don't think it is quite the same.
<= br>
I meant same in the sense that if any extension is blocked th= en it
can't be used. What the effect of that is depends obvio= usly on what
functionality the extension is providing. The TLS cl= ient can at least detect
such blocking/stripping, and alert the a= pplication or fallback to something=C2=A0
else.

Have other TLS extension specs gone into the details of middlebox= =C2=A0
impacts?
=C2=A0
=C2=A0 This extension may
be na=C3=AFvely expected to provide a different peer authentication
mechanism than the traditional WebPKI.=C2=A0 Users who might expect this extension to protect them from WebPKI compromise via DANE TLSA
records, need to understand that such protection only exists when
DANE is enforced (mandatory) by the client.

The absence of DANE TLSA records, which is downgrade-resistant
when the client has access to DNSSEC authenticated denial of
existence (makes its own DNSSEC lookups) is no longer downgrade-
resistant when delivered via this extension if the client
is willing to accept just WebPKI in the (apparent) absence of DANE
TLSA records.
=C2=A0
Some of this is already= discussed or at least implicit in the draft.
If you want to prop= ose specific text to add or modify, please do so ..

Shumon.

--001a113eb1349a85440565cf22ca-- From nobody Thu Feb 22 08:09:10 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E1F12D7F1; Thu, 22 Feb 2018 08:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 3rH-bEBQ7JxW; Thu, 22 Feb 2018 08:09:01 -0800 (PST) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 325F812D7F4; Thu, 22 Feb 2018 08:08:54 -0800 (PST) Received: by mail-ot0-x22a.google.com with SMTP id 79so5049942oth.11; Thu, 22 Feb 2018 08:08:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=e6MRrLC7mAXaVbiZQCds1mpFN1OZipLIN2WALf0EwBQ=; b=R93fVELpXa+rXRRcdVIc7fnr0NW4jIm8u90PryqRvrBO9+iAnnyAPIjZv04/GO14Ke KO+KWFeobVVhAjFgeuBTKW1Xz2+Z64PIZxO4IU5ZB/5pjhfERxeHIuB+MsPC5GqSgHc1 kzOsaMd2q5p4fAv5QH3jxClOB+QaOZtU/DdJYctExWXJ0SLYNRBEBWLCIseRfdnGRRFh 74Nq18MJVLa9oLak4hI6N3BHDx/bbxK3EKhLvR3NhumytoE/oIRaglLjCE5jy0mZWMwd EjjGmeMJWXI16UzIHFPTQz8Y2DDGX/v7UTfDNbfJ/HWcsjPEIWHsfuOjrinUz9Gw2GCZ dDQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=e6MRrLC7mAXaVbiZQCds1mpFN1OZipLIN2WALf0EwBQ=; b=jnqRzopCm+iohe1Y/2n4DSo36lv69KwkzzHeRqu0AJuodZKiv/Oo+/gF/Yn0IdCZfT KjtOVyf5o+OG8Cy3OP30giH2dsYhclVABbbSZFMjsoCfFAtRORtmGhKPFxb1t/9WhI8Q Yqdjd8Lq0Mg1mNTPnsb+Ss3hkjty49sF4UrT7q59rtw9bFVAX4A8HFH64aQXsmH4OhuI dHi41JRpIqctnXzb65ewPceF8lL46XHXClw2h8dQoOYcwNBn2I+b4gGNbue18dgWDk5z XaJA+j+9T90SMikQ/9NQzaIq+YU4MMW9ceXIaKY9UwkKFrpQB/8tMiVl0oJhuGDOTT9w 6F+g== X-Gm-Message-State: APf1xPBMU3/UqtlqzplGbEbFih/RZ1zwHUtIRIPGLLrfllAiLGttprK/ OqSE/tThYxjZ7setKs5vc+F5HJ30npLzM+kQPKA= X-Google-Smtp-Source: AH8x224j51NWEFUoUBrhvyMApZHyPF02bMI2jSlh4cK7/pmJqx2krKDXlhg5/UjTYpoTAD+d5NRmhufzw39G1236YEo= X-Received: by 10.157.11.199 with SMTP id 65mr5362131oth.40.1519315733472; Thu, 22 Feb 2018 08:08:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.46.119 with HTTP; Thu, 22 Feb 2018 08:08:13 -0800 (PST) In-Reply-To: References: <151800968634.4877.12510609339415982154.idtracker@ietfa.amsl.com> <4c90bb83-5ba1-8193-df67-38e25f76caf8@nlnetlabs.nl> <0FA4B497-4B9A-421B-A9A6-2FEB62D3E41A@dukhovni.org> From: Kathleen Moriarty Date: Thu, 22 Feb 2018 11:08:13 -0500 Message-ID: To: Shumon Huque Cc: Viktor Dukhovni , The IESG , draft-ietf-tls-dnssec-chain-extension@ietf.org, TLS WG , tls-chairs Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-dnssec-chain-extension-06=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 16:09:02 -0000 On Thu, Feb 22, 2018 at 10:59 AM, Shumon Huque wrote: > On Wed, Feb 21, 2018 at 1:49 PM, Viktor Dukhovni > wrote: >> >> >> >> > On Feb 21, 2018, at 11:00 AM, Shumon Huque wrote: >> > >> > On Tue, Feb 13, 2018 at 5:50 PM, Martin Thomson >> > wrote: >> > On Wed, Feb 14, 2018 at 4:07 AM, Kathleen Moriarty >> > wrote: >> > > What's the behavior when the middlebox is a proxy, let's say existin= g >> > > a managed network? I presume from from section 3.1 that this >> > > negotiation doesn't work in that instance unless sites configured fo= r >> > > this are not subject to the proxy as is often done for financial sit= e >> > > access from corporate networks. It would be good to know if it does >> > > work and that is addressed with the text Mirja calls out for her #1 >> > > question. Having this clarified could be helpful. >> > >> > If there is a MitM, then this extension simply isn't negotiated. >> > That's pretty well understood. I don't see why that requires special >> > mention. >> > >> > Yeah, I agree Martin .. this is the same as with any other extension. >> >> Actually, I don't think it is quite the same. > > > I meant same in the sense that if any extension is blocked then it > can't be used. What the effect of that is depends obviously on what > functionality the extension is providing. The TLS client can at least det= ect > such blocking/stripping, and alert the application or fallback to somethi= ng > else. > > Have other TLS extension specs gone into the details of middlebox > impacts? This one is a little different though as end users are expecting e2e without interference with this extension. Understanding the behavior is important for administrators and users as Viktor stated. Best regards, Kathleen > >> >> This extension may >> be na=C3=AFvely expected to provide a different peer authentication >> mechanism than the traditional WebPKI. Users who might expect this >> extension to protect them from WebPKI compromise via DANE TLSA >> records, need to understand that such protection only exists when >> DANE is enforced (mandatory) by the client. >> >> The absence of DANE TLSA records, which is downgrade-resistant >> when the client has access to DNSSEC authenticated denial of >> existence (makes its own DNSSEC lookups) is no longer downgrade- >> resistant when delivered via this extension if the client >> is willing to accept just WebPKI in the (apparent) absence of DANE >> TLSA records. > > > Some of this is already discussed or at least implicit in the draft. > If you want to propose specific text to add or modify, please do so .. > > Shumon. > --=20 Best regards, Kathleen From nobody Thu Feb 22 08:11:12 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9081F1270AB; Thu, 22 Feb 2018 08:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 u2Ab624lKPXA; Thu, 22 Feb 2018 08:11:08 -0800 (PST) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2216012741D; Thu, 22 Feb 2018 08:11:08 -0800 (PST) Received: by mail-it0-x235.google.com with SMTP id a75so6805065itd.0; Thu, 22 Feb 2018 08:11:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q0hTrRqYptFUfCumemJ6c+VN1c/tocmkBc/YvOAxVNI=; b=Yx1eSkMAHOA71rXmaJVnSj6BTejZC3ZPY+Y5CSU2venGtvowFcLl3ONy8d+e2FHnY6 DkICg9P+dLOYOqiea1YlYFTTx9fil9jD9QSfKm4B0JMxyjy/3BpvDS2VTMxQ7ev+fmTk LX46RqnChwobWXfqAlWWu7wciONfNdD0KspmqMfmbXpiWC4RM3QnIKyTiA3ejfb+hVKJ nDLrfS13stakSx+dviJob+6onOMNFo+Sq1ugfNuyxhUNANqhmESpPtE3R0eU3MzD1KkW B80gxvcSwbu9/BgEeLD5WDtzXT+fXNMuulUAeHAL/RMMzdk32BjCR7IOxba8qiU9nR6n 3D4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q0hTrRqYptFUfCumemJ6c+VN1c/tocmkBc/YvOAxVNI=; b=R619uZnLsgGMmrw3zJGbQAmHXdhWxAe4GitWdIswDNM33wDnZhBdM517Bp0hK/cuxL hVxyOF3tqXcsWqfZTZDht66dn32kS9nnqrRG+X0AYLhFZ/cPPKvLRlhZjq1Mw/99BoKG FSig1j6aeQXvk6d1OMbxEExFS1b6JxzueqD9RL1XWBNW8BmD5O1aKgXRizF3XUL/CGOJ kMvzf1T7WW0+xnji0h8d2S/RqW7u3a+ryOatrVPf+FLPquCWbgaJPGb+kAwFZBjyoZH+ 7kvh+jvRYs/oxlYnYBcO2QJD4DS5yCPpsdOxj1dDJumtf1kH96V/w3hIzQxZjyRfqKuR mxfw== X-Gm-Message-State: APf1xPCGnM10UEdNn7rGX/xXFYErZIcN/CSoBpv3U3+1X1nYA1o83ZAf rmQapDrUYT6X2pRVJUV+g3HeuAB/JBlevkoc/ac= X-Google-Smtp-Source: AH8x226Bq+qgYtlsnF0yDGVZ1mmLIMsNLBGlVlGUiRm7tHeF9C7WW1mJrKY+4kV93P6LyiUqe5ujGYkScaksD5mcDYY= X-Received: by 10.36.118.142 with SMTP id z136mr8244531itb.61.1519315867496; Thu, 22 Feb 2018 08:11:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.201.198 with HTTP; Thu, 22 Feb 2018 08:11:06 -0800 (PST) In-Reply-To: References: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com> From: Shumon Huque Date: Thu, 22 Feb 2018 11:11:06 -0500 Message-ID: To: Eric Rescorla Cc: The IESG , draft-ietf-tls-dnssec-chain-extension@ietf.org, Joseph Salowey , tls-chairs , TLS WG Content-Type: multipart/alternative; boundary="001a113f6ad895754f0565cf4a83" Archived-At: Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 16:11:11 -0000 --001a113f6ad895754f0565cf4a83 Content-Type: text/plain; charset="UTF-8" On Wed, Feb 21, 2018 at 12:51 PM, Eric Rescorla wrote: > > > On Wed, Feb 21, 2018 at 7:52 AM, Shumon Huque wrote: > >> >> My comment was about what DANE mode choices the server is offering to >> the client. Certainly, the client can decide whether it wants to use >> DANE or not, and whether it wants to fallback to PKIX. The protocol >> should probably not be proscriptive here, and allow different TLS >> applications (or configurations of such applications) to make choices. >> But maybe there are some general recommendations to be made. >> > >> One additional comment about PKIX fallback on DANE failure: If a >> server is using DANE-EE or DANE-TA, it has the ability to send back >> a much shorter Certificate message - just the EE certificate for the >> former, and typically a very short X.509 chain for the latter. But >> this means that for fallback to PKIX, the client would have to start >> a new handshake omitting the dnssec_chain extension. For efficient >> fallback within the same handshake, the server would always have to >> send back the full PKIX X.509 chain. Maybe that's what we need to >> recommend for servers that support both DANE and traditional PKIX. >> > > That would be my proposal, but I think at least you need to provide the > kind of analysis you do here. > Okay, I'll include that analysis and recommendation. >> > > Servers receiving a "dnssec_chain" extension in the ClientHello, >> and >> > > > which are capable of being authenticated via DANE, SHOULD return >> a >> > > > serialized authentication chain in the extension block of the >> > > > Why is this a SHOULD where the corresponding reqt for TLS 1.2 and >> below >> > > is a >> > > > MAY? >> > > >> > > They should clearly be consistent. My preference would be "SHOULD" for >> > > both. >> > > >> > >> > That's a WG decision. >> >> Ok. Let me know how you want to handle this question. I'd be happy to >> send a separate note to the WG list about it. >> > > Sorry, I didn't mean to discount your view. I meant that I didn't think it > was > role to say which one it should be. > > This is actually a question for the chairs and the AD (Kathleen). If they > think the > WG decided this, then you can just do "SHOULD". If they think it requires > WG > consultation, then you should do that > Ok. > > > > the draft is adopted by the WG, the authors expect to make an >> early >> > > > allocation request as specified in [RFC7120]. >> > > > Do you want this to be marked RECOMMENDED? >> > > >> > > In response to Mirja's earlier comment, I think we are taking out this >> > > sentence. >> > > >> > >> > You're still registering the code point, so you need to determine if >> it's >> > RECOMMENDED or not. >> >> Sorry for being dense - this protocol requires a new codepoint. Do we >> need to say we RECOMMEND that a new code point be registered? >> >> Or are you asking that we RECOMMEND that IANA allocates our preferred >> extension type value (53)? >> > > No. There is a column in the code point assignment for IANA that says > whether the IETF recommends the use of this extension or whether we're > just assigning the code point but don't recommend it. So you need to say > which one it is. I assume the WG wants "Recommended" > Ah, got it. Since the WG adopted this document, "Recommended" would be my assumption too. I'll start making edits based on issues/comments raised in this thread in the github repo, if folks want to follow along, and/or participate: https://github.com/tlswg/dnssec-chain-extension I'll circle back on list when it's ready for review .. Shumon. --001a113f6ad895754f0565cf4a83 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 21, 2018 at 12:51 PM, Eric Rescorla <ekr@rtfm.com> wrot= e:

On Wed, Feb 21, 2018 at 7:52 AM, Shumon Huque <shuque@gmail.c= om> wrote:

My comment was about what DANE mode choices the server is offeri= ng to
the client. Certainly, the client can= decide whether it wants to use
DANE or not= , and whether it wants to fallback to PKIX. The protocol
should probably not be proscriptive here, and allow different= TLS
applications (or configurations of suc= h applications) to make choices.
But maybe = there are some general recommendations to be made.

One additional comment about PKIX fallback on DANE failure: I= f a
server is using DANE-EE or DANE-TA, it = has the ability to send back
a much shorter= Certificate message - just the EE certificate for the
former, and typically a very short X.509 chain for the latter. = But
this means that for fallback to PKIX, t= he client would have to start
a new handsha= ke omitting the dnssec_chain extension. For efficient
fallback within the same handshake, the server would always have= to
send back the full PKIX X.509 chain. Ma= ybe that's what we need to
recommend fo= r servers that support both DANE and traditional PKIX.

That would be my proposal, but I = think at least you need to provide the
kind of analysis you do he= re.

Okay, I'll = include that analysis and recommendation.


>= ; >=C2=A0 =C2=A0 Servers receiving a "dnssec_chain" extension = in the ClientHello, and
> > >=C2= =A0 =C2=A0 which are capable of being authenticated via DANE, SHOULD return= a
> > >=C2=A0 =C2=A0 serialized a= uthentication chain in the extension block of the
> > > Why is this a SHOULD where the corresponding reqt for= TLS 1.2 and below
> > is a
> > > MAY?
= > >
> > They should clearly be = consistent. My preference would be "SHOULD" for
> > both.
> ><= /div>
>
> T= hat's a WG decision.

<= div class=3D"gmail_extra">Ok. Let me know how you want to handle this quest= ion. I'd be happy to
send a separate no= te to the WG list about it.

Sorry, I didn't mean to discount your view. I meant that I di= dn't think it was
role to say which one it should be.

This is actually a question for the chairs and the AD (Ka= thleen). If they think the
WG decided this, then you can just do = "SHOULD". If they think it requires WG
consultation, th= en you should do that

Ok.


> > >=C2=A0 =C2=A0 the draft is adopted by the WG, th= e authors expect to make an early
> >= >=C2=A0 =C2=A0 allocation request as specified in [RFC7120].
> > > Do you want this to be marked RECOMMEN= DED?
> >
> > In response to Mirja's earlier comment, I think we are ta= king out this
> > sentence.
> >
>
=
> You're still registering the code point= , so you need to determine if it's
>= RECOMMENDED or not.

Sorry for being dense - this protocol requires a new = codepoint. Do we=C2=A0
need to say we RECOM= MEND that a new code point be registered?
<= br>
Or are you asking that we RECOMMEND tha= t IANA allocates our preferred
extension ty= pe value (53)?

No.= There is a column in the code point assignment for IANA that says
whether the IETF recommends the use of this extension or whether we'r= e
just assigning the code point but don't recommend it. So yo= u need to say
which one it is. I assume the WG wants "Recomm= ended"

Ah, got= it. Since the WG adopted this document, "Recommended" would
be my assumption too.

I'll start making = edits based on issues/comments raised in this thread in the github=C2=A0
repo, if folks want to follow along, and/or participate:
=
=

I'll circle back on list when it's ready for re= view ..

Shumon.

--001a113f6ad895754f0565cf4a83-- From nobody Thu Feb 22 08:18:03 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A4C127698; Thu, 22 Feb 2018 08:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 osc9OJ6p_vBM; Thu, 22 Feb 2018 08:17:59 -0800 (PST) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFD4A1270AB; Thu, 22 Feb 2018 08:17:59 -0800 (PST) Received: by mail-it0-x22d.google.com with SMTP id p204so6824039itc.4; Thu, 22 Feb 2018 08:17:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QrSVrtpAHa0WIHQCugoz4vEPAEvWXPQPFIhRxaKjBwc=; b=Oqr0xNsCfIZXd3JpbQ/NPah5C/AIYbVdobK0a9/vD81Qr88R+XJpd6VXNZaw03HBG0 wzoGJmFjjfdnzc/mSMG9PkcxngnxMPWvzAOSbGQhkt3ZHC2t4OKzbQnf5sIYQVHhxlJa nRasBy8OINdDOC8saw0/audzcl6Jzq57DvyYDiayKiIjOWr+UN/sOMjyT7R/0LQ8SaWp Xy0NgLfNjziRgG8oqfvu7HpDOhq1MErSZjCe8O/oyEQD1UbZK76rgM7c+yIzPVzLcIP6 KYdW13aCZvPkrc3QM0S/Yx4myH7fTKsFPoc2v6QwQCaj4qhSdxlT9Okxz1QdBnk8l1VJ VTXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QrSVrtpAHa0WIHQCugoz4vEPAEvWXPQPFIhRxaKjBwc=; b=Lno+3GCahE2JVftAdfRegruU96ssN4iBMrW8ApsdsdJcSPm3zFqdCgbzROf6r5YB6u EmEzgCDP1U/Bg255vsHmPBTUwryAwEKzex2vWE5rKkFwJOcV3Q24pdkF5cM8Kv1Hv0sA 5nlaoqeHHMTHSJ3K6LRdmj3OZ3VmvvFLayOqwP3U4LBLDKkEYoR0lSCiG8tmykr7XTE7 tKGjP30td8yetpEAt6Dd8Nm0HLbcM5l6Qj58TK1idLwnOVZkAf4iTodz2iSZDFjszRxQ ZjDMKBRGloZh6gb/9Gt2e5oeh/X7+eRYwYj3l8UfC6lIQla0L5NN2gXT+GSezeurVE1t L4Cw== X-Gm-Message-State: APf1xPBNH4k0jHU6EOTtkpyke55RFMwTB49OCTt+ILV8Kd8FJnBmRdb2 I5G2xt1aKryujBfmhAbMIl1oBBcwM+I4J9yjuPQ= X-Google-Smtp-Source: AH8x227JphCgvgGHDaZ5c4eo79k07YicOD0oLQlNdhqU7+c29AcilH7vbbEcZ4Of5f5UtkXHGfNZW+ceLcny4g2E5IQ= X-Received: by 10.36.127.11 with SMTP id r11mr8261346itc.93.1519316279095; Thu, 22 Feb 2018 08:17:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.201.198 with HTTP; Thu, 22 Feb 2018 08:17:58 -0800 (PST) In-Reply-To: References: <151800968634.4877.12510609339415982154.idtracker@ietfa.amsl.com> <4c90bb83-5ba1-8193-df67-38e25f76caf8@nlnetlabs.nl> <0FA4B497-4B9A-421B-A9A6-2FEB62D3E41A@dukhovni.org> From: Shumon Huque Date: Thu, 22 Feb 2018 11:17:58 -0500 Message-ID: To: Kathleen Moriarty Cc: Viktor Dukhovni , The IESG , draft-ietf-tls-dnssec-chain-extension@ietf.org, TLS WG , tls-chairs Content-Type: multipart/alternative; boundary="001a1147bba61dfbf60565cf6327" Archived-At: Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-dnssec-chain-extension-06=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 16:18:01 -0000 --001a1147bba61dfbf60565cf6327 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 22, 2018 at 11:08 AM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > On Thu, Feb 22, 2018 at 10:59 AM, Shumon Huque wrote: > > On Wed, Feb 21, 2018 at 1:49 PM, Viktor Dukhovni > > > > > Have other TLS extension specs gone into the details of middlebox > > impacts? > > This one is a little different though as end users are expecting e2e > without interference with this extension. Understanding the behavior > is important for administrators and users as Viktor stated. > > Best regards, > Kathleen > Okay Kathleen. We'll add some discussion on this. Viktor - I assume you'll help with text. Shumon. --001a1147bba61dfbf60565cf6327 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 22, 2018 at 11:08 AM, Kathleen Moriarty <kathleen.m= oriarty.ietf@gmail.com> wrote:
On Thu, Feb 22, 2018 at 10:59 A= M, Shumon Huque <shuque@gmail.com> wrote:
> On Wed, Feb 21, 2018 at 1:49 PM, Viktor Dukhovni <viktor@dukhovni.org>

>
> Have other TLS extension specs gone into the details of middlebox
> impacts?

This one is a little different though as end users are expectin= g e2e
without interference with this extension.=C2=A0 Understanding the behavior<= br> is important for administrators and users as Viktor stated.

Best regards,
Kathleen

Okay Kathleen.=C2=A0

We'll add some discussion on this. Viktor - I assume yo= u'll help with text.

Shumon.

--001a1147bba61dfbf60565cf6327-- From nobody Thu Feb 22 09:07:44 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9491512D874; Thu, 22 Feb 2018 09:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 E5W374kZEin7; Thu, 22 Feb 2018 09:07:35 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8543612D86A; Thu, 22 Feb 2018 09:07:35 -0800 (PST) Received: by mail-oi0-x235.google.com with SMTP id x10so1660600oig.2; Thu, 22 Feb 2018 09:07:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4CLO6qp//4n8tELEQ794trixI+Q40h96BFOs/E9RZXg=; b=dfm3EdEgPGr9gyRNuehCURzCybc3wG7Mty+SQgBKWawww5velorptmLNBYInTlv7S3 3e3Q7jWa4TGwk8D85fBhBbmk6zRo1sJA0KzbnwtObrkj2aQj9x/qj8IryGinpBBqv3GU f5fHoffbRuJRJ0bxyC8D9sa+DohQ+/Hdc1kA70SYDfC3qFNOrPh5AMiT77DR8ZvuA6z7 6uwjH7X6uDZPXiiKTVXrPa2lZLoXfuOVZdH5JRfoCXvV0C/L/cY+YyaTvwN0S/AnfqO4 N6JFlbOS2k60bdIfNDWyYUICQnIMm3aZBqM+Yl728nho6j4A9LxrFjz/F4bjDZirHQze LBgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4CLO6qp//4n8tELEQ794trixI+Q40h96BFOs/E9RZXg=; b=QiUBlnjvfUrCoQ/6rCT4qw7k/p4RT4TvinTcGOHkBGrhEM1nMpT/E8DmxorbILAGDX A//h659I7JI1flafclio811S8TQ3tK1+SQVaFHLYMjWAaKH4ntKqzb3v3cqMaqvDj7UP +mlRYR3iIkGGmY6VYX7hUIklm1RtW5DR0k6gAG1uQZNqr17xX8nVJrEYyMLAM7Xjr71K opb3nz/3S6iR7FMFe4wQCStaDKII6Idl/8slCK4Kp1z6K9B/g0vdJxBB4PsLxPMGwJNm r2uy/2abjuqqE2DwNNlLsCy9vL+ofSOyoxrfbmPu+dhTIjSxAo4Zfd8uiFIAVz/Yrqf4 P8jQ== X-Gm-Message-State: APf1xPA6lK4+d2EhhPnOIFYAlTTAY1adkwsfyfzXJRybjztJjjN3oLfP PFq+u5dBBTYobeYpfYHdp0o7ZXS0bKc9thR+n2s= X-Google-Smtp-Source: AH8x225RwfkUZrpP4vjmtWtPqdO7KzIJ1YISD3g9HBTwwuDebuwCYW4sJ5OzKzXGj0UzbG00gBca5h6eyrF3czqAxPQ= X-Received: by 10.84.78.153 with SMTP id c25mr5404144oiy.26.1519319254980; Thu, 22 Feb 2018 09:07:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.46.119 with HTTP; Thu, 22 Feb 2018 09:06:54 -0800 (PST) In-Reply-To: References: <151800968634.4877.12510609339415982154.idtracker@ietfa.amsl.com> <4c90bb83-5ba1-8193-df67-38e25f76caf8@nlnetlabs.nl> <0FA4B497-4B9A-421B-A9A6-2FEB62D3E41A@dukhovni.org> From: Kathleen Moriarty Date: Thu, 22 Feb 2018 12:06:54 -0500 Message-ID: To: Shumon Huque Cc: Viktor Dukhovni , The IESG , draft-ietf-tls-dnssec-chain-extension@ietf.org, TLS WG , tls-chairs Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-dnssec-chain-extension-06=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 17:07:38 -0000 On Thu, Feb 22, 2018 at 11:17 AM, Shumon Huque wrote: > On Thu, Feb 22, 2018 at 11:08 AM, Kathleen Moriarty > wrote: >> >> On Thu, Feb 22, 2018 at 10:59 AM, Shumon Huque wrote: >> > On Wed, Feb 21, 2018 at 1:49 PM, Viktor Dukhovni >> >> > >> > Have other TLS extension specs gone into the details of middlebox >> > impacts? >> >> This one is a little different though as end users are expecting e2e >> without interference with this extension. Understanding the behavior >> is important for administrators and users as Viktor stated. >> >> Best regards, >> Kathleen > > > Okay Kathleen. > > We'll add some discussion on this. Viktor - I assume you'll help with text. Thank you! > > Shumon. > -- Best regards, Kathleen From nobody Thu Feb 22 09:21:19 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A640A12D876; Thu, 22 Feb 2018 09:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 6hrdIBFCDkw2; Thu, 22 Feb 2018 09:21:16 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4B9012D874; Thu, 22 Feb 2018 09:21:15 -0800 (PST) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id D9B1D7A3309; Thu, 22 Feb 2018 17:21:14 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Thu, 22 Feb 2018 12:21:13 -0500 Cc: The IESG , draft-ietf-tls-dnssec-chain-extension@ietf.org, tls-chairs Content-Transfer-Encoding: quoted-printable Message-Id: <3290585E-2C55-4F8A-A82B-06B6F509ED2A@dukhovni.org> References: <151800968634.4877.12510609339415982154.idtracker@ietfa.amsl.com> <4c90bb83-5ba1-8193-df67-38e25f76caf8@nlnetlabs.nl> <0FA4B497-4B9A-421B-A9A6-2FEB62D3E41A@dukhovni.org> To: TLS WG X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-dnssec-chain-extension-06=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 17:21:18 -0000 > On Feb 22, 2018, at 10:59 AM, Shumon Huque wrote: >=20 >>>> If there is a MitM, then this extension simply isn't negotiated. >>>> That's pretty well understood. I don't see why that requires = special >>>> mention. >>>=20 >>> Yeah, I agree Martin .. this is the same as with any other = extension. >>=20 >> Actually, I don't think it is quite the same. >=20 > I meant same in the sense that if any extension is blocked then it > can't be used. What the effect of that is depends obviously on what > functionality the extension is providing. The TLS client can at least = detect > such blocking/stripping, and alert the application or fallback to = something=20 > else. >=20 > Have other TLS extension specs gone into the details of middlebox=20 > impacts? My comments are less about middleboxes (TLS-terminating corporate proxies trusted by the user's browser) and more about unwanted active MiTM attacks. If the MiTM attacker has obtained WebPKI (PKIX) certificates for the destination, then this new extension will not protect the user even when the destination has TLSA records, because the server can deny their existence (not offer the extension) without proof. What makes this case different is that the na=C3=AFve mental model of what it offers is support for DANE-based peer authentication equivalent to doing the DNSSEC lookups on the client end, but with DNSSEC tunneled via the server. Therefore, some text is probably warranted to disabuse the reader of such a na=C3=AFve view. What one gets with this extension, in the more typical cases in which DANE is not "mandatory", is not equivalent to enforcing DANE when it is published by the peer. Rather, what one gets is the ability to use DANE to authenticate sites that one might not otherwise be able to authenticate (no shared WebPKI trust-anchor). The main exception to this limitation is that once DANE TLSA records are obtained and cached (assuming there's a cache), then they may protect against downgrade to PKIX-along for the TTL of the previously obtained records, and if the cache is "refreshed" periodically (prior to expiration) by a client that continues to communicate with the server frequently over newly negotiated connections, then it becomes difficult for an MiTM to downgrade the communication to strip the DANE TLSA extension, unless the MiTM certificates are stolen directly from the server (rather than obtained fraudulently for a new key controlled by the attacker). The above exception will not be typical, so this extension is useful to support DANE-TA(2)/DANE-EE(1) certificate usages, but does not (when not mandatory) support PKIX-TA(0)/PKIX-EE(1), because authenticated denial of existence is lost. If some day (a decade or more from now if and when it is nearly universally implemented by servers) the extension is made mandatory, and requires authenticated denial of existence (or proof that the server's domain is not signed), THEN it would reach parity with direct DNSSEC lookups by the client, and its purpose would be latency reduction, rather than overcoming DNSSEC opaque captive portals... --=20 --=20 Viktor. From nobody Thu Feb 22 10:13:22 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B2F12D93E for ; Thu, 22 Feb 2018 10:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 U5LrUM0g3c2O for ; Thu, 22 Feb 2018 10:13:17 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 B8B4512EAEA for ; Thu, 22 Feb 2018 10:13:09 -0800 (PST) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx44.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eovMc-0000L4-BW for tls@ietf.org; Thu, 22 Feb 2018 19:13:05 +0100 Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eovMX-0006Z3-5V for tls@ietf.org; Thu, 22 Feb 2018 13:12:58 -0500 Received: (qmail 11207 invoked from network); 22 Feb 2018 18:12:19 -0000 Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.56.42.197]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 22 Feb 2018 18:12:18 -0000 To: R du Toit , "tls@ietf.org" References: <9C911514-298C-48EB-BF2E-E7AEDF6411F6@nerd.ninja> From: Christian Huitema Message-ID: <29134f80-08e1-65a6-f0bc-1a135a3fd274@huitema.net> Date: Thu, 22 Feb 2018 10:12:16 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <9C911514-298C-48EB-BF2E-E7AEDF6411F6@nerd.ninja> Content-Type: multipart/alternative; boundary="------------B4528EFABD78BDC0AE08CA57" Content-Language: en-US X-Originating-IP: 168.144.250.232 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.27) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5g7eoTdhRkpu3sOSeQU4M/5602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO5IcVwV4jjVcAOtIXxgohGFVMZsRZacTbJPGp/MBC6Bxom2hFpZdmTC+t9/aZvikOUh5 mNm/WjPqhYqCeBiCKwzwNnO0oYiZjOnC1Xa7kCO2yu59OQA2zKnT1Yg5KX9v7/vRa7MR4hgRIg8N 1QlY4G7x1YBTEs55LirRLgpsvCFtid7SQi4NE/job5y2wAN3GZxznd8NXwc/vKJtfZaXo5QAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0ClKHhIXfDbmhz3DoftFSAfVIRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM81CaOu2xwDQxDsUgSvK+nIcAu00QtM6SrWQsh7MUTu iw4e4u+bfD/hVcSZoV5DGopUM0RAFM2zFsHmT9ujRS4VG0UZfpSr5B8F7k6XZlk+Smj55Nl155o2 Oe/0FuVZZmVzxAG+DjqL5QSEyTpqxgd+hoJiRUJS+7Nru8G8qObMBABriH3x3J15D78KylFpBEP0 fgN5y0tqqfuQuS1mj2WrD/7Rwl5fb+U9Gl2IOh9znlaghRNFS9zoWO5d3m1btADQ+XNr4QUyZNz0 uLvRKYxZQqF/LoUsSniF4plClx3amUzZcpKSeCQrufbZbcAD6/oERpFEqF2lExBUp1VMiBudJvWZ 9M/O6eVqbri1Q0O8/zF9mE6flINXEXJL2r3PrBjLoydbuOy1i9SfmYgxBbq3mdySlZou9qHIGOZD EEo7O+Pd3ebmKuucUVzXcVqfEwQXQ+sESjyASrM/THMyWUoiolU4x0KD113J1SYnBP2uKg== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: Re: [TLS] Comments on draft-ietf-tls-sni-encryption-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 18:13:20 -0000 This is a multi-part message in MIME format. --------------B4528EFABD78BDC0AE08CA57 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/21/2018 3:31 PM, R du Toit wrote: > I have analyzed the two mechanisms proposed in the draft, with > specific focus on the impact of middleboxes.=C2=A0 > > =C2=A0 > > *_Assumptions:_*** > > The middlebox is deployed inline, between the client and the fronting > server, and is allowed to intercept TLS sessions.=C2=A0 The middlebox i= s > policy-driven, and uses SNI as an input in determining whether or not > to intercept the session; the policy must use the SNI of the hidden > server. > We may want to be a bit more specific about middlebox assumptions, both in the draft and in your analysis. The big question centers on your sentence "(the middlebox)=C2=A0 is allow= ed to intercept TLS sessions". Allowed by whom, and how? SNI encryption deployments, today, are attempting to prevent observation and interception by middleboxes that neither the client nor the server authorized. It is not surprising that SNI encryption would achieve just that, in the same way that TLS succeeds in hiding the content from intermediaries. If it doesn't, it's a bug. > =C2=A0 > > *_Mechanism #1 : Tunnel ClientHello in 0-RTT early data._*** > > (1) Mechanism #1 requires 0-RTT support, but the middlebox would not > be violating the TLS 1.3 specification by not implementing 0-RTT.=C2=A0= The > middlebox intercepts all sessions destined to a specific fronting > server (F); the identity of F should be public knowledge, but even if > it is not, we have to assume that the middlebox has a mechanism to > decide when to intercept sessions destined to F.=C2=A0 > Yes, that's a weakness in the "0-RTT tunneling" mechanism. To work properly, it would need some kind of fallback when 0-RTT is blocked. That needs to be taken into account when evaluating the mechanism. > =C2=A0 > > (2) Assume that the middlebox actually supports PSK and 0-RTT, i.e. > TLS intercept with PSK/0-RTT support in the session between the client > and the middlebox, as well as PSK/0-RTT support in the session between > the middlebox and the fronting server.=C2=A0 The middlebox will be able= to > decode ClientHello#2 sent in the 0-RTT early data because the > client_early_traffic_secret will be known to the middlebox.=C2=A0 The > middlebox would thus have access to the SNI of the hidden server, and > would be able to evaluate policy.=C2=A0 The middlebox would have the op= tion > to pull out of the session after sending ClientHello#2 to the fronting > server (re-encrypted with the client_early_traffic_secret shared > between the middlebox and the fronting server). > > =C2=A0 > > *_Mechanism #2: Session ticket that can be decoded by Fronting and > Hidden server._*** > > (3) Mechanism #2 relies on PSK session resumption support in the > middlebox; this is not guaranteed. > Actually, this is not specific to the session ticket solution. The 0-RTT mechanism also relies on PSK session resumption. In your previous paragraph, you state that "the client_early_traffic_secret will be known to the middlebox". But that early secret is based on the PSK in a resumption ticket with the fronting server. So in both cases, your middlebox only works transparently if it keeps track of session tickets and the corresponding identities and keys. > (4) The middlebox would not participate or interfere in any of the > out-of-band channels between the fronting server and the hidden > server, which implies that the middlebox will not be able to decode > the session ticket generated by the hidden server - but it does not > have to.=C2=A0 The middlebox would be able to observe the encoded sessi= on > ticket in the NewSessionTicket message because it intercepts the > initial TLS session between the client and the hidden server (even if > mechanism #1 is used for the first session).=C2=A0 The middlebox would = thus > be able to extract the SNI of the hidden server from the > NewSessionTicket message and build a mapping of encoded session > tickets to hidden servers. TLS sessions (destined to the fronting > server) that were not previously intercepted by the middlebox will use > PSK identities that are not in the mapping table - the middlebox would > likely force intercept of those sessions and strip the unknown PSK > identities, which would result in a TLS session that terminates on the > fronting server, leaving the fronting server without any knowledge of > the hidden server. > Yes, that should be the fall back mode if the middlebox strips away the PSK identity. The client ends up with a session with the fronting server, and the attempt to connect to the hidden server remains secret. I agree that it should be documented in the draft. > =C2=A0 > > (5) Ignoring middleboxes, in my opinion the infrastructure required > for collaboration between fronting servers and hidden servers > (stateful, shared-key, public-key, or otherwise) would be a practical > barrier to entry for most server administrators. > The way to check that is to try some test deployments. We shall see. -- Christian Huitema --------------B4528EFABD78BDC0AE08CA57 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 2/21/2018 3:31 PM, R du Toit wrote:

I have analyzed the two mechanisms proposed in the draft, with specific focus on the impact of middleboxes. 

 

Assumptions:

The middlebox is deployed inline, between the client and the fronting server, and is allowed to intercept TLS sessions.  The middlebox is policy-driven, and uses SNI as an input in determining whether or not to intercept the session; the policy must use the SNI of the hidden server.


We may want to be a bit more specific about middlebox assumptions, both in the draft and in your analysis.

The big question centers on your sentence "(the middlebox)  is allowed to intercept TLS sessions". Allowed by whom, and how? SNI encryption deployments, today, are attempting to prevent observation and interception by middleboxes that neither the client nor the server authorized. It is not surprising that SNI encryption would achieve just that, in the same way that TLS succeeds in hiding the content from intermediaries. If it doesn't, it's a bug.

 

Mechanism #1 : Tunnel ClientHello in 0-RTT early data.

(1) Mechanism #1 requires 0-RTT support, but the middlebox would not be violating the TLS 1.3 specification by not implementing 0-RTT.  The middlebox intercepts all sessions destined to a specific fronting server (F); the identity of F should be public knowledge, but even if it is not, we have to assume that the middlebox has a mechanism to decide when to intercept sessions destined to F. 


Yes, that's a weakness in the "0-RTT tunneling" mechanism. To work properly, it would need some kind of fallback when 0-RTT is blocked. That needs to be taken into account when evaluating the mechanism.

 

(2) Assume that the middlebox actually supports PSK and 0-RTT, i.e. TLS intercept with PSK/0-RTT support in the session between the client and the middlebox, as well as PSK/0-RTT support in the session between the middlebox and the fronting server.  The middlebox will be able to decode ClientHello#2 sent in the 0-RTT early data because the client_early_traffic_secret will be known to the middlebox.  The middlebox would thus have access to the SNI of the hidden server, and would be able to evaluate policy.  The middlebox would have the option to pull out of the session after sending ClientHello#2 to the fronting server (re-encrypted with the client_early_traffic_secret shared between the middlebox and the fronting server).

 

Mechanism #2: Session ticket that can be decoded by Fronting and Hidden server.

(3) Mechanism #2 relies on PSK session resumption support in the middlebox; this is not guaranteed.

Actually, this is not specific to the session ticket solution. The 0-RTT mechanism also relies on PSK session resumption. In your previous paragraph, you state that "the client_early_traffic_secret will be known to the middlebox". But that early secret is based on the PSK in a resumption ticket with the fronting server. So in both cases, your middlebox only works transparently if it keeps track of session tickets and the corresponding identities and keys.

(4) The middlebox would not participate or interfere in any of the out-of-band channels between the fronting server and the hidden server, which implies that the middlebox will not be able to decode the session ticket generated by the hidden server - but it does not have to.  The middlebox would be able to observe the encoded session ticket in the NewSessionTicket message because it intercepts the initial TLS session between the client and the hidden server (even if mechanism #1 is used for the first session).  The middlebox would thus be able to extract the SNI of the hidden server from the NewSessionTicket message and build a mapping of encoded session tickets to hidden servers. TLS sessions (destined to the fronting server) that were not previously intercepted by the middlebox will use PSK identities that are not in the mapping table - the middlebox would likely force intercept of those sessions and strip the unknown PSK identities, which would result in a TLS session that terminates on the fronting server, leaving the fronting server without any knowledge of the hidden server.


Yes, that should be the fall back mode if the middlebox strips away the PSK identity. The client ends up with a session with the fronting server, and the attempt to connect to the hidden server remains secret. I agree that it should be documented in the draft.

 

(5) Ignoring middleboxes, in my opinion the infrastructure required for collaboration between fronting servers and hidden servers (stateful, shared-key, public-key, or otherwise) would be a practical barrier to entry for most server administrators.


The way to check that is to try some test deployments. We shall see.

-- Christian Huitema
--------------B4528EFABD78BDC0AE08CA57-- From nobody Thu Feb 22 12:03:12 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8924B12D95B for ; Thu, 22 Feb 2018 12:03:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nerd.ninja 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 GBuL94LVjQoO for ; Thu, 22 Feb 2018 12:03:09 -0800 (PST) Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02E3312D95A for ; Thu, 22 Feb 2018 12:03:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1519329783; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=Date:Subject:From:To:Message-ID:References:In-Reply-To:Mime-version:Content-type; l=19431; bh=Ap/lx61m5qcdH3XSEQhWnT52iokUv8DCxwxiSWa3/6E=; b=XhAv9vomyxBvlrdiD1Bv1eubPEb0tVQpAbpA1d3fK80hEUpHPK7o8XtC2CD1A+1I ZItt84sos/PRYiHyiFka6M6yhnD/mYmQMcVLjxU3vXc4rvZGq4nWcvJ4dyxNbJdCNC3 HZhE/VN7dV6AagmG+nP3E+9uH19WTCLLbmaueZak= Received: from [192.168.123.225] (dynamic-acs-24-112-242-116.zoominternet.net [24.112.242.116]) by mx.zohomail.com with SMTPS id 1519329783805605.6553580520401; Thu, 22 Feb 2018 12:03:03 -0800 (PST) User-Agent: Microsoft-MacOutlook/f.20.0.170309 Date: Thu, 22 Feb 2018 15:03:01 -0500 From: R du Toit To: Christian Huitema , "tls@ietf.org" Message-ID: <227FFE8E-AFF1-4C69-8644-EC51B2B1F6F4@nerd.ninja> Thread-Topic: Comments on draft-ietf-tls-sni-encryption-01.txt References: <9C911514-298C-48EB-BF2E-E7AEDF6411F6@nerd.ninja> <29134f80-08e1-65a6-f0bc-1a135a3fd274@huitema.net> In-Reply-To: <29134f80-08e1-65a6-f0bc-1a135a3fd274@huitema.net> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3602156583_1680432960" X-ZohoMailClient: External X-ZohoMail: Z_658201841 SPT_1 Z_47369130 SPT_1 SLF_D Archived-At: Subject: Re: [TLS] Comments on draft-ietf-tls-sni-encryption-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 20:03:11 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3602156583_1680432960 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I see at least 6 classes of "middlebox": 1. Inline corporate device (e.g. proxy); explicitly trusted by client throu= gh configuration. 2. Inline lawful intercept surveillance device; the client is not aware tha= t it is "trusting" the device.=C2=A0 (NOTE: I'm not commenting on whether this i= s ethical, just listing the options). 3. Inline surveillance device using some crypto backdoor (hopefully this is= theoretical for TLS 1.3!). 4. Inline active MiTM attack. 5. Passive monitoring device, either inline or TAP/SPAN; authorized by clie= nt; "passive" in the sense that it does not modify TLS content. 6. Passive monitoring device; not authorized Proper TLS 1.3 stack implementations would hopefully nullify classes 3 and = 4. My focus was on class 1, but class 2 will have similar capabilities. Different mechanisms, possibly out-of-band, would be needed to hide knowled= ge of the hidden server from classes 1 and 2.=C2=A0 Furthermore, classes 1 and 2= will initially have a severe impact on the deployment of the mechanisms des= cribed in the draft. I agree that both mechanisms will be effective against classes 5 and 6.=C2=A0 W= as that the goal? =20 --Roelof =20 From: Christian Huitema Date: Thursday, February 22, 2018 at 1:12 PM To: R du Toit , "tls@ietf.org" Subject: Re: Comments on draft-ietf-tls-sni-encryption-01.txt =20 On 2/21/2018 3:31 PM, R du Toit wrote: I have analyzed the two mechanisms proposed in the draft, with specific foc= us on the impact of middleboxes.=20 =20 Assumptions: The middlebox is deployed inline, between the client and the fronting serve= r, and is allowed to intercept TLS sessions. The middlebox is policy-driven= , and uses SNI as an input in determining whether or not to intercept the se= ssion; the policy must use the SNI of the hidden server. We may want to be a bit more specific about middlebox assumptions, both in = the draft and in your analysis. The big question centers on your sentence "(the middlebox) is allowed to i= ntercept TLS sessions". Allowed by whom, and how? SNI encryption deployments= , today, are attempting to prevent observation and interception by middlebox= es that neither the client nor the server authorized. It is not surprising t= hat SNI encryption would achieve just that, in the same way that TLS succeed= s in hiding the content from intermediaries. If it doesn't, it's a bug. =20 Mechanism #1 : Tunnel ClientHello in 0-RTT early data. (1) Mechanism #1 requires 0-RTT support, but the middlebox would not be vio= lating the TLS 1.3 specification by not implementing 0-RTT. The middlebox i= ntercepts all sessions destined to a specific fronting server (F); the ident= ity of F should be public knowledge, but even if it is not, we have to assum= e that the middlebox has a mechanism to decide when to intercept sessions de= stined to F. =20 Yes, that's a weakness in the "0-RTT tunneling" mechanism. To work properly= , it would need some kind of fallback when 0-RTT is blocked. That needs to b= e taken into account when evaluating the mechanism. =20 (2) Assume that the middlebox actually supports PSK and 0-RTT, i.e. TLS int= ercept with PSK/0-RTT support in the session between the client and the midd= lebox, as well as PSK/0-RTT support in the session between the middlebox and= the fronting server. The middlebox will be able to decode ClientHello#2 se= nt in the 0-RTT early data because the client_early_traffic_secret will be k= nown to the middlebox. The middlebox would thus have access to the SNI of t= he hidden server, and would be able to evaluate policy. The middlebox would= have the option to pull out of the session after sending ClientHello#2 to t= he fronting server (re-encrypted with the client_early_traffic_secret shared= between the middlebox and the fronting server). =20 Mechanism #2: Session ticket that can be decoded by Fronting and Hidden ser= ver. (3) Mechanism #2 relies on PSK session resumption support in the middlebox;= this is not guaranteed. Actually, this is not specific to the session ticket solution. The 0-RTT me= chanism also relies on PSK session resumption. In your previous paragraph, y= ou state that "the client_early_traffic_secret will be known to the middlebo= x". But that early secret is based on the PSK in a resumption ticket with th= e fronting server. So in both cases, your middlebox only works transparently= if it keeps track of session tickets and the corresponding identities and k= eys. (4) The middlebox would not participate or interfere in any of the out-of-b= and channels between the fronting server and the hidden server, which implie= s that the middlebox will not be able to decode the session ticket generated= by the hidden server - but it does not have to. The middlebox would be abl= e to observe the encoded session ticket in the NewSessionTicket message beca= use it intercepts the initial TLS session between the client and the hidden = server (even if mechanism #1 is used for the first session). The middlebox = would thus be able to extract the SNI of the hidden server from the NewSessi= onTicket message and build a mapping of encoded session tickets to hidden se= rvers. TLS sessions (destined to the fronting server) that were not previous= ly intercepted by the middlebox will use PSK identities that are not in the = mapping table - the middlebox would likely force intercept of those sessions= and strip the unknown PSK identities, which would result in a TLS session t= hat terminates on the fronting server, leaving the fronting server without a= ny knowledge of the hidden server. Yes, that should be the fall back mode if the middlebox strips away the PSK= identity. The client ends up with a session with the fronting server, and t= he attempt to connect to the hidden server remains secret. I agree that it s= hould be documented in the draft. =20 (5) Ignoring middleboxes, in my opinion the infrastructure required for col= laboration between fronting servers and hidden servers (stateful, shared-key= , public-key, or otherwise) would be a practical barrier to entry for most s= erver administrators. The way to check that is to try some test deployments. We shall see. -- Christian Huitema=20 --B_3602156583_1680432960 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

I see at least 6 classes of "middlebox":

<= p class=3DMsoNormal>1. Inline corporate device = (e.g. proxy); explicitly trusted by client through configuration.=

2. Inline lawfu= l intercept surveillance device; the client is not aware that it is "tr= usting" the device.=C2=A0 (NOTE: I'm not commenting on whether this is ethi= cal, just listing the options).

3. Inline surveillance device using some crypto b= ackdoor (hopefully this is theoretical for TLS 1.3!).

<= p class=3DMsoNormal>4. Inline active MiTM attac= k.

5.= Passive monitoring device, either inline or TAP/SPAN; authorized by client;= "passive" in the sense that it does not modify TLS content.<= /o:p>

6. Passive= monitoring device; not authorized

Proper TLS 1.3 stack implementatio= ns would hopefully nullify classes 3 and 4.

My focus was on class 1, but class 2 = will have similar capabilities.

Different mechanisms, possibly out-of-band, would= be needed to hide knowledge of the hidden server from classes 1 and 2.=C2=A0 Fu= rthermore, classes 1 and 2 will initially have a severe impact on the deploy= ment of the mechanisms described in the draft.

I agree that both mechanisms will = be effective against classes 5 and 6.=C2=A0 Was that the goal?=

 

--Roelof<= /span>

 

From: Christian Huitema = <huitema@huitema.net>
Date: Thursday, February 22, 2018 at 1= :12 PM
To: R du Toit <r@nerd.ninja>, "tls@ietf.org"= ; <tls@ietf.org>
Subject: Re: Comments on draft-ietf-tls-sni= -encryption-01.txt

 

On 2/21/2018 3:31 PM, R du = Toit wrote:

I have analyzed the two mechanisms proposed in the draft, with specifi= c focus on the impact of middleboxes. 

 

Assumptions:

The middlebox = is deployed inline, between the client and the fronting server, and is allow= ed to intercept TLS sessions.  The middlebox is policy-driven, and uses= SNI as an input in determining whether or not to intercept the session; the= policy must use the SNI of the hidden server.


We may want to be a bit more specific about middlebox a= ssumptions, both in the draft and in your analysis.

The big question = centers on your sentence "(the middlebox)  is allowed to intercept= TLS sessions". Allowed by whom, and how? SNI encryption deployments, t= oday, are attempting to prevent observation and interception by middleboxes = that neither the client nor the server authorized. It is not surprising that= SNI encryption would achieve just that, in the same way that TLS succeeds i= n hiding the content from intermediaries. If it doesn't, it's a bug.

=

 

Mechanism #1 : Tunnel ClientHello in = 0-RTT early data.

(1) Mechanism #1 requires 0-RT= T support, but the middlebox would not be violating the TLS 1.3 specificatio= n by not implementing 0-RTT.  The middlebox intercepts all sessions des= tined to a specific fronting server (F); the identity of F should be public = knowledge, but even if it is not, we have to assume that the middlebox has a= mechanism to decide when to intercept sessions destined to F.  =


Yes, that's a weakness in the &q= uot;0-RTT tunneling" mechanism. To work properly, it would need some ki= nd of fallback when 0-RTT is blocked. That needs to be taken into account wh= en evaluating the mechanism.


 

(2) Ass= ume that the middlebox actually supports PSK and 0-RTT, i.e. TLS intercept w= ith PSK/0-RTT support in the session between the client and the middlebox, a= s well as PSK/0-RTT support in the session between the middlebox and the fro= nting server.  The middlebox will be able to decode ClientHello#2 sent = in the 0-RTT early data because the client_early_traffic_secret will be know= n to the middlebox.  The middlebox would thus have access to the SNI of= the hidden server, and would be able to evaluate policy.  The middlebo= x would have the option to pull out of the session after sending ClientHello= #2 to the fronting server (re-encrypted with the client_early_traffic_secret= shared between the middlebox and the fronting server).

=  

<= u>Mechanism #2: Session ticket that can be de= coded by Fronting and Hidden server.

(3) Mechani= sm #2 relies on PSK session resumption support in the middlebox; this is not= guaranteed.

Actually, this is= not specific to the session ticket solution. The 0-RTT mechanism also relie= s on PSK session resumption. In your previous paragraph, you state that &quo= t;the client_early_traffic_secret will be known to the middlebox". But = that early secret is based on the PSK in a resumption ticket with the fronti= ng server. So in both cases, your middlebox only works transparently if it k= eeps track of session tickets and the corresponding identities and keys.
=

(4) The middlebox would not participate or interfere in any of the= out-of-band channels between the fronting server and the hidden server, whi= ch implies that the middlebox will not be able to decode the session ticket = generated by the hidden server - but it does not have to.  The middlebo= x would be able to observe the encoded session ticket in the NewSessionTicke= t message because it intercepts the initial TLS session between the client a= nd the hidden server (even if mechanism #1 is used for the first session).&n= bsp; The middlebox would thus be able to extract the SNI of the hidden serve= r from the NewSessionTicket message and build a mapping of encoded session t= ickets to hidden servers. TLS sessions (destined to the fronting server) tha= t were not previously intercepted by the middlebox will use PSK identities t= hat are not in the mapping table - the middlebox would likely force intercep= t of those sessions and strip the unknown PSK identities, which would result= in a TLS session that terminates on the fronting server, leaving the fronti= ng server without any knowledge of the hidden server.

<= /blockquote>


Yes, that should be the fall back mode if the mi= ddlebox strips away the PSK identity. The client ends up with a session with= the fronting server, and the attempt to connect to the hidden server remain= s secret. I agree that it should be documented in the draft.


<= p class=3DMsoNormal style=3D'margin-left:.5in'>&n= bsp;

(5) Ignoring middleboxes, in my opinion the infrast= ructure required for collaboration between fronting servers and hidden serve= rs (stateful, shared-key, public-key, or otherwise) would be a practical bar= rier to entry for most server administrators.


The way to check that is to try some test deployments. W= e shall see.

-- Christian Huitema

--B_3602156583_1680432960-- From nobody Thu Feb 22 13:32:35 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FBE12DA49 for ; Thu, 22 Feb 2018 13:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 2Y8tyz8RmGUc for ; Thu, 22 Feb 2018 13:32:31 -0800 (PST) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CBE012DA47 for ; Thu, 22 Feb 2018 13:32:31 -0800 (PST) Received: by mail-wr0-x22f.google.com with SMTP id m5so12054644wrg.1 for ; Thu, 22 Feb 2018 13:32:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JhE+EBZJmnKD4KT0/Nl3n3bMBmuPO1Kz/F747ysUUOs=; b=R/2rSrREm83RIuwMsBAKATIlzAuE5gzBlgvK9yTDcLyq8HcFuu9dCsYXbIFBtDx8dw /0Clx6PAcFaBMcVnrIUg9pcuD6a1VfVx4jrN6qbkJkUIi9p/vIVvepV6vjxyWIfB6On/ RGmOAOC2CO6yU3JnIvmQjdM0jJQx8xUJkPhEXEW23VbHxgYrJxmBfYU6SwiU2+QpLJTl BGtjBgvyWzkkZjl+QIridKl45t+J+HdEDqIMqgOskkq9UwWRAIsBfPIsx9uNhPllzsvH 79mVk+QYl75ssYYxo/9+H0p2webLTrXGS5mfzvMfqXzJhmaK4lq/bMYIS7V2ShqEFg/8 B5Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JhE+EBZJmnKD4KT0/Nl3n3bMBmuPO1Kz/F747ysUUOs=; b=TQAh1uDce2R5lf5unHAjo0i0JvyVSuDJWKl9M++tYOJslZOEqrJ43bxHsxfZ5KmlIr eoKMYX9CMQmrdyX5qlsR8/6sewpB/AwGK0rfknB06K1R1SDlUN9cgEbukQJc9crK+N6P Ta17FR5ijzZIUvgCC6FafH9IHkLjewgYKDczBGGvS0Zm4bkVzXjFxcPf2RH828aJgV3K 7EdSRD46mlbQ9xdwiWUHMDx84X/WkJVS3G12WYmZCa0gB6NYXKWoGA+M24VmUvVQeKR1 Y2y7ol3juYy/swsgte9RQ1QhZjb6MLzNBTmxuXol+EmJDsFeBtBMIzos+AfJDT3LlB34 Xfew== X-Gm-Message-State: APf1xPBBU+DCctl3ZjRwN2S5qa3czthhSolR8f3pT8GfsYJNuSh/lehw dFk61VfpjYsobux/+3+1V+VR4SrWSqxJDpbAePxI4A== X-Google-Smtp-Source: AH8x227pP6KpE3O/zuEoPutMqKm0pkUBiUUV7zWNUJW0x/vR73R5zSYpVM7cKLB5Wjn5wdTrCiTYBIkk3aN1SRhs3Fk= X-Received: by 10.223.142.194 with SMTP id q60mr7425521wrb.113.1519335149866; Thu, 22 Feb 2018 13:32:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.11.12 with HTTP; Thu, 22 Feb 2018 13:32:08 -0800 (PST) In-Reply-To: <1245150098.5877048.1518481362605.JavaMail.zimbra@inria.fr> References: <20180201135947.77809B819EE@rfc-editor.org> <1245150098.5877048.1518481362605.JavaMail.zimbra@inria.fr> From: Adam Langley Date: Thu, 22 Feb 2018 13:32:08 -0800 Message-ID: To: Xavier Bonnetain Cc: RFC Errata System , Wan-Teh Chang , Nikos Mavrogiannopoulos , =?UTF-8?Q?Joachim_Str=C3=B6mbergson?= , Simon Josefsson , Kathleen Moriarty , Eric Rescorla , Joseph Salowey , sean+ietf@sn3rd.com, tls@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] [Technical Errata Reported] RFC7905 (5251) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 21:32:33 -0000 On Mon, Feb 12, 2018 at 4:22 PM, Xavier Bonnetain wrote: > If we are in the situation C =3D 0, D =3D 1 and L=3D2^{14} for (D)TLS, th= e forgery probability may indeed not be affected (and may even be smaller).= However, the explanation "Poly1305 is designed to ensure that forged messa= ges are rejected with a probability of 1-(n/2^107), where n is the maximum = length of the input to Poly1305." is presenting Poly1305 as slightly strong= er than it really is (and there is an attack with success probability 2^{-1= 06} with C=3D1, D=3D1, L=3D1, as the hashing key r has 106 effective bits). I don't believe that this contradicts the equation. While it's true that r only contains 106 bits, knowing r isn't sufficient to forge a message unless one also has a legitimate message from which to calculate the masking value. In the C =3D 0 situation, the attacker does not have such a message. As the attacker gathers samples of legitimate messages, their success probability does, indeed, increase. I suspect that any simplification of the security equation is going to have these issues. Cheers AGL From nobody Fri Feb 23 02:49:14 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666B2124235; Fri, 23 Feb 2018 02:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 p7KhOqxmDIln; Fri, 23 Feb 2018 02:49:05 -0800 (PST) Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [185.49.140.10]) (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 3B8D9128C0A; Fri, 23 Feb 2018 02:49:05 -0800 (PST) Received: from [IPv6:2001:980:2283:fe:c559:e689:f783:adea] (unknown [IPv6:2001:980:2283:fe:c559:e689:f783:adea]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 0AC3D87E3; Fri, 23 Feb 2018 11:49:03 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1519382943; bh=rJlNX7UfqzY5JL6YBTrlBc6qv+Zyn2JsHDEovPBiSiY=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=P7424Q+vdMnPxvA9fhyzghTzinA1Dj2geLSN0uAyw60CLWdZ7nE4AnKl+rATb/ya9 PgscVoXnmTnrOvnLn7X4B+zYSE4EQFb9gwem545qhiCGfaE5xgMcOJyQIo2pAyufwn +HVgS/SHwCKL1OvBpnMFjAVLrEFuFAVLpzGX4tnY= To: Shumon Huque , Paul Wouters Cc: Eric Rescorla , TLS WG , draft-ietf-tls-dnssec-chain-extension@ietf.org, The IESG , tls-chairs References: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com> From: Willem Toorop Message-ID: <087503d8-0c74-314c-d868-4127087c3eae@nlnetlabs.nl> Date: Fri, 23 Feb 2018 11:49:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 10:49:08 -0000 Op 22-02-18 om 16:44 schreef Shumon Huque: > On Wed, Feb 21, 2018 at 2:48 PM, Paul Wouters > wrote: > > On Wed, 21 Feb 2018, Shumon Huque wrote: > > Okay, got it. For people that have already implemented this, I think > there has been an implicit understanding that the format of the > chain > data is a sequence of concatenated wire format RRs exactly as > they appear > in a DNS message section > > > Note, I would not call it "sequence of concatenated wire format RRs", as > it is simply the wireformat of a DNS message. > > The fact that some parts > are concatenated RR's is just part of the wireformat of the DNS reply > message. That is, this isn't introducing some new form of concatenated > content - it is _just_ a regular DNS wire format message, and the > document should not go deeper into its explanation. > > > It would _not_ be correct to say that this is a "DNS wire format > message" - that  > would mean there is a DNS header section with flags and response codes,  > and other sections. The chain data structure as currently specified > really is  > concatenated wire-format RRs (as they appear _within_ a DNS message  > _section_). Let me know if that is unclear in the draft (or my proposed > edits). > > I recall at one point way back there was a discussion about whether the > chain > data should just be a fully formed DNS message, but I don't believe that > idea > had much support in the working group (personally I would have been fine > with  > that choice too, if it did have support). A DNS message is a 12 octet header followed by a question, followed by a list of RRs. The header does not contain any relevant information with respect to the chain query. The question is unnecessary, because only a TLSA record for the name and port of the service (or a secure path from the name of the service, via CNAME or DNAME to the name of the TLSA RRset), is acceptable for a client, so a client would have to disregard the question in a DNS message anyway. The list of RRs remains and is sufficient for the DNSSEC chain extension. A response of a rfc7901 EDNS chain query can be used almost directly as the content for the extension. You just have to strip/skip the irrelevant data from the front of the message (i.e. the 12 byte header, the query name and 8 octets type/class/ttl). > I noticed some discussion about the ordering of this content. I am not > sure why that should be done. DNS doesn't care about the order, and > neither should producers or consumers of this extension. DNS has no > ordering inside its message. > > > Yes, that is in fact where we ended up, roughly. > > The draft does currently say that the answer record(s) appear first. And > then > the authentication chain records follow and that TLS client should be > prepared > to receive the authentication chain records in any order.  > > Requiring the answer records first seems logical to me - it is what > existing  > libraries do, and also what the EDNS chain query spec does (answer records  > appear first in the ANSWER section, and DNSSEC authentication chain records > appear in the AUTHORITY section in any order). > > There is some residual wording in the draft about ordering of CNAMEs etc in > the answer records part. Assuming the WG agrees, I am fine with relaxing > that requirement - that ended up in there because although there is no > defined > ordering of RRs within a DNS message section, as a practical matter CNAMEs > are almost always ordered since there are some DNS queriers that get > confused  > otherwise. This is a new protocol though, so we can be more faithful to > the DNS  > spec. > > I don't think getting unrelated DNSSEC records would be an issue. TLS > has its maximum sizes for the handshake. In fact, it could allow the > extension to have some useful data in the case of MX or SRV.  (and could > be a feature to build a nice resolver over TLS using 1 tor circuit). > > > The draft currently doesn't address the MX or SRV use case. I suggest > that we tackle that in a future version. > > I'm also not sure about the talking of unsigned CNAME records from > DNAME. The above pseudo code (extended with special cases) should be > in some DNS library, and that library will know what records to expect > unsigned which are proven by the DNAME (or wildcard) synthesis and knows > when/if to add it to the validated cache. I don't think that should be > explained in this RFC at all. The DNS implementation does not need > to be specified in this document and it should just focus on saying > that "the DNS message response is validated and upon validation the > content can be considered DANE validated". > > > Where we ended up, is that WG participants asked for some level of DNSSEC > detail to be included in this doc. > > Shumon. > From nobody Fri Feb 23 09:14:13 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2371C127136 for ; Fri, 23 Feb 2018 09:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 4iaMuayNWVIS for ; Fri, 23 Feb 2018 09:14:10 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 97E1B1270AB for ; Fri, 23 Feb 2018 09:14:10 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1NHBheZ013970; Fri, 23 Feb 2018 17:14:08 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=zFo8nvr1lic2396lZ9sPtqqqre+r6Z05t1f5k5bTKHw=; b=lueO+E7O9t/tBn6jS4+lWk1LINMuxyQOuMciMlV47N/ro8GhBnODxwimuRxn5updz6kT bpL/L6mJpQWKyVQIKDwZYg5sdNJgRp3ezoBsRY9JCwF+mzZW03brIwD0KCyMDKlDSbvv 7CYxVZNo8lFG4JulYRch2UIpwrJX4jsP52dt+XtVKzdnGfTuUIs/HthgZLIoTFK2rTWJ s0fsqSCsjO6ZPIn/knf2Qe8D/cV64dvJV6brW6wde2Ai0wdIsWO3wcXfVh4mIYVK7YTG LDEjJ6iTexXmaZPteo29vB6u36X3pyATtsEpnh8c21qtDxLXWiLuIm8BGTzHEIN7Zoni XA== Received: from prod-mail-ppoint4 ([96.6.114.87]) by mx0b-00190b01.pphosted.com with ESMTP id 2g9u54ca0x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Feb 2018 17:14:08 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w1NHBf2S025419; Fri, 23 Feb 2018 12:14:07 -0500 Received: from email.msg.corp.akamai.com ([172.27.27.21]) by prod-mail-ppoint4.akamai.com with ESMTP id 2g6gm1sbew-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 23 Feb 2018 12:14:07 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 23 Feb 2018 11:14:06 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Fri, 23 Feb 2018 11:14:06 -0600 From: "Salz, Rich" To: tlswg/tls13-spec , tlswg/tls13-spec CC: "tls@ietf.org" Thread-Topic: [tlswg/tls13-spec] Add the record header to additional data for AEAD (de)protection. (#1158) Thread-Index: AQHTrMdefNvH7Raa2kaAOuBtx37IpKOySp6A Date: Fri, 23 Feb 2018 17:14:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.a.0.180210 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.183] Content-Type: multipart/alternative; boundary="_000_C5E4024A0AA947608002FD9D9352882Fakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-23_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=659 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802230213 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-23_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=600 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802230213 Archived-At: Subject: Re: [TLS] [tlswg/tls13-spec] Add the record header to additional data for AEAD (de)protection. (#1158) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 17:14:12 -0000 --_000_C5E4024A0AA947608002FD9D9352882Fakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyB3b3VsZCBjaGFuZ2UgdGhlIHdpcmUgcHJvdG9jb2wgeWV0IGFnYWluLiAgSXMgaXQgcmVh bGx5IG5lY2Vzc2FyeSBvciBqdXN0IGEgbmljZS10by1oYXZlPw0KDQoNCg== --_000_C5E4024A0AA947608002FD9D9352882Fakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <9905179B4698574BA473214014CDDB78@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmg0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5r OiJIZWFkaW5nIDQgQ2hhciI7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cglmb250LXdlaWdodDpib2xkO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxl LW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K c3Bhbi5IZWFkaW5nNENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgNCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyA0IjsNCglmb250 LWZhbWlseToiQ2FsaWJyaSBMaWdodCIsc2Fucy1zZXJpZjsNCgljb2xvcjojMkY1NDk2Ow0KCWZv bnQtc3R5bGU6aXRhbGljO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxp c3QgbDANCgl7bXNvLWxpc3QtaWQ6ODA0MTk4NjQyOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczot MjE0NTg3ODg4Njt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6 MjA0Nzc0OTg2MzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NTAxMjU4MzQ0O30NCkBsaXN0IGwx OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9 DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDgN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoyMTQxOTk1OTYxOw0KCW1zby1saXN0 LXRlbXBsYXRlLWlkczotMjEyMDQyNDgzMjt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNv LWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHdv dWxkIGNoYW5nZSB0aGUgd2lyZSBwcm90b2NvbCB5ZXQgYWdhaW4uJm5ic3A7IElzIGl0IHJlYWxs eSBuZWNlc3Nhcnkgb3IganVzdCBhIG5pY2UtdG8taGF2ZT88bzpwPjwvbzpwPjwvcD4NCjxwPjxh IG5hbWU9Il9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjojNjY2NjY2Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_C5E4024A0AA947608002FD9D9352882Fakamaicom_-- From nobody Fri Feb 23 11:20:24 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59271241F3; Fri, 23 Feb 2018 11:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 zQMScODOoorG; Fri, 23 Feb 2018 11:20:13 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B21C61205F0; Fri, 23 Feb 2018 11:20:13 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id b34so10890182ioj.6; Fri, 23 Feb 2018 11:20:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZksCrGAFNV1cp5fNAjOeChv/ObleQzDSf9UKT67Aoa0=; b=sr4XYxo/FGNFclaBXr9ow6yjFxdv01Px3MocPD0LSvrlidJhtKuGjJ+I4Tq1Fad7oD TQrBQ8j8nEhsCt3HOZebNQ5nI58b0efJrjqbmAdUvdnZtYLxLoz6gXpj/rvB+JnsToSr PTnQA2ZfVSsxKvFacKDCFvMyEA9gZjrSx3hSOCLhwDskC+AbqOah61aJBbh2DmTa5QSW cR2FPyxFwFUumQeEuQAzqPJ55MqYxusjQTCNxspUlWyMtAbbchl6mCQV5EobL9dVgjFe PLxDo4qIc8dq3tLrbm3iz9Mfy06UEG4qXTcL/eWy6dhy9N4pvHaK769YB+aaN7bhY9hb /KiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZksCrGAFNV1cp5fNAjOeChv/ObleQzDSf9UKT67Aoa0=; b=Gjc7i9ktAjmZQyyZ1jj0gQ94GOq2gSJoo+POruUcXqnBzc3FzLa11b3AIqHtoeIEXn BxDTOpXrZz/x7xzyVNh4c8GaHHRNo96Cy9AOGpI1OWzUtYBKjYwd6wvQczZEU4lpR8ub mzV8RK9yT3MMcIoR2XARCysF3p5JrMOr/6rBenIrpc/Sk/YxSBqEGr5HYAgwavt4hoWW nOtbS/2IGVdfh47ls+3qEnwMSTEbs17lndqdowC+vTMn898V14TGi+BWdyK+tdb3PfkH 71gA8fU/Itt5ohwz2an9kUlv8Lbau456Fn3cEKd6DKPTdT67AsxibjKjQVl3W490XyVX yKgQ== X-Gm-Message-State: APf1xPDPSf2R+EGuhMzy5kGHFod9vK/8O9CtIieG5SSXnV052RHO/CEj sJ8pTSaO+WWlIWguDgPwPl1avcsg1ESJ+H+SqSA= X-Google-Smtp-Source: AG47ELvYbZ0O6Hg8iQXwHaRY3nbI/Fk2vbpIuKwVjWo4nkdIbp2or2SQbGxWUf8K5Bld4NO+40cQGfTKEWArpd4gLxs= X-Received: by 10.107.181.133 with SMTP id e127mr3098909iof.243.1519413613028; Fri, 23 Feb 2018 11:20:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.201.198 with HTTP; Fri, 23 Feb 2018 11:20:12 -0800 (PST) In-Reply-To: <3290585E-2C55-4F8A-A82B-06B6F509ED2A@dukhovni.org> References: <151800968634.4877.12510609339415982154.idtracker@ietfa.amsl.com> <4c90bb83-5ba1-8193-df67-38e25f76caf8@nlnetlabs.nl> <0FA4B497-4B9A-421B-A9A6-2FEB62D3E41A@dukhovni.org> <3290585E-2C55-4F8A-A82B-06B6F509ED2A@dukhovni.org> From: Shumon Huque Date: Fri, 23 Feb 2018 14:20:12 -0500 Message-ID: To: Viktor Dukhovni Cc: TLS WG , The IESG , draft-ietf-tls-dnssec-chain-extension@ietf.org, tls-chairs Content-Type: multipart/alternative; boundary="001a11444c72abea0a0565e60c82" Archived-At: Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-dnssec-chain-extension-06=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 19:20:16 -0000 --001a11444c72abea0a0565e60c82 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 22, 2018 at 12:21 PM, Viktor Dukhovni wrote: > > > My comments are less about middleboxes (TLS-terminating corporate > proxies trusted by the user's browser) and more about unwanted > active MiTM attacks. If the MiTM attacker has obtained WebPKI > (PKIX) certificates for the destination, then this new extension > will not protect the user even when the destination has TLSA > records, because the server can deny their existence (not offer > the extension) without proof. > > What makes this case different is that the na=C3=AFve mental model > of what it offers is support for DANE-based peer authentication > equivalent to doing the DNSSEC lookups on the client end, but > with DNSSEC tunneled via the server. > > Therefore, some text is probably warranted to disabuse the reader > of such a na=C3=AFve view. What one gets with this extension, in the > more typical cases in which DANE is not "mandatory", is not > equivalent to enforcing DANE when it is published by the peer. > Rather, what one gets is the ability to use DANE to authenticate > sites that one might not otherwise be able to authenticate (no > shared WebPKI trust-anchor). > Yes, I agree that some elaboration on this limitation of the protocol is useful. In case you missed it, I do actually document the limitation quite explicitly in Section 8, which I'll excerpt here: "This protocol currently provides no way for a server to prove that it doesn't have a TLSA record. Hence absent whitelists, a client misdirected to a server that has fraudulently acquired a public CA issued certificate for the real server's name, could be induced to establish a PKIX verified connection to the rogue server that precluded DANE authentication. This could be solved by enhancing this protocol to require that servers without TLSA records need to provide a DNSSEC authentication chain that proves this (i.e. the chain includes NSEC or NSEC3 records that demonstrate either the absence of the TLSA record, or the absence of a secure delegation to the associated zone). Such an enhancement would be impossible to deploy incrementally though since it requires all TLS servers to support this protocol." But perhaps it needs to feature more prominently in the document rather than being buried in the context of a discussion about mandating the use of this extension. The limitation exists independent of whether a TLS application is trying to mandate things. My suggestion is to move this discussion to the beginning of the Security Considerations section, and then adding some of your elaborating points, including a direct comparison with clients querying DANE records themselves. It might also be worth a brief mention in the Intro section that the protocol lacks authenticated denial and pointing the reader/implementer to the Security Considerations section for more details. Shumon Huque --001a11444c72abea0a0565e60c82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 22, 2018 at 12:21 PM, Viktor Dukhovni <ietf-dane@dukhovni.org= > wrote:

My comments are less about middleboxes (TLS-terminating corporate proxies trusted by the user's browser) and more about unwanted
active MiTM attacks.=C2=A0 If the MiTM attacker has obtained WebPKI
(PKIX) certificates for the destination, then this new extension
will not protect the user even when the destination has TLSA
records, because the server can deny their existence (not offer
the extension) without proof.

What makes this case different is that the na=C3=AFve mental model
of what it offers is support for DANE-based peer authentication
equivalent to doing the DNSSEC lookups on the client end, but
with DNSSEC tunneled via the server.

Therefore, some text is probably warranted to disabuse the reader
of such a na=C3=AFve view.=C2=A0 What one gets with this extension, in the<= br> more typical cases in which DANE is not "mandatory", is not
equivalent to enforcing DANE when it is published by the peer.
Rather, what one gets is the ability to use DANE to authenticate
sites that one might not otherwise be able to authenticate (no
shared WebPKI trust-anchor).

Yes, I agr= ee that some elaboration on this limitation of the protocol
is us= eful. In case you missed it, I do actually document the limitation=C2=A0
quite explicitly in Section 8, which I'll excerpt here:

=C2=A0 =C2=A0"This protocol currently provides = no way for a server to prove that it
=C2=A0 =C2=A0doesn't hav= e a TLSA record.=C2=A0 Hence absent whitelists, a client
=C2=A0 = =C2=A0misdirected to a server that has fraudulently acquired a public CA
=C2=A0 =C2=A0issued certificate for the real server's name, cou= ld be induced to
=C2=A0 =C2=A0establish a PKIX verified connectio= n to the rogue server that
=C2=A0 =C2=A0precluded DANE authentica= tion.=C2=A0 This could be solved by enhancing
=C2=A0 =C2=A0this p= rotocol to require that servers without TLSA records need to
=C2= =A0 =C2=A0provide a DNSSEC authentication chain that proves this (i.e. the<= /div>
=C2=A0 =C2=A0chain includes NSEC or NSEC3 records that demonstrat= e either the
=C2=A0 =C2=A0absence of the TLSA record, or the abse= nce of a secure delegation to
=C2=A0 =C2=A0the associated zone).= =C2=A0 Such an enhancement would be impossible to
=C2=A0 =C2=A0de= ploy incrementally though since it requires all TLS servers to
= =C2=A0 =C2=A0support this protocol."

Bu= t perhaps it needs to feature more prominently in the document=C2=A0
<= div>rather than being buried in the context of a discussion about mandating=
the use of this extension. The limitation exists independent of = whether=C2=A0
a TLS application is trying to mandate things.

My suggestion is to move this discussion to the beginn= ing of the
Security Considerations section, and then adding some = of your
elaborating points, including a direct comparison with cl= ients querying=C2=A0
DANE records themselves. It might also be wo= rth a brief mention in the
Intro section that the protocol lacks = authenticated denial and pointing
the reader/implementer to the S= ecurity Considerations section for more=C2=A0
details.
=
Shumon Huque

--001a11444c72abea0a0565e60c82-- From nobody Fri Feb 23 14:31:45 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19312126BF7; Fri, 23 Feb 2018 14:31:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.72.4 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-tls-record-limit@ietf.org, Sean Turner , Kathleen.Moriarty.ietf@gmail.com, tls@ietf.org, sean@sn3rd.com, tls-chairs@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151942510509.13699.10296913954231691028.idtracker@ietfa.amsl.com> Date: Fri, 23 Feb 2018 14:31:45 -0800 Archived-At: Subject: [TLS] EXTENDED Last Call: (Record Size Limit Extension for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 22:31:45 -0000 The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Record Size Limit Extension for Transport Layer Security (TLS)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-03-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract An extension to Transport Layer Security (TLS) is defined that allows endpoints to negotiate the maximum size of protected records that each will send the other. This replaces the maximum fragment length extension defined in RFC 6066. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Sun Feb 25 17:39:07 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839F4127275 for ; Sun, 25 Feb 2018 17:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 49BVEaLc_t4U for ; Sun, 25 Feb 2018 17:39:04 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E4721271FD for ; Sun, 25 Feb 2018 17:39:04 -0800 (PST) Received: by mail-oi0-x22d.google.com with SMTP id x12so9522248oie.13 for ; Sun, 25 Feb 2018 17:39:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=tlWn9XpbzQ9on3NnprH/sgscP4ctSjytUKmW3rXb1G8=; b=VxuUBDq40nNA3VuptzIoTIqfPZJjwrtQoY0d3ijIx/oiZOP6WBnYLJv6N2FzcTz8DW BrjeHwQ93wBk8J387y25gFXIzwdA0uKFzMBqmcnaPjn6YEIrk2Y5frH01E78yPIkpkv/ yOnAHD0vU0/j0hlAcs6aSXVouDfvqM4NK68XMNBm0iNSKG5IQuiHoNmZDKrYHUX+rYDk oluiVtc7ArEPoQOCfWQETzCfUNjcWiX9Mzyw8+zl2qmqy1mk7Fe2Mz5K5ghPCdsUxEyK 4O/II1vBihKKahOCE5t+2OLmuFdPvdqZqc9ZJvSUBG2CMe1jwaNpdg+QaK7re+6xX+TA WTlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=tlWn9XpbzQ9on3NnprH/sgscP4ctSjytUKmW3rXb1G8=; b=ANqODeY7zfyzXeXmwGsWwNHnWcXXXXlI1GZl+vWCFkrr+16Txc8tfJUpk8wtWkgKLu aczyfCdNdVwspAeuDVhmmBbE/PT9Ag0NODmYkI66KNLso3zx2s0dSGwDhwn6DpLgNrYr zyrY+ZrllbMvIedhrXCWfq3uCoxyB6FMdgZpFUPhjSmT4/fQONh3Db5GPNiSm4/oFBWw tlkMoHEritEABAHVKlg0+ngDsUr0oAA7wAlIaiGPyazdILw12iqe05na/333u4OX5SJY MZCJ+j2s4uSc9/5eOeqZzUSqpqsMpdWF/ICedNFN6tvG1UO6SpbxNmF49lgUc+bjWwx8 VQmg== X-Gm-Message-State: APf1xPDZkQ6ukILkNPrQ7reOYXpwFmrtS0+0kRuPs6J5qNAcYxegHvD5 keKjmXTC4PM2ASytaTRuG6Rf7NsYCAM+B0x7Nnh/4490 X-Google-Smtp-Source: AG47ELtgJ361etJ/piVmxiZPhvABluz2Yb0j0PL2soPBDa9NxjMn++wmGGHvvU7aRrJsTwBNKDWobcRT0KWyfTLg0wE= X-Received: by 10.202.56.214 with SMTP id f205mr5362957oia.254.1519609143309; Sun, 25 Feb 2018 17:39:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.16.85 with HTTP; Sun, 25 Feb 2018 17:39:02 -0800 (PST) From: Martin Thomson Date: Mon, 26 Feb 2018 12:39:02 +1100 Message-ID: To: "" Cc: Alan DeKok , Benjamin Kaduk Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] Multiple records in record limit (was: Secdir review) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 01:39:05 -0000 Out of the secdir review (thanks again Alan!), I realized that the draft never actually said this: PMTU governs the size of UDP datagrams, which limits the size of records, but does not prevent records from being smaller. An endpoint that sends small records is still able to send multiple records in a single UDP datagram. I think that I should add that explanation. Does anyone think that this should go further and advise against putting multiple records in the same datagram? From nobody Sun Feb 25 18:13:16 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C6C127275 for ; Sun, 25 Feb 2018 18:13:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 zvII6EaBw1Wn for ; Sun, 25 Feb 2018 18:13:14 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54E6120713 for ; Sun, 25 Feb 2018 18:13:13 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id l206so17369479qke.1 for ; Sun, 25 Feb 2018 18:13:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mLiUEC/JRiPf47aedqCjkdz46z2JMr33tj7xHUPj5ZM=; b=lflYjHPiFhj2rnB1B5AhgFFgEnvO3eiEZnB2ldS7j/FjYrI99JimMMcg2NaZahyB+X 6O15ZD32rxQDqDDt6ghBm1NVWXB98IxhJq1K8UguqScyg1qqbFuFQ13gAr+0RF+Nk+b8 G+Fh1ky3QkZzfrC7hjBPww299LPlQFIhQueouZY5OKtCwcMo1PMHP4J/n3b88XzbHWHf IXih/NoatZGal6783UYFem3Irp2oG8cdK4lKvKVGaXdlYhCIjz+/px2/Bny9DBN5V4// 0bbgxTFhQIv+PLtptsnioNzxyNv0fcWeoACIkWv0rGlOLmnk8LZzmJRalqfDRabLQGiZ 38sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mLiUEC/JRiPf47aedqCjkdz46z2JMr33tj7xHUPj5ZM=; b=bTCmoRhXJ3kxS+aKoSEagmVvZkveomIsvVEEXU0H1y4Fu/kotcLKVXc4leQ5NOKaC+ UMb9lOxd9mLOTcAapY8UYfN0OE+rgAPk/yTxnuUyfUc/xffdrxTsaryQDI3xE8SR0FMX CcrZXJDiZDff5Ihc6nZYaH5nXvMHETC74D7w8uHpF3R10gWkyZ8/pobfG+Xaa8jxKtvD pA++t4Aez+jAkwIiQrH7O5ik+vkLvVRF25d2mSFUxLw+XrlMJJnZofk/M9QsvO1rOJzR Ww1u1/b9E4f19dA18H5He8RnxqFnqw/CfHi86KQYeVq4Bab2cyGf8GGJcahmhjwaBuKE qgzQ== X-Gm-Message-State: APf1xPAWvmtoLxzed4BuNhQHOef3FDX3nXitoba0m7HJhaMuA8Xrq9im /oXe0CxBkwySj1fm2a2bVzIK2VW6vs0s9PVrn+dXCg== X-Google-Smtp-Source: AG47ELtMGZP/PvCAEypYs7frl3rmi9b6uxmZWS98ZmKJxiFtUdOzJPUyUuWVLY9CShfyb8DKvorFVpD/Ug9q9E7QGFg= X-Received: by 10.55.221.198 with SMTP id u67mr14974697qku.91.1519611192924; Sun, 25 Feb 2018 18:13:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.176 with HTTP; Sun, 25 Feb 2018 18:12:32 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Sun, 25 Feb 2018 18:12:32 -0800 Message-ID: To: Martin Thomson Cc: "" , Benjamin Kaduk , Alan DeKok Content-Type: multipart/alternative; boundary="001a114992e059fe160566140d5f" Archived-At: Subject: Re: [TLS] Multiple records in record limit (was: Secdir review) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 02:13:15 -0000 --001a114992e059fe160566140d5f Content-Type: text/plain; charset="UTF-8" I think this is the right answer. -Ekr On Sun, Feb 25, 2018 at 5:39 PM, Martin Thomson wrote: > Out of the secdir review (thanks again Alan!), I realized that the > draft never actually said this: > > PMTU governs the size of UDP datagrams, which limits the size of > records, but > does not prevent records from being smaller. An endpoint that sends > small > records is still able to send multiple records in a single UDP datagram. > > I think that I should add that explanation. > > Does anyone think that this should go further and advise against > putting multiple records in the same datagram? > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114992e059fe160566140d5f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think this is the right answer.

-Ekr<= /div>


On Sun, Feb 25, 2018 at 5:39 PM, Martin Thomson = <martin.th= omson@gmail.com> wrote:
Out= of the secdir review (thanks again Alan!), I realized that the
draft never actually said this:

=C2=A0 =C2=A0PMTU governs the size of UDP datagrams, which limits the size = of records, but
=C2=A0 =C2=A0does not prevent records from being smaller.=C2=A0 An endpoint= that sends small
=C2=A0 =C2=A0records is still able to send multiple records in a single UDP= datagram.

I think that I should add that explanation.

Does anyone think that this should go further and advise against
putting multiple records in the same datagram?

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a114992e059fe160566140d5f-- From nobody Mon Feb 26 02:28:25 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320DA12D7F6 for ; Mon, 26 Feb 2018 02:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 KmRKWF8Xzl1F for ; Mon, 26 Feb 2018 02:28:22 -0800 (PST) Received: from mail-wr0-f173.google.com (mail-wr0-f173.google.com [209.85.128.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49263126D74 for ; Mon, 26 Feb 2018 02:28:22 -0800 (PST) Received: by mail-wr0-f173.google.com with SMTP id k9so20608702wre.9 for ; Mon, 26 Feb 2018 02:28:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=rPh1hY2bNk6fHyvTnhjykYWs+CNtfVziFTuWaRdZmqM=; b=e5MZS1rLnPeAmoZBwKwDw8EL5D0hOgpgfZfgrG+esh5CjKRbICUY2lG1GOfNm1G4/B xlGmnWCHBZyun1Vk2J1GkyO/2Tn4LhhwFsinCm+w7BE45mugFKTBwZje/6aw9E646w25 EwWXKrst3w/bpJ8PDGa+31epZ6YSClISKKT7TN9mGWUsWvRHfOwI5cBn9Nv0HvCtL5RA AFBJE3GwxukcKjjfWEDdbhBXLqB6i1RMcopVP9DCXmfXCuCaprNmTP7WtH5WU7zFGhJF DTeHIPcUgIfnKPL8KQatfM8mb3Wua3WPf9bZKcs+eTWSvpf2Nj2+gugYv7HBkkwJfWtw 7HfA== X-Gm-Message-State: APf1xPCOOOzTOnL70njGrdvslSBFHEh6CwQc0IbzKof6ECaroH/v+T76 Exhs+jT33bFq/oQ69IjT0BYHU828VMQ= X-Google-Smtp-Source: AH8x227cmhpO17cP0zUHNLMW/WFIIXUTcx+dIlitA/eXdL0Usn6bOCYmRs0jjk01udvCqbnPyhUFcg== X-Received: by 10.223.136.72 with SMTP id e8mr8407188wre.163.1519640899971; Mon, 26 Feb 2018 02:28:19 -0800 (PST) Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id l11sm6167912wrg.71.2018.02.26.02.28.19 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 26 Feb 2018 02:28:19 -0800 (PST) Message-ID: <1519640898.10011.48.camel@redhat.com> From: Nikos Mavrogiannopoulos To: tls@ietf.org Date: Mon, 26 Feb 2018 11:28:18 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.5 (3.26.5-1.fc27) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Multiple records in record limit (was: Secdir review) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 10:28:24 -0000 On Mon, 2018-02-26 at 12:39 +1100, Martin Thomson wrote: > Out of the secdir review (thanks again Alan!), I realized that the > draft never actually said this: > > PMTU governs the size of UDP datagrams, which limits the size of > records, but > does not prevent records from being smaller. An endpoint that > sends small > records is still able to send multiple records in a single UDP > datagram. > > I think that I should add that explanation. > > Does anyone think that this should go further and advise against > putting multiple records in the same datagram? I'm not sure which part of the protocol text this would refer to, but DTLS1.2 says in https://tools.ietf.org/html/rfc6347#section-4.1.1 ``` Multiple DTLS records may be placed in a single datagram. They are simply encoded consecutively. ``` so even though I agree that the advice against putting multiple records in the same datagram is a good one (I'm not even sure if that works today with existing implementations), the advice seems against the original protocol. Shouldn't that text be in the upcoming DTLS1.3 rather than an update like record size limit which seems unrelated? regards, Nikos From nobody Mon Feb 26 06:27:19 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B37112D7F0; Mon, 26 Feb 2018 06:27:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 ukI9f729S0ND; Mon, 26 Feb 2018 06:27:13 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 7BAA31242F5; Mon, 26 Feb 2018 06:27:13 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3zqkg11hPqz3Jb; Mon, 26 Feb 2018 15:27:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1519655229; bh=KKstflm6oIOxOyw5bfdIw0D5tJg/LXv4x4qVfjCTb3c=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=jJ6jRsmvniv6NnHCsq7/znfbvNC/yvFfCpRb6krfCOEaeV2iTKGqjZGJ5C5KFERYh Lw0lKsW4xR97pmY0fdi7Ee4hBa3ck3pik+yzM1JjtZ5UIh7wJR6+2Fu8KvIOEL1cda v9ZGu7kz35N+IX7nzVODbNE1h+4/lg9XlMGKAzkE= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id PwOE2YSbr7ti; Mon, 26 Feb 2018 15:27:01 +0100 (CET) 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 mx.nohats.ca (Postfix) with ESMTPS; Mon, 26 Feb 2018 15:27:00 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id ECCC92BA295; Mon, 26 Feb 2018 09:26:59 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca ECCC92BA295 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DF79E40D7001; Mon, 26 Feb 2018 09:26:59 -0500 (EST) Date: Mon, 26 Feb 2018 09:26:59 -0500 (EST) From: Paul Wouters To: Shumon Huque cc: Eric Rescorla , TLS WG , draft-ietf-tls-dnssec-chain-extension@ietf.org, The IESG , tls-chairs In-Reply-To: Message-ID: References: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 14:27:17 -0000 On Thu, 22 Feb 2018, Shumon Huque wrote: > On Wed, Feb 21, 2018 at 2:48 PM, Paul Wouters wrote: > On Wed, 21 Feb 2018, Shumon Huque wrote: > > Okay, got it. For people that have already implemented this, I think > there has been an implicit understanding that the format of the chain > data is a sequence of concatenated wire format RRs exactly as they appear > in a DNS message section > > > Note, I would not call it "sequence of concatenated wire format RRs", as > it is simply the wireformat of a DNS message. > > The fact that some parts > are concatenated RR's is just part of the wireformat of the DNS reply > message. That is, this isn't introducing some new form of concatenated > content - it is _just_ a regular DNS wire format message, and the > document should not go deeper into its explanation. > > > It would _not_ be correct to say that this is a "DNS wire format message" - that  > would mean there is a DNS header section with flags and response codes,  > and other sections. The chain data structure as currently specified really is  > concatenated wire-format RRs (as they appear _within_ a DNS message  > _section_). Let me know if that is unclear in the draft (or my proposed edits). So it was decided to not use a full DNS packet format? And then since you miss the structure of the Answer Section and Additional/Authority Section, you require the "answer RR's" come first where you basically emulate an Answer Section? Isn't that an indication that we should really use the wireformat of an entire DNS message here? Maybe some DNS library/tools people can chime in here to tell us if this matters much to them (assuming they are adding support for creating/consuming these chains of RRsets in wire format. I am personally a little sad we cannot have a dig +chainquery command where we write out the entire answer packet format to a blob, to be loaded by the TLS server. And where a TLS client cannot just hand over the blob "as if it came in as a reply from a DNS server" to its DNS/cache receiving code path. > I recall at one point way back there was a discussion about whether the chain > data should just be a fully formed DNS message, but I don't believe that idea > had much support in the working group (personally I would have been fine with  > that choice too, if it did have support). Do you remember why not? I'll see about checking the archives, but to me the hint that you are losing information and require some kind of ordering seems to suggest there is a need for using the full DNS message reply format. > There is some residual wording in the draft about ordering of CNAMEs etc in > the answer records part. Assuming the WG agrees, I am fine with relaxing > that requirement - that ended up in there because although there is no defined > ordering of RRs within a DNS message section, as a practical matter CNAMEs > are almost always ordered since there are some DNS queriers that get confused  > otherwise. This is a new protocol though, so we can be more faithful to the DNS  > spec. I would prefer the residual wording to go away. Any hints at order being important should be squashed. > I don't think getting unrelated DNSSEC records would be an issue. TLS > has its maximum sizes for the handshake. In fact, it could allow the > extension to have some useful data in the case of MX or SRV.  (and could > be a feature to build a nice resolver over TLS using 1 tor circuit). > > The draft currently doesn't address the MX or SRV use case. I suggest > that we tackle that in a future version. Jus make sure the document doesn't forbid any such data, and allow the client to ignore these or put them in the cache as it sees fit. > I'm also not sure about the talking of unsigned CNAME records from > DNAME. The above pseudo code (extended with special cases) should be > in some DNS library, and that library will know what records to expect > unsigned which are proven by the DNAME (or wildcard) synthesis and knows > when/if to add it to the validated cache. I don't think that should be > explained in this RFC at all. The DNS implementation does not need > to be specified in this document and it should just focus on saying > that "the DNS message response is validated and upon validation the > content can be considered DANE validated". > > > Where we ended up, is that WG participants asked for some level of DNSSEC > detail to be included in this doc. Again, that will only lead to bad implementations. There should be no need to update this document once something like ANAME, ALIAS or ZNAME is introduced to the DNS. So you should not talk about these things at all. TLS client should use a dns library that knows these things, or if they want to write one from scratch, these implementors should look at the DNS RFCs and not this RFC for guidance on how the DNS protocol works. Paul From nobody Mon Feb 26 07:48:52 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B3B126FB3 for ; Mon, 26 Feb 2018 07:48:49 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 D5AIjZM2iRMg for ; Mon, 26 Feb 2018 07:48:40 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 6F501120725 for ; Mon, 26 Feb 2018 07:48:40 -0800 (PST) Received: from [192.168.20.124] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [99.248.225.186]) by mail.networkradius.com (Postfix) with ESMTPSA id 44CB02022; Mon, 26 Feb 2018 15:48:39 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Mon, 26 Feb 2018 10:48:35 -0500 Cc: "" , Benjamin Kaduk Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Martin Thomson X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] Multiple records in record limit (was: Secdir review) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 15:48:49 -0000 On Feb 25, 2018, at 8:39 PM, Martin Thomson = wrote: >=20 > Out of the secdir review (thanks again Alan!), I realized that the > draft never actually said this: >=20 > PMTU governs the size of UDP datagrams, which limits the size of = records, but > does not prevent records from being smaller. An endpoint that sends = small > records is still able to send multiple records in a single UDP = datagram. >=20 > I think that I should add that explanation. >=20 > Does anyone think that this should go further and advise against > putting multiple records in the same datagram? Yes. I don't think there's any good reason for that kind of = behaviour. Alan DeKok. From nobody Mon Feb 26 08:12:00 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08832127078 for ; Mon, 26 Feb 2018 08:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 BIl2NzwlBC_w for ; Mon, 26 Feb 2018 08:11:56 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B631E124217 for ; Mon, 26 Feb 2018 08:11:56 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id n12so13617qtl.5 for ; Mon, 26 Feb 2018 08:11:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OoUej061NGuBIObBwJLm7zRnxbYqoMVGe+fCPpQ148U=; b=tFapQu9pDsskMcqfGaT0I/c2uIoBQswOJmet2/PCPCKB4s/sMxWgGOZzqn9g8FBgFa 7yqRA4o+A0rhgPdfQJpyok3RC0XgJblP2pufhVd1YyFL96jWbm6asuShbtaJFtH1xBXT 3Lz8lZppfetF9EqFwhZ9mNyHWH3RDn2yupiBVG3PX0ZAAwBsgxPOVtmSc4HEghfxw8BV PzBZXD1srkAleKOp+Bk8mPZo1wfT4cSrkrdDVMPbCjQOYwU7vskUFIYhcsx6bYs/Hlc8 5KYgrulH2192yUfON/NIz+9MPbD7FnPSzptwAvuwH7OqZF2Yz/vubIHQfrIMyM3881SL 3EWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OoUej061NGuBIObBwJLm7zRnxbYqoMVGe+fCPpQ148U=; b=lV2Q25MTo8NbYyVCkAwMs52kno40dH1UP3/2TKY2W5Qz41WNhn3sdEz79mUMJFme28 ZrHuO0HDxlgEmQziUZTNhrhFnUrhr4r0V4c4SlxO0sIZY1ODKrfsOystKJLxW03ieXe3 K9SUxRgjzzyCe9f/1IhwkZnfuxxJtsihcGWOemKjUf6aXsIxIlZ0T2qsMgdQB5NsOduQ M4NvahehPdR7bOm5XK9xcMcYB5iFlD8G0erokGfx+vp+v8HciispiDHaRF+lk0Tbw/GU js21qR0RxuR64adrMepMsGWvyu5nU2PtY8DizkDE/0wGFYAw1nUc5j8z7EKFFnqaGGb2 OkYQ== X-Gm-Message-State: APf1xPAUnViTRwpqI6PBdqFMlVXgYmLt3AFErUKERY+rqnQSwN2BJgQu dtVMqyM5NlUuPXgnL3Czw6erS1HOXaCUnepY0Dz0Gw== X-Google-Smtp-Source: AG47ELukFpKPHq7L0wViMvJIR1GUIJph/kg/sI+7RyAjTNZ8TsyVP3u05d+C3xGgNT0Y2hS/KfN+MMkgVBZ5g6fsUOs= X-Received: by 10.237.56.34 with SMTP id j31mr18729334qte.208.1519661515810; Mon, 26 Feb 2018 08:11:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.176 with HTTP; Mon, 26 Feb 2018 08:11:15 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Mon, 26 Feb 2018 08:11:15 -0800 Message-ID: To: Alan DeKok Cc: Martin Thomson , "" , Benjamin Kaduk Content-Type: multipart/alternative; boundary="001a113b7f18d447a405661fc4fb" Archived-At: Subject: Re: [TLS] Multiple records in record limit (was: Secdir review) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 16:11:59 -0000 --001a113b7f18d447a405661fc4fb Content-Type: text/plain; charset="UTF-8" On Mon, Feb 26, 2018 at 7:48 AM, Alan DeKok wrote: > On Feb 25, 2018, at 8:39 PM, Martin Thomson > wrote: > > > > Out of the secdir review (thanks again Alan!), I realized that the > > draft never actually said this: > > > > PMTU governs the size of UDP datagrams, which limits the size of > records, but > > does not prevent records from being smaller. An endpoint that sends > small > > records is still able to send multiple records in a single UDP > datagram. > > > > I think that I should add that explanation. > > > > Does anyone think that this should go further and advise against > > putting multiple records in the same datagram? > > Yes. I don't think there's any good reason for that kind of behaviour. > There actually are. One example is packing handshake and data records in the same datagram. -Ekr > Alan DeKok. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113b7f18d447a405661fc4fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Feb 26, 2018 at 7:48 AM, Alan DeKok <aland@deployingra= dius.com> wrote:
On Feb 25, 2018, at 8:39 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
>
> Out of the secdir review (thanks again Alan!), I realized that the
> draft never actually said this:
>
>=C2=A0 =C2=A0PMTU governs the size of UDP datagrams, which limits the s= ize of records, but
>=C2=A0 =C2=A0does not prevent records from being smaller.=C2=A0 An endp= oint that sends small
>=C2=A0 =C2=A0records is still able to send multiple records in a single= UDP datagram.
>
> I think that I should add that explanation.
>
> Does anyone think that this should go further and advise against
> putting multiple records in the same datagram?

=C2=A0 Yes.=C2=A0 I don't think there's any good reason for = that kind of behaviour.

There actually = are. One example is packing handshake and data records in the same datagram= .

-Ekr


=C2=A0 Alan DeKok.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a113b7f18d447a405661fc4fb-- From nobody Mon Feb 26 09:20:50 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331B1124BFA; Mon, 26 Feb 2018 09:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 2NyZk_sJzLuy; Mon, 26 Feb 2018 09:20:43 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A73BA12025C; Mon, 26 Feb 2018 09:20:43 -0800 (PST) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id E9CF67A3309; Mon, 26 Feb 2018 17:20:36 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: Date: Mon, 26 Feb 2018 12:20:36 -0500 Cc: tls-chairs , draft-ietf-tls-dnssec-chain-extension@ietf.org, The IESG Content-Transfer-Encoding: quoted-printable Message-Id: <9CE8B6BF-CAC0-46AE-B5FC-AF3D45EF9DBC@dukhovni.org> References: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com> To: TLS WG X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Feb 2018 17:20:45 -0000 > On Feb 26, 2018, at 9:26 AM, Paul Wouters wrote: >=20 > So it was decided to not use a full DNS packet format? And then since = you > miss the structure of the Answer Section and Additional/Authority > Section, you require the "answer RR's" come first where you basically > emulate an Answer Section? >=20 > Isn't that an indication that we should really use the wireformat of = an > entire DNS message here? Maybe some DNS library/tools people can chime > in here to tell us if this matters much to them (assuming they are > adding support for creating/consuming these chains of RRsets in wire > format. >=20 > I am personally a little sad we cannot have a dig +chainquery command > where we write out the entire answer packet format to a blob, to be = loaded by > the TLS server. And where a TLS client cannot just hand over the blob > "as if it came in as a reply from a DNS server" to its DNS/cache > receiving code path. The latter would require compression support on the receiving side, = which has been specifically excluded so far. I am not against making the data more compact, though it is rather late in the process, but I have a more pressing issue. I think that as it stands, lack of authenticated denial of existence is a *fatal* flaw in the protocol. I just don't see a sufficiently = practical scenario in which this extension confers a useful security benefit. Perhaps this draft should go back to the working group, to consider a = new protocol element, by which the server commits to support the extension = for a time that is substantially longer than the underlying DNS TTLs. = During this time (suggested to be weeks or months, when in production after = initial testing), the server MUST support the extension and respond with EITHER = a valid TLSA RRset chain, or with a valid denial of existence. The protocol, thus extended, can then be seen as a more robust form of = key pinning, in which pins are stored server-side, and only the fact that pinning is expected is stored client-side (for any length of time, the client may still do short-term caching of TLSA RRs based on the DNS = TTL). The protocol is still subject to downgrade (to PKIX) on first contact, but is this a common element of all protocols that bootstrap security on first use. Indeed the WebPKI itself is largely TOFU as most certs (which are predominantly DV certs) are issued by CAs based on rather weak initial evidence. --=20 Viktor. --=20 Viktor. From nobody Tue Feb 27 06:11:42 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69116126DC2 for ; Tue, 27 Feb 2018 06:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 j8BPpUwopQ-z for ; Tue, 27 Feb 2018 06:11:34 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E819712D88F for ; Tue, 27 Feb 2018 06:11:31 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id m13so18528247qtg.13 for ; Tue, 27 Feb 2018 06:11:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=P8EoEDAvxEQC9HyWfuLLd9QoJi+dC//ewrC7L0UQG3I=; b=YpzKYaSYN89bbww3vcluisYY7vE4vKHFEFdufM6PrPgeBzGhxY+/DSNXCVeEPyTJ/U Bq+pmX8UbK2GwpnF43ZzC7hdPc8kWv3aWg9hY+jZhICsYBrw3E+a/F/I2Zjfc3+0isff v4XKIm3KTzZkZIRzpn+dnz9I057g0Sc1jmzQM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=P8EoEDAvxEQC9HyWfuLLd9QoJi+dC//ewrC7L0UQG3I=; b=krvmFTuPjWrAU6PWhHLAttswkPPrkhBIgTFmFBdMyPN4rgqnBjKcrQZECSlLpM4+6S EtCbHlj7HxkWPEkhnLiipVdWJZpw+3jwwFI9L7sBBW48IJwW1xgfY+wvB3EMY+qZGuWu UwZk3+5jnOlAFzMdn/0OBV+DZIoyhP2iyFTf1ck1fzJ6vEX81/W/hn/kuJ+Q3gkFVO5i AvyXmWKP5LzVuXj5EcC7Iboop/uUe+aoE/66N8W2kD9KqDWK3yrHMfVm/4bwbR2SiQ8f NtadWWxtl7zGPu1GfGY4SMk4ADfMtIm/i8q0nQOrXGn2ZuQj0UXdcpooYcWp8xabmX2W ElhQ== X-Gm-Message-State: APf1xPDhCSqHQHqftXdvUqmXM4gn4SNWAiofPYUX08BhgTMFUJ0RFmm7 bILsJcoljo3wsYEOmq3IcNzj2w== X-Google-Smtp-Source: AG47ELt2VSIrJvqRdtqVgsNSb+KXURrYVUverCnaJedkattLXfrxDPHN209OoMcOBQ1i/UNr8J2AtQ== X-Received: by 10.200.55.233 with SMTP id e38mr23626052qtc.158.1519740691018; Tue, 27 Feb 2018 06:11:31 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id r51sm7008039qtr.93.2018.02.27.06.11.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Feb 2018 06:11:30 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: <151915624732.3939.12189669437030269709@ietfa.amsl.com> Date: Tue, 27 Feb 2018 09:11:28 -0500 Cc: gen-art@ietf.org, ietf@ietf.org, draft-ietf-tls-iana-registry-updates.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <151915624732.3939.12189669437030269709@ietfa.amsl.com> To: Stewart Bryant , "" X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Genart last call review of draft-ietf-tls-iana-registry-updates-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 14:11:35 -0000 > On Feb 20, 2018, at 14:50, Stewart Bryant = wrote: >=20 > Reviewer: Stewart Bryant > Review result: Ready with Issues >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-tls-iana-registry-updates-05 > Reviewer: Stewart Bryant > Review Date: 2018-02-20 > IETF LC End Date: 2018-03-01 > IESG Telechat date: 2018-03-08 >=20 > Summary: A well written document that is difficult to check and easy = to make a > mistake with. There are a tiny number of editorial matters. The matter = of the > semantics of Recommended =3D no may need to further thought and = clarification. >=20 > Major issues: None >=20 > Minor issues: >=20 > I think convention is to list the documents being updated in the = Abstract, but > cannot find any formal guidance. You=E2=80=99re right that is the convention, but it=E2=80=99s not = required. draft-flanagan-7322bis is attempting to make including = updates in the abstract a must, but it=E2=80=99s not been through any = kind of LC yet. There is a sentence there saying that a lot of RFCs are = updated and to see the updates header so I think under the 7322 to = balance concise and to not include references I=E2=80=99m thinking this = is okay. > =3D=3D=3D=3D=3D=3D >=20 > If an item is marked as not recommended it does not necessarily mean > SB> Do you mean "marked as not recommended" or "not marked as = recommended=E2=80=9D. There are two states for the Recommended column: YES and NO. I can go = either way on whether marked as not recommended =3D NO not marked as recommended =3D NO WG - thoughts? > =3D=3D=3D=3D=3D=3D=3D > SB> I am worried about the semantics of Recommended =3D no. > SB> Presumably there are three states: recommended, not recommended, > SB> and silent/don't know/don't care/not yet. Which of these > SB> states does Recommended =3D no represent? There are two states and a draft that specifies a value in a registry = that has a Recommended column needs to state which it is. I=E2=80=99m = not too concerned because we can change the column value later if it = turns out a NO should have been a YES. > Nits/editorial comments: > Abstract >=20 > This document describes a number of changes to (D)TLS IANA = registries >=20 > SB> TLS is not a well known abbreviation and so needs expanding Right well I should fix that ;) I made the following tweak: OLD: (D)TLS NEW Transport Layer Security and Datagram Transport Layer Security = ((D)TLS) PR: https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/63 > =3D=3D=3D=3D=3D=3D=3D=3D >=20 > This document instructs IANA to make changes to a number of (D)TLS- >=20 > SB> TLS needs expanding See above. spt From nobody Tue Feb 27 06:12:22 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED5112D951 for ; Tue, 27 Feb 2018 06:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 mTJdhiD6fRxD for ; Tue, 27 Feb 2018 06:12:13 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 226E112D952 for ; Tue, 27 Feb 2018 06:11:49 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id s188so23642835qkb.2 for ; Tue, 27 Feb 2018 06:11:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0WFQrL4Z/jdtO/vivkCQ9GttGvfLSMXRaaUIjjbKsrY=; b=QHYaEKKqTQsCDN0IaHGu01o6f+9RsBLtV96yaoZgZmwd1SEk9QygDmIJFfO3Khx9xt OP+JPHHY2qsoSoaKJDI7drLrBBFJ+7xSonThIRBspwGEFDygo4Ge0piCyu8pDpyOlbcP c98zafOpa5XsVEWsMYUtTNS/eZDqXjh5fTOCA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0WFQrL4Z/jdtO/vivkCQ9GttGvfLSMXRaaUIjjbKsrY=; b=pOn5l0cYhai7NVG2/fuw8I2T9d8DNmILSes6YF7POsiRApAcpCWBgKlNGaYIbBF8KV Tuyf3amXDbOUrK6qEVKfztH/2HGzoRjOwT4OfAsr1RBUEahOZmkzlOPgkfbQ8a8JQXQe NjtA5/l2a8psGCxIdVJlc3wZW0ynSptmbLvSXw/aVKPOzfGki8N8w1AojIYU35kHCXLk 4RO6Sm+HnB5ddwzDz+a9zwScm8/lGuc+ZSOQkJ3BgL5Wp9z09wAXKsCIcHCzpq47jnlp 8Tv6WdjsdJzV0lF62FJQpIJNH+seg0mt4YyVrvFqDCIFPDjhtYoO/q9Y1mqwygY/XU4r 8w6A== X-Gm-Message-State: APf1xPCrSW9IXRna2HmqCaUeEXnCDN16MFgV90G5Z9qVpkc9Ci3+ggwT hYxijGGfG2Dasmkfpc6DvcuIqEazGZ4= X-Google-Smtp-Source: AG47ELtrNaeWRHxl+3hDNSpKVCsvZXDusxRPws3d3aREP7fbylICnCIetCrNeilDPxE5uwKxWYpmxQ== X-Received: by 10.55.163.8 with SMTP id m8mr23123628qke.13.1519740708179; Tue, 27 Feb 2018 06:11:48 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id r51sm7008039qtr.93.2018.02.27.06.11.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Feb 2018 06:11:47 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: <151912347695.29703.11473433478669184845@ietfa.amsl.com> Date: Tue, 27 Feb 2018 09:11:46 -0500 Cc: ops-dir@ietf.org, ietf@ietf.org, draft-ietf-tls-iana-registry-updates.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <151912347695.29703.11473433478669184845@ietfa.amsl.com> To: Dan Romascanu , "" X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Opsdir last call review of draft-ietf-tls-iana-registry-updates-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 14:12:15 -0000 > On Feb 20, 2018, at 05:44, Dan Romascanu wrote: >=20 > Reviewer: Dan Romascanu > Review result: Has Issues >=20 > I am the assigned OPS-DIR reviewer for this draft. The OPS DIrectorate = reviews > a great part of the IETF documents being processed by the IESG for the = OPS ADs. > Please treat with these comments as with all other IETF LC comments. = Please > wait for direction from your document shepherd or AD before posting a = new > version of the draft. >=20 > This document which updates several TLS and DTLS RFCs describes a = number of > changes to TLS IANA registries that range from adding notes to the = registry all > the way to changing the registration policy. This is not a protocol or = a > protocol update document, thus a full OPS-DIR review conforming to RFC = 5706 is > not needed. =46rom an operational point of view this document is = important, as > operators may need to refer to IANA registries in their daily work of = ensuring > functionality and maintaining networks where TLS and DTLS are used. >=20 > The document is Ready from an OPS-DIR perspective, with a few minor = issues. The > issues listed below are useful for all categories of users of this = document: > implementers, operators, end users. None is them is major, but it = would be good > to be addressed before the document approval. >=20 > 1. The document adds a Recommended column to many of the TLS = registries. The > rationale and meaning of a parameter being or not being Recommended = are > detailed in Section 6. It would be useful from an operator perspective = to add > to the registries where the Recommended column is added a text similar = to the > one in Section 6, that explains the rationale and the meaning. = Something on the > lines of: >=20 > * 'If a parameter is marked as Recommended, implementations > should support it. Adding a recommended parameter > to a registry or updating a parameter to recommended status > requires standards action. Not all parameters defined in standards > track documents need to be marked as recommended. >=20 > If an item is not marked as Recommended it does not necessarily mean > that it is flawed, rather, it indicates that either the item has not > been through the IETF consensus process, has limited applicability, > or is intended only for specific use cases.=E2=80=99 I=E2=80=99m sure that adding this note wouldn't hurt, but we=E2=80=99re = updating all of the registries that are getting a Recommended column to = point to this document.=20 So I could could go either way here - what do other folks think? > 2. Also Section 6. All sections that add Recommended columns need to = also > modify the References column in order to add a reference to this = document. So, I think we=E2=80=99ve done that (double checking): - s8 adds a recommended column and updates references - s9 adds a recommended column and updates references - s10 adds a recommended column and updates references - s13 adds a recommended column and updates references - s15 adds a recommended column and updates references > 3. Section 14. IANA shall update the reference for this registry to = also refer > this document. s4 also updates the references to this document so at first I was = confused, but I think you=E2=80=99re looking for: OLD: 120 no_application_protocol Y [RFC7301] NEW:=20 120 no_application_protocol Y [RFC7301][this-RFC] PR submitted: https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/62 > 4. Section 18. s/ Criteria that SHOULD be applied by the Designated = Experts > includes determining whether the proposed registration duplicates = existing > functionality/Criteria that SHOULD be applied by the Designated = Experts > includes determining whether the proposed registration does not = duplicate > existing functionality/ I stole this wording from another RFC so I=E2=80=99m leaning towards = leaving it as is. spt From nobody Tue Feb 27 06:34:38 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85AF12D949; Tue, 27 Feb 2018 06:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 WVeak4Xsu-vz; Tue, 27 Feb 2018 06:34:30 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 35868126DC2; Tue, 27 Feb 2018 06:34:30 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1REXYct006162; Tue, 27 Feb 2018 14:34:25 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=6SvKpW6Ze43CL0y4wi58Pv6PIyxaAKfhSkC46rcGoXo=; b=CyybzFWmQ6wu4It9B/FsOlE24SycKE1RAVB3RIJsrIvzPWfHiA97MROeRjfuSDFHXfms FbdjQV15x8htCKCNmWfj5LJ8u9bhjUDfvgUc0EJGDRB6KKP0ZekHGhz3D1SZvMpXhjZn eaqeWVUudDQ3JCwd8sBjPRy5IZydX2vT03PBbvBcOqkgbmxEoMxfPIlYYyP1JbXCs8ZC Z8JUL7GpDDMB4Vtw2oQ7SA6Hen8XITXxsTaY6TYlelJKTm4GJgg+Vb3/AEKU/1Tbde1u xRL4eUp31ijkPXdiF7WkhTeEIAnrkEM1f1uk1tFiJhhFh239FfmuoGjMEu0Nfs2yYW9i wQ== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050102.ppops.net-00190b01. with ESMTP id 2gb2gc92ke-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Feb 2018 14:34:25 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w1REVbo0001978; Tue, 27 Feb 2018 09:34:24 -0500 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2gb490yqbp-1; Tue, 27 Feb 2018 09:34:24 -0500 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id D25AD20066; Tue, 27 Feb 2018 14:34:23 +0000 (GMT) To: Viktor Dukhovni , TLS WG Cc: draft-ietf-tls-dnssec-chain-extension@ietf.org, tls-chairs , The IESG References: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com> <9CE8B6BF-CAC0-46AE-B5FC-AF3D45EF9DBC@dukhovni.org> From: Benjamin Kaduk Message-ID: <56e66d4e-13c7-b2cd-e716-b86c12e50fe8@akamai.com> Date: Tue, 27 Feb 2018 08:34:23 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <9CE8B6BF-CAC0-46AE-B5FC-AF3D45EF9DBC@dukhovni.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-27_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=981 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802270183 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-27_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=953 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802270183 Archived-At: Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 14:34:32 -0000 On 02/26/2018 11:20 AM, Viktor Dukhovni wrote: > >> On Feb 26, 2018, at 9:26 AM, Paul Wouters wrote: >> >> So it was decided to not use a full DNS packet format? And then since you >> miss the structure of the Answer Section and Additional/Authority >> Section, you require the "answer RR's" come first where you basically >> emulate an Answer Section? >> >> Isn't that an indication that we should really use the wireformat of an >> entire DNS message here? Maybe some DNS library/tools people can chime >> in here to tell us if this matters much to them (assuming they are >> adding support for creating/consuming these chains of RRsets in wire >> format. >> >> I am personally a little sad we cannot have a dig +chainquery command >> where we write out the entire answer packet format to a blob, to be loaded by >> the TLS server. And where a TLS client cannot just hand over the blob >> "as if it came in as a reply from a DNS server" to its DNS/cache >> receiving code path. > The latter would require compression support on the receiving side, which > has been specifically excluded so far. I am not against making the data > more compact, though it is rather late in the process, but I have a more > pressing issue. > > I think that as it stands, lack of authenticated denial of existence is > a *fatal* flaw in the protocol. I just don't see a sufficiently practical > scenario in which this extension confers a useful security benefit. It of course would not be a fatal flaw if the document was targeting Experimental status, but I do not have the sense that the authors wish to make that switch. > Perhaps this draft should go back to the working group, to consider a new > protocol element, by which the server commits to support the extension for > a time that is substantially longer than the underlying DNS TTLs. During > this time (suggested to be weeks or months, when in production after initial > testing), the server MUST support the extension and respond with EITHER a > valid TLSA RRset chain, or with a valid denial of existence. > > The protocol, thus extended, can then be seen as a more robust form of key > pinning, in which pins are stored server-side, and only the fact that > pinning is expected is stored client-side (for any length of time, the > client may still do short-term caching of TLSA RRs based on the DNS TTL). There doesn't seem to be much interest in pinning-like schemes for TLS at this point (see also the "TLS server identity pinning" proposal from the SAAG/secdispatch session at IETF 100). And I do think the lack of authenticated denial of existence is something the WG was aware of during our earlier discussions, so it's unclear that there is a need to hold things up for this issue. -Benjamin > The protocol is still subject to downgrade (to PKIX) on first contact, > but is this a common element of all protocols that bootstrap security > on first use. Indeed the WebPKI itself is largely TOFU as most certs > (which are predominantly DV certs) are issued by CAs based on rather > weak initial evidence. > From nobody Tue Feb 27 06:52:06 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E86512D965; Tue, 27 Feb 2018 06:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 xAttqomfWDHx; Tue, 27 Feb 2018 06:52:03 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 4562F12D963; Tue, 27 Feb 2018 06:52:03 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1RElw8O028681; Tue, 27 Feb 2018 14:52:02 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=ATJdWHGzjMnPgRu2/uAUAZbfPMwjcOEYR0kl8tSuH8Y=; b=Ywv8yPdEJvFHZoGJnETneb+CG++sVNh3z7YASIAZ428B33aYfQswuDQXUMvoo4GWsHWP qDt4FOn1+XyfyHE4u/mmqWF6CP4fAc8qIT7yCVAgwQk3raSoO4XExQZc7cUTypSY+e6v g0+Gsknh2Dmc8G8fH3Fsr6FDCc1PFUaHpNUodpUzTX94hdbePWTqx4D1DubKH11tyliv hfJqngLz2ZMalDGahhFlGhaXqpJvV54cxm0Zgd4vK5Mn07GyAlnbd38ZZ8EJtOHcmGHT mJHSQDLIwH2hfleEKpfRM9IYM80svhL4+frBLWHjAkS5sunF4cniUnxW2SDUQLulUjPh lQ== Received: from prod-mail-ppoint4 ([96.6.114.87]) by mx0a-00190b01.pphosted.com with ESMTP id 2gb2g09d3b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Feb 2018 14:52:01 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w1REpFdZ019145; Tue, 27 Feb 2018 09:52:00 -0500 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2gb49fqrvb-1; Tue, 27 Feb 2018 09:52:00 -0500 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id B32AF20077; Tue, 27 Feb 2018 14:51:59 +0000 (GMT) To: Sean Turner , Stewart Bryant , "" Cc: gen-art@ietf.org, ietf@ietf.org, draft-ietf-tls-iana-registry-updates.all@ietf.org References: <151915624732.3939.12189669437030269709@ietfa.amsl.com> From: Benjamin Kaduk Message-ID: <8b4049a1-aef2-913c-a485-16aedb6116f8@akamai.com> Date: Tue, 27 Feb 2018 08:51:59 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-27_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=862 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802270187 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-27_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=854 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802270186 Archived-At: Subject: Re: [TLS] Genart last call review of draft-ietf-tls-iana-registry-updates-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 14:52:04 -0000 On 02/27/2018 08:11 AM, Sean Turner wrote: > There are two states for the Recommended column: YES and NO. I can go either way on whether > marked as not recommended = NO > not marked as recommended = NO > > WG - thoughts? I thought we had always been clear that it was "not marked as recommended", i.e., "we make no comment about its status". -Ben From nobody Tue Feb 27 06:55:50 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B792612DA1D; Tue, 27 Feb 2018 06:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 DSt6M_wcOsVm; Tue, 27 Feb 2018 06:55:26 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 6961712DA29; Tue, 27 Feb 2018 06:55:26 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1REqvdN021309; Tue, 27 Feb 2018 14:55:25 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=+Uk1jDOURyXn2CpAy+gDyKNgeemEbK0XVb6IDCmyT4k=; b=baC0D3unW1ifrICDf6YJANzhxUMztYOXWrvD6rxNENqjXWgJ2MfiLy2YhzLnrZxpXRdx k2pRRDn6FXytuGXCPusbzN8OxNExjZ3BAkC4fUUr55AbsqsrU+Nw3M9IDFfLrLix6s+5 gHLedjlFvIVOZVRMKwKCJJNrqiP8E0G3ZI+fN7nMg4b88OX9zPo2RybQ5MtB2v53qT8q MGQgPOEGWqYT4fdqtxHPtA7YPDek7qUxqg9473+LmOrlsmcTM2+oPJAFPKsrC5u7uRP0 gffbL6z9VGp/OsENe+omA893ZzPeQp2aUpnq/04Jg4czZn0sbAunTielbai4ktlPbk1C zA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050102.ppops.net-00190b01. with ESMTP id 2gb2gc94gy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 27 Feb 2018 14:55:25 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w1REpDBK023249; Tue, 27 Feb 2018 09:55:24 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2gb48ytmq9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 27 Feb 2018 09:55:24 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag3mb1.msg.corp.akamai.com (172.27.123.60) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 27 Feb 2018 09:55:23 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 27 Feb 2018 09:55:23 -0500 From: "Salz, Rich" To: "Kaduk, Ben" , Sean Turner , "Stewart Bryant" , "" CC: "gen-art@ietf.org" , "ietf@ietf.org" , "draft-ietf-tls-iana-registry-updates.all@ietf.org" Thread-Topic: [TLS] Genart last call review of draft-ietf-tls-iana-registry-updates-04 Thread-Index: AQHTqoQhZ0uM0NM+zkmLTU44+DBgkqO4qIEAgAALUoD//6z9gA== Date: Tue, 27 Feb 2018 14:55:22 +0000 Message-ID: References: <151915624732.3939.12189669437030269709@ietfa.amsl.com> <8b4049a1-aef2-913c-a485-16aedb6116f8@akamai.com> In-Reply-To: <8b4049a1-aef2-913c-a485-16aedb6116f8@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.a.0.180210 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.128] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-27_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=725 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802270187 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-27_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=659 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802270187 Archived-At: Subject: Re: [TLS] Genart last call review of draft-ietf-tls-iana-registry-updates-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 14:55:33 -0000 IA0KPiAgICBJIHRob3VnaHQgd2UgaGFkIGFsd2F5cyBiZWVuIGNsZWFyIHRoYXQgaXQgd2FzICJu b3QgbWFya2VkIGFzDQogPiAgIHJlY29tbWVuZGVkIiwgaS5lLiwgIndlIG1ha2Ugbm8gY29tbWVu dCBhYm91dCBpdHMgc3RhdHVzIi4NCg0KVGhhdCB3YXMgbXkgdW5kZXJzdGFuZGluZyB0by4gIFRo ZSBjaG9pY2VzIGFyZSAicmVjb21tZW5kZWQiIG9yICJubyBjb21tZW50Ig0KDQo= From nobody Tue Feb 27 06:56:09 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5874B12D96D for ; Tue, 27 Feb 2018 06:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 J-goxYIREqwb for ; Tue, 27 Feb 2018 06:56:03 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4734412DA54 for ; Tue, 27 Feb 2018 06:55:52 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id o25so18316783qkl.7 for ; Tue, 27 Feb 2018 06:55:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9diE7ooTA4PK10Ko57w46es2A8EQ/lAH+Ra/b/tUAys=; b=HEh4mWq/5TUv6BOuB0Z9VSWSF7tUKD7uzwhEaQconSc9BswgfwJ5wHufpKcH/rwRQQ gJokfJ0b542Xjv+BPlRk0YsciamS5opO3pxn7WZhdJLD818LqRCTHVhXOdT+gjBBW6u0 y/g3A1fooNAGAcKUJscB9YLKVRqDL3RUbyvJQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9diE7ooTA4PK10Ko57w46es2A8EQ/lAH+Ra/b/tUAys=; b=kXl/Amhai2aGxwZf+D7oM8rmjZAyCBWNFBPs+j7ZBNLh3zKiz4t13y1QYHhNf2DnzI Ooydy5k/VQgN2DVirdcJ4PgiLjoo/1rGQ579dKFjBbbwUgLxthofAA0gcPE3mWZDQsRE NHImbup0CNZ6MS10IHrzRK+1PQF67iUIb8s95MQIB0ZXxplmVbY8/sYLgnat3RWnBopY DfhhPXPpe3zWC/zHU6NNXrhyQVhdnPkoQltA3ZddMaX5ZCvh7VB9judlU+uod+rhoY7q 3rfmO9N67sgmEoFlpLI1eCoUaAFPiab20Dbn5V2rr0SSifl9PgTWz+DIVWvE5VZuH/cH /8hw== X-Gm-Message-State: APf1xPDNgGosvuTovQwlhsJpanUmjtpxMWEQMdNFwb95CUTiR1xej63k prSXcfrjkydJ/D4lRicef8YuLA== X-Google-Smtp-Source: AG47ELslBcjrwZWqtjxgN75WbJyGqhtToR0+IPaLsE8C2zvho+1Wpubracjq4Df5yz7UNnMeWT+aAA== X-Received: by 10.55.65.81 with SMTP id o78mr21998746qka.274.1519743351449; Tue, 27 Feb 2018 06:55:51 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id o17sm6329990qkl.94.2018.02.27.06.55.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Feb 2018 06:55:50 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: <8b4049a1-aef2-913c-a485-16aedb6116f8@akamai.com> Date: Tue, 27 Feb 2018 09:55:48 -0500 Cc: Stewart Bryant , "" , gen-art@ietf.org, ietf@ietf.org, draft-ietf-tls-iana-registry-updates.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <47710D79-7B79-4F92-91C9-311827D5D981@sn3rd.com> References: <151915624732.3939.12189669437030269709@ietfa.amsl.com> <8b4049a1-aef2-913c-a485-16aedb6116f8@akamai.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Genart last call review of draft-ietf-tls-iana-registry-updates-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 14:56:05 -0000 > On Feb 27, 2018, at 09:51, Benjamin Kaduk wrote: >=20 > On 02/27/2018 08:11 AM, Sean Turner wrote: >> There are two states for the Recommended column: YES and NO. I can = go either way on whether >> marked as not recommended =3D NO >> not marked as recommended =3D NO >>=20 >> WG - thoughts? >=20 > I thought we had always been clear that it was "not marked as > recommended", i.e., "we make no comment about its status". In s6 it is "marked as not recommended=E2=80=9D. This is easily = changed. spt= From nobody Tue Feb 27 06:56:34 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B3912DA0C for ; Tue, 27 Feb 2018 06:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 1ddwQ-hP5brn for ; Tue, 27 Feb 2018 06:56:31 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E02C012DA6B for ; Tue, 27 Feb 2018 06:56:25 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id v90so23461253qte.12 for ; Tue, 27 Feb 2018 06:56:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=56klXBJjyUZOKIywqkvp7Li1DFUOL0rTUdWmxxTXu5g=; b=lMyos6Cw0vWj+/dz3FNg6329eJo+vtVOkhoEYQ5qnE9EgSeoScWRRxtLMZ+gjcUBWw hoEW6NW3cm8AAGJLU7rfY+nt7kZjUdaP/ouzPLHHoR18/Oo54RfwMTmtWcJYE4109j5y bKmNR8vtRAzVNl6e17GzJb6PbkmpbdtDFa8nY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=56klXBJjyUZOKIywqkvp7Li1DFUOL0rTUdWmxxTXu5g=; b=t0nFjOlle9P/SYMJ4dfYWC53ut7P09Ku+H1IyfmSh26bX0foSavL8aPHJbIz7zVhJw Kn2eBWSmAv3IdZ/rnbdUgwjuwJ5C4lzrjupe0czNAd9wDCMjMNI+OB1gRWsJhIc+E/y6 kzNfh3U/AxpWm1TsWQOjxhgPMhRIZLHqAu2FP12/4asIbIpG2pIPY+gXjH70btA+kfGf VVBT73aGjnUM1Guwgn1kaAhPqqLiDXg3Vj6MD5daxMS1GNgVwZmrdve99k+DLVmiTVRL 6JkTOatuOBRJUqJ/y+RRk5I7kY2eZcRJxtjviD1IWCb//Nftffso52Wfc9TBbLlC1C7w MCCQ== X-Gm-Message-State: APf1xPD6l3eSWYh2YgOr9mBRqx2QKzLWo2lWd3dxlFs+JnQBpIx380oJ /QiOSGVsis8Gqexs6kt4ScsmuQ== X-Google-Smtp-Source: AG47ELvc6tJa67DMkH0WKG765b4l9sp4VOQ/NsSJSjzKKUMULF8TgxDJCDGX9Xcfi0+5cqP1cAuTOg== X-Received: by 10.237.56.70 with SMTP id j64mr23486280qte.186.1519743385134; Tue, 27 Feb 2018 06:56:25 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id o17sm6329990qkl.94.2018.02.27.06.56.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Feb 2018 06:56:24 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: Date: Tue, 27 Feb 2018 09:56:23 -0500 Cc: Benjamin Kaduk , Stewart Bryant , "" , "gen-art@ietf.org" , "ietf@ietf.org" , "draft-ietf-tls-iana-registry-updates.all@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4C3FE524-1C77-4E23-823A-D8FB0B44B85C@sn3rd.com> References: <151915624732.3939.12189669437030269709@ietfa.amsl.com> <8b4049a1-aef2-913c-a485-16aedb6116f8@akamai.com> To: Rich Salz X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Genart last call review of draft-ietf-tls-iana-registry-updates-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 14:56:33 -0000 > On Feb 27, 2018, at 09:55, Salz, Rich wrote: >=20 >=20 >> I thought we had always been clear that it was "not marked as >> recommended", i.e., "we make no comment about its status". >=20 > That was my understanding to. The choices are "recommended" or "no = comment=E2=80=9D Yes, but we put =E2=80=9CNO=E2=80=9D as a column value. spt= From nobody Tue Feb 27 06:59:24 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828E912DA6A for ; Tue, 27 Feb 2018 06:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 LKUd0sf585jY for ; Tue, 27 Feb 2018 06:59:19 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22AF412DA1D for ; Tue, 27 Feb 2018 06:59:16 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id y137so23843822qka.4 for ; Tue, 27 Feb 2018 06:59:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1jjlJ2PCNhTJ/BLQ+fBqbq1B6W1RPyh3tU0gv4zgfzs=; b=meMRUiJReXPW99e33v1Sj2dYHUK2ky5/k5h/HG7PG3NCqYQLJbhauiedGXSoq0MZEk 5XpGwFjsnfnhhIFGg0Ma3no6a1v6737MGvttmTpmNyFA0RJYfjNLc0FF9L1YmOQ1dNiE GXzc2uK13fDQIA56uAL4Z7uWxemYS7r/MV3oc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1jjlJ2PCNhTJ/BLQ+fBqbq1B6W1RPyh3tU0gv4zgfzs=; b=fxTjw1UH+k1M7zp0GwDvmYjcHsECKMNBfPSp1DTqURwfQOE3iOvVMWqg8e66xUC5yp 58ILj+3h2zbhBkWhbwYHgIdStABHgLzGGlTk6XOlMaLHgiyee4VvWMj3g5dj5RRVkxh5 X6msIQI3lzRLl3mWVe8khfMSnBvJQvdXV/NOZ89vKFhTZHw/YxS75LytAalq9rdK/m71 g9jND+bqxIAYNHK6Nj206VL0/xwsTDVA12cFxAeuSq1+E3sSXsIkSmztuVA/WwDddyVF fjMvbXLff2U6HbmD/pytSg6geuZhmtDhGdF9e/x4iEPZ6bQKs+cGRphd3jMIiEKj/XUM /KEQ== X-Gm-Message-State: APf1xPAUyGsGpfaquezgDbyN+QaByJN5BAq+WTHx23ezQJCZg4b6KU91 QgKqD64WQKNQeVzF1uXr15NQdg== X-Google-Smtp-Source: AG47ELtVld6yKUQ0msRK5M/eDsheTgQgeIn5tCRMnERwIiIUxiItlZoGVkUufvaT0QMxErnp03UNsw== X-Received: by 10.55.23.201 with SMTP id 70mr22394209qkx.24.1519743555325; Tue, 27 Feb 2018 06:59:15 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id s66sm5728246qkc.37.2018.02.27.06.59.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Feb 2018 06:59:14 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: <47710D79-7B79-4F92-91C9-311827D5D981@sn3rd.com> Date: Tue, 27 Feb 2018 09:59:13 -0500 Cc: Stewart Bryant , "" , gen-art@ietf.org, ietf@ietf.org, draft-ietf-tls-iana-registry-updates.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1A9D784F-4EF7-4243-982B-D5B76C5F3503@sn3rd.com> References: <151915624732.3939.12189669437030269709@ietfa.amsl.com> <8b4049a1-aef2-913c-a485-16aedb6116f8@akamai.com> <47710D79-7B79-4F92-91C9-311827D5D981@sn3rd.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Genart last call review of draft-ietf-tls-iana-registry-updates-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 14:59:20 -0000 > On Feb 27, 2018, at 09:55, Sean Turner wrote: >=20 >=20 >=20 >> On Feb 27, 2018, at 09:51, Benjamin Kaduk wrote: >>=20 >> On 02/27/2018 08:11 AM, Sean Turner wrote: >>> There are two states for the Recommended column: YES and NO. I can = go either way on whether >>> marked as not recommended =3D NO >>> not marked as recommended =3D NO >>>=20 >>> WG - thoughts? >>=20 >> I thought we had always been clear that it was "not marked as >> recommended", i.e., "we make no comment about its status". >=20 > In s6 it is "marked as not recommended=E2=80=9D. This is easily = changed. https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/63 From nobody Tue Feb 27 07:12:25 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F5912D965; Tue, 27 Feb 2018 07:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 KdWWVuzG6pl5; Tue, 27 Feb 2018 07:12:17 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18D1612D77C; Tue, 27 Feb 2018 07:12:16 -0800 (PST) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 287BF7A3309; Tue, 27 Feb 2018 15:12:16 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: <56e66d4e-13c7-b2cd-e716-b86c12e50fe8@akamai.com> Date: Tue, 27 Feb 2018 10:12:15 -0500 Cc: draft-ietf-tls-dnssec-chain-extension@ietf.org, tls-chairs , The IESG Content-Transfer-Encoding: 7bit Message-Id: <9A433CB4-48B6-4CC2-9150-8C1FA629A3A9@dukhovni.org> References: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com> <9CE8B6BF-CAC0-46AE-B5FC-AF3D45EF9DBC@dukhovni.org> <56e66d4e-13c7-b2cd-e716-b86c12e50fe8@akamai.com> To: TLS WG X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 15:12:19 -0000 > On Feb 27, 2018, at 9:34 AM, Benjamin Kaduk wrote: > > There doesn't seem to be much interest in pinning-like schemes for TLS > at this point (see also the "TLS server identity pinning" proposal from > the SAAG/secdispatch session at IETF 100). > And I do think the lack of authenticated denial of existence is > something the WG was aware of during our earlier discussions, so it's > unclear that there is a need to hold things up for this issue. Awareness of is different from thinking through the full implications. I for one did not have the cycles to consider all the implications, and many others likely also focused on the data format, and may not have considered the use-cases with care. Note that DANE-based "pinning" is fundamentally different from other "pinning" approaches, in that the client does not store the key digests for any significant length of time. All it may do is cache the DANE TLSA records for a short time bounded by the DNS TTL. The digests that "pin" the server's (or issuing CA's) keys are managed in the server's DNS zone, and can be promptly updated by the server, and the client can learn of the change when presented with new TLSA records, OR as I now believe is essential for this specification to be at all useful, presented with authenticated denial of existence. The only thing needed for denial of existence to be workable, is that the client cache a commitment by the server (a boolean value) to support the extension until such time as the server provides authenticated denial of existence of TLSA records. This is much less brittle than client-side key pinning, with all its attended problems with stale data. If this protocol has no denial of existence, I don't see any reason for anyone to deploy it. Why publish something that's basically useless? -- Viktor. From nobody Tue Feb 27 07:47:36 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D907012D969; Tue, 27 Feb 2018 07:47:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl 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 vxR2t5EMb1VC; Tue, 27 Feb 2018 07:47:27 -0800 (PST) Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 73C8D126C22; Tue, 27 Feb 2018 07:47:27 -0800 (PST) Received: from [IPv6:2001:980:2283:fe:e174:43b2:2b9b:795a] (unknown [IPv6:2001:980:2283:fe:e174:43b2:2b9b:795a]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id D55188723; Tue, 27 Feb 2018 16:47:24 +0100 (CET) Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=nlnetlabs.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1519746444; bh=xFy8UV6F0JcfBQlAmOJ+N+S8M6/xmSjggJLaptecpDw=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=J7PKUFW6vjzJ6OYMW5Nm98zrgwC8bg/flI5zRa/88Cr17XTtQSMBvHcOtXJruCDJ4 XInuXcyYHXlzAUqlWsSIaTptcNdcGRbWA6u0zabnd5JZwV1GKNkL0A8/3vSwysePEV bXk4rt0cGJocdKZ24Eh8dQotejOfdAWjmUM0fBQw= To: Viktor Dukhovni , TLS WG Cc: draft-ietf-tls-dnssec-chain-extension@ietf.org, tls-chairs , The IESG References: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com> <9CE8B6BF-CAC0-46AE-B5FC-AF3D45EF9DBC@dukhovni.org> <56e66d4e-13c7-b2cd-e716-b86c12e50fe8@akamai.com> <9A433CB4-48B6-4CC2-9150-8C1FA629A3A9@dukhovni.org> From: Willem Toorop Message-ID: <903d090a-2156-17e4-4b63-bb2374468c7d@nlnetlabs.nl> Date: Tue, 27 Feb 2018 16:47:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <9A433CB4-48B6-4CC2-9150-8C1FA629A3A9@dukhovni.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 15:47:30 -0000 Op 27-02-18 om 16:12 schreef Viktor Dukhovni: > > >> On Feb 27, 2018, at 9:34 AM, Benjamin Kaduk wrote: >> >> There doesn't seem to be much interest in pinning-like schemes for TLS >> at this point (see also the "TLS server identity pinning" proposal from >> the SAAG/secdispatch session at IETF 100). >> And I do think the lack of authenticated denial of existence is >> something the WG was aware of during our earlier discussions, so it's >> unclear that there is a need to hold things up for this issue. > > Awareness of is different from thinking through the full implications. > I for one did not have the cycles to consider all the implications, > and many others likely also focused on the data format, and may not > have considered the use-cases with care. > > Note that DANE-based "pinning" is fundamentally different from other > "pinning" approaches, in that the client does not store the key > digests for any significant length of time. All it may do is > cache the DANE TLSA records for a short time bounded by the DNS TTL. > The digests that "pin" the server's (or issuing CA's) keys are managed > in the server's DNS zone, and can be promptly updated by the server, > and the client can learn of the change when presented with new TLSA > records, OR as I now believe is essential for this specification to > be at all useful, presented with authenticated denial of existence. > > The only thing needed for denial of existence to be workable, is > that the client cache a commitment by the server (a boolean value) > to support the extension until such time as the server provides > authenticated denial of existence of TLSA records. > > This is much less brittle than client-side key pinning, with all > its attended problems with stale data. > > If this protocol has no denial of existence, I don't see any reason > for anyone to deploy it. Why publish something that's basically > useless? Well.. support of the option could be obligatory for new TLS services, like DNS over TLS. With DNS over TLS there is no user interaction making third-party PKIX (i.e. a CA store) impractical. Another possibility to authenticate DNS-over-TLS upstreams by clients, is to setup the TLS without authentication, and then use that to do the DANE queries over it (for privacy and to bypass hampering middle-boxes), then authenticate the certificate and upgrade the connection to be usable for all queries. This works but is harder to implement and causes a latency penalty because of the extra negotiations. Note that the new initial draft (not WG yet) for encrypting the path from the recursive to the authoritative, suggests DANE authentication of the authoritative, and references the tls-dnssec-chain-extension draft as the initial method -of acquiring the needed DNSSEC data- to try: https://tools.ietf.org/html/draft-bortzmeyer-dprive-resolver-to-auth Also, with DANE I like the fact that a DNS domain holder/owner can vouch for it's own domain name instead of needing a third party. And although, opposed to DANE over DNSSEC, this extension doesn't add any security, it still has that property. From nobody Tue Feb 27 07:59:06 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B336412D969; Tue, 27 Feb 2018 07:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 qmnct-ERK866; Tue, 27 Feb 2018 07:59:01 -0800 (PST) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0D2A1242F5; Tue, 27 Feb 2018 07:59:01 -0800 (PST) Received: by mail-it0-x231.google.com with SMTP id w19so11657148ite.0; Tue, 27 Feb 2018 07:59:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Z5pLJCuvDTppboAj/B1NcI8D3AYlYeiVvy4Kx7D+T/E=; b=iPe24s3HM5ofOQV6l5azLXMOGas3tkmbN1mBRdFaBmp3hIzhEqtrROqb/ZEW8BvSjb xOdpMRaHnNYLtSwit7oDUsjFl3Y2FnN114eGzhPq6rfyhiIG4M5By9NR4dTpwa/a5fNh wuSUM7O2XPi5CAvPBYUGZb84j9UnvLDwo7McD56WYQkyqB38k2eTfhaI/yk8Qm6GnSu+ y41KzymxKTz4TFgpllewe6uO4Hf0rz92bvpT3xk2lky28n0VP8vNvJqTujG4k/MMS7K1 UOoxPhnyXt/6kQeXajlSuaMdjkUkDJmd1XnzY7CaozA4wJIFH6kGsXG0o4XI/2Tbus1W foHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Z5pLJCuvDTppboAj/B1NcI8D3AYlYeiVvy4Kx7D+T/E=; b=sbkCdIZRj+Hn9M4d0Cjo+FgigTEc0sUOoeQYwo4anLOqcNxKR3m/VVlf4yjHIrnVgu jaL5XhjSVEdh1b4UPtZyZqcO1YFNS7lIRbfV17g/jYMZBGfaymqXckxZUEKzIXFHpPn7 5neem5McSkvnILP8FW5Uv3w+JvnOfYhvl4nMBpqOTT32GSD9+b9+T399kSH6MRuVF6SL 1hUo0WO3xgTBgfjIX3wVQ9BZqgzrI5/X+gksm4v6bqDSoykPGdcMNl9I7PZTrNxXY1eu DiV9LhVBi+a1/9fwddCzuOt/ARtWTnRPyhludvntV3gchET54Zje9A9TZW2EJJcbqcy8 91dw== X-Gm-Message-State: APf1xPANhnMqwOWuKd4i5xZDTZ1XiDZRrY1F59+qUbmzIOxXl6ucg1w1 PaCwKop9AUgPxDkrMVHqN1fYz8PxvDs2WwE4NC3F+3NV X-Google-Smtp-Source: AG47ELszNPUBjGyv2Ailz0Jd2o5bm+rxBD+Yl+4oe/U2kPXilyOUP6KhFjedcAFo81FfwWZ4J1C+7sMOOkoYLJZIeco= X-Received: by 10.36.253.204 with SMTP id m195mr18057402ith.151.1519747140981; Tue, 27 Feb 2018 07:59:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.201.198 with HTTP; Tue, 27 Feb 2018 07:59:00 -0800 (PST) In-Reply-To: <70D42B5C-7FF9-49C1-95D4-13FDC611FF96@dukhovni.org> References: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com> <70D42B5C-7FF9-49C1-95D4-13FDC611FF96@dukhovni.org> From: Shumon Huque Date: Tue, 27 Feb 2018 10:59:00 -0500 Message-ID: To: Viktor Dukhovni Cc: TLS WG , tls-chairs , draft-ietf-tls-dnssec-chain-extension@ietf.org, The IESG Content-Type: multipart/alternative; boundary="94eb2c11ce6e7c973e056633b437" Archived-At: Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 15:59:05 -0000 --94eb2c11ce6e7c973e056633b437 Content-Type: text/plain; charset="UTF-8" On Mon, Feb 26, 2018 at 12:19 PM, Viktor Dukhovni wrote: > > I think that as it stands, lack of authenticated denial of existence is > a *fatal* flaw in the protocol. I just don't see a sufficiently practical > scenario in which this extension confers a useful security benefit. Viktor, Is this a new realization you've recently arrived at? You've been commenting on this draft for a number of years now, and I have assumed that you were well aware of the lack of authenticated denial. In fact, there is text in the Intro section that declares that this protocol is unsuitable for SMTP/DANE precisely because it requires confirmation of the existence or not of the TLSA record - that text came about because of discussion with you. Several of us were well aware of this during the early days of the draft, but perhaps many folks did not fully appreciate the impacts until I elaborated on them last year, and added text that described the "adversary with fraudulently obtained PKIX credentials" attack. It is certainly a limitation/flaw. Whether or not it is fatal is debatable. What this means is that this protocol allows opportunistic use of DANE authentication, but guarantee of use needs mechanisms external to the protocol. Section 8 already describes several such mechanisms that could be employed. So, I think this topic is covered. This limitation also may not be applicable at all for green field TLS/DNSSEC applications that can require the use of the extension unconditionally. Having an authenticated denial mechanism would allow the TLS client to have an inband way to enforce DANE authentication if available. I suspect though that re-introducing a debate on this topic will lead us into an argument about what it means for a server to publish a TLSA record. Is it just a mechanism to use the DNSSEC to authenticate keys and certificates? Or is it also a policy signal that says DANE must be used? I do not think the latter idea has any consensus in the IETF currently. > Perhaps this draft should go back to the working group, to consider a new > protocol element, by which the server commits to support the extension for > a time that is substantially longer than the underlying DNS TTLs. During > this time (suggested to be weeks or months, when in production after initial > testing), the server MUST support the extension and respond with EITHER a > valid TLSA RRset chain, or with a valid denial of existence. This is a rather substantial change proposal. It's worth considering, but I'd like to hear others chime in. But as I said, there are ways to use this spec and address some of the limitations outside the protocol today - you can cache and pin knowledge of TLSA existence, even without an in-protocol commitment, although the latter would be better. That may be good enough for the first iteration of the protocol. Note that extending the protocol to incorporate authenticated denial also means that the chain data would likey need a DNS response code. That's a stronger argument to move to a full DNS message format (I'll answer Paul Wouter's specific comments on that topic separately later). Shumon. --94eb2c11ce6e7c973e056633b437 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Feb 26, 2018 at 12:19 PM, Viktor Dukhovni <viktor@dukhovni.org> wrote:
>
> I think that as it stands, = lack of authenticated denial of existence is
> a *fatal* flaw in the protocol.=C2=A0 I just don't see a suffici= ently practical
> scenario in which this= extension confers a useful security benefit.

Viktor,

Is this a new realization you'= ;ve recently arrived at? You've been
co= mmenting on this draft for a number of years now, and I have
assumed that you were well aware of the lack of authentic= ated denial.
In fact, there is text in the = Intro section that declares that
this proto= col is unsuitable for SMTP/DANE precisely because it
requires confirmation of the existence or not of the TLSA record = -
that text came about because of discussio= n with you.

Several of us were well aware of this during the early days of the
draft, but perhaps many folks did not fully a= ppreciate the impacts
until I elaborated on= them last year, and added text that described
the "adversary with fraudulently obtained PKIX credentials" a= ttack.

It is certainly a limitation/flaw. Whether or not it is fatal is
debatable. What this means is that this protocol all= ows opportunistic
use of DANE authenticatio= n, but guarantee of use needs mechanisms
ex= ternal to the protocol. Section 8 already describes several such
mechanisms that could be employed. So, I think this t= opic is covered.

This limitation also may not be applicable at all for green fiel= d
TLS/DNSSEC applications that can require = the use of the extension
unconditionally.

Having = an authenticated denial mechanism would allow the TLS client
to have an inband way to enforce DANE authentication if a= vailable.
I suspect though that re-introduc= ing a debate on this topic will
lead us int= o an argument about what it means for a server to publish
a TLSA record. Is it just a mechanism to use the DNSSEC to= authenticate
keys and certificates? Or is = it also a policy signal that says DANE
must= be used? I do not think the latter idea has any consensus in the
IETF currently.

=

> = Perhaps this draft should go back to the working group, to consider a new
> protocol element, by which the server c= ommits to support the extension for
> a = time that is substantially longer than the underlying DNS TTLs.=C2=A0 Durin= g
> this time (suggested to be weeks or = months, when in production after initial
&g= t; testing), the server MUST support the extension and respond with EITHER = a
> valid TLSA RRset chain, or with a va= lid denial of existence.


This is a rather su= bstantial change proposal. It's worth considering,
but I'd like to hear others chime in. But as I said, there = are ways
to use this spec and address some = of the limitations outside the
protocol tod= ay - you can cache and pin knowledge of TLSA existence,
even without an in-protocol commitment, although the latter wo= uld be
better. That may be good enough for = the first iteration of the protocol.

Note that extending the protocol to incorpor= ate authenticated denial
also means that th= e chain data would likey need a DNS response code.
That's a stronger argument to move to a full DNS message format= (I'll
answer Paul Wouter's specifi= c comments on that topic separately later).

Shumon.

--94eb2c11ce6e7c973e056633b437-- From nobody Tue Feb 27 08:02:51 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B380712DA2C; Tue, 27 Feb 2018 08:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 mR8CRPmtPARU; Tue, 27 Feb 2018 08:02:27 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CA5412D7F0; Tue, 27 Feb 2018 08:02:27 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id s198so24126431qke.5; Tue, 27 Feb 2018 08:02:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RXwctsVII9MIqDASp71tEgN4Zjog8647ETxlhsEwsUQ=; b=jjizSTe8aQx+FvdHeKUtd4fesgxOJ5i1Y+jVKnJ1X1fmxKnV7Ig1HUDFE/zyteSCmO KkAyOksGRiQ4Z+ORCUICWP43tJwuNTCvgoFFR7yx7vRBBKI6TgSm7uJBZFLSVLOuxZlz AXENo3WLs726emtXgSB05a4gY3XeOvSsBtVlpPh39Yb7JVdx1v+LK/88Kofl3kR+bh9c EIcXlqkR1hFHyvFshowu4nxyqE0NcO6KI5/A96juwblTIhH/38naav14/IBp6Dm3RNTq mtqJ4cuH9nOJNdTffoF+iBzlUuZLAND8JIlqqgliCq4E1DYWg4D1FW885rhEvokGVoG5 wi0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RXwctsVII9MIqDASp71tEgN4Zjog8647ETxlhsEwsUQ=; b=dMY5EYv6OWcPsyIkKSMWrwd6FqMobZp2fd4WQCvBJa2Kw8pX/9PCg+/krfOVdbI+za PCSk6Qr/qLn9kZMjy1uEoVcqwnc2Uqll21WHdXUsygkNsXqvo5Gxk6h6rPItuAr9ETxP NZaJaT+WHPe0O3bEVVpPmuFHLQlH1HoxcvWnKWUIxl53w4/YjfNneeeHuNe3mo+RHMM/ bI/L75dSTglZrfteC5jnFOIiqSZmU+tXg23sHrz7fTTaW5ZKb24OJZkAET27lbXdRXhn MQHnKbq9UEUVuywaOghyNrNrVhA6OpW0/ssc1fGTrghf+20gbY3X5fJjpLQoqtJPb6br NONQ== X-Gm-Message-State: APf1xPDXZ44Gvs8EZLdv4kCjYgUdyj5m4sXhV/iM2ZswE5RKCaZJtmp1 RdoawKMgJozagF06F7cjs/+Hr2yjNNOHUE0FRFA= X-Google-Smtp-Source: AG47ELtPaRsO1K2C/uUn3dir2qEijaLDuFQJ4KJmbTy0HKLcPfdlDd6tPnVtlXAY6LnjcN0Wc96reH61mGSEvpL8CIY= X-Received: by 10.55.6.140 with SMTP id 134mr24361461qkg.281.1519747346624; Tue, 27 Feb 2018 08:02:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.23.200 with HTTP; Tue, 27 Feb 2018 08:02:26 -0800 (PST) In-Reply-To: References: <151912347695.29703.11473433478669184845@ietfa.amsl.com> From: Dan Romascanu Date: Tue, 27 Feb 2018 18:02:26 +0200 Message-ID: To: Sean Turner Cc: "" , ops-dir@ietf.org, ietf , draft-ietf-tls-iana-registry-updates.all@ietf.org Content-Type: multipart/alternative; boundary="001a114c5194be7680056633c02f" Archived-At: Subject: Re: [TLS] Opsdir last call review of draft-ietf-tls-iana-registry-updates-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 16:02:32 -0000 --001a114c5194be7680056633c02f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Sean, Thanks for the answer and for addressing my comments. Short observations are inserted. Regards, Dan On Tue, Feb 27, 2018 at 4:11 PM, Sean Turner wrote: > > > > On Feb 20, 2018, at 05:44, Dan Romascanu wrote: > > > > Reviewer: Dan Romascanu > > Review result: Has Issues > > > > I am the assigned OPS-DIR reviewer for this draft. The OPS DIrectorate > reviews > > a great part of the IETF documents being processed by the IESG for the > OPS ADs. > > Please treat with these comments as with all other IETF LC comments. > Please > > wait for direction from your document shepherd or AD before posting a n= ew > > version of the draft. > > > > This document which updates several TLS and DTLS RFCs describes a numbe= r > of > > changes to TLS IANA registries that range from adding notes to the > registry all > > the way to changing the registration policy. This is not a protocol or = a > > protocol update document, thus a full OPS-DIR review conforming to RFC > 5706 is > > not needed. From an operational point of view this document is > important, as > > operators may need to refer to IANA registries in their daily work of > ensuring > > functionality and maintaining networks where TLS and DTLS are used. > > > > The document is Ready from an OPS-DIR perspective, with a few minor > issues. The > > issues listed below are useful for all categories of users of this > document: > > implementers, operators, end users. None is them is major, but it would > be good > > to be addressed before the document approval. > > > > 1. The document adds a Recommended column to many of the TLS registries= . > The > > rationale and meaning of a parameter being or not being Recommended are > > detailed in Section 6. It would be useful from an operator perspective > to add > > to the registries where the Recommended column is added a text similar > to the > > one in Section 6, that explains the rationale and the meaning. Somethin= g > on the > > lines of: > > > > * 'If a parameter is marked as Recommended, implementations > > should support it. Adding a recommended parameter > > to a registry or updating a parameter to recommended status > > requires standards action. Not all parameters defined in standards > > track documents need to be marked as recommended. > > > > If an item is not marked as Recommended it does not necessarily mean > > that it is flawed, rather, it indicates that either the item has not > > been through the IETF consensus process, has limited applicability, > > or is intended only for specific use cases.=E2=80=99 > > I=E2=80=99m sure that adding this note wouldn't hurt, but we=E2=80=99re u= pdating all of > the registries that are getting a Recommended column to point to this > document. > > So I could could go either way here - what do other folks think? > I *think* that the note would help - clarifying what 'not marked as Recommended' means vs. (possibly) writing 'no' in the Recommended column. > > 2. Also Section 6. All sections that add Recommended columns need to al= so > > modify the References column in order to add a reference to this > document. > > So, I think we=E2=80=99ve done that (double checking): > > - s8 adds a recommended column and updates references > - s9 adds a recommended column and updates references > - s10 adds a recommended column and updates references > - s13 adds a recommended column and updates references > - s15 adds a recommended column and updates references > > > 3. Section 14. IANA shall update the reference for this registry to als= o > refer > > this document. > > s4 also updates the references to this document so at first I was > confused, but I think you=E2=80=99re looking for: > > OLD: > > 120 no_application_protocol Y [RFC7301] > > NEW: > > 120 no_application_protocol Y [RFC7301][this-RFC] > Yes, indeed, this is what I was looking for. > > PR submitted: > https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/62 > > > 4. Section 18. s/ Criteria that SHOULD be applied by the Designated > Experts > > includes determining whether the proposed registration duplicates > existing > > functionality/Criteria that SHOULD be applied by the Designated Experts > > includes determining whether the proposed registration does not duplica= te > > existing functionality/ > > I stole this wording from another RFC so I=E2=80=99m leaning towards leav= ing it as > is. > You are the native English speaker, but my acquired English skills tell me that 'criteria' means what should happen (avoid duplication). > > spt > --001a114c5194be7680056633c02f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Sean,

Thanks for the a= nswer and for addressing my comments.

Short observations are = inserted.

Regards,

Dan


On Tue, Feb 27, 2018 at 4:11 PM, Se= an Turner <sean@sn3rd.com> wrote:


> On Feb 20, 2018, at 05:44, Dan Romascanu <dromasca@gmail.com> wrote:
>
> Reviewer: Dan Romascanu
> Review result: Has Issues
>
> I am the assigned OPS-DIR reviewer for this draft. The OPS DIrectorate= reviews
> a great part of the IETF documents being processed by the IESG for the= OPS ADs.
> Please treat with these comments as with all other IETF LC comments. P= lease
> wait for direction from your document shepherd or AD before posting a = new
> version of the draft.
>
> This document which updates several TLS and DTLS RFCs describes a numb= er of
> changes to TLS IANA registries that range from adding notes to the reg= istry all
> the way to changing the registration policy. This is not a protocol or= a
> protocol update document, thus a full OPS-DIR review conforming to RFC= 5706 is
> not needed. From an operational point of view this document is importa= nt, as
> operators may need to refer to IANA registries in their daily work of = ensuring
> functionality and maintaining networks where TLS and DTLS are used. >
> The document is Ready from an OPS-DIR perspective, with a few minor is= sues. The
> issues listed below are useful for all categories of users of this doc= ument:
> implementers, operators, end users. None is them is major, but it woul= d be good
> to be addressed before the document approval.
>
> 1. The document adds a Recommended column to many of the TLS registrie= s. The
> rationale and meaning of a parameter being or not being Recommended ar= e
> detailed in Section 6. It would be useful from an operator perspective= to add
> to the registries where the Recommended column is added a text similar= to the
> one in Section 6, that explains the rationale and the meaning. Somethi= ng on the
> lines of:
>
> * 'If a parameter is marked as Recommended, implementations
>=C2=A0 =C2=A0should support it. Adding a recommended parameter
>=C2=A0 =C2=A0to a registry or updating a parameter to recommended statu= s
>=C2=A0 =C2=A0requires standards action. Not all parameters defined in s= tandards
>=C2=A0 =C2=A0track documents need to be marked as recommended.
>
>=C2=A0 =C2=A0If an item is not marked as Recommended it does not necess= arily mean
>=C2=A0 =C2=A0that it is flawed, rather, it indicates that either the it= em has not
>=C2=A0 =C2=A0been through the IETF consensus process, has limited appli= cability,
>=C2=A0 =C2=A0or is intended only for specific use cases.=E2= =80=99

I=E2=80=99m sure that adding this note wouldn't hurt, but we=E2=80=99re= updating all of the registries that are getting a Recommended column to po= int to this document.

So I could could go either way here - what do other folks think?

I *think* that the note would help - clarifying w= hat 'not marked as Recommended' means vs. (possibly) writing 'n= o' in the Recommended column.


> 2. Also Section 6. All sections that add Recommended columns need to a= lso
> modify the References column in order to add a reference to this docum= ent.

So, I think we=E2=80=99ve done that (double checking):

- s8 adds a recommended column and updates references
- s9 adds a recommended column and updates references
- s10 adds a recommended column and updates references
- s13 adds a recommended column and updates references
- s15 adds a recommended column and updates references

> 3. Section 14. IANA shall update the reference for this registry to al= so refer
> this document.

s4 also updates the references to this document so at first I was co= nfused, but I think you=E2=80=99re looking for:

OLD:

=C2=A0 120=C2=A0 =C2=A0no_application_protocol=C2=A0 Y=C2=A0 [RFC7301]

NEW:

=C2=A0 120=C2=A0 =C2=A0no_application_protocol=C2=A0 Y=C2=A0 [RFC7301][this= -RFC]

Yes, indeed, this is what I was l= ooking for.
=C2=A0

PR submitted:
https://github.com/tlswg/d= raft-ietf-tls-iana-registry-updates/pull/62

> 4. Section 18. s/ Criteria that SHOULD be applied by the Designated Ex= perts
> includes determining whether the proposed registration duplicates exis= ting
> functionality/Criteria that SHOULD be applied by the Designated Expert= s
> includes determining whether the proposed registration does not duplic= ate
> existing functionality/

I stole this wording from another RFC so I=E2=80=99m leaning towards= leaving it as is.

You are the native E= nglish speaker, but my acquired English skills tell me that 'criteria&#= 39; means what should happen (avoid duplication).
=C2=A0

spt

--001a114c5194be7680056633c02f-- From nobody Tue Feb 27 08:11:30 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40AE1126C22; Tue, 27 Feb 2018 08:11:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Txu3V-MBOI5T; Tue, 27 Feb 2018 08:11:27 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A32F61243FE; Tue, 27 Feb 2018 08:11:27 -0800 (PST) Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 559127A3309; Tue, 27 Feb 2018 16:11:26 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Viktor Dukhovni In-Reply-To: <903d090a-2156-17e4-4b63-bb2374468c7d@nlnetlabs.nl> Date: Tue, 27 Feb 2018 11:11:25 -0500 Cc: draft-ietf-tls-dnssec-chain-extension@ietf.org, tls-chairs , The IESG Content-Transfer-Encoding: 7bit Message-Id: <8664D263-1188-42DD-99B8-5110B3A36179@dukhovni.org> References: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com> <9CE8B6BF-CAC0-46AE-B5FC-AF3D45EF9DBC@dukhovni.org> <56e66d4e-13c7-b2cd-e716-b86c12e50fe8@akamai.com> <9A433CB4-48B6-4CC2-9150-8C1FA629A3A9@dukhovni.org> <903d090a-2156-17e4-4b63-bb2374468c7d@nlnetlabs.nl> To: TLS WG X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 16:11:29 -0000 > On Feb 27, 2018, at 10:47 AM, Willem Toorop wrote: > >> If this protocol has no denial of existence, I don't see any reason >> for anyone to deploy it. Why publish something that's basically >> useless? > > Well.. support of the option could be obligatory for new TLS services, > like DNS over TLS. With DNS over TLS there is no user interaction > making third-party PKIX (i.e. a CA store) impractical. Sure, if restricted to applications in which the extension is mandatory, the problem goes away. But much of the appeal of this specification was I believe that it would finally make it possible to do use DANE between a browser and web server, and without authenticated DoE, it falls well short of at least that goal. > Note that the new initial draft (not WG yet) for encrypting the path > from the recursive to the authoritative, suggests DANE authentication of > the authoritative, and references the tls-dnssec-chain-extension draft > as the initial method -of acquiring the needed DNSSEC data- to try: > > https://tools.ietf.org/html/draft-bortzmeyer-dprive-resolver-to-auth This is a very different context from that faced by most other application clients. Here the client is a DNS server (iterative resolver) talking to authoritative servers, and sending the TLSA records over TLS is just an optimization, the client can retrieve these separately. > Also, with DANE I like the fact that a DNS domain holder/owner can vouch > for it's own domain name instead of needing a third party. And > although, opposed to DANE over DNSSEC, this extension doesn't add any > security, it still has that property. For existing applications, with a deployed base of PKIX (WebPKI) servers, this extension provides no secure upgrade path. This problem severely limits the utility of this extension. I now think we can and should do better. Otherwise, this specification will not be a suitable basis for DANE-based peer authentication in HTTPS, except for a narrow set of situations in which DANE is required by some out-of-band external mechanism. I think it makes sense to add a DANE latch TTL to the server's response, which communicates to the client that the server commits to continue to support the extension for some time considerably in excess of the TLSA record TTL. The client can cache that commitment for use with future connections to the server. With that in place, we get meaningful applicability to HTTPS as used by general-purpose web browsers. Or have we given up on ever using DANE for HTTPS in browsers? -- Viktor. From nobody Tue Feb 27 08:22:06 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7A712D969 for ; Tue, 27 Feb 2018 08:22:01 -0800 (PST) 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=unavailable autolearn_force=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 IiEG6kEQ8qQm for ; Tue, 27 Feb 2018 08:22:00 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F32512DA2C for ; Tue, 27 Feb 2018 08:22:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 427343004CE for ; Tue, 27 Feb 2018 11:21:58 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id lIiFa4oGBpIB for ; Tue, 27 Feb 2018 11:21:56 -0500 (EST) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 595E83004D7; Tue, 27 Feb 2018 11:21:56 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Tue, 27 Feb 2018 11:21:57 -0500 Cc: IETF TLS , IETF Gen-ART , IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <151915624732.3939.12189669437030269709@ietfa.amsl.com> To: Sean Turner , Stewart Bryant X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Genart last call review of draft-ietf-tls-iana-registry-updates-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 16:22:02 -0000 >> Minor issues: >>=20 >> I think convention is to list the documents being updated in the = Abstract, but >> cannot find any formal guidance. >=20 > You=E2=80=99re right that is the convention, but it=E2=80=99s not = required. draft-flanagan-7322bis is attempting to make including = updates in the abstract a must, but it=E2=80=99s not been through any = kind of LC yet. There is a sentence there saying that a lot of RFCs are = updated and to see the updates header so I think under the 7322 to = balance concise and to not include references I=E2=80=99m thinking this = is okay. >=20 If another update top the document is needed, then it does not seem hard = to comply with the coming convention. =3D=3D=3D=3D=3D=3D >>=20 >> If an item is marked as not recommended it does not necessarily mean >> SB> Do you mean "marked as not recommended" or "not marked as = recommended=E2=80=9D. >=20 > There are two states for the Recommended column: YES and NO. I can go = either way on whether > marked as not recommended =3D NO > not marked as recommended =3D NO >=20 > WG - thoughts? I think the second wording is more clear. >> =3D=3D=3D=3D=3D=3D=3D >> SB> I am worried about the semantics of Recommended =3D no. >> SB> Presumably there are three states: recommended, not recommended, >> SB> and silent/don't know/don't care/not yet. Which of these >> SB> states does Recommended =3D no represent? >=20 > There are two states and a draft that specifies a value in a registry = that has a Recommended column needs to state which it is. I=E2=80=99m = not too concerned because we can change the column value later if it = turns out a NO should have been a YES. It would be more clear is Section 6 said that each parameter will have = either "yes" or "no" in the new recommended column. Russ From nobody Tue Feb 27 08:24:37 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA181242F5; Tue, 27 Feb 2018 08:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 MoleuZFgQTQ2; Tue, 27 Feb 2018 08:24:33 -0800 (PST) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F409512D86A; Tue, 27 Feb 2018 08:24:32 -0800 (PST) Received: by mail-io0-x234.google.com with SMTP id f1so7907607iob.0; Tue, 27 Feb 2018 08:24:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rX8Ay9QgIYYmBSWe738zBIBEeEFeRn1nNDj6F/Ok9LY=; b=Kpf9XSkcMZY/p0KVmOkr9Kw/+30WWjDu5sLOtO8d0x89a8dQcuubEOCnOzSaQTo/Ui SkER4XjOMtQZNbBWgL20xnBF+IoTdI4knM3uw1f4lQzPYvWXdc6zyutHEDuA60OMSEqR CH3Z0I6z4IGQEdKXIE8lvL0oo2Ns2W3bBghJoALKMSynifT7w1/B4xns/jaLoaOJameb 2/85WoI170G1JcgdkmX3U2J2rnXPXktYI1dwxiwK7uKwXRitboghRlNlZXvqZfYPSHkd IrbUd2N69IZqg21MTH0ltTU4juTmdm3bh/8GeGXx+7rwTsyosIXd0BxY/ljfGYC6Chf3 y0WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rX8Ay9QgIYYmBSWe738zBIBEeEFeRn1nNDj6F/Ok9LY=; b=hnb8y/D/6jxGMmlf1QFhUL3z9CQWBovmT0qD+ZMFyveKaYq18cOcrRRVaIy/j/tCtt hE1xVunHxQdDnl4ZWU6G57EsmiWt/BXF+pj5umLONmtNGgvbhDhqfdVJ1qswu4U69ZI5 rhrWl+LYaNPdryPpv1w3RN2uo9fmVSpPrKY57S11qZTSkAFPdgGoaMRe52JVGngjr09s N/xh0QJwG1ZZ/vZ6jDvmoJCdkjy8MptAn8cAlCkkCKzRYftE/CfkWFcm/glPPZaZL14B jxWHBoeLdVxyQvH37HPAzPV3cmX6ZtIIdCGAoOFjRdLp43PBMUbOUGZiFzewxh+Mw5g5 x1eQ== X-Gm-Message-State: APf1xPD7m6ZZRq+nIqDrI3j+M30qVvj8TKgMz7f2rGWUJjjh7VCuXvAt EPbWIXPYP1inCH+ZGXfpR2N/yQ48feMtvM+AbT8= X-Google-Smtp-Source: AG47ELs0+m4jczAdS153A32okwN5Ln0iXFSoaJq+iXaOXp5MhP1+TwZ7iSyc/jh6L6gygWGC63MaNYV7DsLN5pELIEA= X-Received: by 10.107.53.231 with SMTP id k100mr18075324ioo.292.1519748672431; Tue, 27 Feb 2018 08:24:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.201.198 with HTTP; Tue, 27 Feb 2018 08:24:31 -0800 (PST) In-Reply-To: References: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com> <70D42B5C-7FF9-49C1-95D4-13FDC611FF96@dukhovni.org> From: Shumon Huque Date: Tue, 27 Feb 2018 11:24:31 -0500 Message-ID: To: Viktor Dukhovni Cc: TLS WG , tls-chairs , draft-ietf-tls-dnssec-chain-extension@ietf.org, The IESG Content-Type: multipart/alternative; boundary="001a1144a158c4aa400566340f74" Archived-At: Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 16:24:36 -0000 --001a1144a158c4aa400566340f74 Content-Type: text/plain; charset="UTF-8" On Tue, Feb 27, 2018 at 10:59 AM, Shumon Huque wrote: > > > Several of us were well aware of this during the early days of the > draft, but perhaps many folks did not fully appreciate the impacts > until I elaborated on them last year, and added text that described > the "adversary with fraudulently obtained PKIX credentials" attack. > Following up to my own message, sorry .. It occurred to me that perhaps a good way to mitigate this risk is a combo of mechanisms like CAA and Certificate Transparency logs. Shumon Huque --001a1144a158c4aa400566340f74 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 27, 2018 at 10:59 AM, Shumon Huque <shuque@gmail.com>= wrote:


Several of us = were well aware of this during the early days of the
draft, but perhaps many folks did not fully appreciate the impact= s
until I elaborated on them last year, and= added text that described
the "advers= ary with fraudulently obtained PKIX credentials" attack.

Following up to my own message, sorry = ..

It occurred to me that perhaps a good way to mi= tigate this risk is
a combo of mechanisms like CAA and Certificat= e Transparency logs.

Shumon Huque

--001a1144a158c4aa400566340f74-- From nobody Tue Feb 27 08:25:40 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE568124217 for ; Tue, 27 Feb 2018 08:25:35 -0800 (PST) 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=unavailable autolearn_force=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 4PqsPJdh31z1 for ; Tue, 27 Feb 2018 08:25:34 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1EFA12DA4B for ; Tue, 27 Feb 2018 08:25:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C05AA3005D9 for ; Tue, 27 Feb 2018 11:25:30 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Yz_B7ZZyu7cH for ; Tue, 27 Feb 2018 11:25:28 -0500 (EST) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id B49E6300436; Tue, 27 Feb 2018 11:25:28 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Tue, 27 Feb 2018 11:25:29 -0500 Cc: IETF TLS , ops-dir@ietf.org, IETF Content-Transfer-Encoding: quoted-printable Message-Id: <57ECF9E5-80AC-4353-9E46-73A19BD085E3@vigilsec.com> References: <151912347695.29703.11473433478669184845@ietfa.amsl.com> To: Sean Turner , Dan Romascanu X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Opsdir last call review of draft-ietf-tls-iana-registry-updates-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 16:25:36 -0000 > On Feb 20, 2018, at 05:44, Dan Romascanu wrote: >=20 > Reviewer: Dan Romascanu > Review result: Has Issues >=20 > I am the assigned OPS-DIR reviewer for this draft. The OPS DIrectorate = reviews > a great part of the IETF documents being processed by the IESG for the = OPS ADs. > Please treat with these comments as with all other IETF LC comments. = Please > wait for direction from your document shepherd or AD before posting a = new > version of the draft. >=20 > This document which updates several TLS and DTLS RFCs describes a = number of > changes to TLS IANA registries that range from adding notes to the = registry all > the way to changing the registration policy. This is not a protocol or = a > protocol update document, thus a full OPS-DIR review conforming to RFC = 5706 is > not needed. =46rom an operational point of view this document is = important, as > operators may need to refer to IANA registries in their daily work of = ensuring > functionality and maintaining networks where TLS and DTLS are used. >=20 > The document is Ready from an OPS-DIR perspective, with a few minor = issues. The > issues listed below are useful for all categories of users of this = document: > implementers, operators, end users. None is them is major, but it = would be good > to be addressed before the document approval. >=20 > 1. The document adds a Recommended column to many of the TLS = registries. The > rationale and meaning of a parameter being or not being Recommended = are > detailed in Section 6. It would be useful from an operator perspective = to add > to the registries where the Recommended column is added a text similar = to the > one in Section 6, that explains the rationale and the meaning. = Something on the > lines of: >=20 > * 'If a parameter is marked as Recommended, implementations > should support it. Adding a recommended parameter > to a registry or updating a parameter to recommended status > requires standards action. Not all parameters defined in standards > track documents need to be marked as recommended. >=20 > If an item is not marked as Recommended it does not necessarily mean > that it is flawed, rather, it indicates that either the item has not > been through the IETF consensus process, has limited applicability, > or is intended only for specific use cases.=E2=80=99 Wouldn't it be sufficient to add a note a the bottom of the registry = that says: If an item is marked as not recommended it does not necessarily mean that it is flawed, rather, it indicates that either the item has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. Russ From nobody Tue Feb 27 08:53:36 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB95126BF7; Tue, 27 Feb 2018 08:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 E-a-VY1GWa_6; Tue, 27 Feb 2018 08:53:24 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 8D08B124217; Tue, 27 Feb 2018 08:53:23 -0800 (PST) X-AuditID: 12074422-ad7ff7000000741c-d5-5a958d00c565 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 1E.CE.29724.10D859A5; Tue, 27 Feb 2018 11:53:21 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w1RGrFVi008668; Tue, 27 Feb 2018 11:53:16 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w1RGr8UD003606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Feb 2018 11:53:11 -0500 Date: Tue, 27 Feb 2018 10:53:09 -0600 From: Benjamin Kaduk To: Russ Housley Cc: Sean Turner , Dan Romascanu , ops-dir@ietf.org, IETF TLS , IETF Message-ID: <20180227165308.GZ50954@kduck.kaduk.org> References: <151912347695.29703.11473433478669184845@ietfa.amsl.com> <57ECF9E5-80AC-4353-9E46-73A19BD085E3@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57ECF9E5-80AC-4353-9E46-73A19BD085E3@vigilsec.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPKsWRmVeSWpSXmKPExsUixG6nrsvYOzXK4PlXA4vGx1oWr17cZLd4 tnE+i0Vv0xJmiyurGpktPp3vYnRg89g56y67x5IlP5k8Dh5k9Fh15wtrAEsUl01Kak5mWWqR vl0CV8bGPa3sBR+ZK56c1W5g/MPUxcjJISFgInFoxkL2LkYuDiGBxUwSk79tYYJwNjJKfLu8 C8q5yiTRs+46C0gLi4CqxOR5S9hBbDYBFYmG7svMILaIgLrE3/kXwEYxC/QxSuyZ+54VJCEs EC4xdf07oCIODl6gfe9OsEEMXcsosXfJZ7BBvAKCEidnPgFbwCygJXHj30smkHpmAWmJ5f84 QMKcAg4SHyatZQSxRQWUJfb2HWKfwCgwC0n3LCTdsxC6FzAyr2KUTcmt0s1NzMwpTk3WLU5O zMtLLdI11cvNLNFLTSndxAgObxelHYwT/3kdYhTgYFTi4c3InholxJpYVlyZe4hRkoNJSZR3 YydQiC8pP6UyI7E4I76oNCe1+BCjBAezkgjvysWTo4R4UxIrq1KL8mFS0hwsSuK8HibaUUIC 6YklqdmpqQWpRTBZGQ4OJQleiR6goYJFqempFWmZOSUIaSYOTpDhPEDDnUBqeIsLEnOLM9Mh 8qcYLTnaVj5pY+bY9eglkLzx4nUbsxBLXn5eqpQ479tuoAYBkIaM0jy4maB0JZG9v+YVozjQ i8K8hSBjeYCpDm7qK6CFTEALj3yeArKwJBEhJdXAmMg9s379o5lW155Mmq5vqljgWVuzu+uW 2t9zTDu+KstsOvPKZdvffMWwbxbzqq93yZy8+GHL23Lb8mNvf6uUara/vKuh2C58wbPTNuaK w2eWDKE783rX/alwvvqQ4dbSotyFydn5chIcGY6KzLEnnKun3da7r1VYekJse1lqYPmN/l6T hbo8SizFGYmGWsxFxYkA+CO8GDIDAAA= Archived-At: Subject: Re: [TLS] Opsdir last call review of draft-ietf-tls-iana-registry-updates-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 16:53:25 -0000 On Tue, Feb 27, 2018 at 11:25:29AM -0500, Russ Housley wrote: > > > Wouldn't it be sufficient to add a note a the bottom of the registry that says: > > If an item is marked as not recommended it does not necessarily mean > that it is flawed, rather, it indicates that either the item has not > been through the IETF consensus process, has limited applicability, > or is intended only for specific use cases. Basically. But, "not marked as recommended", please. -Ben From nobody Tue Feb 27 11:22:14 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5EA126D05 for ; Tue, 27 Feb 2018 11:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 Lvmtxz4M4ifY for ; Tue, 27 Feb 2018 11:22:06 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3179C127058 for ; Tue, 27 Feb 2018 11:22:06 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id c7so24619614qtn.3 for ; Tue, 27 Feb 2018 11:22:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sLEu4CyWB4rajuR2qoF3Hkkmf4dEKT2UyRcukSfDYxY=; b=mt/Urco8J+cyXBVHrJ3IXHnyIXIM3aih5GWg2zVG/tQf+e91w/a3S7uN9Oht7jeKtF 0Mf63SFBidtgR4o43eLcQhxVM4W2CnCpLuJu9JNstEfzKG6osaIcTMpaefiAmPUihMnd 9fblf2nkOL5oYLr7hXc/py5348ZfH2MW6+hN0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sLEu4CyWB4rajuR2qoF3Hkkmf4dEKT2UyRcukSfDYxY=; b=LxWpJ4zAypMB+iMCKEnN0tWM22LzQM3t6NECkaUXW7Hk/t2DRorrGRcccLLqR+SMPo AN+U7dl5tVZXGLG/gmJNXYGAyrpdpnfOTB2WZgWtC7OaP7JZ1RWr/Shvf2TpzecsknbD OaFE6hStvJHXAGtQjg6FLAa46x8WvqNnXoVxX2SynJ3qDrxpZLhpBQT3kN7h0UiMB6iV s8HNVhHFCrDzziwKKNJs6OuxF8IY3QffEtBe9B54sZ6bfWe8BQpDs1yZ9Pxy0lH3QUGO i7MO/gAn+4PJibAZETXMtG4zHwUlD2KnMwePdlqOX9WsjUO7JFmDvKfi1v3VR5bPpQfI jdMw== X-Gm-Message-State: APf1xPC0E9LrzK/IHpEDlY4n0Ay91w8EZ1eu7wTSUZjefcqJzQo/udyl vVcFhvA97XIzkXQR5HUXf8w26Q== X-Google-Smtp-Source: AG47ELv72Ui/PCBgHxJxhrTu7XCo2efuiE0on4CFlJ6cGY7TUdiRQ+Adu5gznJXbAk5j7qmoWnHeDA== X-Received: by 10.200.55.81 with SMTP id p17mr26341998qtb.282.1519759325231; Tue, 27 Feb 2018 11:22:05 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id m24sm846011qtc.81.2018.02.27.11.22.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Feb 2018 11:22:04 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: Date: Tue, 27 Feb 2018 14:22:03 -0500 Cc: Stewart Bryant , IETF TLS , IETF Gen-ART , IETF Content-Transfer-Encoding: quoted-printable Message-Id: <0EF565D9-C1F4-480A-9D01-8BAEB616736E@sn3rd.com> References: <151915624732.3939.12189669437030269709@ietfa.amsl.com> To: Russ Housley X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Genart last call review of draft-ietf-tls-iana-registry-updates-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 19:22:08 -0000 > On Feb 27, 2018, at 11:21, Russ Housley wrote: >=20 >=20 >>> Minor issues: >>>=20 >>> I think convention is to list the documents being updated in the = Abstract, but >>> cannot find any formal guidance. >>=20 >> You=E2=80=99re right that is the convention, but it=E2=80=99s not = required. draft-flanagan-7322bis is attempting to make including = updates in the abstract a must, but it=E2=80=99s not been through any = kind of LC yet. There is a sentence there saying that a lot of RFCs are = updated and to see the updates header so I think under the 7322 to = balance concise and to not include references I=E2=80=99m thinking this = is okay. >>=20 >=20 > If another update top the document is needed, then it does not seem = hard to comply with the coming convention. Just an FYI I plan to object to the coming convention :) > =3D=3D=3D=3D=3D=3D >>>=20 >>> If an item is marked as not recommended it does not necessarily mean >>> SB> Do you mean "marked as not recommended" or "not marked as = recommended=E2=80=9D. >>=20 >> There are two states for the Recommended column: YES and NO. I can = go either way on whether >> marked as not recommended =3D NO >> not marked as recommended =3D NO >>=20 >> WG - thoughts? >=20 > I think the second wording is more clear. fixed >>> =3D=3D=3D=3D=3D=3D=3D >>> SB> I am worried about the semantics of Recommended =3D no. >>> SB> Presumably there are three states: recommended, not recommended, >>> SB> and silent/don't know/don't care/not yet. Which of these >>> SB> states does Recommended =3D no represent? >>=20 >> There are two states and a draft that specifies a value in a registry = that has a Recommended column needs to state which it is. I=E2=80=99m = not too concerned because we can change the column value later if it = turns out a NO should have been a YES. >=20 > It would be more clear is Section 6 said that each parameter will have = either "yes" or "no" in the new recommended column. Can do: OLD: The instructions in this document add a Recommended column to many of = the TLS registries NEW: The instructions in this document add a Recommended column with a = value of YES or NO to many of the (D)TLS registries PR: = https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/63= From nobody Tue Feb 27 13:01:40 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5BB12D94C for ; Tue, 27 Feb 2018 13:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 aKZhgbNVPFtT for ; Tue, 27 Feb 2018 13:01:37 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A6C41242EA for ; Tue, 27 Feb 2018 13:01:37 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id n12so304573qtl.5 for ; Tue, 27 Feb 2018 13:01:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DlVcPr0c5m3mtLjdqQ3ccuv7/29V7iaJkq57JswjQ3k=; b=SaWJofV31XIpHmkKqtTUwam5/0r0p+V5pnWHGCfg0DBsK8cttgWS87qKn/agixmN6E 6uftbRPO891VAjzyDy8qpoLg6yWBsri3bGVjOzgPrrBQnumE07tUNtzHq9yj02O++lcN N89etotlubQTdEb4TK3lEM+Z+cuveEfK8bltQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DlVcPr0c5m3mtLjdqQ3ccuv7/29V7iaJkq57JswjQ3k=; b=KsjHzzL8pvanj1FdVHFeV4vhdrTZ5N6zK1yOUMi970g6y+Ap/+49dlIqiWcUTlACGi FsxGhT6j5LGd3un+5k7TjdoSEHeyQn3qLik0TRiqT6757fAQIc0J0SJj/AEE8uDzJBh/ 9iXhCjCzPVxD+AHL3+M20GLnrc/XthU/fAiqzJmJmQ4XW1ceO/bLm9/uUEc3kxoqouv/ RbP9KILOPUD89cxQaNg4SdjGfTCNWHXb6RMfVF1LNvaDDvwmywX5bT8WwhlwwVs/3af8 lYYrXaMJOx1W2diTQ1/fYpuMnV3R7PZ8w/8CKH3cHGFEtvk2Bod+gCXuxXPLjiyj5SxX SvHQ== X-Gm-Message-State: APf1xPC23vqLxw/f7+1Q68jmZ94+Y9g+nUPQ7XAKR3i7m+HyVfYTAdZU R3q+t7o0E2qUfdaKaD2Mi1TvPA== X-Google-Smtp-Source: AG47ELtSHm6YouWn2sHtFiJH/YGFta/+2V/81NEdBsOF5jFw43wSJapSBaX3dzP3qlitIg0UMzDc+Q== X-Received: by 10.200.24.46 with SMTP id q43mr26341321qtj.309.1519765296742; Tue, 27 Feb 2018 13:01:36 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id u4sm45091qtg.28.2018.02.27.13.01.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Feb 2018 13:01:36 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: <20180227165308.GZ50954@kduck.kaduk.org> Date: Tue, 27 Feb 2018 16:01:34 -0500 Cc: Russ Housley , Dan Romascanu , ops-dir@ietf.org, IETF TLS , IETF Content-Transfer-Encoding: quoted-printable Message-Id: <29391D2F-B263-4EEE-81CF-1C32AC627B44@sn3rd.com> References: <151912347695.29703.11473433478669184845@ietfa.amsl.com> <57ECF9E5-80AC-4353-9E46-73A19BD085E3@vigilsec.com> <20180227165308.GZ50954@kduck.kaduk.org> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Opsdir last call review of draft-ietf-tls-iana-registry-updates-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 21:01:39 -0000 > On Feb 27, 2018, at 11:53, Benjamin Kaduk wrote: >=20 > On Tue, Feb 27, 2018 at 11:25:29AM -0500, Russ Housley wrote: >>=20 >>=20 >> Wouldn't it be sufficient to add a note a the bottom of the registry = that says: >>=20 >> If an item is marked as not recommended it does not necessarily = mean >> that it is flawed, rather, it indicates that either the item has = not >> been through the IETF consensus process, has limited applicability, >> or is intended only for specific use cases. >=20 > Basically. But, "not marked as recommended", please. Check out the PR: https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/62= From nobody Tue Feb 27 15:17:19 2018 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E3112EB00; Tue, 27 Feb 2018 15:11:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: Kathleen.Moriarty.ietf@gmail.com, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151977307992.5200.2322762380562413607.idtracker@ietfa.amsl.com> Date: Tue, 27 Feb 2018 15:11:19 -0800 Archived-At: Subject: [TLS] tls - Requested sessions have been scheduled for IETF 101 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 23:11:21 -0000 Dear Sean Turner, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tls Session 1 (2:30:00) Wednesday, Morning Session I 0930-1200 Room Name: Blenheim size: 200 --------------------------------------------- tls Session 2 (1:00:00) Monday, Afternoon Session III 1740-1840 Room Name: Balmoral size: 250 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: Sean Turner Number of Sessions: 2 Length of Session(s): 2.5 Hours, 1 Hour Number of Attendees: 120 Conflicts to Avoid: First Priority: quic rtcweb stir curdle saag uta acme cfrg httpbis tokbind perc dispatch suit Second Priority: dprive ace Third Priority: tcpinc lamps People who must be present: Eric Rescorla Sean Turner Joseph A. Salowey Kathleen Moriarty Benjamin Kaduk Resources Requested: Special Requests: 1 hour slot pre-plenary If sec-dispatch ends up being a thing please don't schedule us against that. Also please don't put us up against the TEEP. --------------------------------------------------------- From nobody Tue Feb 27 15:36:19 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA99D12EA54; Tue, 27 Feb 2018 15:36:17 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 hj1pcwqe4W-h; Tue, 27 Feb 2018 15:36:16 -0800 (PST) Received: from homiemail-a32.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0EBA12D892; Tue, 27 Feb 2018 15:36:16 -0800 (PST) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 5216E6000F07; Tue, 27 Feb 2018 15:36:16 -0800 (PST) Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id B44686000F06; Tue, 27 Feb 2018 15:36:15 -0800 (PST) Date: Tue, 27 Feb 2018 17:36:12 -0600 From: Nico Williams To: Shumon Huque Cc: Viktor Dukhovni , The IESG , draft-ietf-tls-dnssec-chain-extension@ietf.org, TLS WG , tls-chairs Message-ID: <20180227233610.GD8921@localhost> References: <151801408058.4807.6327251050641650375.idtracker@ietfa.amsl.com> <70D42B5C-7FF9-49C1-95D4-13FDC611FF96@dukhovni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 23:36:18 -0000 On Tue, Feb 27, 2018 at 11:24:31AM -0500, Shumon Huque wrote: > On Tue, Feb 27, 2018 at 10:59 AM, Shumon Huque wrote: > > Several of us were well aware of this during the early days of the > > draft, but perhaps many folks did not fully appreciate the impacts > > until I elaborated on them last year, and added text that described > > the "adversary with fraudulently obtained PKIX credentials" attack. > > Following up to my own message, sorry .. > > It occurred to me that perhaps a good way to mitigate this risk is > a combo of mechanisms like CAA and Certificate Transparency logs. NO. That's insanely complicated. A pin-for-X-minutes TTL is trivial. Let's do this pin-to-DANE thing. Nico -- From nobody Tue Feb 27 15:39:07 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C338412EA64; Tue, 27 Feb 2018 15:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com 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 PYLQQJ7qmXHi; Tue, 27 Feb 2018 15:38:59 -0800 (PST) Received: from homiemail-a32.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6F4512D892; Tue, 27 Feb 2018 15:38:59 -0800 (PST) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 70B016000F06; Tue, 27 Feb 2018 15:38:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=ZrbatDrwJTpuyx S+cVwODzcQ/uw=; b=h8n07jzSTNH3Yas89hqVEUUy3JOEAdgIXb4Zp3U7rIy0Lc KnSgmAXmty0/Hih/ZGp+OLpvvJeL8vA1L5vDddWzbPdrCbN9H9IQTZNPuSU/Cc4E wZw5ZQ0Foj1gVA60PmG0O2XRdtDL9V+xGD+U462EU43qUe8mvlWXsR5rvj4co= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id E42F26000F05; Tue, 27 Feb 2018 15:38:58 -0800 (PST) Date: Tue, 27 Feb 2018 17:38:55 -0600 From: Nico Williams To: Shumon Huque Cc: Viktor Dukhovni , The IESG , draft-ietf-tls-dnssec-chain-extension@ietf.org, TLS WG , tls-chairs Message-ID: <20180227233854.GE8921@localhost> References: <70D42B5C-7FF9-49C1-95D4-13FDC611FF96@dukhovni.org> <20180227233610.GD8921@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180227233610.GD8921@localhost> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 23:39:01 -0000 On Tue, Feb 27, 2018 at 05:36:12PM -0600, Nico Williams wrote: > On Tue, Feb 27, 2018 at 11:24:31AM -0500, Shumon Huque wrote: > > On Tue, Feb 27, 2018 at 10:59 AM, Shumon Huque wrote: > > > Several of us were well aware of this during the early days of the > > > draft, but perhaps many folks did not fully appreciate the impacts > > > until I elaborated on them last year, and added text that described > > > the "adversary with fraudulently obtained PKIX credentials" attack. > > > > Following up to my own message, sorry .. > > > > It occurred to me that perhaps a good way to mitigate this risk is > > a combo of mechanisms like CAA and Certificate Transparency logs. > > NO. That's insanely complicated. A pin-for-X-minutes TTL is trivial. > Let's do this pin-to-DANE thing. And I should add that if you'd work around downgrades by using CT, then why bother with this extension *AT ALL*?! I can't be emphatic enough about this. This is an utter waste of everyone's time here if we don't have this pin-to-DANE feature in this draft. The authors' time, the WG's time, the IESG's time, and implementors' time. Nico -- From nobody Wed Feb 28 11:32:34 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616FE1200E5 for ; Wed, 28 Feb 2018 11:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 uLDC5dvy1ur3 for ; Wed, 28 Feb 2018 11:32:32 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7239A126C19 for ; Wed, 28 Feb 2018 11:32:30 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id o25so4475603qkl.7 for ; Wed, 28 Feb 2018 11:32:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=N0F9SmFKW5mHVrDGIAyw8InZCfgYhITZGZE7FqqJzkA=; b=DE+VaIQCyjHw699PDRr61E2om9QZQu0HBzWxtUlExUoZtKP6Sg0Y+dRJgK1JzOt40+ RhEV/1+bPVJLQVg9n2COsGzWgoNBoEiiaMkUa+9rRatssE0vm9VdGlcsPoDI7je3704N DE24Zx7mGJy+OchxijUr6isV9yboCiytz7TZk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=N0F9SmFKW5mHVrDGIAyw8InZCfgYhITZGZE7FqqJzkA=; b=XClali3rDD0VQJRCavRWrkMVRG3qV17pRQDaRxmvXF/0YZqA3/kjfmPJYRPv0rw9Qy b3WWX4PR6rzppDwcDAwnE8zrkRLE/nBQhf4EWQoH/+/5O/77tVO3IrR7a4HElFo9Cexr t5AnNcPmYUD5YisYgL536hr7/6goRPEnROgqAGCbKTtcghkJMaKH1KyX7LfMV24HC3UA 8BiLh0AehIF1PVHqQJGvGe1iOAIUKMF7A42O+ePXs+ye37TgL6n7AnTwVTHuZXzeVyBn 0dJrjiZKvqXXWH88w4jJ9h6czgoTAVO7EfrDRg6lzy1WCropHfQQEQONDBIOFldYh4jR 4aFQ== X-Gm-Message-State: APf1xPAw3/a2ChMOsCRp2lWxEtB9z3hXKbjTe8/g3odfM2G1+/ihnsAC 6Q9Ktt4QI3jFe/hTfBbwfzsg6dCMvSw= X-Google-Smtp-Source: AG47ELvTCSB3Cp5YP7t+KCl88kc7ZPv9KMuQVom0U1xmqP25cyrTTBZhdfICu3lybtKTA1un8CQQBQ== X-Received: by 10.55.126.69 with SMTP id z66mr28587356qkc.218.1519846348764; Wed, 28 Feb 2018 11:32:28 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id i51sm1703988qta.32.2018.02.28.11.32.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Feb 2018 11:32:27 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: <151872913465.7464.15939171695893457090.idtracker@ietfa.amsl.com> Date: Wed, 28 Feb 2018 14:32:26 -0500 Cc: Kathleen Moriarty , tls-chairs , draft-ietf-tls-iana-registry-updates@ietf.org, Stephen Farrell Content-Transfer-Encoding: quoted-printable Message-Id: References: <151872913465.7464.15939171695893457090.idtracker@ietfa.amsl.com> To: IETF TLS X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] Last Call: (IANA Registry Updates for TLS and DTLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 19:32:33 -0000 While discussing the other changes with Joe, I noted the AES-128 CCM PSK = cipher suites listed need to be the ones that are being registered in = draft-ietf-tls-ecdhe-psk-aead. That draft lists two: TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 while draft-ietf-tls-iana-registry-updates lists: TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 draft-ietf-tls-iana-registry-updates needs drop = TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 from the recommended list because = it=E2=80=99s not defined. PR to fix is here: https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/64 spt > On Feb 15, 2018, at 16:12, The IESG wrote: >=20 >=20 > The IESG has received a request from the Transport Layer Security WG = (tls) to > consider the following document: - 'IANA Registry Updates for TLS and = DTLS' > as Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits = final > comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2018-03-01. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the = beginning of > the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > This document describes a number of changes to (D)TLS IANA = registries > that range from adding notes to the registry all the way to changing > the registration policy. These changes were mostly motivated by WG > review of the (D)TLS-related registries undertaken as part of the > TLS1.3 development process. This document updates many (D)TLS RFCs > (see updates header). >=20 >=20 >=20 >=20 > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ >=20 > IESG discussion can be tracked via > = https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/ball= ot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 > The document contains these normative downward references. > See RFC 3967 for additional information:=20 > rfc5878: Transport Layer Security (TLS) Authorization Extensions = (Experimental - IETF stream) >=20 >=20 >=20 From nobody Wed Feb 28 12:07:24 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9237120227; Wed, 28 Feb 2018 12:07:16 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 oxcTuFYP-1lO; Wed, 28 Feb 2018 12:07:15 -0800 (PST) Received: from homiemail-a32.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 775B51200E5; Wed, 28 Feb 2018 12:07:15 -0800 (PST) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id DC7B26000F05; Wed, 28 Feb 2018 12:07:14 -0800 (PST) Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 3DF806000F06; Wed, 28 Feb 2018 12:07:14 -0800 (PST) Date: Wed, 28 Feb 2018 14:07:10 -0600 From: Nico Williams To: Shumon Huque Cc: Viktor Dukhovni , The IESG , draft-ietf-tls-dnssec-chain-extension@ietf.org, TLS WG , tls-chairs Message-ID: <20180228200707.GF8921@localhost> References: <70D42B5C-7FF9-49C1-95D4-13FDC611FF96@dukhovni.org> <20180227233610.GD8921@localhost> <20180227233854.GE8921@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180227233854.GE8921@localhost> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 20:07:17 -0000 IF there's an objection to modifying the extension in order to add a pin-to-DANE TTL field, I would propose the following instead: Make the pin-to-DANE be "forever" but make it so it can easily be cleared if DANE is undeployed for the service. That would look like this: - if the server sends the extension with a valid DANE RR chain -> pin to DANE (no TTL needed; see below) - if the server sends the extension with a non-existence proof for DANE -> clear the PIN to DANE - if the server sends the extension with proof that an intermediate domain is not signed -> clear the PIN to DANE This has the great benefit that it is simple. Also, I'm not at all sure that a pin TTL is actually useful. If I know bar.foo.example. supports DANE, why would I want to asynchronously stop expecting it to use DANE when it could just tell me (with a suitable proof)? Nico -- From nobody Wed Feb 28 14:41:36 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575B3127023 for ; Wed, 28 Feb 2018 14:41:29 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 sX5KioTQT7f6 for ; Wed, 28 Feb 2018 14:41:27 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94A76126FB3 for ; Wed, 28 Feb 2018 14:41:27 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id g60so5148007qtd.11 for ; Wed, 28 Feb 2018 14:41:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=DRG1DNwvB66cP/bQufeedQQo4fM56/Kav250kC46tBY=; b=QPY/ywArVjvezMpMX3STy6ocAFBwFmKSV8xBpftPm1E+U7iziIRlDLDMzfAjfeprB9 13xPFsDuhA+G0x7pX/Kh7e/83nEtKzJJkGLrNgwR5KjXiKInbLI9uij4kj6A2Y5Lc3Om lwG6Ati5/L0o1W8Q+KH5e5dgAR+E+izjwXsNI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=DRG1DNwvB66cP/bQufeedQQo4fM56/Kav250kC46tBY=; b=s6vaKFhHW7KWOGnklUef6wTBEWL+eL4CEyUSkfvLgXD0CL/px4r+Ez/3CBUReFC+Wv MP2GqzuGRDTw5VlVDh4A7drCNwt23TpyfAhbmdqFLXyiVNIzRWwB2mtu/2vK8UztU3ws qghdBrGqQVu+VdVweNvi7695L7WiJr99+G7bMcght/bliyoTFqIIhmQdMPT2uU2uxrBT dfokoJqg+gu9jvjz1S7Xd7eP9ZANdvUUIx+tJr4YAqJYDY2LzlRghqvg+YOgOMWMtQij ZF9xHXb29AO7SPhDAd4KRCFwx1doN9C7qgSvJl76dHvecEv0I/lxDUM5ivtCn6tYptUf L74g== X-Gm-Message-State: APf1xPD3J0Fh4xVj7FvpAyaRRuB3YuGgC/IqTCDmsOQWObN2xIrvwzG+ xzNYs9zdkD6nIGM/kRnAfPmsCXEm0nk= X-Google-Smtp-Source: AG47ELtxMVSipgQX2TzdIN4kdnXeJwuwd681/hqt8+JRe2x2yHxbM1t6d8Tc2EflC65rUzp9YVyE2Q== X-Received: by 10.200.83.12 with SMTP id t12mr33548161qtn.333.1519857686649; Wed, 28 Feb 2018 14:41:26 -0800 (PST) Received: from [172.16.0.18] ([96.231.218.194]) by smtp.gmail.com with ESMTPSA id o126sm1776096qkc.77.2018.02.28.14.41.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Feb 2018 14:41:25 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 28 Feb 2018 17:41:23 -0500 References: <6D27D187-ABD3-442F-9EA1-1D1BC6180A6C@sn3rd.com> To: "" In-Reply-To: <6D27D187-ABD3-442F-9EA1-1D1BC6180A6C@sn3rd.com> Message-Id: <350247DB-520D-423D-8422-F4B2235CEF6A@sn3rd.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [TLS] TLS@IETF101: agenda requests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 22:41:29 -0000 This is a reminder to get those requests in! Thanks, spt > On Jan 30, 2018, at 15:55, Sean Turner wrote: >=20 > All, >=20 > The TLS WG will meet @ IETF101. Please submit requests for agenda = time to tls-chairs@ietf.org. Along with your request please let us know = how long you would like. We will send out a remind later, but we are = trying to get an early sense of how much time we will need. >=20 > Thanks! >=20 > J&S