From nobody Mon Jun 9 06:30:56 2014 Return-Path: X-Original-To: tcpcrypt@ietfa.amsl.com Delivered-To: tcpcrypt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B8C1A0319; Thu, 5 Jun 2014 14:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DJ4HkkQaqcf; Thu, 5 Jun 2014 14:31:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC511A02B0; Thu, 5 Jun 2014 14:31:12 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140605213112.12161.1481.idtracker@ietfa.amsl.com> Date: Thu, 05 Jun 2014 14:31:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/sLxxYpWnfHy47iisOQCyw32gLRg X-Mailman-Approved-At: Mon, 09 Jun 2014 06:30:54 -0700 Cc: tcpinc WG Subject: [Tcpcrypt] WG Review: TCP Increased Security (tcpinc) X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 21:31:14 -0000 A new IETF working group has been proposed in the Transport Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2014-06-15. TCP Increased Security (tcpinc) ------------------------------------------------ Current Status: Proposed WG Technical advisors: Stephen Farrell Assigned Area Director: Martin Stiemerling Mailing list Address: tcpcrypt@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tcpcrypt Archive: http://www.ietf.org/mail-archive/web/tcpcrypt/ Charter: The TCPINC WG will develop the TCP extensions to provide unauthenticated encryption and integrity protection of TCP streams. The WG will define an unauthenticated key exchange mechanism. In addition, the WG will define the TCP extensions to utilize unauthenticated keys, resulting in encryption and integrity protection without authentication. This is better than plain-text because it thwarts passive eavesdropping, but is weaker than using authenticated keys, because it is vulnerable to man- in-the-middle attacks during the initial unathenticated key exchange. This work is part of the IETF effort to evolve the Internet architecture given the latest events of pervasive monitoring (see BCP 188). The goal of this WG is to provide an additional security tool that complements existing protocols at other layers in the stack. The WG will be looking for the designs that find the right tradeoff spot between conflicting requirements: to provide reasonable security for the majority of connections. This work will deal with unprotected connections, and therefore will focus more on improvements from a baseline of no security than on achieving the high standard of security that is already available to users of authenticated TLS. Providing unauthenticated encryption and integrity protection at the TCP layer will provide a set of features that cannot be achieved with existing tools. Those features include: - encryption and integrity protection without modifications to the upper layers (no API changes), - encryption and integrity protection with forward secrecy with a per-connection granularity, - simple NAT and firewall traversal capabilities, - key rollover without significant impact to the TCP connection, - lower overhead compared to solutions relying in stacking multiple protocols to achieve different features, - no manual configuration required. A more detailed description of the motivations for TCP-based solutions can be found in draft-bellovin-tcpsec-01 and in RFC5925. The working group will produce documents specifying the required TCP extensions and additional documents needed. The high-level requirements for the protocol for providing TCP unauthenticated encryption and integrity protection are: - It should work over the vast majority of paths that unmodified TCP works over, in particular it must be compatible with NATs (at the very minimum with the NATs that comply with BEHAVE requirements as documented in RFC4787, RFC5382 and RFC5508). - The protocol must be usable by unmodified applications. This effort is complementary to other security protocols developed in the IETF (such as TLS) as it protects those applications and protocols that are difficult to change or may even not be able to be changed in a backward compatible way. It also provides some protection in scenarios where application developers are unwilling to change their applications (e.g., by configuring encryption) solely for the sake of improving security. - The protocol must provide cryptographic algorithm agility. - The protocol must gracefully fall-back to TCP if the remote peer does not support the proposed extensions. - When encryption is enabled, it must at least provide protection against passive eavesdropping by default, - Any required TCP option should use a minimum amount of TCP option space, especially in SYN segments. - The protocol must not require any authentication or configuration from applications or users. However, hooks for external authentication must be made available. The WG will not work on new authentication mechanisms. - The protocol must have acceptable performance, including acceptable latency and processing overheads. For example, the protocol may try to re-use existing cryptographic material for future communication between the same endpoints to avoid expensive public key operations on connection set up. When encryption is enabled, then the protocol: - must always provide forward secrecy. - must always provide integrity protection of the payload data (it is open for discussion for the WG if the TCP header should or should not be protected). - must always provide payload encryption. - must not provide extra linkability: when encryption is enabled, the TCP traffic should not give a third party observer any extra way to associate those packets with the specific peers beyond information that would have been present in a cleartext session. - must allow the initiator of the connection to avoid fingerprinting: some initiators may want to avoid appearing as the same endpoint when connecting to a remote peer on subsequent occasions. This should either be the default or some mechanism should be available for initiators to drop or ignore shared state to avoid being fingerprintable any more than would be the case for a cleartext session. Security features at the TCP-level can benefit other TCP extensions. For example, both Multipath TCP and TCP Fast Open require proof that some connections are related. Session resumption and Message Authentication Codes (MACs) can provide this evidence. The working group should identify synergies and design the security protocol in such a way that other TCP efforts can benefit from it. Of course, TCP extensions that break must be identified too, and kept to a minimum. The working group will produce the following documents: - A framework for unauthenticated encryption and integrity protection of TCP connections. This document will describe basic design considerations, including the motivation and the applicability of the proposed mechanism, the interaction with other security mechanisms in different layers of the stack, the interaction with external authentication mechanisms, the expected protection, privacy considerations and residual threats. - Definition of the unauthenticated key exchange mechanism and the extensions to current TCP to utilize unauthenticated key to provide encryption and integrity protection. This covers all the protocol changes required. This will be an experimental document. - An extended API describing how applications can obtain further benefits of the proposed extensions. In particular, the hooks for supporting external authentication will be defined in this document. This will be an informational document. Milestones: TBD From nobody Wed Jun 18 14:15:11 2014 Return-Path: X-Original-To: tcpcrypt@ietfa.amsl.com Delivered-To: tcpcrypt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCFB1A0195 for ; Wed, 18 Jun 2014 14:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_64=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9W1BCaDHG_X for ; Wed, 18 Jun 2014 14:15:07 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BD3E1A0314 for ; Wed, 18 Jun 2014 14:15:07 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id il7so1386602vcb.41 for ; Wed, 18 Jun 2014 14:15:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=W6OIBqEwgTPKZUT9LYy52Z0hTl6Hhg2JZd+LiRaJktw=; b=WuQSOoz7Q3/nvkBdokXeYzCCBQKi24TM9h8eYvu84HlL2f7nDa7W7n8sz4b7lxoReS QqdZpg+Vgc7Hfpm5RO0KZ+APaAih7vDPA/oc0PuWmm095XqSID6jpz9yh3AzJ/cmwU3n MLjUb+ZMq1l55fI8HK9Z47GfuOS/YGEEMbZYXc2zvEZvTfb+1fii+DIujEn75f3EnG1L uIiC4wYQvQ3Di4irLpTgt2YEv/SSNO82eFhhpnc6PfQphBKgE9F3b0XtQeCX+L1zw4XI DgGXJ+CgZYSESrNaxyi34j5cmvtrB8ciGiKQZxb07giPLoEcpTbg3ENeu/7TDveMBOoT IKHA== MIME-Version: 1.0 X-Received: by 10.52.29.236 with SMTP id n12mr327284vdh.38.1403126106337; Wed, 18 Jun 2014 14:15:06 -0700 (PDT) Received: by 10.58.235.34 with HTTP; Wed, 18 Jun 2014 14:15:06 -0700 (PDT) Date: Wed, 18 Jun 2014 17:15:06 -0400 Message-ID: From: Sandy Harris To: tcpcrypt@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/6OgjfhX8CzDu-51ThS3VESU_1nA Subject: [Tcpcrypt] Initial questions X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 21:15:09 -0000 This is basically a fine idea & I'm glad to see people working on it. Some comments in the archive had me somewhat worried, and the current draft charter has the following: - When encryption is enabled, it must at least provide protection against passive eavesdropping by default, ... When encryption is enabled, then the protocol: - must always provide forward secrecy. - must always provide integrity protection of the payload data ... - must always provide payload encryption. Why on Earth do these have "When encryption is enabled"? As others have said quite eloquently in various posts, there is no reason at all to even consider a null encryption mode; anyone who needs that can just fall back to TCP. I'd go further. At a bare minimum, reject the insecure things FreeS/WAN refused to do 15 years ago even though they were in the IPsec RFCs -- single DES, small DH groups and null encryption. http://www.freeswan.org/freeswan_trees/freeswan-2.06/doc/compat.html#dropped Probably today we should go much further. No MD5 or SHA1 since there are known problems. No 3DES since newer ciphers are far faster. No reliance on the whole X.509 cert infrastructure SLL/TLS uses; that also has known problems. I'm not sure what else. The draft charter also has: - The protocol must provide cryptographic algorithm agility. OK, but there is a balance to be struck. IPsec & TLS both have problems from arguably excessive complexity and in general complexity is the enemy of security. It makes all of design, implementation, testing & auditing much harder. TCPcrypt has a rather narrow niche to fill; that can be done with a fairly simple protocol. We really must strive to keep it simple. Here's a first cut at what we might support: Block ciphers: MUST do AES. SHOULD do the other three AES finalists with open licenses: Mars, Twofish & Serpent. MAY do compatible ciphers which are national standards: Aria for Korea, Camellia for Japan, maybe others. Nothing else. Overhead for those is minimal since they all have same block size as AES and same range of key sizes, so they are drop-in replacements. Also, all the AES candidates and Aria have readily available open source code; I have not checked for Camellia. Key size? I'd mandate 128 bits everywhere to keep it simple. Authentication: The draft has: - must always provide integrity protection of the payload data (it is open for discussion for the WG if the TCP header should or not be protected) AEAD (authenticated encryption with additional data) algorithms have partly replaced the cipher+HMAC combination in both IPsec and TLS. They are often faster, and the "additional data" feature would let us protect the TCP header at negligible extra cost. I'd say they are obviously what we should use. I'd just take two with existing RFCs -- AES-GCM RFC 5288 and OCB RFC 7253 -- and make them both MUST. Leave HMAC out to keep it simple. The draft also has: - Must gracefully fall-back to TCP if the remote peer does not support the proposed extensions Aren't there a set of policy questions there? Some users might prefer to drop the connection rather than communicate insecurely. Perhaps they need a mechansim to set policy, globally and/or on a per-connection basis. FreeS/WAN had something like this for IPsec over a decade ago: http://www.freeswan.org/freeswan_trees/freeswan-2.06/doc/policygroups.html At an absolute minimum, I think there must be a requirement that any fallback action is logged. Another question is whether we could achieve the goals of this group with almost no work just by deploying existing stuff. The now-closed BTNS working group did RFCs 5386 & 5387 on "Better than nothing security", which they implemented as an unauthenticated mode for IPsec. That sounds much like what we are aiming at. Can we just work on getting BTNS deployed, thereby protecting both TCP and other protocols? The draft has: - Must not require any authentication or configuration from applications or users. However, hooks for external authentication must be made available. RFC 4322 describes an authentication mechansim for IPsec opportunistic encryption using keys stored in DNS. Could we make that the external hook and fall back to BTNS if the right record is not found? Even if we choose to avoid the complexity of IPsec and design something specifically for TCP instead of just using BTNS, the idea of using DNS for keys may be useful. I do not know details, but it looks as though the DANE working group is doing this sort of thing: https://datatracker.ietf.org/wg/dane/ From nobody Wed Jun 18 14:20:40 2014 Return-Path: X-Original-To: tcpcrypt@ietfa.amsl.com Delivered-To: tcpcrypt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C76E1A0314 for ; Wed, 18 Jun 2014 14:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 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, HTML_OBFUSCATE_10_20=0.093, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qqNVsGC0JOL for ; Wed, 18 Jun 2014 14:20:38 -0700 (PDT) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED1561A0303 for ; Wed, 18 Jun 2014 14:20:37 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id db11so1460518veb.12 for ; Wed, 18 Jun 2014 14:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HXxVkj1a3JY8Fw+miduJkLYjBhi0qphpeL5BCuw3+lA=; b=scDvayFjpj9gNiiLvroIf7MAtRcO48HSrVVaPKG5UR6d8/whctNexQMoVmXI+Q3b7y 0G5itAcHpqv6UkOplopg2yP0lj65edQ9zHEEYy3Fo4rY6Tg+/3xcPGscSV9TSvCCSHBP k7KzSaajSG8JIepePvy09aKMvsLeBrzctIiGwqtdWtkCB2Ukw0D9RJN6DlDcpTD19n5B 7V8fpnpixDQR0H2sJq2oktVO24lyKthImG6/q+WhlCRKelhz7jX9jSlbBYfD7qBE/EZw T7nJ394ju0gmimgt6DYzWY+9g2dAehkdasPnRtf0rusHeK0eSY94R9l9BcV0fBeOrcba 5CBg== X-Received: by 10.221.59.194 with SMTP id wp2mr41224vcb.59.1403126437106; Wed, 18 Jun 2014 14:20:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.168.133 with HTTP; Wed, 18 Jun 2014 14:20:16 -0700 (PDT) In-Reply-To: References: From: Tony Arcieri Date: Wed, 18 Jun 2014 14:20:16 -0700 Message-ID: To: Sandy Harris Content-Type: multipart/alternative; boundary=001a11335472dbdf6c04fc22d430 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/1-6ggYKXJ9EYXjMcKVTo9zV5zSw Cc: "tcpcrypt@ietf.org" Subject: Re: [Tcpcrypt] Initial questions X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 21:20:39 -0000 --001a11335472dbdf6c04fc22d430 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 18, 2014 at 2:15 PM, Sandy Harris wrote: > Why on Earth do these have "When encryption is enabled"? "Every once in a while, someone not an NSA employee, but who had longstanding ties to NSA, would make a suggestion that reduced privacy or security, but which seemed to make sense when viewed by people who didn't know much about crypto. For example, using the same IV (initialization vector) throughout a session, rather than making a new one for each packet. Or, retaining a way to for this encryption protocol to specify that no encryption is to be applied." -- John Gilmore -- Tony Arcieri --001a11335472dbdf6c04fc22d430 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 18, 2014 at 2:15 PM, Sandy Harris <sandyinchina@gmail.com> wrote:
Why on Earth do these have "When encryption is enable= d"?

= =C2=A0"Every=C2=A0once=C2=A0in a=C2=A0while,=C2=A0someone=C2=A0not=C2=A0an=C2=A0NSA=C2=A0employee= ,=C2=A0<= /span>but=C2= =A0who=C2=A0had
=C2=A0=C2=A0= longstanding=C2=A0ties=C2=A0to=C2=A0NSA, would make a suggestion that reduced privacy<= br style=3D"font-family:arial,sans-serif;font-size:13px"> =C2=A0 or secur= ity,=C2=A0but=C2=A0which seemed to make sense when viewed by people who =C2=A0 didn'= ;t know much about crypto. For example, using the same IV
=C2=A0 (initialization vector) throughout= a session, rather than making a new
=C2=A0 one for = each packet. Or, retaining a way to for this encryption
=C2=A0 protocol to specify that no encryption= is to be applied."

=C2=A0 =C2=A0 -- John Gilm= ore=C2=A0

--
Tony Arcieri
--001a11335472dbdf6c04fc22d430-- From nobody Wed Jun 18 14:26:59 2014 Return-Path: X-Original-To: tcpcrypt@ietfa.amsl.com Delivered-To: tcpcrypt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9DF1A0319 for ; Wed, 18 Jun 2014 14:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCoEmzHnvS1n for ; Wed, 18 Jun 2014 14:26:49 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4DBD1A0303 for ; Wed, 18 Jun 2014 14:26:49 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s5ILQZpK010839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 18 Jun 2014 14:26:35 -0700 (PDT) Message-ID: <53A2040B.7000804@isi.edu> Date: Wed, 18 Jun 2014 14:26:35 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Sandy Harris , tcpcrypt@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/8OCW_s5cb_OoMQOpY062ukWQhL0 Subject: Re: [Tcpcrypt] Initial questions X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 21:26:51 -0000 On 6/18/2014 2:15 PM, Sandy Harris wrote: > This is basically a fine idea & I'm glad to see people working on it. > > Some comments in the archive had me somewhat worried, and the current > draft charter has the following: > > - When encryption is enabled, it must at least provide protection against > passive eavesdropping by default, > ... > When encryption is enabled, then the protocol: > - must always provide forward secrecy. > - must always provide integrity protection of the payload data ... > - must always provide payload encryption. > > Why on Earth do these have "When encryption is enabled"? As others > have said quite eloquently in various posts, there is no reason at all > to even consider a null encryption mode; anyone who needs that can > just fall back to TCP. That's what "when encryption is enabled" means - i.e., there are (at least) two valid modes: use TCPCRYPT do not use TCPCRYPT Regardless of what this WG develops, the latter will always need to be an alternative. The charter is perhaps being overly pedantic in noting that the gains claimed occur only when the methods indicated are in use. Joe From nobody Wed Jun 18 14:37:30 2014 Return-Path: X-Original-To: tcpcrypt@ietfa.amsl.com Delivered-To: tcpcrypt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158FD1A0166 for ; Wed, 18 Jun 2014 14:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcdMkqe8R6ji for ; Wed, 18 Jun 2014 14:37:20 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8CAC1A010F for ; Wed, 18 Jun 2014 14:37:20 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s5ILag8o013932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 18 Jun 2014 14:36:42 -0700 (PDT) Message-ID: <53A2066A.4090802@isi.edu> Date: Wed, 18 Jun 2014 14:36:42 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Sandy Harris , tcpcrypt@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/MYz1K7YYbySKb5XArr644OMqLLA Subject: Re: [Tcpcrypt] Initial questions X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 21:37:26 -0000 Comments on your other points: On 6/18/2014 2:15 PM, Sandy Harris wrote: As to the specific algorithms and how many, we probably all agree that a small number of required algorithms is preferable. I think 2 is a good upper bound on the MUST algorithms, though. Algorithm agility just means that the protocol isn't inherently dependent on any one algorithm, so that it can be extended in the future to support other algorithms - that seems prudent. ... > Authentication: The draft has: > > - must always provide integrity protection of the payload data (it is open for > discussion for the WG if the TCP header should or not be protected) If you don't protect the header, IMO you're not doing TCP security, and might as well use TLS. > - Must gracefully fall-back to TCP if the remote peer does not support the > proposed extensions > > Aren't there a set of policy questions there? Gracefully != silently Gracefully != without regard for policy I think the intent of the requirement is that graceful fallback needs to be supported, but not that it is either silent or the default - especially for associations indicated as preferring/requiring TCPCRYPT. > Another question is whether we could achieve the goals of this group > with almost no work just by deploying existing stuff. > > The now-closed BTNS working group did RFCs 5386 & 5387 on "Better than > nothing security", which they implemented as an unauthenticated mode > for IPsec. That sounds much like what we are aiming at. Can we just > work on getting BTNS deployed, thereby protecting both TCP and other > protocols? That's certainly one possibility, but IPsec protection isn't quite the same as TCP-level. IPsec won't create new keying material for each TCP connection, whereas a TCP-level solution might. IPsec solutions also often required tunneling over UDP for NAT traversal, whereas a TCP solution might not (e.g., if the TCP header is protected but not encrypted). > The draft has: > > - Must not require any authentication or configuration from > applications or users. However, hooks for external authentication must > be made available. > > RFC 4322 describes an authentication mechansim for IPsec opportunistic > encryption using keys stored in DNS. Could we make that the external > hook and fall back to BTNS if the right record is not found? It's possible, but TCP currently doesn't consult the DNS directly; inserting this dependence in a TCP-layer protocol could introduce additional delays. Joe From nobody Wed Jun 18 22:43:43 2014 Return-Path: X-Original-To: tcpcrypt@ietfa.amsl.com Delivered-To: tcpcrypt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC5B1A0172 for ; Wed, 18 Jun 2014 22:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.852 X-Spam-Level: X-Spam-Status: No, score=-104.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfxzevrsEj3B for ; Wed, 18 Jun 2014 22:43:37 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01CA41A0343 for ; Wed, 18 Jun 2014 22:43:35 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 28CC98B5DE3 for ; Thu, 19 Jun 2014 07:43:34 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [10.0.1.2] (37.120.220.87.dynamic.jazztel.es [87.220.120.37]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id 042A9766F9E for ; Thu, 19 Jun 2014 07:43:33 +0200 (CEST) Message-ID: <53A27886.9070402@it.uc3m.es> Date: Thu, 19 Jun 2014 07:43:34 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tcpcrypt@ietf.org References: <53A2040B.7000804@isi.edu> In-Reply-To: <53A2040B.7000804@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20766.004 X-TM-AS-Result: No--28.840-7.0-31-1 X-imss-scan-details: No--28.840-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/Iacj8yuT8PhT-ySA_n2wOGPjUTM Subject: Re: [Tcpcrypt] Initial questions X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 05:43:40 -0000 Yes, exactly what Joe said. This is the extract of one email that cuased this particular piece of text in the charter: On Thu, Mar 13, 2014 at 10:21:55AM +0100, marcelo bagnulo braun wrote: (the original charter text used to say) > - the protocol must gracefully fall-back to TCP if the remote peer > does not support the proposed extensions > - the protocol must always provide forward secrecy. > - the protocol must always provide integrity protection of the (then someone commented) Cool! How do you reconcile the first point with the last two? If it falls back to normal TCP, it would also need SSL or similar to always provide forward secrecy and integrity protection. Or is this part of the TCPcrypt API that the application must be careful to check? So, we changed it to what is currently in the charter. Hope this clarifies this particular point. Regards, marcelo El 18/06/14 23:26, Joe Touch escribió: > > > On 6/18/2014 2:15 PM, Sandy Harris wrote: >> This is basically a fine idea & I'm glad to see people working on it. >> >> Some comments in the archive had me somewhat worried, and the current >> draft charter has the following: >> >> - When encryption is enabled, it must at least provide protection >> against >> passive eavesdropping by default, >> ... >> When encryption is enabled, then the protocol: >> - must always provide forward secrecy. >> - must always provide integrity protection of the payload data ... >> - must always provide payload encryption. >> >> Why on Earth do these have "When encryption is enabled"? As others >> have said quite eloquently in various posts, there is no reason at all >> to even consider a null encryption mode; anyone who needs that can >> just fall back to TCP. > > That's what "when encryption is enabled" means - i.e., there are (at > least) two valid modes: > > use TCPCRYPT > > do not use TCPCRYPT > > Regardless of what this WG develops, the latter will always need to be > an alternative. The charter is perhaps being overly pedantic in noting > that the gains claimed occur only when the methods indicated are in use. > > Joe > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > From nobody Wed Jun 18 22:58:52 2014 Return-Path: X-Original-To: tcpcrypt@ietfa.amsl.com Delivered-To: tcpcrypt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A47E1A033D for ; Wed, 18 Jun 2014 22:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.252 X-Spam-Level: X-Spam-Status: No, score=-104.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noytD9hY3Rid for ; Wed, 18 Jun 2014 22:58:45 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE6661A0172 for ; Wed, 18 Jun 2014 22:58:44 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id ECCC18B7677 for ; Thu, 19 Jun 2014 07:58:42 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [10.0.1.2] (37.120.220.87.dynamic.jazztel.es [87.220.120.37]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: marcelo@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id B8E7B76566A for ; Thu, 19 Jun 2014 07:58:42 +0200 (CEST) Message-ID: <53A27C13.703@it.uc3m.es> Date: Thu, 19 Jun 2014 07:58:43 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tcpcrypt@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20766.004 X-TM-AS-Result: No--29.329-7.0-31-1 X-imss-scan-details: No--29.329-7.0-31-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/y772IZLWGy4Qocs-L3-BOPaXI2I Subject: Re: [Tcpcrypt] Initial questions X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 05:58:48 -0000 below... El 18/06/14 23:15, Sandy Harris escribió: > This is basically a fine idea & I'm glad to see people working on it. > > Some comments in the archive had me somewhat worried, and the current > draft charter has the following: > > - When encryption is enabled, it must at least provide protection against > passive eavesdropping by default, > ... > When encryption is enabled, then the protocol: > - must always provide forward secrecy. > - must always provide integrity protection of the payload data ... > - must always provide payload encryption. > > Why on Earth do these have "When encryption is enabled"? I replied to this in a separated email > As others > have said quite eloquently in various posts, there is no reason at all > to even consider a null encryption mode; The requirement for disabling encryption was removed from the charter. The text above refers to the case when a TCPINC host is talking to a legacy host. > anyone who needs that can > just fall back to TCP. > > I'd go further. At a bare minimum, reject the insecure things > FreeS/WAN refused to do 15 years ago even though they were in the > IPsec RFCs -- single DES, small DH groups and null encryption. > http://www.freeswan.org/freeswan_trees/freeswan-2.06/doc/compat.html#dropped > > Probably today we should go much further. No MD5 or SHA1 since there > are known problems. No 3DES since newer ciphers are far faster. No > reliance on the whole X.509 cert infrastructure SLL/TLS uses; that > also has known problems. I'm not sure what else. > > The draft charter also has: > > - The protocol must provide cryptographic algorithm agility. > > OK, but there is a balance to be struck. IPsec & TLS both have > problems from arguably excessive complexity and in general complexity > is the enemy of security. It makes all of design, implementation, > testing & auditing much harder. TCPcrypt has a rather narrow niche to > fill; that can be done with a fairly simple protocol. We really must > strive to keep it simple. Right, this needs more discussion. The other side of the coin is that if you dotn provide agility and a vulnerability is found in an algorithm, then you are in bad shape. So, i agree, we need to find the way to provide agility with minimum complexity (not sure if we will be able to make it simpler than what is already out there though) > > Here's a first cut at what we might support: > > Block ciphers: MUST do AES. SHOULD do the other three AES finalists > with open licenses: Mars, Twofish & Serpent. MAY do compatible ciphers > which are national standards: Aria for Korea, Camellia for Japan, > maybe others. Nothing else. > > Overhead for those is minimal since they all have same block size as > AES and same range of key sizes, so they are drop-in replacements. > Also, all the AES candidates and Aria have readily available open > source code; I have not checked for Camellia. > > Key size? I'd mandate 128 bits everywhere to keep it simple. > > Authentication: The draft has: > > - must always provide integrity protection of the payload data (it is open for > discussion for the WG if the TCP header should or not be protected) > > AEAD (authenticated encryption with additional data) algorithms have > partly replaced the cipher+HMAC combination in both IPsec and TLS. > They are often faster, and the "additional data" feature would let us > protect the TCP header at negligible extra cost. I'd say they are > obviously what we should use. mmm, the problem with securing the header is not about the performance of signing the header but about the impact to other aspects. In particular, how this interacts with middleboxes? Clearly you cant protect the IP address and the ports as it would break nat compatibility. what about the other fields? well, there are some other boxes out there that do funny things with seq numbers (boxes coalescing segments), do we want to be compatible with those or not? The other aspect realted to this is where we carry the MAC for each segment, in the payload or in an option? Do we have room in options to carry this for every segment? wouldnt people rather have more sack blocks? If we go for carrying the MAC in the payload, then it is much harder to secure the header. Again, all these are discussions we need to have. I personally dont have a clear position, i just dont find it obvious (i know some of you do) > I'd just take two with existing RFCs -- AES-GCM RFC 5288 and OCB RFC > 7253 -- and make them both MUST. Leave HMAC out to keep it simple. > > The draft also has: > > - Must gracefully fall-back to TCP if the remote peer does not support the > proposed extensions > > Aren't there a set of policy questions there? Some users might prefer > to drop the connection rather than communicate insecurely. The main issue addressed here is incremental deployment. In early phases of deployment, a host needs to be able to communicate with legacy hosts. When wider deployment is available it can have stringent policies, i guess. Regards, marcelo From nobody Thu Jun 19 03:09:55 2014 Return-Path: X-Original-To: tcpcrypt@ietfa.amsl.com Delivered-To: tcpcrypt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1D81A00DA for ; Thu, 19 Jun 2014 03:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4t-7xzAXvWe for ; Thu, 19 Jun 2014 03:09:48 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 710EB1A00BF for ; Thu, 19 Jun 2014 03:09:48 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 20AA66D602; Thu, 19 Jun 2014 06:09:44 -0400 (EDT) Message-ID: <53A2B6E7.9030500@iang.org> Date: Thu, 19 Jun 2014 11:09:43 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tcpcrypt@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/wsIV3EAiFECZ9FmKLdykUZD2Gmg Subject: Re: [Tcpcrypt] Initial questions X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 10:09:53 -0000 On 18/06/2014 22:20 pm, Tony Arcieri wrote: > On Wed, Jun 18, 2014 at 2:15 PM, Sandy Harris > wrote: > > Why on Earth do these have "When encryption is enabled"? > > > "Every once in a while, someone not an NSA employee, but who had > longstanding ties to NSA, would make a suggestion that reduced privacy > or security, but which seemed to make sense when viewed by people who > didn't know much about crypto. For example, using the same IV > (initialization vector) throughout a session, rather than making a new > one for each packet. Or, retaining a way to for this encryption > protocol to specify that no encryption is to be applied." > > -- John Gilmore The problem with this view is that we can also do the same things to ourselves, without the need of hints from the NSA. If you take a big room of experts, they've all got their hobby horses, their pet wishes. The sum total of those pet features would result in a non-working protocol, and half of those pet features would result in a mess -- perhaps working, sometimes secure. Having said that, in this fertile ground, it is certainly easy for groups like the NSA to influence and tilt certain directions. But we shouldn't be so quick to blame them. It is the job of spooks to interfere, and it is we that are at fault first and foremost by providing a target-rich environment. iang From nobody Thu Jun 19 03:30:21 2014 Return-Path: X-Original-To: tcpcrypt@ietfa.amsl.com Delivered-To: tcpcrypt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C271A0114 for ; Thu, 19 Jun 2014 03:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgFXFEAlTyxc for ; Thu, 19 Jun 2014 03:30:18 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5C601A00F0 for ; Thu, 19 Jun 2014 03:30:17 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id BC33D6D5FD; Thu, 19 Jun 2014 06:30:16 -0400 (EDT) Message-ID: <53A2BBB7.2030303@iang.org> Date: Thu, 19 Jun 2014 11:30:15 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tcpcrypt@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/F9f8PuC93MTZKX59Cq97qXSSf3I Subject: Re: [Tcpcrypt] Initial questions X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 10:30:20 -0000 On 18/06/2014 22:15 pm, Sandy Harris wrote: > This is basically a fine idea & I'm glad to see people working on it. > > Some comments in the archive had me somewhat worried, and the current > draft charter has the following: my 2c below. > - When encryption is enabled, it must at least provide protection against > passive eavesdropping by default, > ... > When encryption is enabled, then the protocol: > - must always provide forward secrecy. > - must always provide integrity protection of the payload data ... > - must always provide payload encryption. > > Why on Earth do these have "When encryption is enabled"? As others > have said quite eloquently in various posts, there is no reason at all > to even consider a null encryption mode; anyone who needs that can > just fall back to TCP. Perhaps we can change the text to say more about what is meant: When TCPCRYPT mode is enabled, the protocol will provide a good stab at the following: - must PFS - must integrity - must encrypt payload, and must block passive eavesdropping etc. > I'd go further. At a bare minimum, reject the insecure things > FreeS/WAN refused to do 15 years ago even though they were in the > IPsec RFCs -- single DES, small DH groups and null encryption. > http://www.freeswan.org/freeswan_trees/freeswan-2.06/doc/compat.html#dropped > > Probably today we should go much further. No MD5 or SHA1 since there > are known problems. No 3DES since newer ciphers are far faster. No > reliance on the whole X.509 cert infrastructure SLL/TLS uses; that > also has known problems. I'm not sure what else. I don't think we need to enumerate the current fads on algorithms. Everyone knows what is old and tired. Currently the fad is ChaCha20/Poly1305. But in 3 years the new fad will be a CAESAR winner. Leave the WG some room to move with the times. > The draft charter also has: > > - The protocol must provide cryptographic algorithm agility. As previously written (ranted?), I'm adamantly against any such thing. IMHO the protocol should provide precisely one and only one whole cipher suite; the truth, the whole truth and nothing but the truth! For any issues that might arise, change the protocol. Entirely. You will anyway ... so we need a way to negotiate the protocol number, from 1 to 2 to 3, etc. > OK, but there is a balance to be struck. IPsec & TLS both have > problems from arguably excessive complexity and in general complexity > is the enemy of security. It makes all of design, implementation, > testing & auditing much harder. TCPcrypt has a rather narrow niche to > fill; that can be done with a fairly simple protocol. We really must > strive to keep it simple. Nothing gets simpler than the ONE! > Here's a first cut at what we might support: > > Block ciphers: MUST do AES. SHOULD do the other three AES finalists > with open licenses: Mars, Twofish & Serpent. MAY do compatible ciphers > which are national standards: Aria for Korea, Camellia for Japan, > maybe others. Nothing else. > > Overhead for those is minimal since they all have same block size as > AES and same range of key sizes, so they are drop-in replacements. > Also, all the AES candidates and Aria have readily available open > source code; I have not checked for Camellia. > > Key size? I'd mandate 128 bits everywhere to keep it simple. Even if I agreed with the above, I'd say, this is the job of the WG, not to be listed in the charter at all. Too low level. > Authentication: The draft has: > > - must always provide integrity protection of the payload data (it is open for > discussion for the WG if the TCP header should or not be protected) > > AEAD (authenticated encryption with additional data) algorithms have > partly replaced the cipher+HMAC combination in both IPsec and TLS. > They are often faster, and the "additional data" feature would let us > protect the TCP header at negligible extra cost. I'd say they are > obviously what we should use. > > I'd just take two with existing RFCs -- AES-GCM RFC 5288 and OCB RFC > 7253 -- and make them both MUST. Leave HMAC out to keep it simple. This is all the job of the WG, to come up with a suite. Keep that competition out of the charter, let the WG also have their fun ;-) > The draft also has: > > - Must gracefully fall-back to TCP if the remote peer does not support the > proposed extensions > > Aren't there a set of policy questions there? Some users might prefer > to drop the connection rather than communicate insecurely. Perhaps > they need a mechansim to set policy, globally and/or on a > per-connection basis. FreeS/WAN had something like this for IPsec over > a decade ago: > http://www.freeswan.org/freeswan_trees/freeswan-2.06/doc/policygroups.html Well, we want this stuff to spread like the plague. So, I'd keep policy well away from users. Any switch provided to users just has a habit of branching decision trees, interfering with something else in their daily lives, and potentially causing the whole shebang to be switched off until it works. E.g., if there is to be some policy discussion I would frame it in these terms for the charter: - there is to be zero confuguration load for the sysadm/user > At an absolute minimum, I think there must be a requirement that any > fallback action is logged. Oh, sure. That's like remembering to put air in tires, no need to say that in the charter. > Another question is whether we could achieve the goals of this group > with almost no work just by deploying existing stuff. > > The now-closed BTNS working group did RFCs 5386 & 5387 on "Better than > nothing security", which they implemented as an unauthenticated mode > for IPsec. That sounds much like what we are aiming at. Can we just > work on getting BTNS deployed, thereby protecting both TCP and other > protocols? If it fits the charter, then let it be proposed -- in the WG ring. Let's have a nice clean fight, no hitting below the belt, ... Especially, I'd like a fast knockout in round 1. If we can slide in BTNS for the TCPCRYPT v1, and then have a better, later-gen bells&whistles proposal for v2, then we could win twice over. > The draft has: > > - Must not require any authentication or configuration from > applications or users. However, hooks for external authentication must > be made available. > > RFC 4322 describes an authentication mechansim for IPsec opportunistic > encryption using keys stored in DNS. Could we make that the external > hook and fall back to BTNS if the right record is not found? Any external hook, that included? That is, it is beyond scope how that is done. The point is to allow a later TLS drop-in replacement to bootstrap over TCPCRYPT and allow a fuller authentication to work. > Even if we choose to avoid the complexity of IPsec and design > something specifically for TCP instead of just using BTNS, the idea of > using DNS for keys may be useful. I do not know details, but it looks > as though the DANE working group is doing this sort of thing: > https://datatracker.ietf.org/wg/dane/ Yep, but out of scope to specify which. Only need would be to keep an eye on the ways and make sure there are no snafus. iang From nobody Thu Jun 19 03:46:08 2014 Return-Path: X-Original-To: tcpcrypt@ietfa.amsl.com Delivered-To: tcpcrypt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78CB11A0139 for ; Thu, 19 Jun 2014 03:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWdTwW71UCTL for ; Thu, 19 Jun 2014 03:46:06 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 357DE1A011F for ; Thu, 19 Jun 2014 03:46:06 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 79AC06D605; Thu, 19 Jun 2014 06:46:02 -0400 (EDT) Message-ID: <53A2BF69.3040001@iang.org> Date: Thu, 19 Jun 2014 11:46:01 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tcpcrypt@ietf.org References: <53A2066A.4090802@isi.edu> In-Reply-To: <53A2066A.4090802@isi.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/P_hJ4uwfD0KfR5cJGgLfBbOrWyQ Subject: Re: [Tcpcrypt] Initial questions X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 10:46:07 -0000 On 18/06/2014 22:36 pm, Joe Touch wrote: > Comments on your other points: > > On 6/18/2014 2:15 PM, Sandy Harris wrote: > > As to the specific algorithms and how many, we probably all agree that a > small number of required algorithms is preferable. I think 2 is a good > upper bound on the MUST algorithms, though. Actually, no. I for one disagree. There should be one true cipher suite [0]. > Algorithm agility just means that the protocol isn't inherently > dependent on any one algorithm, so that it can be extended in the future > to support other algorithms - that seems prudent. If an exploit is found, then it's time to role out version 2. You'll need a way to negotiate the version anyway, may as well use it. (I know it is popular to approximate the whole 'all' thing in WG-speak and I'm happy to go down in flames on the rough consensus.) iang [0] http://iang.org/ssl/h1_the_one_true_cipher_suite.html From nobody Thu Jun 19 10:56:20 2014 Return-Path: X-Original-To: tcpcrypt@ietfa.amsl.com Delivered-To: tcpcrypt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A33E1A0294 for ; Thu, 19 Jun 2014 10:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSiloJj8cHoB for ; Thu, 19 Jun 2014 10:56:18 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 331A71A0083 for ; Thu, 19 Jun 2014 10:56:18 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s5JHtsOv026625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 19 Jun 2014 10:55:54 -0700 (PDT) Message-ID: <53A3242E.7020106@isi.edu> Date: Thu, 19 Jun 2014 10:55:58 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ianG , tcpcrypt@ietf.org References: <53A2066A.4090802@isi.edu> <53A2BF69.3040001@iang.org> In-Reply-To: <53A2BF69.3040001@iang.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/HP-FGQIfGBNfiG3KTBzKum4ZMEI Subject: Re: [Tcpcrypt] Initial questions X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 17:56:19 -0000 On 6/19/2014 3:46 AM, ianG wrote: > On 18/06/2014 22:36 pm, Joe Touch wrote: >> Comments on your other points: >> >> On 6/18/2014 2:15 PM, Sandy Harris wrote: >> >> As to the specific algorithms and how many, we probably all agree that a >> small number of required algorithms is preferable. I think 2 is a good >> upper bound on the MUST algorithms, though. > > Actually, no. I for one disagree. There should be one true cipher > suite [0]. If you have only one, then if (or when) you urgently decide it's vulnerable and want an alternate you need to wait for deployment of an update (e.g., as happened to TCP MD5). That will undermine the utility of a solution. That's why TCP-AO included two 'must implement' algorithms from the start, and why it's important to do so here as well. Joe From nobody Thu Jun 19 11:23:47 2014 Return-Path: X-Original-To: tcpcrypt@ietfa.amsl.com Delivered-To: tcpcrypt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B20A51A0305 for ; Thu, 19 Jun 2014 11:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLwNNUr2FnHE for ; Thu, 19 Jun 2014 11:23:42 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E7F21A02D4 for ; Thu, 19 Jun 2014 11:23:42 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 3532F6D61F; Thu, 19 Jun 2014 14:23:39 -0400 (EDT) Message-ID: <53A32AAA.1060400@iang.org> Date: Thu, 19 Jun 2014 19:23:38 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Joe Touch , tcpcrypt@ietf.org References: <53A2066A.4090802@isi.edu> <53A2BF69.3040001@iang.org> <53A3242E.7020106@isi.edu> In-Reply-To: <53A3242E.7020106@isi.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/aA9Mjss5ktRgi1CLFPDIAqS4_kA Subject: Re: [Tcpcrypt] Initial questions X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 18:23:44 -0000 On 19/06/2014 18:55 pm, Joe Touch wrote: > On 6/19/2014 3:46 AM, ianG wrote: >> On 18/06/2014 22:36 pm, Joe Touch wrote: >>> Comments on your other points: >>> >>> As to the specific algorithms and how many, we probably all agree that a >>> small number of required algorithms is preferable. I think 2 is a good >>> upper bound on the MUST algorithms, though. >> >> Actually, no. I for one disagree. There should be one true cipher >> suite [0]. > > If you have only one, then if (or when) you urgently decide it's > vulnerable and want an alternate you need to wait for deployment of an > update (e.g., as happened to TCP MD5 MD5 isn't a good example. It has been effectively deprecated by SHA1 (and SHA0 ;) as of around 1996. MD5 was collision-cracked around 2004, as reported at Crypto 2004 in Santa Barbara. When did TCP have this 'urgent decision' ? If it happened several years after 1996, then what you have is a forewarning that was ignored. If it was after 2004, well, no amount of warning will do, and algorithmic agility is a crutch that should be stripped away in order to focus attention. > ). That will undermine the utility > of a solution. > > That's why TCP-AO included two 'must implement' algorithms from the > start, and why it's important to do so here as well. I'd like to see some historical evidence of when this actually made a difference? Yes, we understand the idea. But we now have 20 years of experience in Internet protocols. We have data. What does the data say about algorithmic agility, in the field? The closest I've seen is the backoff in TLS back to RC4. But even that only gets halfmarks because RC4 itself should have been deprecated ages ago. iang From nobody Thu Jun 19 11:35:33 2014 Return-Path: X-Original-To: tcpcrypt@ietfa.amsl.com Delivered-To: tcpcrypt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976581A03DB for ; Thu, 19 Jun 2014 11:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNehP1pqdFQq for ; Thu, 19 Jun 2014 11:35:28 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A63321A03E2 for ; Thu, 19 Jun 2014 11:35:28 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s5JIZ6bx000971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 19 Jun 2014 11:35:09 -0700 (PDT) Message-ID: <53A32D5A.10007@isi.edu> Date: Thu, 19 Jun 2014 11:35:06 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ianG , tcpcrypt@ietf.org References: <53A2066A.4090802@isi.edu> <53A2BF69.3040001@iang.org> <53A3242E.7020106@isi.edu> <53A32AAA.1060400@iang.org> In-Reply-To: <53A32AAA.1060400@iang.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/LO6O4HA7xypWBqI4mPvUOKfyo14 Subject: Re: [Tcpcrypt] Initial questions X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 18:35:30 -0000 On 6/19/2014 11:23 AM, ianG wrote: > On 19/06/2014 18:55 pm, Joe Touch wrote: ... > When did TCP have this 'urgent decision' ? If it happened several years > after 1996, then what you have is a forewarning that was ignored. If it > was after 2004, well, no amount of warning will do, and algorithmic > agility is a crutch that should be stripped away in order to focus > attention. 2004 was the first practical attack on MD5; the first draft of TCP-AO was 2007. It took another three years for the IETF sausage mill to generate a final result. Given that TCP-AO was used mostly for router security, and nobody had reported a successful MD5-based attack in the wild, that's not bad IMO. The primary problem with TCP MD5 was that it wasn't algorithm-agile. ... >> That's why TCP-AO included two 'must implement' algorithms from the >> start, and why it's important to do so here as well. > > I'd like to see some historical evidence of when this actually made a > difference? Yes, we understand the idea. But we now have 20 years of > experience in Internet protocols. We have data. What does the data say > about algorithmic agility, in the field? You're arguing two points at the same time. 1) use one algorithm I've already pointed out how that's dangerous; it prevents pre-deploying a backup when a given algorithm is deprecated. 2) don't have algorithm agility This is counter to your earlier post. If you consider that any one algorithm won't last forever, then ultimately we'll want a solution that can support different algorithms. I don't like either of the above, but they're separate points. Joe From nobody Thu Jun 19 23:14:06 2014 Return-Path: X-Original-To: tcpcrypt@ietfa.amsl.com Delivered-To: tcpcrypt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 121EA1A0641 for ; Thu, 19 Jun 2014 23:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgvvWsCyLGef for ; Thu, 19 Jun 2014 23:14:01 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BD271A0649 for ; Thu, 19 Jun 2014 23:13:57 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 941C36D643; Fri, 20 Jun 2014 02:13:55 -0400 (EDT) Message-ID: <53A3D122.8030501@iang.org> Date: Fri, 20 Jun 2014 07:13:54 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: tcpcrypt@ietf.org References: <53A2066A.4090802@isi.edu> <53A2BF69.3040001@iang.org> <53A3242E.7020106@isi.edu> <53A32AAA.1060400@iang.org> <53A32D5A.10007@isi.edu> In-Reply-To: <53A32D5A.10007@isi.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/Qa-d-UmLDdeBPFhC0CIH6bbI6x0 Subject: Re: [Tcpcrypt] Initial questions X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 06:14:04 -0000 On 19/06/2014 19:35 pm, Joe Touch wrote: > > > On 6/19/2014 11:23 AM, ianG wrote: >> On 19/06/2014 18:55 pm, Joe Touch wrote: > ... >> When did TCP have this 'urgent decision' ? If it happened several years >> after 1996, then what you have is a forewarning that was ignored. If it >> was after 2004, well, no amount of warning will do, and algorithmic >> agility is a crutch that should be stripped away in order to focus >> attention. > > 2004 was the first practical attack on MD5; the first draft of TCP-AO > was 2007. It took another three years for the IETF sausage mill to > generate a final result. > > Given that TCP-AO was used mostly for router security, and nobody had > reported a successful MD5-based attack in the wild, that's not bad IMO. Right. So it worked. The reason it worked fine -- no attacks reported until 2008 [0] -- was likely due to the lack of collision vulnerability in a protocol. There was no urgent decision, just useful caution. > The primary problem with TCP MD5 was that it wasn't algorithm-agile. That's to repeat your conclusion. I'm asserting a different conclusion: the problem with the MD5 upgrade was a management one, not a real one. The maintenance of the protocol should have started the replacement sometime before 2004. > ... >>> That's why TCP-AO included two 'must implement' algorithms from the >>> start, and why it's important to do so here as well. >> >> I'd like to see some historical evidence of when this actually made a >> difference? Yes, we understand the idea. But we now have 20 years of >> experience in Internet protocols. We have data. What does the data say >> about algorithmic agility, in the field? > > You're arguing two points at the same time. > > 1) use one algorithm > > I've already pointed out how that's dangerous; it prevents > pre-deploying a backup when a given algorithm is deprecated. You've pointed out it is dangerous. Can you provide historical evidence for this claim? We've debunked MD5 in TCP-AO. If it never happened, can it be still called dangerous? If there is one thing that actually we are quite good at, it is selecting a single strong suite. How about we concentrate on what actually does go wrong, demonstrably, in protocols? Complexity leads to failure in takeup, anyone? > 2) don't have algorithm agility > > This is counter to your earlier post. If you consider > that any one algorithm won't last forever, then ultimately > we'll want a solution that can support different algorithms. OK, we're agreed that life moves on. As do security products. Versions upgrade. Let's look at say SSL. It has run from v1 - v2 - v3 - TLS 1.0 - 1.1 - 1.2 - 1.4. At each of those changes, there are incompatibilities within. In each case, the client/server conversation has to negotiate which version the other side is capable of talking, and (generally) prefer the latest. In each version, there is a chance to move forward. This chance to move forward may be taken for: protocol weaknesses, advances in the science, features, speed increases, ... *and the cipher suite*. Now look at the history of important fixes to SSL. SSL v3 patch, TLS/SNI, renegotiation bug, heartbleed, gotofail, debian random, etc. In practice, we're replacing the in-place version because of other bugs, and improvements, over time, faster than we're seeing any problem with any of the well chosen algorithms. So we may as well just do that: have TLS v+1 ready to go. Also note that automated upgrade is the way that everyone does stuff these days, and it can easily move faster than our ability to roll out a config change. Anyone got any numbers on how long it takes Apple to upgrade 80% of clients? Can they beat the OODA loop of 3.5 years for SSL [1]? > I don't like either of the above, but they're separate points. Here's another one: why do you care? This is opportunistic encryption, anyway. We get what we can for free. Why bother about the freak occurrence of an algorithm break when it can be hit by MITM anyway? When we're losing most of the marketplace to slowness in install? How are you going to tell people to switch, given that our problem space is automatic operation, without people knowing? Is there anyone here who feels that (say) ChaCha20/Poly1305 is at risk of a sudden break? Who doesn't feel safe in an opportunistic protocol against mass surveillance unless there is a backup inside it? iang [0] http://wiki.cacert.org/Risk/History#MD5-Root [1] http://financialcryptography.com/mt/archives/001210.html From nobody Fri Jun 20 15:24:41 2014 Return-Path: X-Original-To: tcpcrypt@ietfa.amsl.com Delivered-To: tcpcrypt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0DE1A031C for ; Fri, 20 Jun 2014 15:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqJ_oeCWD5yO for ; Fri, 20 Jun 2014 15:24:39 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7267A1A0313 for ; Fri, 20 Jun 2014 15:24:39 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s5KMNUvE007532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 20 Jun 2014 15:23:30 -0700 (PDT) Message-ID: <53A4B462.7010106@isi.edu> Date: Fri, 20 Jun 2014 15:23:30 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ianG , tcpcrypt@ietf.org References: <53A2066A.4090802@isi.edu> <53A2BF69.3040001@iang.org> <53A3242E.7020106@isi.edu> <53A32AAA.1060400@iang.org> <53A32D5A.10007@isi.edu> <53A3D122.8030501@iang.org> In-Reply-To: <53A3D122.8030501@iang.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/v1kscz1-twvF8EgMthNhS8Ibphk Subject: Re: [Tcpcrypt] Initial questions X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 22:24:40 -0000 On 6/19/2014 11:13 PM, ianG wrote: ... > Why bother about the freak occurrence of an algorithm break when it can > be hit by MITM anyway? When we're losing most of the marketplace to > slowness in install? Two algorithms, with one as the preferred default is prudent as a pre-deployed backup... > How are you going to tell people to switch, given that our problem space > is automatic operation, without people knowing? and it also helps us validate that the system can support other algorithms without major revision (i.e., we need an answer to this question, and the best way to test it is with two algorithms). That's my view, and you've already disagreed with it; let's see what others have to say. Joe From nobody Fri Jun 20 19:33:42 2014 Return-Path: X-Original-To: tcpcrypt@ietfa.amsl.com Delivered-To: tcpcrypt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F341A02F6 for ; Fri, 20 Jun 2014 19:33:40 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8H29ss3UYbDN for ; Fri, 20 Jun 2014 19:33:38 -0700 (PDT) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 043871A0096 for ; Fri, 20 Jun 2014 19:33:37 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id db11so4215506veb.40 for ; Fri, 20 Jun 2014 19:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=E2XYK6ZAILjS7GUIu0KoKIdi1hxLAOFbFfiQcard6AU=; b=FI64kEZLz0faumfvs3uTMFaFfk6p8LwFptRG7THgRpNBmxWYwgvg4i/H/YQzyyWnZo +rfBKrQYZCDCh/Y8tbs//f1znH/BDtAdpVdy7rvjZkRRttWt87HAHudhKLpKA2P0Ikx6 2Qiik7phGUUNM3nc9KMcn1UvoXuzLVTvtQ5M661sG9XxpjhYEFtf1iWDvR2upibx+BF/ uNBp1H7n0FYwlDZO8OH9eNtnC2Qqqq4fKgL7l8K7vM41IT7onh4Ij8hZNNrdzxec5t3S BfOHgub2vfuGpoB53+1cbOwumct7Luf/wpUyprNNwNjMHftMv+UyaDvR/6ZremPbl6rE Z1ZQ== X-Received: by 10.220.250.203 with SMTP id mp11mr6241691vcb.2.1403318017089; Fri, 20 Jun 2014 19:33:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.168.133 with HTTP; Fri, 20 Jun 2014 19:33:17 -0700 (PDT) In-Reply-To: <53A3242E.7020106@isi.edu> References: <53A2066A.4090802@isi.edu> <53A2BF69.3040001@iang.org> <53A3242E.7020106@isi.edu> From: Tony Arcieri Date: Fri, 20 Jun 2014 19:33:17 -0700 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=089e013d0502ea688f04fc4f6f41 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/3FCe-0VBgoqXHyD1qmYq0g-4bZg Cc: "tcpcrypt@ietf.org" , ianG Subject: Re: [Tcpcrypt] Initial questions X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jun 2014 02:33:40 -0000 --089e013d0502ea688f04fc4f6f41 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 19, 2014 at 10:55 AM, Joe Touch wrote: > If you have only one, then if (or when) you urgently decide it's > vulnerable and want an alternate you need to wait for deployment of an > update (e.g., as happened to TCP MD5). That will undermine the utility of a > solution. > Hey Joe, Perhaps you should pay attention to 2014, and not look at things through a historical glass, darkly. In case you haven't been paying attention, vulnerabilities have been accelerating at something of an exponential rate, and pretty much everything that hasn't happened in 2014 is practically irrelevant at this point. Cipher agility is clearly not the problem. Implementation vulnerabilities are the problem. In fact, the rate at which cipher vulnerabilities have been discovered is practically glacial at this point. Things have gotten a lot more complicated since MD5 is even a hash function anyone with a clue would use for any reason whatsoever. Perhaps you should stop referencing anything that has anything to do with MD5, period. It's not germane to the discussion of any modern protocol, except perhaps if you want to discuss historical failures. -- Tony Arcieri --089e013d0502ea688f04fc4f6f41 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 19, 2014 at 10:55 AM, Joe Touch <touc= h@isi.edu> wrote:
If you have only one, then i= f (or when) you urgently decide it's vulnerable and want an alternate y= ou need to wait for deployment of an update (e.g., as happened to TCP MD5).= That will undermine the utility of a solution.

Hey Joe,

Perhaps = you should pay attention to 2014, and not look at things through a historic= al glass, darkly.

In case you haven't been pay= ing attention, vulnerabilities have been accelerating at something of an ex= ponential rate, and pretty much everything that hasn't happened in 2014= is practically irrelevant at this point.

Cipher agility is clearly not the problem. Implementati= on vulnerabilities are the problem. In fact, the rate at which cipher vulne= rabilities have been discovered is practically glacial at this point.

Things have gotten a lot more complicated since MD5 is = even a hash function anyone with a clue would use for any reason whatsoever= . Perhaps you should stop referencing anything that has anything to do with= MD5, period. It's not germane to the discussion of any modern protocol= , except perhaps if you want to discuss historical failures.

--
Tony Arcieri
--089e013d0502ea688f04fc4f6f41-- From nobody Sun Jun 22 06:07:03 2014 Return-Path: X-Original-To: tcpcrypt@ietfa.amsl.com Delivered-To: tcpcrypt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11A71B2946 for ; Sun, 22 Jun 2014 06:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEiLwoFoVWaR for ; Sun, 22 Jun 2014 06:06:58 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83EB61B2938 for ; Sun, 22 Jun 2014 06:06:58 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id 97B8964F1 for ; Sun, 22 Jun 2014 06:06:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=date:from :to:subject:message-id:references:mime-version:content-type :in-reply-to; s=selector1; bh=Fq8avlYATK62z5SVuftUICQjZlo=; b=lJ PJzSnm+0Ii5ARguCEMSH42HYqliw6Uz6MpuUHyR5j/AbZm83eDhqtFTHELPgeZ5f ch1nihp6I+G5biuJ/MmZqRXpYOWd60XopUyP8wRA5oaWTx6nXgq3YYjSyhyGJl49 SeLoD+whumP/oBG/swji6zWkLoE4CYk0ebCjlcLwI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=date:from :to:subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=selector1; b=Vd7LDH4PA7i2SjUNC/FbqAN54vUC dcmjnf3ps82/8gQfjikVWfi0paBhtdCjSlQUeVs5ZKM7BvVWYNwJ8kU2p3dPnwbb hbBStwNflf+GJRNxCgQPXnqh1BGkZvAaajIm/B2sNwy8/mBrMAt4nT8rY7NBHjd2 6W0MfQg4hqfjh5s= Received: by banjo.employees.org (Postfix, from userid 1736) id 8366764C7; Sun, 22 Jun 2014 06:06:57 -0700 (PDT) Date: Sun, 22 Jun 2014 06:06:57 -0700 From: Derek Fawcus To: tcpcrypt@ietf.org Message-ID: <20140622130657.GB39625@banjo.employees.org> References: <53A2066A.4090802@isi.edu> <53A2BF69.3040001@iang.org> <53A3242E.7020106@isi.edu> <53A32AAA.1060400@iang.org> <53A32D5A.10007@isi.edu> <53A3D122.8030501@iang.org> <53A4B462.7010106@isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53A4B462.7010106@isi.edu> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/i7RduJ7VuNQgMyZjQyub7-OJdCs Subject: Re: [Tcpcrypt] Initial questions X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 13:07:01 -0000 On Fri, Jun 20, 2014 at 03:23:30PM -0700, Joe Touch wrote: > > That's my view, and you've already disagreed with it; let's see what > others have to say. I like the idea of the initiator being able to specify the crypto algorithm, say an 8 bit value, we have 1 or 2 intially defined. If the receiver doesn't support the selected algorithm, the whole tcpcrypt option will fail and we fallback to unencrypted. Thereafter the initiator (application or host stack - not sure which) can decide to terminate the connection, and maybe retry with a different algorithm, continue unencryted, or whatever. i.e. local policy. The idea being that we deploy with one recommended algorithm which everyone supports, and if a sucessful attack is found on it, we can switch over to the next algorithm. I don't think the endpoints should negotiate the algorithm, if the initiators choice is not supported, the session is unencryted. i.e. avoid round trips to agree/negotiate an algorithm, and don't supply a list of choices in the initiation. I'm not sure of the effect with simultaneous open, but probably OK until the recommended version changes. .pdf From nobody Sun Jun 22 06:10:15 2014 Return-Path: X-Original-To: tcpcrypt@ietfa.amsl.com Delivered-To: tcpcrypt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C901B28EB for ; Sun, 22 Jun 2014 06:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSt7UCA9KK30 for ; Sun, 22 Jun 2014 06:10:06 -0700 (PDT) Received: from banjo.employees.org (banjo.employees.org [198.137.202.19]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A4E1B27A3 for ; Sun, 22 Jun 2014 06:10:06 -0700 (PDT) Received: from banjo.employees.org (localhost [127.0.0.1]) by banjo.employees.org (Postfix) with ESMTP id D1BFA62AC for ; Sun, 22 Jun 2014 06:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=date:from :to:subject:message-id:references:mime-version:content-type :in-reply-to; s=selector1; bh=kGEh+IPS5jYSrRr7beX7Y5Wr3sQ=; b=Cv 17lfRBacVGjQqSYeyvaE1PVuvNEOqPeeI7PTlAj3ZH4BxJYeZGtu0nwlzfxJRl6s NBVtQeWdB8sDlLjj//J79akSiZ5W/fVjruBskcebwH8RFIeJO0wLdG2RLDnKtTUC 7CCltmHAEofMWpJk9nUpm6wb8fuMvU7Sp33nXijiA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=date:from :to:subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=selector1; b=d/Ah0L/GVPsk3gxB4TuL9vXnMD/q c7c4VN65y+BFrnsQjuqWMuUtF7kUABzAX3hXK325fOn6tCAOfmzjkcrypIJO1Mjm yEN/ySb3Af6vacdH8FGlpE8W5eeNBeJYE4JbUAWJTspvUkRJ9Pqk3ExdVi6SPNKR +Dwrrx6nVM2eQY0= Received: by banjo.employees.org (Postfix, from userid 1736) id CBC22625B; Sun, 22 Jun 2014 06:10:05 -0700 (PDT) Date: Sun, 22 Jun 2014 06:10:05 -0700 From: Derek Fawcus To: tcpcrypt@ietf.org Message-ID: <20140622131005.GC39625@banjo.employees.org> References: <53A2066A.4090802@isi.edu> <53A2BF69.3040001@iang.org> <53A3242E.7020106@isi.edu> <53A32AAA.1060400@iang.org> <53A32D5A.10007@isi.edu> <53A3D122.8030501@iang.org> <53A4B462.7010106@isi.edu> <20140622130657.GB39625@banjo.employees.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140622130657.GB39625@banjo.employees.org> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/mPvc6_YJfK3zoG_7_PWtLIgO2Kw Subject: Re: [Tcpcrypt] Initial questions X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2014 13:10:08 -0000 On Sun, Jun 22, 2014 at 06:06:57AM -0700, Derek Fawcus wrote: > > I don't think the endpoints should negotiate the algorithm, > if the initiators choice is not supported, the session is unencryted. > i.e. avoid round trips to agree/negotiate an algorithm, > and don't supply a list of choices in the initiation. Or could one argue that the above is not too dissimilar to simply having a version field in the tcpcrypt protocol, and we can associate a version with any set of crypto algorithms? .pdf From nobody Sun Jun 22 18:05:57 2014 Return-Path: X-Original-To: tcpcrypt@ietfa.amsl.com Delivered-To: tcpcrypt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CECB01B27E1 for ; Sun, 22 Jun 2014 18:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y66S6p9ZYtcB for ; Sun, 22 Jun 2014 18:05:54 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E7C81A0396 for ; Sun, 22 Jun 2014 18:05:54 -0700 (PDT) Received: from [192.168.1.91] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s5N14xKU023516 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 22 Jun 2014 18:05:04 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=us-ascii From: Joe Touch In-Reply-To: <20140622131005.GC39625@banjo.employees.org> Date: Sun, 22 Jun 2014 18:05:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <567A40D7-67F7-441D-AC37-844DE7B12F37@isi.edu> References: <53A2066A.4090802@isi.edu> <53A2BF69.3040001@iang.org> <53A3242E.7020106@isi.edu> <53A32AAA.1060400@iang.org> <53A32D5A.10007@isi.edu> <53A3D122.8030501@iang.org> <53A4B462.7010106@isi.edu> <20140622130657.GB39625@banjo.employees.org> <20140622131005.GC39625@banjo.employees.org> To: Derek Fawcus X-Mailer: Apple Mail (2.1878.2) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/TfX_fvcahibuXxUOgwGi0p1f8uA Cc: tcpcrypt@ietf.org Subject: Re: [Tcpcrypt] Initial questions X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 01:05:56 -0000 On Jun 22, 2014, at 6:10 AM, Derek Fawcus = wrote: > On Sun, Jun 22, 2014 at 06:06:57AM -0700, Derek Fawcus wrote: >>=20 >> I don't think the endpoints should negotiate the algorithm, >> if the initiators choice is not supported, the session is = unencryted. Even if that's true, there can still be merit to picking from among a = set of required algorithms during negotiation. >> i.e. avoid round trips to agree/negotiate an algorithm, Whether negotiation takes additional exchanges depends on the mechanism. >> and don't supply a list of choices in the initiation. >=20 > Or could one argue that the above is not too dissimilar to simply > having a version field in the tcpcrypt protocol, and we can > associate a version with any set of crypto algorithms? Once it's negotiated, it serves no purpose to continue to indicate it in = the header. If parameters need to be renegotiated, that happens during = the renegotiation. Joe= From nobody Tue Jun 24 07:45:28 2014 Return-Path: X-Original-To: tcpcrypt@ietfa.amsl.com Delivered-To: tcpcrypt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD4E11B2ACE for ; Tue, 24 Jun 2014 07:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mdWZam_FvIy for ; Tue, 24 Jun 2014 07:45:22 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A1FB1B2A4E for ; Tue, 24 Jun 2014 07:45:22 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:46016 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WzRyX-000K3v-CL for tcpcrypt@ietf.org; Tue, 24 Jun 2014 10:45:33 -0400 Message-ID: <53A98F00.4000702@bbn.com> Date: Tue, 24 Jun 2014 10:45:20 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tcpcrypt@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/y9QSzV_ZW7KHYbOhr6FQRPbzz0Q Subject: Re: [Tcpcrypt] Initial questions X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 14:45:27 -0000 Sandy, > ... > > Probably today we should go much further. No MD5 or SHA1 since there > are known problems. No 3DES since newer ciphers are far faster. No > reliance on the whole X.509 cert infrastructure SLL/TLS uses; that > also has known problems. I'm not sure what else. To which X.509 cert infrastructure problems are you referring? Do you mean the Web PKI or PKI in general? IPsec, for example, does not make use of the Web PKI. Just curious. > The draft charter also has: > > - The protocol must provide cryptographic algorithm agility. > > OK, but there is a balance to be struck. IPsec & TLS both have > problems from arguably excessive complexity and in general complexity > is the enemy of security. It makes all of design, implementation, > testing & auditing much harder. TCPcrypt has a rather narrow niche to > fill; that can be done with a fairly simple protocol. We really must > strive to keep it simple. I'm not sure what your position is re alg agility, based on the paragraph above. I can say that failure to accommodate alg agility will almost certainly cause the IESG to reject this as a standard, based on precedents for some time. > Here's a first cut at what we might support: > > Block ciphers: MUST do AES. SHOULD do the other three AES finalists > with open licenses: Mars, Twofish & Serpent. MAY do compatible ciphers > which are national standards: Aria for Korea, Camellia for Japan, > maybe others. Nothing else. why would one make the other AES finalists SHOULD? They didn't make the cut. > Key size? I'd mandate 128 bits everywhere to keep it simple. recall that AES has 256-bit keys as an option as a counter to possible quantum computing attacks. Why rule out that option? > The draft also has: > > - Must gracefully fall-back to TCP if the remote peer does not support the > proposed extensions > > Aren't there a set of policy questions there? Some users might prefer > to drop the connection rather than communicate insecurely. Perhaps > they need a mechansim to set policy, globally and/or on a > per-connection basis. FreeS/WAN had something like this for IPsec over > a decade ago: > http://www.freeswan.org/freeswan_trees/freeswan-2.06/doc/policygroups.html This is a different context. I believe the goal is to try to negotiate use of encryption silently, and thus failing silently makes sense. There was a session in the STRINT workshop that addressed a topic very close to this. It's conclusion was to fail silently (and to use PFS, and ...) > At an absolute minimum, I think there must be a requirement that any > fallback action is logged. And who will check the logs? A log on a user machine will likely go unread in 99.99% of cases, unless there is a plan to submit the logs to some central monitoring source. But that would raise a set of privacy questions, so ... > Another question is whether we could achieve the goals of this group > with almost no work just by deploying existing stuff. Always a good question. > The now-closed BTNS working group did RFCs 5386 & 5387 on "Better than > nothing security", which they implemented as an unauthenticated mode > for IPsec. That sounds much like what we are aiming at. Can we just > work on getting BTNS deployed, thereby protecting both TCP and other > protocols? I think the folks who pursue BTNS are best-equipped to address that question. Ask Sam Hartman, maybe Joe would like to comment as well. Steve From nobody Tue Jun 24 11:23:54 2014 Return-Path: X-Original-To: tcpcrypt@ietfa.amsl.com Delivered-To: tcpcrypt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8F71A0406 for ; Tue, 24 Jun 2014 11:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkiqTpFK4pm6 for ; Tue, 24 Jun 2014 11:23:47 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 394B51A040A for ; Tue, 24 Jun 2014 11:22:45 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s5OIMRKQ023334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 24 Jun 2014 11:22:28 -0700 (PDT) Message-ID: <53A9C1E3.5060605@isi.edu> Date: Tue, 24 Jun 2014 11:22:27 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephen Kent , tcpcrypt@ietf.org References: <53A98F00.4000702@bbn.com> In-Reply-To: <53A98F00.4000702@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/EWB5xQGIRfz02y3Uf01BSn-K7Sg Subject: Re: [Tcpcrypt] Initial questions X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 18:23:48 -0000 On 6/24/2014 7:45 AM, Stephen Kent wrote: > Sandy, ... >> The now-closed BTNS working group did RFCs 5386 & 5387 on "Better than >> nothing security", which they implemented as an unauthenticated mode >> for IPsec. That sounds much like what we are aiming at. Can we just >> work on getting BTNS deployed, thereby protecting both TCP and other >> protocols? > > I think the folks who pursue BTNS are best-equipped to address that > question. Ask Sam Hartman, maybe Joe would like to comment as well. RFC5925 already describes the rationale for TCP authentication vs. IPsec. The same issues are relevant for TCP encryption. The other aspect of BTNS - use of DH without authentication (which isn't TOFU; it's trust-on-any-use in a sense because IDs aren't retained) might be similar to various approaches offered here (e.g., it's the basis of draft-touch-tcp-ao-encrypt. Joe From nobody Tue Jun 24 12:19:26 2014 Return-Path: X-Original-To: tcpcrypt@ietfa.amsl.com Delivered-To: tcpcrypt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6A91B2E89 for ; Tue, 24 Jun 2014 12:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMkPY16lQixe for ; Tue, 24 Jun 2014 12:19:13 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9FBB1B2C92 for ; Tue, 24 Jun 2014 12:19:09 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 6FF1E6D5F2; Tue, 24 Jun 2014 15:19:05 -0400 (EDT) Message-ID: <53A9CF27.9040600@iang.org> Date: Tue, 24 Jun 2014 20:19:03 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Stephen Kent , tcpcrypt@ietf.org References: <53A98F00.4000702@bbn.com> In-Reply-To: <53A98F00.4000702@bbn.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/l78aejFOWjT3ZqNB0DE5KwVPZWw Subject: Re: [Tcpcrypt] Initial questions X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 19:19:16 -0000 On 24/06/2014 15:45 pm, Stephen Kent wrote: > Sandy, ... >> The draft charter also has: >> >> - The protocol must provide cryptographic algorithm agility. ... This bit: > I can say that failure to accommodate alg agility will almost certainly > cause > the IESG to reject this as a standard, based on precedents for some time. Interesting point! Probably worth reaching out to those folk and asking whether they are serious about enforced alg agility. And why they care so much in the context of TCPcrypt, which is opportunistic anyway, and as such provides not much of a guarantee. ... >> Key size? I'd mandate 128 bits everywhere to keep it simple. (In the charter, we shouldn't mandate any size. Just let the proponents walk the gauntlet with their choices.) > recall that AES has 256-bit keys as an option as a counter to possible > quantum computing attacks. Why rule out that option? Because this is TCPcrypt. The enemy is the unavailability of any encryption at at all, not the QC bogeyman. If we deploy TCPcrypt to 99% of all nodes, and they're all vulnerable to QC, we still win. (Because, to spell it out, we can always upgrade later on when the bogeyman starts deploying QC in the mega-scale, and meanwhile we won against everyone else.) >> The draft also has: >> >> - Must gracefully fall-back to TCP if the remote peer does not support >> the >> proposed extensions >> >> Aren't there a set of policy questions there? Some users might prefer >> to drop the connection rather than communicate insecurely. Perhaps >> they need a mechansim to set policy, globally and/or on a >> per-connection basis. FreeS/WAN had something like this for IPsec over >> a decade ago: >> http://www.freeswan.org/freeswan_trees/freeswan-2.06/doc/policygroups.html >> > This is a different context. I believe the goal is to try to negotiate > use of encryption silently, and thus failing silently makes sense. (concur.) iang From nobody Tue Jun 24 13:22:09 2014 Return-Path: X-Original-To: tcpcrypt@ietfa.amsl.com Delivered-To: tcpcrypt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2151B27E4 for ; Tue, 24 Jun 2014 13:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mu5fe47iLvs for ; Tue, 24 Jun 2014 13:22:06 -0700 (PDT) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AB671B27E6 for ; Tue, 24 Jun 2014 13:22:05 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id jz11so953850veb.30 for ; Tue, 24 Jun 2014 13:22:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=oguXCRmovyxN98+REfdclqHc3Qd59TBmuyTbNF+mXPI=; b=uuFQTFlviOaCz2U3VAjRBxUWFCDGusWAK1RCq4ON9aU72ybEsG6rrdQ5wdIBA9jPgN a7qWLbnssiq23lHltvk5UamKBiIHIVJ/6FZ5RQ7pf7AvK7AZJECvX7noQC8pJVQW/bhm 2bJtLNDjmhF6lI+15IBJ56aAMtYM+ssrvyTsuHjDEG8MeCNcafrlhEtd3mMgkYUqXl8H Qc6G6XZLnM92IJx6IvO6ecoFzlzyHLpdqpyTaTA2cbIz0HIuB3BAri7wkaasVF8ZNXRj 65cXl92bSz09TwkK6mdge7JDWUlrNuzwiH5hwrn0AItSP2jkPT8YdCOg0A2WGR0tYj/v s+SQ== MIME-Version: 1.0 X-Received: by 10.58.116.4 with SMTP id js4mr2593462veb.38.1403641324468; Tue, 24 Jun 2014 13:22:04 -0700 (PDT) Received: by 10.58.226.165 with HTTP; Tue, 24 Jun 2014 13:22:04 -0700 (PDT) In-Reply-To: <53A98F00.4000702@bbn.com> References: <53A98F00.4000702@bbn.com> Date: Tue, 24 Jun 2014 16:22:04 -0400 Message-ID: From: Sandy Harris To: tcpcrypt@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/1Gu8sF0qyPyRV5hffYJkGXYgZ0g Subject: Re: [Tcpcrypt] Initial questions X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 20:22:08 -0000 On Tue, Jun 24, 2014 at 10:45 AM, Stephen Kent wrote: >> Probably today we should go much further. No MD5 or SHA1 since there >> are known problems. No 3DES since newer ciphers are far faster. No >> reliance on the whole X.509 cert infrastructure SLL/TLS uses; that >> also has known problems. I'm not sure what else. > > To which X.509 cert infrastructure problems are you referring? Do you > mean the Web PKI or PKI in general? IPsec, for example, does not make > use of the Web PKI. Just curious. I said SSL/TLS, implying the web. I think there are more general problems in PKI -- see some of Peter Gutmann's comments, for example -- but those are not relevant here. >> The draft charter also has: >> >> - The protocol must provide cryptographic algorithm agility. >> >> OK, but there is a balance to be struck. IPsec & TLS both have >> problems from arguably excessive complexity and in general complexity >> is the enemy of security. It makes all of design, implementation, >> testing & auditing much harder. TCPcrypt has a rather narrow niche to >> fill; that can be done with a fairly simple protocol. We really must >> strive to keep it simple. > > I'm not sure what your position is re alg agility, based on the paragraph > above. I wrote "OK, but ..". > I can say that failure to accommodate alg agility will almost certainly > cause the IESG to reject this as a standard, based on precedents > for some time. OK, we need some agility, both because it is a good safety measure and because IESG will likely insist. BUT the fewer choices there are, the simpler the protocol can be. That has costs in "design, implementation, testing & auditing" & extra options may mean a risk of downgrade attacks. IPsec has a lot of arguably unnecessary complexity -- pre-shared keys or public keys, main mode or aggressive mode, with or without PFS, actual encryption or do the whole negotiation and then use null encryption, ... Such things should be flatly rejected here; just choose one secure option. As for cipher suites, we need at least two to test the agility and the negotiation part of the protocol. On the other hand, having fewer makes it simpler. I conclude we should have exactly two MUST implement algorithms per choice. >> Here's a first cut at what we might support: >> >> Block ciphers: MUST do AES. SHOULD do the other three AES finalists >> with open licenses: Mars, Twofish & Serpent. MAY do compatible ciphers >> which are national standards: Aria for Korea, Camellia for Japan, >> maybe others. Nothing else. > > why would one make the other AES finalists SHOULD? They didn't make the cut. They are easy to add, patent-free and with open source software readily available, and they have had lots of analysis. Maybe make one a MUST (I'd pick Serpent) and the others MAY. >> Key size? I'd mandate 128 bits everywhere to keep it simple. > > recall that AES has 256-bit keys as an option as a counter to possible > quantum computing attacks. Why rule out that option? The protocol can be simpler if it does not negotiate key size. Make it 256 everywhere, perhaps, but don't complicate the protocol. If quantum attacks become feasible, my understanding is that more-or-less everything we are likely to use would become vulnerable: DH, RSA, ... We'd need a new version no matter what symmetric ciphers were in play. Anyway, this is an opportunistic encryption protocol which blocks easy wholesale monitoring. Its essential goals do not include resistance to more sophisticated attacks, whether MITM or quantum. From nobody Tue Jun 24 13:31:57 2014 Return-Path: X-Original-To: tcpcrypt@ietfa.amsl.com Delivered-To: tcpcrypt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085051B2801 for ; Tue, 24 Jun 2014 13:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66E6fnil6oRx for ; Tue, 24 Jun 2014 13:31:54 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB1401B2825 for ; Tue, 24 Jun 2014 13:31:54 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s5OKVBFp020214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 24 Jun 2014 13:31:11 -0700 (PDT) Message-ID: <53A9E00F.7020502@isi.edu> Date: Tue, 24 Jun 2014 13:31:11 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Sandy Harris , tcpcrypt@ietf.org References: <53A98F00.4000702@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/farcc22jZ4iw4ivoVBKSm0YNF-Q Subject: Re: [Tcpcrypt] Initial questions X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 20:31:56 -0000 On 6/24/2014 1:22 PM, Sandy Harris wrote: ... > Anyway, this is an opportunistic encryption protocol which blocks > easy wholesale monitoring. Of content. Nothing in the charter ensures protection of the meta information (endpoints addrs or ports), nor is traffic confidentiality required. Joe From nobody Tue Jun 24 17:18:00 2014 Return-Path: X-Original-To: tcpcrypt@ietfa.amsl.com Delivered-To: tcpcrypt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6B21B29DC for ; Tue, 24 Jun 2014 17:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5jqxtb7CtXf for ; Tue, 24 Jun 2014 17:17:55 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEBC1B2973 for ; Tue, 24 Jun 2014 17:17:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B944FBE4D; Wed, 25 Jun 2014 01:17:54 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BokMIrrfQx2e; Wed, 25 Jun 2014 01:17:53 +0100 (IST) Received: from [10.87.48.8] (unknown [86.46.20.27]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9B35CBE47; Wed, 25 Jun 2014 01:17:53 +0100 (IST) Message-ID: <53AA1531.40306@cs.tcd.ie> Date: Wed, 25 Jun 2014 01:17:53 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Sandy Harris , tcpcrypt@ietf.org References: <53A98F00.4000702@bbn.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/sZhp8zjHV5ANYrT7zIgAOB3UnnI Subject: Re: [Tcpcrypt] Initial questions X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 00:17:57 -0000 Hiya, On 24/06/14 21:22, Sandy Harris wrote: >> > I can say that failure to accommodate alg agility will almost certainly >> > cause the IESG to reject this as a standard, based on precedents >> > for some time. > > OK, we need some agility, both because it is a good safety measure > and because IESG will likely insist. Planning for what to do on the basis of what the IESG might conclude at this level of detail is not a great plan. For example, by the time the spec reaches the IESG the relevant folks may have changed (I'm one of 'em for now btw) and/or opinions as to the desirable mechanisms for algorithm agility could have changed somewhat. > > BUT the fewer choices there are, the simpler the protocol can be. > That has costs in "design, implementation, testing & auditing" & > extra options may mean a risk of downgrade attacks. There is a separate (sporadic) discussion on the saag list about this. [1] Russ has written a draft trying to capture algorithm agility in the form of a BCP. iang isn't keen but may so far be in the rough. OTOH, we do have issues - its just dumb that there are 300+ TLS ciphersuites, even with the combinatoric explosion, and then there's vanity/national crypto as well that might also be thought of differently here, or not, we'll see. So basically, I'd say leave this one until the WG which I hope will be formed very shortly gets to discussing its protocol details. And at that point I hope we see an argument about what's the right thing to do. S. From nobody Wed Jun 25 04:07:13 2014 Return-Path: X-Original-To: tcpcrypt@ietfa.amsl.com Delivered-To: tcpcrypt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B55B1B2C05 for ; Wed, 25 Jun 2014 04:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlRnmLThqiqD for ; Wed, 25 Jun 2014 04:07:08 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A52DE1B2C33 for ; Wed, 25 Jun 2014 04:04:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B9036BE8B; Wed, 25 Jun 2014 12:04:35 +0100 (IST) 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 NKzkmOjziAAS; Wed, 25 Jun 2014 12:04:35 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5D766BE32; Wed, 25 Jun 2014 12:04:35 +0100 (IST) Message-ID: <53AAACC3.302@cs.tcd.ie> Date: Wed, 25 Jun 2014 12:04:35 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Sandy Harris , tcpcrypt@ietf.org References: <53A98F00.4000702@bbn.com> <53AA1531.40306@cs.tcd.ie> In-Reply-To: <53AA1531.40306@cs.tcd.ie> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/44fnpA9RYqynPA4rvYPPlrBFq4E Subject: Re: [Tcpcrypt] Initial questions X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 11:07:11 -0000 Sorry, I omitted the link to the saag discussion about algorithm agility (thanks Marcelo for spotting that). The initial thread starts at [1], and iang's disagreement at [2]. S. [1] https://www.ietf.org/mail-archive/web/saag/current/msg04844.html [2] https://www.ietf.org/mail-archive/web/saag/current/msg04960.html On 25/06/14 01:17, Stephen Farrell wrote: > > Hiya, > > On 24/06/14 21:22, Sandy Harris wrote: >>>> I can say that failure to accommodate alg agility will almost certainly >>>> cause the IESG to reject this as a standard, based on precedents >>>> for some time. >> >> OK, we need some agility, both because it is a good safety measure >> and because IESG will likely insist. > > Planning for what to do on the basis of what the IESG might > conclude at this level of detail is not a great plan. For > example, by the time the spec reaches the IESG the relevant > folks may have changed (I'm one of 'em for now btw) and/or > opinions as to the desirable mechanisms for algorithm > agility could have changed somewhat. > >> >> BUT the fewer choices there are, the simpler the protocol can be. >> That has costs in "design, implementation, testing & auditing" & >> extra options may mean a risk of downgrade attacks. > > There is a separate (sporadic) discussion on the saag list about > this. [1] Russ has written a draft trying to capture algorithm > agility in the form of a BCP. iang isn't keen but may so far be > in the rough. OTOH, we do have issues - its just dumb that there > are 300+ TLS ciphersuites, even with the combinatoric explosion, > and then there's vanity/national crypto as well that might also > be thought of differently here, or not, we'll see. > > So basically, I'd say leave this one until the WG which I hope > will be formed very shortly gets to discussing its protocol > details. And at that point I hope we see an argument about what's > the right thing to do. > > S. > > > > _______________________________________________ > Tcpcrypt mailing list > Tcpcrypt@ietf.org > https://www.ietf.org/mailman/listinfo/tcpcrypt > > From nobody Fri Jun 27 05:37:53 2014 Return-Path: X-Original-To: tcpcrypt@ietfa.amsl.com Delivered-To: tcpcrypt@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484281B2B35 for ; Fri, 27 Jun 2014 05:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.928 X-Spam-Level: X-Spam-Status: No, score=0.928 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ws2lBIApUBL for ; Fri, 27 Jun 2014 05:37:48 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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 6E88B1B2AB5 for ; Fri, 27 Jun 2014 05:37:48 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s5RCbXEC000669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Jun 2014 15:37:33 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s5RCbXwR001513; Fri, 27 Jun 2014 15:37:33 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21421.25997.54400.11141@fireball.kivinen.iki.fi> Date: Fri, 27 Jun 2014 15:37:33 +0300 From: Tero Kivinen To: ianG In-Reply-To: <53A9CF27.9040600@iang.org> References: <53A98F00.4000702@bbn.com> <53A9CF27.9040600@iang.org> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 13 min X-Total-Time: 12 min Archived-At: http://mailarchive.ietf.org/arch/msg/tcpcrypt/Knx7n472Z6uW5hyt2BFaoHs-Im0 Cc: tcpcrypt@ietf.org, Stephen Kent Subject: Re: [Tcpcrypt] Initial questions X-BeenThere: tcpcrypt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion list for adding encryption to TCP." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 12:37:51 -0000 ianG writes: > > I can say that failure to accommodate alg agility will almost > > certainly cause the IESG to reject this as a standard, based on > > precedents for some time. > > Interesting point! Probably worth reaching out to those folk and asking > whether they are serious about enforced alg agility. I at least think that we do need algorithm agility. We do not need to deploy multiple algorithms, but we need option to be able to implement multiple algorithms and select common one between peers. > And why they care so much in the context of TCPcrypt, which is > opportunistic anyway, and as such provides not much of a guarantee. To provide upgrade path. > > recall that AES has 256-bit keys as an option as a counter to possible > > quantum computing attacks. Why rule out that option? > > Because this is TCPcrypt. The enemy is the unavailability of any > encryption at at all, not the QC bogeyman. > > If we deploy TCPcrypt to 99% of all nodes, and they're all vulnerable to > QC, we still win. > > (Because, to spell it out, we can always upgrade later on when the > bogeyman starts deploying QC in the mega-scale, and meanwhile we won > against everyone else.) So you seem to prefer algorithm agility yourself, by saying "we can always upgrade later". To be able to upgrade later do require algorithm agility. When we need to do upgrade that will take YEARS, or DECADES, as we need to update every single implementation in the world. This means that upgrade is never done completely, there will most likely always be old devices which have not been updated, thus future devices need to be able to talk to old and new devices both, thus requiring algorithm agility. IKEv1 was obsoleted 2005 and replaced with IKEv2. Still lots of implementations only support IKEv1, even when it is quite broken (and I know Dan will disagree with me about this, but in my personal opinion IKEv1 is quite broken, there is no point of arguing it here, IKEv2 is much better protocol), and even those which support IKEv1 and IKEv2 still use IKEv1 as default because the IKEv1 didn't have good enough algorithm agility, i.e. there was lots of implementations who just drop all packets whose version number is not 1.0 causing timeout if you start out with IKEv2. Also lots of people when they comment about IKE list the problems in the IKEv1 which were already fixed in IKEv2. Another example is that SSL 3.0 is still used in some implementations even when newer versions of TLS have been out for some time. If you now go and only allow connections using TLS 1.2 there will lots of clients who cannot connect to you anymore, and TLS 1.2 came out 2008. With these examples about IKEv2 and TLS 1.2, I am trying to tell you that upgrading protocols takes lots of time, especially if there is new protocol version involved. Its much easier to implement new ciphers etc with old protocol than to deploy completely new protocol. Thus algorithm agility is important feature, and it needs to be there from the beginning, otherwise we are stuck with the first version for long time. -- kivinen@iki.fi