From nobody Sat Oct 1 09:55:10 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 081D912B069; Sat, 1 Oct 2016 09:55:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147534090502.2786.3139848881347672896.idtracker@ietfa.amsl.com> Date: Sat, 01 Oct 2016 09:55:05 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-10.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2016 16:55:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : Protecting Internet Key Exchange Protocol version 2 (IKEv2) Implementations from Distributed Denial of Service Attacks Authors : Yoav Nir Valery Smyslov Filename : draft-ietf-ipsecme-ddos-protection-10.txt Pages : 30 Date : 2016-10-01 Abstract: This document recommends implementation and configuration best practices for Internet Key Exchange Protocol version 2 (IKEv2) Responders, to allow them to resist Denial of Service and Distributed Denial of Service attacks. Additionally, the document introduces a new mechanism called "Client Puzzles" that help accomplish this task. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-ddos-protection-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ddos-protection-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 4 06:45:26 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FD6129856 for ; Tue, 4 Oct 2016 06:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRmPgPoBkelb for ; Tue, 4 Oct 2016 06:45:22 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB56C129848 for ; Tue, 4 Oct 2016 06:45:21 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u94DjEIq024501 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 4 Oct 2016 16:45:14 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u94DjD6x001324; Tue, 4 Oct 2016 16:45:13 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22515.45673.944549.840807@fireball.acr.fi> Date: Tue, 4 Oct 2016 16:45:13 +0300 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <4413733F9BF24D94821C1814E88C3C26@buildpc> References: <4413733F9BF24D94821C1814E88C3C26@buildpc> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 21 min X-Total-Time: 30 min Archived-At: Cc: IPsecME WG Subject: [IPsec] Interoperability problem concerning RFC 7427 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 13:45:26 -0000 [This is bit old email, but I have not seen any replies to this, and I am sending this as implementor not as chair.] Valery Smyslov writes: > The problem is that RFC7427 doesn't provide any means to find out > what kind of signatures peer supports. If you have RSA certificate, > you need somehow to guess whether you can use newer PSS signature > format or should stick to old PKCS 1 one. The SIGNATURE_HASH_ALGORITHMS > notification doesn't provide any information of this kind. RFC7427 > is silent whether support for RSASSA-PSS is required to be compliant > with it, so I think it is absolutely legal now to have support for Digital Signature > authentication method and have no support for RSASSA-PSS > (as in the product we have tested with). > The draft draft-ietf-ipsecme-rfc4307bis does requires that if > Digital Signatures are supported, then RSASSA-PSS with SHA2-256 > MUST be supported. However, even if it becomes RFC in near future, > it'll take a couple of years before it is adopted by major vendors. Section 5 of the RFC7427 covers this, and we also discussed this when the RFC was being written. The consensus was that in most cases there is existing configuration between peers anyways, thus configuring which key to be used is just one more configuration option to do, and that is easy way to solve the issue. I.e., in the end we decided we do not want to add negotiation for the public key algorithm. [1] https://www.ietf.org/mail-archive/web/ipsec/current/msg08701.html [2] https://www.ietf.org/mail-archive/web/ipsec/current/msg08671.html > I think that it is a more fundamental problem: RFC7427 allows peers > to announce what hash functions they support, but the peers > cannot announce what kinds of signatures (or what signature formats) > they support. Few years ago life was simpler: there were a couple > of widely used signature schemes and they use different types of > public keys. So, if you had RSA certificate, you could be sure that > RSA PKCS 1 signature format would be understood by anyone. > Now we have new incompatible RSA signature format - RSASSA-PSS > and mere having RSA certificate is not enough to choose right > signature format. I envision that similar situation can repeat > in the future with Elliptic Curve certificates. Now new kind of signature > is being developed for Edwards curve public keys - EDDSA. > However, as far as I anderstand, any Edwards curve key can > be converted to short Weierstrass's form and used in ECDSA. > So we'll probably have a mess when some implementations > support EDDSA, while some use Edwards keys in ECDSA > (at least for a while), that will result in interoperability problems. I think the current consensus is that you should not use same private key with different signature algorithms. I.e., I think they are saying that you should not use same private key for the different versions of the EdDSA etc. On the other hand draft-irtf-cfrg-eddsa do say that "one can use the same keypair for both Ed25519, Ed25519ctx and Ed25519ph" because the signature method is defined so it is still safe. Anyways, I would expect that nobody would want to use the same key for both EdDSA and ECDSA. And whether you want to use same private key for both Ed25519 and Ed25519ph is something that some people say you should not. So I do not think this issue will come up with using same private key for different EC signing methods, but it will come up with RSASSA-PSS. > So, my question is - what to do with all this. > 1. Do nothing. Coming back to the interoperability problem we have, This is what we decided when we published RFC7427. > it is possible to find some workarounds: > - don't use RSASSA-PSS until it becomes ubiquitous (however if everybody > follows this way it'll never become ubiquitous) > - it is possible for the initiator to restart exchange if it receives > AUTHENTICATION_FAILED while using RSASSA_PSS > and use RSA PKCS 1 in the new run. However, this approach > will slow down connection setup and waste resources of > both initiator and responder. > - it is possible for responder to look at the format of signature > the initiator used and act in accordance - if the initiator > doesn't use RSASSA-PSS then don't use it. > These are all workarounds and they complicate implementations > and waste resources for no good reason. We said that in initiator you need to either try all keys, use Certificate request as hint, or have preconfiguration. In the responder you can use the same format than the initiator used (if it used signature authentication). If not, you can either use certificate requests as hint, or use preconfiguration. > 2. Add some indication of signature form/format the peers support. > I can see two possible solutions. > - define new entries in Hash Algorithms registry > that are not hash functions but are rather signature formats. > For example, add RSASSA_PSS. If it is included > in SIGNATURE_HASH_ALGORITHMS notification. > it will mean that this format is supported with any real hash > algorithms that are included in this notification. > It is clearly a hack of RFC 7427. > - define new notification SIGNATURE_FORMATS, which > will include supported signature forms/formats. > It seems to be a most "proper" way, however > it is the slowest one (new RFC is needed). As we already once decided we are not going to do it, I do not think we want to come back to this. It is fine to come back to same issues if something has changed, but I do not think there has been any real changes in here, actually I think the issue is getting easier, as rfc4307bis will say that RSASSA-PSS is MUST, thus this issue will go away and everybody can start using RSASSA-PSS, and just have some fallback option for old implementations not supporting rfc4307bis. I do not think this is issue for ECDSA or EdDSA. And draft-nir-ipsecme-eddsa-01 says that *ph SHOULD ONT be used... -- kivinen@iki.fi From nobody Tue Oct 4 07:11:42 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD15129633 for ; Tue, 4 Oct 2016 07:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.235 X-Spam-Level: * X-Spam-Status: No, score=1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.496, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrg5z3fsb92m for ; Tue, 4 Oct 2016 07:11:38 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C356D12988A for ; Tue, 4 Oct 2016 07:11:27 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id b75so52164542lfg.3 for ; Tue, 04 Oct 2016 07:11:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-transfer-encoding; bh=M9EMCVzcaU3OV3Rn/7T124bKBV/ZJNj+nemFYWYaKCc=; b=ff7yTbSNQjMQ0wICe3qXbBVIRZ0KIrM/0DFsTTaf+iciS9xcTbdTcKYaYFXnNDwaqa ZHu4DpqA6rbbk+vr9ShcOb435aDVAQ56F+bPZASjDcajI27wNjsIIxdhuXUJA75+memq hiy3tLRnDysfR/XlA769bniZR5zBJrcmw4uHxcZCpv5jPnqgsB/qtYQ/AoaZsUymyjNb 3SlcjP6ozo7ti8rd63n8xPkd+PRH41hO/2rb58oQ01HGcBJuT4CJ31e956Y4PWqz1QMK KjiVJ+aqHvr2lZ7F1AvG2bL/XaNWztPl7JOTlZ7rY/E0YLjKXPbIkAQDg9Q1PWoME1nk 7f7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=M9EMCVzcaU3OV3Rn/7T124bKBV/ZJNj+nemFYWYaKCc=; b=Cf+37ltMRV99+On/zYOf+0q1GKMwJLyQ2T91NTVTzSYJ1N9E8wtXxu3XB8vzEjmsQW r8Q82lIOEPmz5u5QdosNR8jMoqYd1XwJxPQROTCJFfLzwAO1/dINT/m1RnEa47pZG5sR CdPi3ndbu+1N5DdFXWGqE306f3e369kSh0+2hB7enbLuZ7PZ27WBy42PqUhq82v4t3uB PCAtrbxdMLDlAVU/b7TpXmvaeXF2QNqR7qTJz3Gddtg3Edx835qMGUZfhkqFW9wFMXfc UPdFPgCq8DOyQhviYGVrbQxEB9hXXg72uYjgoUr3ElPwsBDJ8VdTBnXHl7JWRYBV0aPD xcLg== X-Gm-Message-State: AA6/9Rng0gONbQGfcppLA/AlEjfFeUi6i4XFSrTo9GNqfSNRz3gvCRBFXj9yP3OmLnPAMQ== X-Received: by 10.46.5.2 with SMTP id 2mr1628142ljf.73.1475590285889; Tue, 04 Oct 2016 07:11:25 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id g201sm752348lfg.8.2016.10.04.07.11.24 (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Tue, 04 Oct 2016 07:11:24 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Tero Kivinen" References: <4413733F9BF24D94821C1814E88C3C26@buildpc> <22515.45673.944549.840807@fireball.acr.fi> Date: Tue, 4 Oct 2016 17:11:18 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Interoperability problem concerning RFC 7427 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 14:11:41 -0000 Hi Tero, > [This is bit old email, but I have not seen any replies to this, and I > am sending this as implementor not as chair.] > > Valery Smyslov writes: >> The problem is that RFC7427 doesn't provide any means to find out >> what kind of signatures peer supports. If you have RSA certificate, >> you need somehow to guess whether you can use newer PSS signature >> format or should stick to old PKCS 1 one. The SIGNATURE_HASH_ALGORITHMS >> notification doesn't provide any information of this kind. RFC7427 >> is silent whether support for RSASSA-PSS is required to be compliant >> with it, so I think it is absolutely legal now to have support for Digital Signature >> authentication method and have no support for RSASSA-PSS >> (as in the product we have tested with). >> The draft draft-ietf-ipsecme-rfc4307bis does requires that if >> Digital Signatures are supported, then RSASSA-PSS with SHA2-256 >> MUST be supported. However, even if it becomes RFC in near future, >> it'll take a couple of years before it is adopted by major vendors. > > Section 5 of the RFC7427 covers this, and we also discussed this when > the RFC was being written. The consensus was that in most cases there > is existing configuration between peers anyways, thus configuring > which key to be used is just one more configuration option to do, and > that is easy way to solve the issue. > > I.e., in the end we decided we do not want to add negotiation for the > public key algorithm. > > [1] https://www.ietf.org/mail-archive/web/ipsec/current/msg08701.html > [2] https://www.ietf.org/mail-archive/web/ipsec/current/msg08671.html No this was different issue. I remember that discussion very well (since I initiated it) and I wouldn't start it over again. The issue we came across is not about different algorithms (say indicating whether we need to use RSA or ECDSA if we have both certificates). The algorithm is essentially one - RSA, and we have exactly one RSA certificate. However, we can create AUTH payload using RSA-PKCS 1.5 or using RSASSA-PSS signature formats. And we came across that the peer from different vendor doesn't understand RSASSA-PSS signatures while supporting RFC7427. This is the issue. We have no clue whether it is safe to use RSASSA-PSS or not and the RFC gives us no means to get this clue. This is the problem. [snip] > So I do not think this issue will come up with using same private key > for different EC signing methods, but it will come up with RSASSA-PSS. I'm not so sure that EC signing methods will not suffer from this issue, giving the speed the new ones appear and become popular. >> So, my question is - what to do with all this. >> 1. Do nothing. Coming back to the interoperability problem we have, > > This is what we decided when we published RFC7427. No, it was different discussion. You persuaded me then that Certificate Request etc. works well for selecting the proper private key. It doesn't work at all for selecting the "proper" signature format. >> it is possible to find some workarounds: >> - don't use RSASSA-PSS until it becomes ubiquitous (however if everybody >> follows this way it'll never become ubiquitous) >> - it is possible for the initiator to restart exchange if it receives >> AUTHENTICATION_FAILED while using RSASSA_PSS >> and use RSA PKCS 1 in the new run. However, this approach >> will slow down connection setup and waste resources of >> both initiator and responder. >> - it is possible for responder to look at the format of signature >> the initiator used and act in accordance - if the initiator >> doesn't use RSASSA-PSS then don't use it. >> These are all workarounds and they complicate implementations >> and waste resources for no good reason. > > We said that in initiator you need to either try all keys, use > Certificate request as hint, or have preconfiguration. Certificate Request doesn't work. Preconfiguration doesn't scale. Trying all signature formats is possible, but I expect that many implementers (and users) will just disable RSASSA-PSS, that is a bad thing... > In the responder you can use the same format than the initiator used > (if it used signature authentication). If not, you can either use > certificate requests as hint, or use preconfiguration. Yes, it is possible for the responder to look at the signature format the initiator used and act correcpondently. However, if many initiators disable RSASSA-PSS for the request then responders won't use it either, leading to even more slow adoption of this signature sceme. >> 2. Add some indication of signature form/format the peers support. >> I can see two possible solutions. >> - define new entries in Hash Algorithms registry >> that are not hash functions but are rather signature formats. >> For example, add RSASSA_PSS. If it is included >> in SIGNATURE_HASH_ALGORITHMS notification. >> it will mean that this format is supported with any real hash >> algorithms that are included in this notification. >> It is clearly a hack of RFC 7427. >> - define new notification SIGNATURE_FORMATS, which >> will include supported signature forms/formats. >> It seems to be a most "proper" way, however >> it is the slowest one (new RFC is needed). > > As we already once decided we are not going to do it, I do not think > we want to come back to this. It is fine to come back to same issues > if something has changed, but I do not think there has been any real It is a bit different issue. And it is practical. > changes in here, actually I think the issue is getting easier, as > rfc4307bis will say that RSASSA-PSS is MUST, thus this issue will go > away and everybody can start using RSASSA-PSS, and just have some > fallback option for old implementations not supporting rfc4307bis. Yes, the issue with RSASSA-PSS should go away once the RFC4307bis is issued and adopted by majority of vendors. It'll take a couple of years. > I do not think this is issue for ECDSA or EdDSA. And > draft-nir-ipsecme-eddsa-01 says that *ph SHOULD ONT be used... Not so sure... Regards, Valery. From nobody Tue Oct 4 10:38:18 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2335F129401 for ; Tue, 4 Oct 2016 10:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVVpwIsDKZXd for ; Tue, 4 Oct 2016 10:38:14 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04B241293F8 for ; Tue, 4 Oct 2016 10:38:14 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id p138so225109642wmb.1 for ; Tue, 04 Oct 2016 10:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=UVg0KvQmW6zoyFfHVneccYEvfSy5uWTY/rWoI0ipDHE=; b=L6G1iSip3XBfH7VlMCu0xM1IcNfLDSYdfhTHSMnSboXUOG5IhPqBIbe+6Gj30Dfzf4 5buMHHy1EcY6qgzYFNSU5av3JYaPsYGM0zOchLRVZ+529K90Dwj7Besn7Zayn4PRAKhU tDGBPJst2UY+Z//3OmU/w7e8xlc5ESmpkuthDKblm9A151hJxG4dpd9X9oucawH3m7Am 9hp2K5F5UFcZIAyUk4ke9xvBnFBxowycTanqTffzFht1fa4LOGHdtxClCOpBJWMDaz8E SKwjdmnbge79dWQ2d6OzvQratU/eLbQtF4hjtokyasgx9zFx4I38+34xzzFiPHnBDEIM N/fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=UVg0KvQmW6zoyFfHVneccYEvfSy5uWTY/rWoI0ipDHE=; b=MoU+lXWGxeN0hpVLfrrCh9HEU9kybaEiFYJUrUP2JxV51fuLz67EC5AoLiiZ+C7RMf Iiykd4QWGXBhW7Mi9Nagvn4mfYb+4r72zd3Mx+8dM0RpDPlW4T0WYkozjJA9JDa6XgaS TYbP0+s+NzkRKK5q/ERAOpIpOz7PjnnH9yKGYaLUXm8ebhxSrA79hUQ5DQ27iAStCQUG ynAKU0esenOCRDY07trvlER0pn44A9dwxlVGnAzez4pCXE27JH4IrVgIMI9Au2sffJLf SeFBW/ZI24ty5vd0R00XEm8DCeHx/0StSJbaayVpjj9eCXZDX1Xo3EF0DGFIhf/99KSi xdaQ== X-Gm-Message-State: AA6/9RnPqC9PVMEMipLQlTPUv6yXxBfcghJ89wxqvXrZUJDBNWf3yq0P7QvupKr/ql+S3Q== X-Received: by 10.28.149.77 with SMTP id x74mr5332085wmd.95.1475602692389; Tue, 04 Oct 2016 10:38:12 -0700 (PDT) Received: from [192.168.1.13] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id x135sm27581486wmd.0.2016.10.04.10.38.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Oct 2016 10:38:11 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_BCCBE854-327E-4457-AAB9-B7AB291BEE70" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Yoav Nir X-Priority: 3 In-Reply-To: Date: Tue, 4 Oct 2016 20:38:08 +0300 Message-Id: <50ABC4C4-B5AD-4C92-87B6-D9E88E01146A@gmail.com> References: <4413733F9BF24D94821C1814E88C3C26@buildpc> <22515.45673.944549.840807@fireball.acr.fi> To: Valery Smyslov X-Mailer: Apple Mail (2.3226) Archived-At: Cc: IPsecME WG , Tero Kivinen Subject: Re: [IPsec] Interoperability problem concerning RFC 7427 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 17:38:16 -0000 --Apple-Mail=_BCCBE854-327E-4457-AAB9-B7AB291BEE70 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 4 Oct 2016, at 17:11, Valery Smyslov wrote: >=20 > Hi Tero,=20 >> [This is bit old email, but I have not seen any replies to this, and = I >> am sending this as implementor not as chair.] >> Valery Smyslov writes: >>> The problem is that RFC7427 doesn't provide any means to find out >>> what kind of signatures peer supports. If you have RSA certificate, >>> you need somehow to guess whether you can use newer PSS signature >>> format or should stick to old PKCS 1 one. The = SIGNATURE_HASH_ALGORITHMS >>> notification doesn't provide any information of this kind. RFC7427 >>> is silent whether support for RSASSA-PSS is required to be compliant >>> with it, so I think it is absolutely legal now to have support for = Digital Signature >>> authentication method and have no support for RSASSA-PSS (as in the = product we have tested with). >>> The draft draft-ietf-ipsecme-rfc4307bis does requires that if >>> Digital Signatures are supported, then RSASSA-PSS with SHA2-256 >>> MUST be supported. However, even if it becomes RFC in near future, >>> it'll take a couple of years before it is adopted by major vendors. >> Section 5 of the RFC7427 covers this, and we also discussed this when >> the RFC was being written. The consensus was that in most cases there >> is existing configuration between peers anyways, thus configuring >> which key to be used is just one more configuration option to do, and >> that is easy way to solve the issue. >> I.e., in the end we decided we do not want to add negotiation for the >> public key algorithm. >> [1] https://www.ietf.org/mail-archive/web/ipsec/current/msg08701.html >> [2] https://www.ietf.org/mail-archive/web/ipsec/current/msg08671.html >=20 > No this was different issue. I remember that discussion very well = (since > I initiated it) and I wouldn't start it over again.=20 > The issue we came across is not about different algorithms > (say indicating whether we need to use RSA or ECDSA if we have > both certificates). The algorithm is essentially one - RSA, and we = have exactly one RSA certificate. However, we can create AUTH > payload using RSA-PKCS 1.5 or using RSASSA-PSS signature > formats. And we came across that the peer from different > vendor doesn't understand RSASSA-PSS signatures while > supporting RFC7427. This is the issue. We have no clue > whether it is safe to use RSASSA-PSS or not and > the RFC gives us no means to get this clue. This is the problem.=20 There is one clue. The signature in the certificate. If the certificate = is signed with PKCS #1.5 it is safest to use PKCS #1.5 for = authentication. If the certificate is signed with PSS then it=E2=80=99s = probably safe to use PSS in the signature. I know this greatly delays the deployment of PSS, because for a = certificate issuer PKCS #1.5 is the safest route, but I don=E2=80=99t = know that we can do better without either a negotiation or prior = agreement (which just means configuration from an implementer=E2=80=99s = POV) Yoav --Apple-Mail=_BCCBE854-327E-4457-AAB9-B7AB291BEE70 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 4 Oct 2016, at 17:11, Valery Smyslov <svanru@gmail.com> = wrote:

Hi Tero, 
[This is bit old email, but I have not seen any replies to = this, and I
am sending this as implementor not as = chair.]
Valery Smyslov writes:
The problem is that RFC7427 doesn't provide any = means to find out
what kind of signatures peer supports. = If you have RSA certificate,
you need somehow to guess = whether you can use newer PSS signature
format or should = stick to old PKCS 1 one. The SIGNATURE_HASH_ALGORITHMS
notification doesn't provide any information of this kind. = RFC7427
is silent whether support for RSASSA-PSS is = required to be compliant
with it, so I think it is = absolutely legal now to have support for Digital Signature
authentication method and have no support for RSASSA-PSS (as = in the product we have tested with).
The draft = draft-ietf-ipsecme-rfc4307bis does requires that if
Digital = Signatures are supported, then RSASSA-PSS with SHA2-256
MUST= be supported. However, even if it becomes RFC in near future,
it'll take a couple of years before it is adopted by major = vendors.
Section 5 of the RFC7427 covers = this, and we also discussed this when
the RFC was being = written. The consensus was that in most cases there
is = existing configuration between peers anyways, thus configuring
which key to be used is just one more configuration option to = do, and
that is easy way to solve the issue.
I.e., in the end we decided we do not want to add negotiation = for the
public key algorithm.
[1] https://www.ietf.org/mail-archive/web/ipsec/current/msg08701.ht= ml
[2] https://www.ietf.org/mail-archive/web/ipsec/current/msg08671.ht= ml

No this was different issue. I = remember that discussion very well (since
I initiated it) and I wouldn't = start it over again. 
The issue we came across is not about different = algorithms
(say indicating whether we need to use RSA or = ECDSA if we have
both certificates). The algorithm is = essentially one - RSA, and we have exactly one RSA certificate. However, = we can create AUTH
payload using RSA-PKCS 1.5 or using = RSASSA-PSS signature
formats. And we came across that the peer = from different
vendor doesn't understand RSASSA-PSS signatures = while
supporting RFC7427. This is the issue. We have = no clue
whether it is safe to use RSASSA-PSS or not = and
the RFC gives us no means to get this clue. This = is the problem. 

There is = one clue.  The signature in the certificate. If the certificate is = signed with PKCS #1.5 it is safest to use PKCS #1.5 for authentication. = If the certificate is signed with PSS then it=E2=80=99s probably safe to = use PSS in the signature.

I know this greatly delays the deployment of PSS, because for = a certificate issuer PKCS #1.5 is the safest route, but I don=E2=80=99t = know that we can do better without either a negotiation or prior = agreement (which just means configuration from an implementer=E2=80=99s = POV)

Yoav

= --Apple-Mail=_BCCBE854-327E-4457-AAB9-B7AB291BEE70-- From nobody Tue Oct 4 11:09:06 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19AAF129418 for ; Tue, 4 Oct 2016 11:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcgxE-9GdJCN for ; Tue, 4 Oct 2016 11:09:03 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 448A2129400 for ; Tue, 4 Oct 2016 11:09:03 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id l131so192156206lfl.2 for ; Tue, 04 Oct 2016 11:09:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-transfer-encoding:importance; bh=Hl2hQtMAWWHsqwlBc45ZS2PiIzEO9IvY0GanIvJj5Ns=; b=UWvSjrhN/ZxEt5GHfE5Nd8kvwPme7bmAv4Q5PrQ7LQ+vu61JEazIQDtlH29lmYI4/a WvxvsrRUrVD60MdzH22vjal9ltBGQBw7bL5KKdSSslCbuxRQuCRQylv3qNZ+huRTkG4V aH4eQkQTPT4QEOVFVktFLKIezhmJqV41PdMhi4wloSxi0dg+8/tW7ALUacLwISNCOxaJ MjaBSrGMgG71xwGZtJbwAxtZ9zoA4DSX6J68kmUhReBuNl0URb8nsgoNqpOBOBPcJRdi l/Eu2Mzz4AzCihFsFMhUTlM021xsAwnUel0AHKLcDFBnJPJDhfCG+hdbiuN3F8Q2NxHH JxQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=Hl2hQtMAWWHsqwlBc45ZS2PiIzEO9IvY0GanIvJj5Ns=; b=BYx3qp1+87yUZT+reeCmmdlAjwhCZfw3EQEXeIc0AO3zOszV6NIRsRkdjg/loXhz1v gt9CL+rHryXL3+nBezK+Y6GfC1rLrY7R1YMEO7/ZFf4dKusujWO9ct7FcKl8hHe5d6L4 Mx5R7W4Ynw/g88uYSzKifdvWBWmRyzPHxgwPY/+Et9z+x5cjp/IyHN/xoY+K6xl2KD0X WMJbEfaEvOM5SjdHElg3c0CPvcPwjGYeSnovH7G2VTk4/Qc4f41Az2AyFYYvHy6S7ORz HxSk86a4rOcxYSOuKDcVgvpiMMVR2+lkZy3pzkybCZ7ewLlmjln2VF1by4+Wa+9S6zEH M2cQ== X-Gm-Message-State: AA6/9RligcUWS7/3pgDJkWbsavKBEojqLE4jGElYdyd2AaL6NrXSwW1Arevwlou/xLmpYw== X-Received: by 10.25.74.143 with SMTP id x137mr2039914lfa.10.1475604541332; Tue, 04 Oct 2016 11:09:01 -0700 (PDT) Received: from chichi (ppp83-237-171-240.pppoe.mtu-net.ru. [83.237.171.240]) by smtp.gmail.com with ESMTPSA id i5sm904542lfe.40.2016.10.04.11.08.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 04 Oct 2016 11:09:00 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Yoav Nir" References: <4413733F9BF24D94821C1814E88C3C26@buildpc> <22515.45673.944549.840807@fireball.acr.fi> <50ABC4C4-B5AD-4C92-87B6-D9E88E01146A@gmail.com> In-Reply-To: <50ABC4C4-B5AD-4C92-87B6-D9E88E01146A@gmail.com> Date: Tue, 4 Oct 2016 21:08:56 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: IPsecME WG , Tero Kivinen Subject: Re: [IPsec] Interoperability problem concerning RFC 7427 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 18:09:05 -0000 Hi Yoav, >> No this was different issue. I remember that discussion very well (since >> I initiated it) and I wouldn't start it over again. >> The issue we came across is not about different algorithms >> (say indicating whether we need to use RSA or ECDSA if we have >> both certificates). The algorithm is essentially one - RSA, and we have exactly one RSA certificate. However, we can >> create AUTH >> payload using RSA-PKCS 1.5 or using RSASSA-PSS signature >> formats. And we came across that the peer from different >> vendor doesn't understand RSASSA-PSS signatures while >> supporting RFC7427. This is the issue. We have no clue >> whether it is safe to use RSASSA-PSS or not and >> the RFC gives us no means to get this clue. This is the problem. >> > There is one clue. The signature in the certificate. If the certificate is signed with PKCS #1.5 it is safest to use > PKCS #1.5 for authentication. > If the certificate is signed with PSS then it’s probably safe to use PSS in the signature. That was my first thought when we came across this issue. I thought that if peer's certificate is signed with RDASSA-PSS then it must be safe to use RSASSA-PSS in IKEv2. To my disappointment our peer did understand certificate with PSS, but at the same time failed to understand PSS in IKEv2. That was a sad truth of life. So, unfortunately it doesn't reliably work. > I know this greatly delays the deployment of PSS, because for a certificate issuer PKCS #1.5 is the safest route, > but I don’t know that we can do better without either a negotiation or prior agreement (which just means configuration > from an implementer’s POV) I don't think negotiation is needed. It's enough if each side announces its capabilities, the same way it is done in RFC7427 with hash functions. And the easiest way to do it is to add pseudo-hash value "RSASSA-PSS supported" into the hash algorithms registry. In this case each side will announces that it supports some set of hash algorithms in signature and announces whether RSASSA-PSS is supported. I understand that it is a clear protocol hack and I don't want to follow this way, but it is the easiest path. Can you suggest better solution (apart from "do nothing")? Regards, Valery. > Yoav From nobody Tue Oct 4 14:40:11 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E33129513 for ; Tue, 4 Oct 2016 14:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.996 X-Spam-Level: X-Spam-Status: No, score=-4.996 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=-2.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkA1VjVvP2or for ; Tue, 4 Oct 2016 14:40:08 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E92B312951F for ; Tue, 4 Oct 2016 14:40:07 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3spXPw5yv4z4m; Tue, 4 Oct 2016 23:40:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1475617204; bh=LNaEJUMUQRJFWi/eXygzhXY74zIVivIMHf8oxjTfBS4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=tqfyFKV63+yb5r7P2XeUIzYCuDwQ5F2TniizVqfLE9sYPOcLzaldoY3nwDMqWd0yz pE9n6udOJ1pTVc+SDMWEZ/oEdPVenKi+onkTQmeeWVcM3fJKWZKZOnGhpfbRhE2VZ7 KXO42Ja2fJtMpD5Nq4orHIrcSgdyHCjaDekStYec= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id wjFrtqvlXZu4; Tue, 4 Oct 2016 23:40:03 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 4 Oct 2016 23:40:03 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id BDCED5C83C; Tue, 4 Oct 2016 17:40:02 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca BDCED5C83C Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AA79C40D3584; Tue, 4 Oct 2016 17:40:02 -0400 (EDT) Date: Tue, 4 Oct 2016 17:40:02 -0400 (EDT) From: Paul Wouters To: Valery Smyslov In-Reply-To: Message-ID: References: <4413733F9BF24D94821C1814E88C3C26@buildpc> <22515.45673.944549.840807@fireball.acr.fi> <50ABC4C4-B5AD-4C92-87B6-D9E88E01146A@gmail.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Interoperability problem concerning RFC 7427 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 21:40:10 -0000 On Tue, 4 Oct 2016, Valery Smyslov wrote: > I don't think negotiation is needed. It's enough if each side announces its > capabilities, > the same way it is done in RFC7427 with hash functions. And the easiest way > to do > it is to add pseudo-hash value "RSASSA-PSS supported" into the hash > algorithms registry. > In this case each side will announces that it supports some set of hash > algorithms in signature and > announces whether RSASSA-PSS is supported. I understand that it is a clear > protocol hack > and I don't want to follow this way, but it is the easiest path. Can you > suggest better > solution (apart from "do nothing")? I'm really against this solution. As you said, we can expect more of this with ECC variants, and it will just be a large cluttering of the integ registry. What's wrong with adding a new notify type that can be used on the initiator as well as on the responder? And so doesn't have the problem of favouring the "old ways" for compatibility? Paul From nobody Tue Oct 4 22:42:46 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5343612940E for ; Tue, 4 Oct 2016 22:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.796 X-Spam-Level: X-Spam-Status: No, score=0.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.496, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gK7lJprUgst8 for ; Tue, 4 Oct 2016 22:42:44 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F7E1126B6D for ; Tue, 4 Oct 2016 22:42:43 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id b81so81898753lfe.1 for ; Tue, 04 Oct 2016 22:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-transfer-encoding; bh=glzuS/Xu8zYqH0LAgqA6z3i2FnuxqKHnhxkxAbe7Zxc=; b=zuagyV0BpEzXl9Lg5vRSfrCyzM81RnxyV9kOQAUyDlCyA2+xrTKUB7nmRCDfGBiJa3 5vywHLJB6/nJoUYNaya6+z8AFU4eSepkY/Cq/TYu8hcbXS3324BazJIrDT3S7+6TMdaV 9PMrPiez1Ywnp8P5XmCyu8HccASmtD8/vGTyWKOgKMyCtrHN2Fjre2TTwWbCJhY+SGkU DNn++XMmCgowmOTgXvnfO3G5s30icS1c9tompg4tqjlSjSMaYDal2k+Kl7iRQYAi1zpz 3yefCuLRpFwWFGnRLlybzBqjquO2U+mloUGwhtNRG5NpxFFwHkn55pFGHUiPMH5aaQtY BZvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=glzuS/Xu8zYqH0LAgqA6z3i2FnuxqKHnhxkxAbe7Zxc=; b=WKPeVR8Zc+828tOruTljsxsnXLn8zyjNHdwfuTd3vLY0ClSD4K6P5RrTkbeb0eyuLF h/rcLuy5Zko6P2UlmG4dVr/EsttvRskUs6c5I5BeSj9a8NKzelZY0Mm3ZORUeve+trub 30aPWqPE+hxjOWzyqAZJNyfjX5ny3jki5p6d95aU71nazZs0XhMuEOPm6RpBlitPJAso FiO8IIaSrmEFLielvQvIeKkm4Bkv1JyQD4Howjva8V4EiKO5c/WD67oL1RJvP8pQRr6b kmLhtEM3wIpLgHypuOgNtHGES8dMcYSoFEf1b/tBkXkyfaG/houipHzKmbPD1lvrOl/6 35sQ== X-Gm-Message-State: AA6/9RkzZF1KOQNa+0G0fO7OmGUW4LQngI61xAJeSFTcuzh9AMK768vf6g6KiY48RmdgWA== X-Received: by 10.25.44.142 with SMTP id s136mr3186133lfs.156.1475646161541; Tue, 04 Oct 2016 22:42:41 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id q69sm1347708lfi.15.2016.10.04.22.42.40 (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Tue, 04 Oct 2016 22:42:40 -0700 (PDT) Message-ID: <53F847A3C4D6405E8590DC7D6B177579@buildpc> From: "Valery Smyslov" To: "Paul Wouters" References: <4413733F9BF24D94821C1814E88C3C26@buildpc> <22515.45673.944549.840807@fireball.acr.fi> <50ABC4C4-B5AD-4C92-87B6-D9E88E01146A@gmail.com> Date: Wed, 5 Oct 2016 08:42:36 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Interoperability problem concerning RFC 7427 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 05:42:45 -0000 Hi Paul, >> I don't think negotiation is needed. It's enough if each side announces its >> capabilities, >> the same way it is done in RFC7427 with hash functions. And the easiest way >> to do >> it is to add pseudo-hash value "RSASSA-PSS supported" into the hash >> algorithms registry. >> In this case each side will announces that it supports some set of hash >> algorithms in signature and >> announces whether RSASSA-PSS is supported. I understand that it is a clear >> protocol hack >> and I don't want to follow this way, but it is the easiest path. Can you >> suggest better >> solution (apart from "do nothing")? > > I'm really against this solution. As you said, we can expect more of > this with ECC variants, and it will just be a large cluttering of the > integ registry. I'm not happy with it either. But it is a "quick hack" that would fix this particular problem. > What's wrong with adding a new notify type that can be used on the > initiator as well as on the responder? And so doesn't have the problem > of favouring the "old ways" for compatibility? Nothing wrong. In my original message https://mailarchive.ietf.org/arch/msg/ipsec/0XYpWpMrtU_IXmn_RxfWWvsXztM I suggested three ways to deal with the problem: 1. Do nothing 2. Make a quick hack by defining a fake hash function "RSASSA_PSS" in IKEv2 Hash Algorithms registry. 3. Define new notification SIGNATURE_FORMATS that would list supported signature formats In my opinion the third option is the right way to go. However, I can leave with the first two too. Just want to know what the WG thinks of it. > Paul Regards, Valery. From nobody Wed Oct 5 00:03:19 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CE7129541 for ; Wed, 5 Oct 2016 00:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4ILYGgRt_Kz for ; Wed, 5 Oct 2016 00:03:15 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06D6612953F for ; Wed, 5 Oct 2016 00:03:15 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id f193so209865534wmg.0 for ; Wed, 05 Oct 2016 00:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rS38iJpw9iGw4ZQK/I8VXbFRcKfnmOAPlNWH51u0UGg=; b=GkZCmUZjc85BH9LN9JNV/dovhiYvVUgJxYbx/V0Zmx+y9W0GY0C31Cs7IwEItbf5c5 1im/WurXIAR5a1zaPIJStnmI2xfOjBYflXjuiiMWbIhM+L8hcRHChkqTAYOzo9ce/2KD mV6rsvSITu9QkYAPfORQwOpH9bsy9aeKGVBL5+PGdA2iVsA26Kbb+piAyTIlIHJi6Lbv y3+evCU20dO+Y7NHsDXxgXei1dP+8UVQguMZudpAIjsOk1Sb3cwNTAM83oR+BZP1Cydh K01rYQI0MNFJKvkjkYL/dUjvwqz0zdcXIynnD76nKCPGUhFao7RB/BFU9c04TdZE3iy/ 2a6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rS38iJpw9iGw4ZQK/I8VXbFRcKfnmOAPlNWH51u0UGg=; b=hfsB40GYtiOouTQqSp7yOsZmA/1x4XviHFsjMj4rHXdHbmiVDqRVSTjvJHa4KIQSI8 c7qokhHL+DOBynISGepc11Z4NuhltTLkA6HTCGVjjl5e9AbRyF2uU1uKS5I8aeyRiKYo hgoFYk0QeQygArmUvG3tZDuY9SHQ7PMYZ6Vxxp58HS4mQi8YuIcbEhihvRgFC/nLp7K8 tgV6OCOEg0kbb4s5c5GT5O4SFdcBqHjC2Ik6gAq8w3zGa4o37Egd5QBuQmhGKdc3Bnpz eOqtvtyNJKXKKS1Lw/yqORSCiXGmTFlbKC+Zi2bnnp8lYgFcvQpP2hLfbHj1cctARfsh SzPQ== X-Gm-Message-State: AA6/9RmFFDxQQBjdLwrmL685k4KAUP2kUMgz4Qn3iMNB36xldwZDkuwD37e2me5phdth2Q== X-Received: by 10.28.19.194 with SMTP id 185mr17529605wmt.51.1475650993515; Wed, 05 Oct 2016 00:03:13 -0700 (PDT) Received: from [192.168.6.36] (bzq-28-168-31-176.red.bezeqint.net. [31.168.28.176]) by smtp.gmail.com with ESMTPSA id h3sm7220308wjp.45.2016.10.05.00.01.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Oct 2016 00:03:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Yoav Nir X-Priority: 3 In-Reply-To: <53F847A3C4D6405E8590DC7D6B177579@buildpc> Date: Wed, 5 Oct 2016 10:01:52 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2EE452AB-4124-4A9B-BEB8-1B128806BB5B@gmail.com> References: <4413733F9BF24D94821C1814E88C3C26@buildpc> <22515.45673.944549.840807@fireball.acr.fi> <50ABC4C4-B5AD-4C92-87B6-D9E88E01146A@gmail.com> <53F847A3C4D6405E8590DC7D6B177579@buildpc> To: Valery Smyslov X-Mailer: Apple Mail (2.3226) Archived-At: Cc: IPsecME WG , Paul Wouters Subject: Re: [IPsec] Interoperability problem concerning RFC 7427 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 07:03:17 -0000 Perhaps we (as in the working group) should schedule some time (15-20 = minutes?) to discuss the options in Seoul. Understanding both RFC 7427 and PSS signatures when they are in = certificates, but not PSS signatures when they are in AUTH payloads is a = pretty egregious kind of wrongness, but if this wrongness exists in the = wild, we should probably come up with a strategy on how to deal with it. Yoav From nobody Wed Oct 5 00:26:48 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125471294FD for ; Wed, 5 Oct 2016 00:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.935 X-Spam-Level: * X-Spam-Status: No, score=1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=3.496, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGLeX4PrU4nH for ; Wed, 5 Oct 2016 00:26:46 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCC0D1293EE for ; Wed, 5 Oct 2016 00:26:45 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id b75so70156581lfg.3 for ; Wed, 05 Oct 2016 00:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-transfer-encoding; bh=RheiqZAcNaBroxG9hrqyO3/uLioiJknlKAL5G9cDfg8=; b=erJ+PBLrImJEeeKGw3aM8oZkTXMMxDPVNURbOTjbhWBANfvbtzvYnrrIcXIaFRM4+U avIt752aXHuMK7sHFJwgRomarq6zUQhygnyy+k03jhEzbC/5p60FJb9leA7/dFgDC5Cm sRJHTueKa1xGvBdIviSwXql48EnJNZEIXzPmGcpzEj23d24PMi//HyT+6Jgg6yYuo/XG RH573QIbUQheLcUBVH63xCbDaV2WJWB4th/00ff0AyHsYIh/g1UKsA9fbwKmaMPUN1jI W6c1vAQZeFLopYt6KQSMbEshaODaz5+llNvZa4Z8naWQqw4cK1/4T3i/jwt3lTou0Zz7 UGmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=RheiqZAcNaBroxG9hrqyO3/uLioiJknlKAL5G9cDfg8=; b=ZASRgMN6cyymxeS2tgE6gTeaclQH+B19hWHHRDJj/guEGCMONJCLzCgj/ff8OZ8HS5 8cWBl05WbmwI7vDpxYK8sq4mstA+ID3X0MzHBBHcCSDnROoH2FbEa2hcfw1abbi72Owe yvMUfu/7tqDk0/4aHE5ZjrmcnY+4zOeD+xS7RnCSRKFdrfckqMRBJAhbsJnLcHXFT2cK lNvTSszq2sSLMs2RIz8tLzlLwL/5guJKkvu7jg+phUNlRpJ0WbkFCVxhcWCnlYcwK9hU Ys01C08toHOcVwpysdFFLGWXwy41vnw991RiqY4oqua4lN61dfX+Wn5h2/le87qwRTSf 1CsA== X-Gm-Message-State: AA6/9Rl/xX5+9tk6YOUkbZPSKTPiYPcMqZ26UIcQKeL/RCiO4/cH4G3oEgx79P1ex2GhbA== X-Received: by 10.25.22.72 with SMTP id m69mr3236302lfi.179.1475652403984; Wed, 05 Oct 2016 00:26:43 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id 75sm1393480lja.34.2016.10.05.00.26.42 (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Wed, 05 Oct 2016 00:26:43 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Yoav Nir" References: <4413733F9BF24D94821C1814E88C3C26@buildpc> <22515.45673.944549.840807@fireball.acr.fi> <50ABC4C4-B5AD-4C92-87B6-D9E88E01146A@gmail.com> <53F847A3C4D6405E8590DC7D6B177579@buildpc> <2EE452AB-4124-4A9B-BEB8-1B128806BB5B@gmail.com> Date: Wed, 5 Oct 2016 10:26:40 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: IPsecME WG , Paul Wouters Subject: Re: [IPsec] Interoperability problem concerning RFC 7427 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 07:26:47 -0000 Sure. I can prepare the slides (if the WG chairs don't mind). Regards, Valery. > Perhaps we (as in the working group) should schedule some time (15-20 minutes?) to discuss the options in Seoul. > > Understanding both RFC 7427 and PSS signatures when they are in certificates, but not PSS signatures when they are > in AUTH payloads is a pretty egregious kind of wrongness, but if this wrongness exists in the wild, we should probably > come up with a strategy on how to deal with it. > > Yoav From nobody Wed Oct 5 04:36:43 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6031E1296A0 for ; Wed, 5 Oct 2016 04:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKp5d6HnbgEp for ; Wed, 5 Oct 2016 04:36:40 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18837126579 for ; Wed, 5 Oct 2016 04:36:39 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u95BaVYq005214 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 5 Oct 2016 14:36:31 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u95BaVnS015730; Wed, 5 Oct 2016 14:36:31 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22516.58815.577872.948004@fireball.acr.fi> Date: Wed, 5 Oct 2016 14:36:31 +0300 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <4413733F9BF24D94821C1814E88C3C26@buildpc> <22515.45673.944549.840807@fireball.acr.fi> <50ABC4C4-B5AD-4C92-87B6-D9E88E01146A@gmail.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 6 min Archived-At: Cc: IPsecME WG , Valery Smyslov Subject: Re: [IPsec] Interoperability problem concerning RFC 7427 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 11:36:42 -0000 Paul Wouters writes: > I'm really against this solution. As you said, we can expect more of > this with ECC variants, and it will just be a large cluttering of the > integ registry. Do you really think we will see this more in ECC? How will that happen more in the ECC? If I have Ed25519 key, why would someone go against the "SHOULD NOT" in draft-nir-ipsecme-eddsa draft and use something else than Ed25519, i.e., why would someone use Ed25519ph, or why would someone use ECDSA with Ed25519 key (even if it would be possible). Are people really going to mix different ECC keys with different algorithms? I would assume it would be better to just create separete keys for each signature algorithm, and not use the same key. With RSA I can see the reason, as people do want to reuse the old existing key they already have and want to use it with old RSA and with RSASSA-PSS, but I have not yet seen reason for that in ECC. So can you explain why you think this will happen in the ECC? -- kivinen@iki.fi From nobody Wed Oct 5 05:25:00 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96CA81296DA for ; Wed, 5 Oct 2016 05:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.235 X-Spam-Level: * X-Spam-Status: No, score=1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.496, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDebEx8cJNXV for ; Wed, 5 Oct 2016 05:24:58 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F7801296D6 for ; Wed, 5 Oct 2016 05:24:58 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id b75so76851080lfg.3 for ; Wed, 05 Oct 2016 05:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-transfer-encoding; bh=5k+jFEr/aXMWFJdQLzRQPKKaei4pYntvQMt2HNjF+zA=; b=UhHt/Nlg7/JT3Tn0HTBz9TAyevFGYEAvotl5yVaJtncdHdOdlzCMO5JkgqQcRdecZp oOUgNVxcB+fMNgNdPKlOCYCQejAVXTTSphXnNjEGJh7Xb/Ibdf/ADGnFoNjB8Ixzspca 8FSyN1aIEo9T7zCe0KXDqdA2YBI1lCcoD67V4oD+ZETRsMSRiQJ+rFYtHlbTmyOyfle4 UfP6HZuHYRV5B24AKqwPgzFefFxR9rZOYjP+7N4bicYCMx/ZfRkEoee0k+wgIqSu/SAt 0b1roSg0P1LsqkIftxC/tIDvTPDF0TXyZ3gR4JbIlht5vVg1lkOBV/jaOdCpCRSbaDLa w75Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=5k+jFEr/aXMWFJdQLzRQPKKaei4pYntvQMt2HNjF+zA=; b=kTVp9grufBmizlZLdkCol99Z9Wb2ZygbCxw8DuIM55pYKfDgz7leeQi68qXhHQdfAf lTmswxwb7cOOST6HejczsoueFX59BTsa/A0xAXHL5d5nXdWeOeiFgmJzKEPEdQP9XL+J 79c2Y5h0QHcNnB7UlGGwEvtYRYcNmabTJ6HxQZCQGi63oCh/FpkpN1LC0xOOKrUC5/Oi Zwhc8niqz+ZXl9vswSXTcDpnJA/EBxWQ9nok1Y+H3ZQRM1Qb7SoNoPj+qXikRF8wrFAX h8yydkpgrMwZX2z9PGSB3lJB82k6j3yUVCeOaSiX9Gm6iT2y9e2j4rsULOPSJshSaxq6 P0Mw== X-Gm-Message-State: AA6/9RngGdiucZK275Q45Hktzv1Rx3PQkCQbdjWdQV/eZO3twvuEC5K2YjPYuiHziEbC9A== X-Received: by 10.25.221.20 with SMTP id u20mr3915183lfg.1.1475670296445; Wed, 05 Oct 2016 05:24:56 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id 24sm1604228lfr.49.2016.10.05.05.24.55 (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Wed, 05 Oct 2016 05:24:55 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Tero Kivinen" , "Paul Wouters" References: <4413733F9BF24D94821C1814E88C3C26@buildpc><22515.45673.944549.840807@fireball.acr.fi><50ABC4C4-B5AD-4C92-87B6-D9E88E01146A@gmail.com> <22516.58815.577872.948004@fireball.acr.fi> Date: Wed, 5 Oct 2016 15:24:52 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Interoperability problem concerning RFC 7427 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 12:24:59 -0000 > Do you really think we will see this more in ECC? How will that happen > more in the ECC? > > If I have Ed25519 key, why would someone go against the "SHOULD NOT" > in draft-nir-ipsecme-eddsa draft and use something else than Ed25519, > i.e., why would someone use Ed25519ph, or why would someone use ECDSA > with Ed25519 key (even if it would be possible). Are people really > going to mix different ECC keys with different algorithms? I would > assume it would be better to just create separete keys for each > signature algorithm, and not use the same key. > > With RSA I can see the reason, as people do want to reuse the old > existing key they already have and want to use it with old RSA and > with RSASSA-PSS, but I have not yet seen reason for that in ECC. > > So can you explain why you think this will happen in the ECC? I didn't say it would happen. I said it could happen. The reasons can be various. For example, after wide adoption of EdDSA some vulnerability is found in the scheme and some modifications are introduced to eliminate it (analogously to appearance of RSASSA-PSS). Or more efficient signature algorithm for exactly the same elliptic curve is found. I don't know. If you asked me few years ago why would new RSA signature format ever appear, I wouldn't know what to answer and would probably agree with you that there were no reasons. But it happened. Regards, Valery. > -- > kivinen@iki.fi From nobody Wed Oct 5 06:15:29 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F291296EA for ; Wed, 5 Oct 2016 06:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ol4qmu-g3F0l for ; Wed, 5 Oct 2016 06:15:24 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0128.outbound.protection.outlook.com [23.103.200.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F05B31296F8 for ; Wed, 5 Oct 2016 06:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/oD4rVtVSDKNSlndLb7FDb0yKllWFMuLe6gAiv6lLwQ=; b=T+bDTYj5UjLUiNC4p1mffPl9GIAAtMUEzfunmxoXcvopah62dNaW/Itct5FJIn8C+3ciJwfC3G3Fk4PvqVXg1sO486ItCi1BJ0G31iET521LllgFMhmcOmXJEeriUQy1joaSxELaxS2Piw5XUowdu4l6To+g6xG9CW/esNw1LwQ= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1438.namprd09.prod.outlook.com (10.173.50.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.649.16; Wed, 5 Oct 2016 13:15:22 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0649.024; Wed, 5 Oct 2016 13:15:22 +0000 From: "Waltermire, David A. (Fed)" To: Valery Smyslov , Yoav Nir Thread-Topic: [IPsec] Interoperability problem concerning RFC 7427 Thread-Index: AQHSHwqHi+Q3vvu8x0Oh/jbsgYcP4A== Date: Wed, 5 Oct 2016 13:15:22 +0000 Message-ID: <2764F366BA6583BF5123555E9B757BD81B9AC369@unknown> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [108.18.200.221] x-ms-office365-filtering-correlation-id: 5891abda-3c13-42fe-35be-08d3ed21a9cc x-microsoft-exchange-diagnostics: 1; MWHPR09MB1438; 7:CXcpGN2zT2wpFAy5VlvydA94gpWHduT1/KvrTY0p+rE8Xy7lDwBUVfE4O60Bczx8Ykq6thtFQOfCY7Q60pzWt52O5EXRu10GnFk2++6JM+U9BjttfmXh3kNvFm43eWFTPlNTIRlzguUcai+YHQ2z7GW3FSkaauEbcOuE2R4HNU8+VPJ0Us0/OEg//UfC9INIY03afQi3coil5w3MK6otuuena0EH3M4IIvr+69/P/9nZNk05ZLqL2epuPYUtKfaadiltYn2c+0xO0ERN5xAJcstYvjaP4/zU69aCWP31IGAX1TJNWaWRwNaL+BkQHqiZpHmh/G01NIIsHlurt/mo7w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR09MB1438; x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:MWHPR09MB1438; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1438; x-forefront-prvs: 008663486A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(189002)(199003)(3280700002)(68736007)(87936001)(106356001)(106116001)(9686002)(99286002)(105586002)(19617315012)(2906002)(33656002)(8936002)(3660700001)(19625215002)(4326007)(16236675004)(10400500002)(5001770100001)(97736004)(189998001)(5660300001)(55846006)(66066001)(5002640100001)(11100500001)(586003)(101416001)(3846002)(102836003)(6116002)(33716001)(19580395003)(54356999)(19580405001)(50986999)(8676002)(81156014)(81166006)(2930100002)(7736002)(7846002)(2900100001)(2920100001)(2860100001)(7906003)(15975445007)(77096005)(122556002)(86362001)(92566002)(82676001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1438; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_2764F366BA6583BF5123555E9B757BD81B9AC369unknown_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2016 13:15:22.5736 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1438 Archived-At: Cc: IPsecME WG , "paul@nohats.ca" Subject: Re: [IPsec] Interoperability problem concerning RFC 7427 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 13:15:28 -0000 --_000_2764F366BA6583BF5123555E9B757BD81B9AC369unknown_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable That is fine. We can give 15 minutes on the agenda for this. Thanks, Dave On: 05 October 2016 03:27, "Valery Smyslov" wrote: Sure. I can prepare the slides (if the WG chairs don't mind). Regards, Valery. > Perhaps we (as in the working group) should schedule some time (15-20 min= utes?) to discuss the options in Seoul. > > Understanding both RFC 7427 and PSS signatures when they are in certifica= tes, but not PSS signatures when they are > in AUTH payloads is a pretty egregious kind of wrongness, but if this wro= ngness exists in the wild, we should probably > come up with a strategy on how to deal with it. > > Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_2764F366BA6583BF5123555E9B757BD81B9AC369unknown_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
That is fine. We can give 15 minutes on the age= nda for this.

Thanks,
Dave


On: 05 October 2016 03:27, "Valery Smyslov" <svanru@gmail.com&= gt; wrote:
Sure. I can prepare the slides (if the WG chairs d= on't mind).

Regards,
Valery.

> Perhaps we (as in the working group) should schedule some time (15-20 = minutes?) to discuss the options in Seoul.
>
> Understanding both RFC 7427 and PSS signatures when they are in certif= icates, but not PSS signatures when they are
> in AUTH payloads is a pretty egregious kind of wrongness, but if this = wrongness exists in the wild, we should probably
> come up with a strategy on how to deal with it.
>
> Yoav

_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec
--_000_2764F366BA6583BF5123555E9B757BD81B9AC369unknown_-- From nobody Wed Oct 5 06:38:42 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87707129710 for ; Wed, 5 Oct 2016 06:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFVbC3Vj26TZ for ; Wed, 5 Oct 2016 06:38:38 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 483E812970B for ; Wed, 5 Oct 2016 06:38:38 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u95DcXPU012845 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 5 Oct 2016 16:38:33 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u95DcXhw014535; Wed, 5 Oct 2016 16:38:33 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22517.601.610899.222221@fireball.acr.fi> Date: Wed, 5 Oct 2016 16:38:33 +0300 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: References: <4413733F9BF24D94821C1814E88C3C26@buildpc> <22515.45673.944549.840807@fireball.acr.fi> <50ABC4C4-B5AD-4C92-87B6-D9E88E01146A@gmail.com> <22516.58815.577872.948004@fireball.acr.fi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 26 min X-Total-Time: 28 min Archived-At: Cc: IPsecME WG , Paul Wouters Subject: Re: [IPsec] Interoperability problem concerning RFC 7427 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 13:38:41 -0000 Valery Smyslov writes: > The reasons can be various. For example, after wide adoption > of EdDSA some vulnerability is found in the scheme and some > modifications are introduced to eliminate it (analogously to If there would be vulnerability in the signature scheme, I think we would say you MUST NOT use the old format and you MUST use the new format... > appearance of RSASSA-PSS). Or more efficient signature > algorithm for exactly the same elliptic curve is found. If more efficient signature algorithm is found, I would still recommend using different keys for different methods. > I don't know. If you asked me few years ago why would new > RSA signature format ever appear, I wouldn't know what to > answer and would probably agree with you that there were no reasons. > But it happened. RSASSA-PSS was specified in 2003, in the RFC3447, which then obsoleted the RFC2437, which then obsoleted the RFC2313. Both RFC2437 and RFCC2313 were from 1998. On the other hand the RSASSA-PSS and RSASSA-PKCS1-v1_5 both are still defined in the RFC3447, but RSASSA-PKCS1-v1_5 was there for gradual transition to the RSASSA-PSS: Although no attacks are known against RSASSA-PKCS1-v1_5, in the interest of increased robustness, RSASSA-PSS is recommended for eventual adoption in new applications. RSASSA-PKCS1-v1_5 is included for compatibility with existing applications, and while still appropriate for new applications, a gradual transition to RSASSA-PSS is encouraged. It also says: A generally good cryptographic practice is to employ a given RSA key pair in only one scheme. This avoids the risk that vulnerability in one scheme may compromise the security of the other, and may be essential to maintain provable security. ... As another example, suppose an RSA key pair is employed in both RSASSA-PSS (Section 8.1) and RSASSA-PKCS1-v1_5. Then the security proof for RSASSA-PSS would no longer be sufficient since the proof does not account for the possibility that signatures might be generated with a second scheme. Similar considerations may apply if an RSA key pair is employed in one of the schemes defined here and in a variant defined elsewhere. I.e., it does recommend that one key pair is used with only one scheme. So reading the RFC3447 you should not use same RSA key with both RSASSA-PKCS1-v1_5 and RSASSA-PSS. So you are supposed to have two key pairs one for each scheme, and then you need to pick one based on other things, like the certificate request, ID payloads (== configuration), or use the same key pair type than other end used. RSASSA-PSS also appeared more than ten years ago, so it is not new, and we have supposedly being doing transition to it for long time... Note, that there is no way of knowing whether your certificate using RSASSA-PSS is going to be acceptable for the other end. If it only supports RSASSA-PKCS1-v1_5 signature method in certificates, you are in same problem, and you have to somehow know that and use the certificate using RSASSA-PKCS1-v1_5 signature method. So in the initiator: do not configure RSASSA-PSS key pair before you know that the responder can accept such key pair. In responder: pick the key pair you are using based on the auth payload the other end sent, or if other end did not use signatures to authenticate, then select key based on the IDr or certificate request. Or just add manual configuration based on the vendor ids to pick RSASSA-PKCS1-v1_5 if you know that implementation do not support RSASSA-PSS. -- kivinen@iki.fi From nobody Wed Oct 5 07:10:25 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34AAE129735 for ; Wed, 5 Oct 2016 07:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.235 X-Spam-Level: * X-Spam-Status: No, score=1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.496, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjy6EOY1ITOH for ; Wed, 5 Oct 2016 07:10:21 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A3B112972C for ; Wed, 5 Oct 2016 07:10:21 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id b81so93897079lfe.1 for ; Wed, 05 Oct 2016 07:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-transfer-encoding; bh=KVlKY43K4hUp1hZIUcnqQnO7RDMHk0CDyjmgCIwz7bA=; b=f/Mvol1+CFsQ0p+S9yhXCLTHLBDe6TA9bqM8hoqGn6jp5u6nBnrTF+yv++Yq1Mi7dQ KBGklGMNMf0aJ9Q5UWQ+Tpegv/qdcJG/xz9TX4bz6+5cPtUkFS/WrFiv1FWGiSyezIoZ ukSIxsukXugDSnv/mUaSS941Jx2LPaFMzJRXKzekiWofS/9q2caSXh7zZ1wdlFLzzHd3 k2F2u0xVynfAaQDMLSDniS3eBRlfGQJI3RDoV4XTlfljFBPYhAtPuVZnxmaePIm0IUTZ dgEYbw3CKNyBlIQwpRbLD+VtWf0jtAz6Bhox3OWEEnLdILcSeAJyUyJQ2kJ/QF6E9AG0 tvig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=KVlKY43K4hUp1hZIUcnqQnO7RDMHk0CDyjmgCIwz7bA=; b=LFHKrCqCO0I002Yftx0zVfv1oCZ5/CTIGKj1sHEDANKVHfg1HDnQ4UDDiQRGsXyHiI Fgxc3GTWizoVcgAaBoJupT2I7JqsgTwJpQ1ozq2lEu6pSX8WpfBACgxA/ANtD81UD5jE IDBcM+smjEchOMHdyARb1WOhB0I1J0ufwDalZpRcsMPXFcDYb40rJyrl/P5grYCQIom3 QN6KBhBmAsdUcoZsaL8h1CkzTPCPrc9/p2zM66vD2MKWXYiZjwAIU+Zk3aCznVM2LYF+ 7cRuZGvwMMtMFSJeT6BNujBlqkXASqT9vwC/jvYFOg7XhE6SG+aHh5NT/lspmkkG1LqT Elrw== X-Gm-Message-State: AA6/9RmnlVSp8PWromVc+sz0cXrzkFMpLD4Q0AORu2gm2k9IVTtYLi79SYIhH6N/iL2CYw== X-Received: by 10.25.65.204 with SMTP id o195mr3661096lfa.176.1475676619042; Wed, 05 Oct 2016 07:10:19 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id g5sm1678677lfe.14.2016.10.05.07.10.18 (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Wed, 05 Oct 2016 07:10:18 -0700 (PDT) Message-ID: <5CBE8ADBA61A43CF90013971F89FE3B0@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" References: <4413733F9BF24D94821C1814E88C3C26@buildpc><22515.45673.944549.840807@fireball.acr.fi><50ABC4C4-B5AD-4C92-87B6-D9E88E01146A@gmail.com><22516.58815.577872.948004@fireball.acr.fi> <22517.601.610899.222221@fireball.acr.fi> Date: Wed, 5 Oct 2016 17:10:15 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: IPsecME WG , Paul Wouters Subject: Re: [IPsec] Interoperability problem concerning RFC 7427 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 14:10:25 -0000 >> The reasons can be various. For example, after wide adoption >> of EdDSA some vulnerability is found in the scheme and some >> modifications are introduced to eliminate it (analogously to > > If there would be vulnerability in the signature scheme, I think we > would say you MUST NOT use the old format and you MUST use the new > format... That won't happen overnight anyway regardless how many MUST and MUST NOT we say. So the schemes will co-exist some time. >> appearance of RSASSA-PSS). Or more efficient signature >> algorithm for exactly the same elliptic curve is found. > > If more efficient signature algorithm is found, I would still > recommend using different keys for different methods. [snip] > So reading the RFC3447 you should not use same RSA key with both > RSASSA-PKCS1-v1_5 and RSASSA-PSS. So you are supposed to have two key > pairs one for each scheme, and then you need to pick one based on > other things, like the certificate request, ID payloads (== > configuration), or use the same key pair type than other end used. How would you do it in practice? Are you suggesting to include the intended purpose into the DN? Otherwise, even if you get two certificates from single CA - one for RSASSA-PKCS1-v1_5 and the other for RSASSA-PSS, you cannot distinguish which to use based on certificate request (will be the same) or ID payload (will be the same). Using the same key pair type works only for Responder. The only workable option for Initiator - preconfiguration, which doesn't scale. > Note, that there is no way of knowing whether your certificate using > RSASSA-PSS is going to be acceptable for the other end. If it only > supports RSASSA-PKCS1-v1_5 signature method in certificates, you are > in same problem, and you have to somehow know that and use the > certificate using RSASSA-PKCS1-v1_5 signature method. True. If we have something like SUPPORTED_SIGNATURE_FORMATS notification that this problem will also be solved - the end entity will indicate that it supports, say, RSASSA-PSS for both IKEv2 and certificates. > So in the initiator: do not configure RSASSA-PSS key pair before you > know that the responder can accept such key pair. It works. But this approach will significantly slow down adoption of more secure RSASSA-PSS scheme, since RSASSA-PKCS-1.5 will be configured "by default" by most users. > In responder: pick the key pair you are using based on the auth > payload the other end sent, or if other end did not use signatures to > authenticate, then select key based on the IDr or certificate request. > Or just add manual configuration based on the vendor ids to pick > RSASSA-PKCS1-v1_5 if you know that implementation do not support > RSASSA-PSS. As I've already said, I can live with "do nothing" approach you describe. >From my point of view it is a bit more complex for implementers, documentation (a lot of heuristics in implementations) and for configuration. User experience will probably suffer too. Otherwise it is a valid approach and I'm not against it. I just wonder if we (the WG) can invent something better. Regards, Valery. > -- > kivinen@iki.fi From nobody Thu Oct 6 06:44:07 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7BF0129653; Thu, 6 Oct 2016 06:44:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147576144472.16176.3839846260008454645.idtracker@ietfa.amsl.com> Date: Thu, 06 Oct 2016 06:44:04 -0700 Archived-At: Subject: [IPsec] The IPSECME WG has placed draft-nir-ipsecme-eddsa in state "Call For Adoption By WG Issued" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 13:44:04 -0000 The IPSECME WG has placed draft-nir-ipsecme-eddsa in state Call For Adoption By WG Issued (entered by Tero Kivinen) The document is available at https://datatracker.ietf.org/doc/draft-nir-ipsecme-eddsa/ From nobody Thu Oct 6 06:47:39 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D81B12965A for ; Thu, 6 Oct 2016 06:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyYFmiKpQhX1 for ; Thu, 6 Oct 2016 06:47:35 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C66A1295C9 for ; Thu, 6 Oct 2016 06:47:34 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u96DlVEJ008472 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 6 Oct 2016 16:47:31 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u96DlVD2002396; Thu, 6 Oct 2016 16:47:31 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22518.22003.429434.968431@fireball.acr.fi> Date: Thu, 6 Oct 2016 16:47:31 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 3 min Archived-At: Subject: [IPsec] Call for adoptation of draft-nir-ipsecme-eddsa-01 as an IPsecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 13:47:37 -0000 I think this document is still waiting for curdle to finalize the OIDs, but otherwise I think it is in good shape, so we should adopt this document for WG document now, so we can go forward when curdle gets its document ready. So this is 2 week call for adoptation of the https://datatracker.ietf.org/doc/draft-nir-ipsecme-eddsa/ as an IPsecME WG document. By adopting this draft, the WG is agreeing to take this on as an official WG item to continue work on the draft. Please reply to this message with any comments supporting or concerns against adopting this draft. This call will run until Thursday, October 20th, 2016 UTC 23:59. -- kivinen@iki.fi From nobody Thu Oct 6 06:50:16 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59975129675 for ; Thu, 6 Oct 2016 06:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id at7fcIyXznSl for ; Thu, 6 Oct 2016 06:50:10 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6829812965B for ; Thu, 6 Oct 2016 06:50:10 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u96Do7pc019594 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Oct 2016 16:50:07 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u96Do7if021753; Thu, 6 Oct 2016 16:50:07 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22518.22159.163293.270498@fireball.acr.fi> Date: Thu, 6 Oct 2016 16:50:07 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: Cc: Kathleen Moriarty Subject: [IPsec] IPsecME status update 2016-10-06 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 13:50:14 -0000 Charter update Charter update was approved 2016-09-16. Document Status: - draft-ietf-ipsecme-ddos-protection (David) Document was approved on 2016-09-29 IESG telechat. IESG comments for document should be done and document was updated and it is now waiting for AD followup. - draft-ietf-ipsecme-rfc4307bis (David) WGLC period done, resulted some changes, should be ready to go forward. - draft-mglt-ipsecme-rfc7321bis (David) Adoptation call started 2016-09-03, there have not been any objections for adoptation. Should be ready for adoptation for WG document, and for WGLC. - draft-ietf-ipsecme-safecurves (Tero) On agenda of 2016-10-13 IESG telecat. Requested for publication as a Proposed Standard. - draft-nir-ipsecme-eddsa (Tero) I think this is still waiting for the curdle to decide for OID. Started 2 week WG Adoptation call on 2016-10-06. - draft-ietf-ipsecme-tcp-encaps (Tero) This should also be ready for WGLC, waiting for Tero to review. New work: - Quantum Resistance (David) Discussion has started on the mailing list about the requirements and when we have those decided on the list, we should start working on document. - draft-pauly-ipsecme-split-dns (David) This was accepted as charter item, but need few more reviews before taking it as WG draft. - draft-mglt-ipsecme-implicit-iv (Tero) This was also accepted as charter item, but would like to see few more reviews before taking it as WG draft. -- kivinen@iki.fi From nobody Thu Oct 6 07:07:27 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED8B129684 for ; Thu, 6 Oct 2016 07:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0Ma8kqqRJL1 for ; Thu, 6 Oct 2016 07:07:24 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0096.outbound.protection.outlook.com [23.103.200.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 364CF129696 for ; Thu, 6 Oct 2016 07:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=a/SL69zYpoo2u83DD0pPe8t0iHMfVJAxh9NIkDORJDE=; b=1akzYMWhs/hUn+bM1ROgq9Ul182903Yj3x8/Tya4V44vFhIvcd42jowhExfDj8TKoVkOHRCF2VYEE+1ymFpNCfbl2afyLwwLL81AhcgjHyEXiK9D01eeFA1IHiRNWRLdw7SxQCLDFbZKR3dFioHqWACcb+uWN0g1b5YPbYCpJ08= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1438.namprd09.prod.outlook.com (10.173.50.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Thu, 6 Oct 2016 14:06:54 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0649.024; Thu, 6 Oct 2016 14:06:54 +0000 From: "Waltermire, David A. (Fed)" To: IPsecME WG Thread-Topic: Call for adoption of draft-mglt-ipsecme-rfc7321bis as an IPSecME WG document Thread-Index: AdIFiu5YSsRPKyt0RkS9hutYx8w6egaT34cQ Date: Thu, 6 Oct 2016 14:06:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-office365-filtering-correlation-id: 88759ebc-62b1-45d8-bf46-08d3edf206f9 x-microsoft-exchange-diagnostics: 1; MWHPR09MB1438; 6:V2FJ5GAMrm4rdQdkmjHwHbiLpqyY18fpjGfg/H4R5wGKbHPTdUCrQWRCZi7T7Pow8Q24+DWYw3ZDblGrmQLnqUXIkfSwqwN4kvHLQFDy1L44fMG6k6Xmn8eUwUG+2aQBzdf6E4R6+Oo1Bh4G2bBApYTgdTwpxJCHpdpO8Hwk3k68opxhkWHYEE+A2wac+PLSSdFHblW51PfDooGU3/LE7QakxR+Xrjjo6YgibbZ++EVLwoBorRl10yDcsJ2pcThlEtQVyfUk3A+rqKvgUdyS+FClBYBv54+Ba1hPMVp+9ccF4b7JJ/g0I+itTPJQ0P163HPGE6jjUZZcyJuas/0dPQ==; 5:5s5MRm6GGX+P3OOUH1JIRrmRAAsjEI8E3XHXpnGt0oPsCNQqrRVsOEj1FaycUyrRqdjZbIYQUU0pECifl2TXrumtNtDCA1guY/RHr62HXNuOpjHrClli0sDthiiAwVvxUKbE5kUUTOJO+VajrF7bzg==; 24:wv5dbtAY14zcj8d5zha9CO7ZhrAzym29RD43WQQ+3IrMZFzIJJ8icO6Tw3P3XpqJXzTQ3U2q/L9KWvlEt2c19aCwsKtTAlcxiXwhZ619k/8=; 7:tRWKoeCgzcJeUS2aIMgUttf3tVHSHhdCYPQfNF7Aitg5BRpg0oimrk+F4NQ0kAFPeFoVYczcp2HmXPHnQEdilEfoz64+UtUOVSm7Cc+B0OqbrWj2qMq3MDto0gIXiG5DMSoMwLOVc1k+MpLuaSKmHwhD+nVzbsJXYzVenkAoPIRC+YY7MYeHAFWl7m7ViBNoZIx60tSqTU2oI4EFs/3B4WTZUPD8qRLIvMaladExxl5z5ZsQ8z902TvlbatNZqtc1hy5rPq7jMLgCbCvI5LrmifQdlfpgmwglrAHU6WY31slK6AS850rawAbtkmo6awC x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR09MB1438; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:MWHPR09MB1438; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1438; x-forefront-prvs: 00872B689F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(189002)(199003)(377454003)(92566002)(76576001)(450100001)(2900100001)(15975445007)(77096005)(230783001)(2906002)(107886002)(54356999)(50986999)(189998001)(3900700001)(3660700001)(3280700002)(97736004)(586003)(3846002)(6116002)(102836003)(101416001)(122556002)(33656002)(8936002)(11100500001)(66066001)(105586002)(81156014)(81166006)(8676002)(305945005)(7736002)(74316002)(7846002)(19580395003)(68736007)(99286002)(9686002)(86362001)(19580405001)(106356001)(6916009)(110136003)(87936001)(5660300001)(10400500002)(5002640100001)(7696004); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1438; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2016 14:06:54.3400 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1438 Archived-At: Subject: Re: [IPsec] Call for adoption of draft-mglt-ipsecme-rfc7321bis as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 14:07:26 -0000 Since there were no concerns raised about adopting this draft, this draft h= as been adopted as an IPSecME working group draft. Authors, please post the= next version as draft-ietf-ipsecme-rfc7321bis-00. Thanks, Dave and Tero > -----Original Message----- > From: Waltermire, David A. (Fed) > Sent: Friday, September 02, 2016 10:33 PM > To: IPsecME WG > Subject: Call for adoption of draft-mglt-ipsecme-rfc7321bis as an IPSecME > WG document >=20 > This is the call for adoption of https://datatracker.ietf.org/doc/draft-m= glt- > ipsecme-rfc7321bis/ as an IPSecME working group (WG) document. >=20 > By adopting this draft, the WG is agreeing to take this on as an official= WG > item to continue work on the draft. Please reply to this message with any > comments supporting or concerns against adopting this draft. This call wi= ll run > until Wednesday, September 14th, 2016 UTC 23:59. >=20 > Thanks, > Dave and Tero From nobody Thu Oct 6 09:20:44 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0EC129555 for ; Thu, 6 Oct 2016 09:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.996 X-Spam-Level: X-Spam-Status: No, score=-4.996 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=-2.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MD0PNML3L15N for ; Thu, 6 Oct 2016 09:20:40 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 336F512959D for ; Thu, 6 Oct 2016 09:20:37 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3sqdDJ5plyz3lY; Thu, 6 Oct 2016 18:20:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1475770832; bh=L5q4ZNhEvwPGwqoRu8hL7aUa7buO0LEIcrOPaGhGqgM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=DoxRJxHC2DeOYz/BbNpAcH+oahcfoTn3XLIfli2cu1CJLelOEwSgs5TLWlwOnTbiP TQaNthUatYa+Y4HrkUYa6DgcZ8/SVl21uzQm7YspBfqkpwfkQWD+yWhszWmiv5lzTW yxuBWn1YNfQVk7qog1ijG6Q4K8Qe1t+y2eoMfBZI= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id zJbNThed03P0; Thu, 6 Oct 2016 18:20:31 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 6 Oct 2016 18:20:31 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 3244C5C83A; Thu, 6 Oct 2016 12:20:28 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 3244C5C83A Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1959B40D3584; Thu, 6 Oct 2016 12:20:28 -0400 (EDT) Date: Thu, 6 Oct 2016 12:20:27 -0400 (EDT) From: Paul Wouters To: "Waltermire, David A. (Fed)" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Call for adoption of draft-mglt-ipsecme-rfc7321bis as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 16:20:43 -0000 On Thu, 6 Oct 2016, Waltermire, David A. (Fed) wrote: > Since there were no concerns raised about adopting this draft, this draft has been adopted as an IPSecME working group draft. Authors, please post the next version as draft-ietf-ipsecme-rfc7321bis-00. Done, Paul From nobody Thu Oct 6 14:49:23 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FAD1297BE; Thu, 6 Oct 2016 14:49:18 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147579055851.23797.1876225249656053845.idtracker@ietfa.amsl.com> Date: Thu, 06 Oct 2016 14:49:18 -0700 Archived-At: Cc: ipsecme-chairs@ietf.org, draft-ietf-ipsecme-ddos-protection@ietf.org, ipsec@ietf.org, Kathleen.Moriarty.ietf@gmail.com, The IESG , rfc-editor@rfc-editor.org, David Waltermire Subject: [IPsec] Protocol Action: 'Protecting Internet Key Exchange Protocol version 2 (IKEv2) Implementations from Distributed Denial of Service Attacks' to Proposed Standard (draft-ietf-ipsecme-ddos-protection-10.txt) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2016 21:49:18 -0000 The IESG has approved the following document: - 'Protecting Internet Key Exchange Protocol version 2 (IKEv2) Implementations from Distributed Denial of Service Attacks' (draft-ietf-ipsecme-ddos-protection-10.txt) as Proposed Standard This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/ Technical Summary This document is a standards track submission that recommends implementation and configuration best practices for Internet Key Exchange Protocol version 2 (IKEv2) Responders, to allow them to resist Denial of Service and Distributed Denial of Service attacks. Additionally, the document introduces a new mechanism called "Client Puzzles" that help accomplish this task. Working Group Summary The document was reviewed by several regular WG participants. Changes suggested by the chairs and participants resulted in a good deal of discussion and revisions to improve the document. The submitted draft represents solid WG consensus. Document Quality No implementations are currently known, but multiple WG members have expressed an interest in implementing the guidance in this document. Personnel Kathleen Moriarty is the responsible Area Director. Dave Waltermire is the document shepherd. IANA Note This document adds a new entry to the 'IKEv2 Payload Types' registry. From nobody Fri Oct 7 08:24:41 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A0A12966D for ; Fri, 7 Oct 2016 08:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.457 X-Spam-Level: X-Spam-Status: No, score=-4.457 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pI3L8Dei4Boh for ; Fri, 7 Oct 2016 08:24:38 -0700 (PDT) Received: from fish.elvis.ru (fish.elvis.ru [82.138.51.18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DE10129426 for ; Fri, 7 Oct 2016 08:24:38 -0700 (PDT) Received: from [10.111.1.40] (helo=robin.office.elvis.ru) by fish.elvis.ru with esmtp (Exim 4.76) (envelope-from ) id 1bsX0S-0000bO-BQ for ipsec@ietf.org; Fri, 07 Oct 2016 18:24:16 +0300 Received: from buildpc (10.111.10.31) by robin.office.elvis.ru (10.111.1.40) with Microsoft SMTP Server id 14.3.319.2; Fri, 7 Oct 2016 18:20:47 +0300 Message-ID: <3AB53A639BCA4863AE9A9CE129360489@buildpc> From: Valery Smyslov To: IPsecME WG Date: Fri, 7 Oct 2016 18:24:14 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Subject: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-compact-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 15:24:41 -0000 Hi all, I've prepared a draft describing an alternate compact format for IKEv2 payloads. Compact format will allow to reduce IKEv2 messages size, that is important for IoT devices. It also decreases the chances that initial IKEv2 messages are fragmented by IP level. Reviews and comments are very welcome. Regards, Valery. ----- Original Message ----- From: To: "Valery Smyslov" Sent: Friday, October 07, 2016 6:18 PM Subject: New Version Notification for draft-smyslov-ipsecme-ikev2-compact-00.txt > > A new version of I-D, draft-smyslov-ipsecme-ikev2-compact-00.txt > has been successfully submitted by Valery Smyslov and posted to the > IETF repository. > > Name: draft-smyslov-ipsecme-ikev2-compact > Revision: 00 > Title: Compact Format of IKEv2 Payloads > Document date: 2016-10-07 > Group: Individual Submission > Pages: 24 > URL: https://www.ietf.org/internet-drafts/draft-smyslov-ipsecme-ikev2-compact-00.txt > Status: https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-compact/ > Htmlized: https://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-compact-00 > > > Abstract: > This document describes a method for reducing the size of the > Internet Key Exchange version 2 (IKEv2) messages by using an > alternate format for IKE payloads. Standard format of many IKE > payloads contains a lot of redundancy. This document takes advantage > of this fact and specifies a way to eliminate some redundancy by > using more dense encoding. Reducing size of IKEv2 messages is > desirable for low power consumption battery powered devices. It also > helps to avoid IP fragmentation of IKEv2 messages. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > From nobody Fri Oct 7 08:26:40 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8163A12966D for ; Fri, 7 Oct 2016 08:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.796 X-Spam-Level: X-Spam-Status: No, score=0.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.496, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLLJuComjWIm for ; Fri, 7 Oct 2016 08:26:37 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7871A12962F for ; Fri, 7 Oct 2016 08:26:37 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id b75so43905336lfg.3 for ; Fri, 07 Oct 2016 08:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:subject:date:mime-version :content-transfer-encoding; bh=Bh1YCbzLf2zTska2hfaUKXbwNWXSvxn9LiqpW+qPixk=; b=EMiUYjsweipQ156QqKXjg2REuLI0TI4rH7OSoyNHEoLDQCgIRX+8YtXLzU26UqZKSW 88XLSYdkMQgS1MGX2HsFF8prWDkqfRZkXc0m2xlHMeITY16G1EGOcSTkbGu8zywDKDgT JqDPZ/y4ooucBymkN9vX+TUpAeMG17FWmGdrE4ZfLEvwfjZFwktijoSjQXuhcgfTnxld z3BAMesgujopt15m2I5Dm1WDDlBrYrLsUSv2mOYCAEOqKUElAerB+9NXjElGYtIYjr3S DShU1y1cnpiiVeCM8Ncr6KD9qmwCd5ZUQMS7oiNe9S98hbrg6t1y1oFAoyceD5x7/rqM Nz/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:subject:date:mime-version :content-transfer-encoding; bh=Bh1YCbzLf2zTska2hfaUKXbwNWXSvxn9LiqpW+qPixk=; b=J7w8HOP+ge3/p0FtEB4E2GlnBVajwkUnG+wo5RPB0XUPka7GqLNuVXgbZ5AUdDF87N 06t4LHAnSWmejPBXsrLAKXqRFDQF3381Kv8hQeqd83Fr+jCYsKbl8BaGc+DUyMFfW2YB sERRG1RhUbmkMIVsXIoAeqgQDm+uSGgpS9/Q0+V6FP0QA+jKm188oTqexziK17zjdVyv wR+JiLF4mK/Iok0hNh0SQ/wMsG8YcM8EKFUqlvzqHKyZQc9g8gEOFOAUxnWOFpSVkVyU h2bxO+kA0rut2CVsyak37NG8qCGJpaOnOz+hEtX24WCa/0wGD8HkAgAuXwictwtrc3U8 r/og== X-Gm-Message-State: AA6/9RmAgKibnjotCkPJwBLml/4yLJDFgabiCUnVQH7PxhAjpIO0em/xbZjl+lS5AHaCQQ== X-Received: by 10.25.0.131 with SMTP id 125mr8996111lfa.149.1475853995330; Fri, 07 Oct 2016 08:26:35 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id h68sm3646081lji.20.2016.10.07.08.26.34 for (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Fri, 07 Oct 2016 08:26:34 -0700 (PDT) Message-ID: <03EDC1D98CFE4DC2AFA2339856424818@buildpc> From: "Valery Smyslov" To: "IPsecME WG" Date: Fri, 7 Oct 2016 18:26:32 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Subject: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-compact-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 15:26:39 -0000 Hi all, I've prepared a draft describing an alternate compact format for IKEv2 payloads. Compact format will allow to reduce IKEv2 messages size, that is important for IoT devices. It also decreases the chances that initial IKEv2 messages are fragmented by IP level. Reviews and comments are very welcome. Regards, Valery. > A new version of I-D, draft-smyslov-ipsecme-ikev2-compact-00.txt > has been successfully submitted by Valery Smyslov and posted to the > IETF repository. > > Name: draft-smyslov-ipsecme-ikev2-compact > Revision: 00 > Title: Compact Format of IKEv2 Payloads > Document date: 2016-10-07 > Group: Individual Submission > Pages: 24 > URL: https://www.ietf.org/internet-drafts/draft-smyslov-ipsecme-ikev2-compact-00.txt > Status: https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-compact/ > Htmlized: https://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-compact-00 > > > Abstract: > This document describes a method for reducing the size of the > Internet Key Exchange version 2 (IKEv2) messages by using an > alternate format for IKE payloads. Standard format of many IKE > payloads contains a lot of redundancy. This document takes advantage > of this fact and specifies a way to eliminate some redundancy by > using more dense encoding. Reducing size of IKEv2 messages is > desirable for low power consumption battery powered devices. It also > helps to avoid IP fragmentation of IKEv2 messages. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat From nobody Fri Oct 7 10:32:07 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38209129598; Fri, 7 Oct 2016 10:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gy7LXhhhkixg; Fri, 7 Oct 2016 10:32:04 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7812D129493; Fri, 7 Oct 2016 10:32:04 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id 192so51138607vkl.2; Fri, 07 Oct 2016 10:32: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:from:date:message-id:subject:to :cc; bh=AMYgJAayuE18cY7zainy5+KqG4RfT3FZFtYFAHdq1BA=; b=wrUo2ws31T4ILgqXAWTuCxpPH+uhHBguCdCtDMjrB/cZL9g+rQvJO6oatO4BSfviPJ tqD3X9SYwVkqcgQz++zbw8QrgMGeCRdoMaAZTmTwtQ/0+h1a973XI7u+sJSANN9dbey1 cSN5kMmhqwTS/3kPb7hIj9EVQn1WEtOphk4t8pN9uSMkI/FtGeDs2luGaCJoX3AOOEEq 7g9jfECymhuCqZFFG59CUXISsL5Z1svPqHSEtQxZ0Mqipf4s/YDnjzEWjFAjUYKlkdZf /pmWXcA8v6Hcp14iy93E0oSmdeI4CCSRP2oYgJuJcbHC+ihUVz3pXRmG6WyTr9XUNtj0 2uKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AMYgJAayuE18cY7zainy5+KqG4RfT3FZFtYFAHdq1BA=; b=CyjpbYzCJNTHJHsWDfAFvhOWsXlDQcfUtWAG07HIIn0RHULNDB+QQ49FaX8N9iyaVI Uk4PSSB9hUYrKfdIqP5mZtr0eZxpZy4whUmGtCIXu+4i8OnPodlWCKxZG0AyGMFxPstF E+cM1T+yqCDDafB4utdLOoAl8mCP23MjoLWl0wZ9OCXEs4yF8jZYb2SscHim3NFATl6b bl6+/A3ip1cwwAqt+nyPcg4bBGfQPY6oMj/ENVMYb1VuQjNcVLMXMwVgJ8kjgOt6PkJV vbBVYnsYOZq+6pWxPNddpg7/228o4Ff796XEAzK2FzG04jvvJ4UcieFWbGS4SPU4Jr57 /K5w== X-Gm-Message-State: AA6/9Rlr24Jrpa7zzExYUFo7TDCyinl6lUIw5KzBabQZwWTLE/YIi3ykF8wN94euGfWZuLBr2mpafrIWdvkrwA== X-Received: by 10.31.168.145 with SMTP id r139mr15653115vke.124.1475861523633; Fri, 07 Oct 2016 10:32:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.68 with HTTP; Fri, 7 Oct 2016 10:32:03 -0700 (PDT) In-Reply-To: References: From: Kathleen Moriarty Date: Fri, 7 Oct 2016 13:32:03 -0400 Message-ID: To: Orit Levin , "ipsec@ietf.org" Content-Type: multipart/alternative; boundary=001a11415e88da9e86053e49c967 Archived-At: Cc: General Area Review Team , "draft-ietf-ipsecme-safecurves.all@ietf.org" Subject: Re: [IPsec] Gen-ART Last Call review of draft-ietf-ipsecme-safecurves-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 17:32:06 -0000 --001a11415e88da9e86053e49c967 Content-Type: text/plain; charset=UTF-8 Orit, Thanks for the review, making sure the editor see this. Kathleen On Tue, Sep 27, 2016 at 5:30 PM, Orit Levin wrote: > I am the assigned Gen-ART reviewer for this draft. The General Area Review > Team (Gen-ART) reviews all IETF documents being processed by the IESG for > the IETF Chair. Please treat these comments just like any other last call > comments. > > For more information, please see the FAQ at area/gen/trac/wiki/GenArtfaq>. > > Document: review of draft-ietf-ipsecme-safecurves-04 > Reviewer: Orit Levin (mailto:oritl@microsoft.com) > Review Date: 2016-09-27 > IETF LC End Date: 2016-09-29 > IESG Telechat date: unknown > > Summary: > This draft is basically ready for publication, but has nits that should be > fixed before publication. The nits are purely editorial, but fixing them > will improve the document's readability. > > 1. Introduction > Par.1 "key agreement (Diffie-Hellman)" : Replace with "key agreement using > Diffie-Hellman". > Par.2 "That document": Replace with the name of the document to make clear > which one is "that" document. > Par.2 "free from": Replace with "resilient to". > > 2. Curve25519 and Curve448 > Add at the start "Implementations of Curve25519 and Curve448 MUST/SHALL > follow the steps described in this section." > Par.1 Replace "are inherited from" with "are compliant with". > Par.2 Replace "goes as" with "is performed as" > > 3. Use and Negotiation in IKEv2 > Consider replacing TBA1/TBA2 throughout the section with [to be replaced > with TBA1/TBA2 according to the IANA assignment]. > 3.2 Consider replace the first sentence with > "Receiving and handling of incompatible point formats MUST comply with [or > MUST follow] considerations/procedures described in section 5 of [RFC7748]." > > 4. Security Considerations > Par.1 Replace the paragraph text to > "For high-performance constant-time implementations, it is RECOMMENDED to > use Curve25519 and Curve448 which were designed for this purpose. > Implementers MUST/SHOULD NOT attempt to improve performance by reusing > supposedly ephemeral key pair across multiple key exchanges [because ...]." > Par.3 In " ... the process used to pick these curves..." replace "these" > with the names to avoid confusion. > Par.3 Replace " ...verification has been done..." with "verification can > be done". > Par.4 Replace ",generated in a fully verifiable way," with "that are > generated in a fully verifiable way". > > 6. Acknowledgements > Par1. Replace "is by Mike" with "were defined/specified/etc. by Mike". > Par1. Replace "are in RFC 7748" with " are documented/specified/etc. in > RFC 7748". > > Thank you, > Orit. > > > > -- Best regards, Kathleen --001a11415e88da9e86053e49c967 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Orit,

Thanks for the review, making sur= e the editor see this.

Kathleen

On Tue, Sep 27, 2016 at = 5:30 PM, Orit Levin <oritl@microsoft.com> wrote:
I am the assigned Gen-ART reviewer for this draft.= The General Area Review Team (Gen-ART) reviews all IETF documents being pr= ocessed by the IESG for the IETF Chair.=C2=A0 Please treat these comments j= ust like any other last call comments.

For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Document: review of draft-ietf-ipsecme-safecurves-04
Reviewer: Orit Levin (mailto:oritl@m= icrosoft.com)
Review Date: 2016-09-27
IETF LC End Date: 2016-09-29
IESG Telechat date: unknown

Summary:
This draft is basically ready for publication, but has nits that should be = fixed before publication. The nits are purely editorial, but fixing them wi= ll improve the document's readability.

1. Introduction
Par.1 "key agreement (Diffie-Hellman)" : Replace with "key a= greement using Diffie-Hellman".
Par.2 "That document": Replace with the name of the document to m= ake clear which one is "that" document.
Par.2 "free from": Replace with "resilient to".

2. Curve25519 and Curve448
Add at the start "Implementations of Curve25519 and Curve448 MUST/SHAL= L follow the steps described in this section."
Par.1 Replace "are inherited from" with "are compliant with&= quot;.
Par.2 Replace "goes as" with "is performed as"

3. Use and Negotiation in IKEv2
Consider replacing TBA1/TBA2 throughout the section with [to be replaced wi= th TBA1/TBA2 according to the IANA assignment].
3.2 Consider replace the first sentence with
"Receiving and handling of incompatible point formats MUST comply with= [or MUST follow] considerations/procedures described in section 5 of [RFC7= 748]."

4. Security Considerations
Par.1 Replace the paragraph text to
"For high-performance constant-time implementations, it is RECOMMENDED= to use Curve25519 and Curve448 which were designed for this purpose. Imple= menters MUST/SHOULD NOT attempt to improve performance by reusing supposedl= y ephemeral key pair across multiple key exchanges [because ...]."
Par.3 In " ... the process used to pick these curves..." replace = "these" with the names to avoid confusion.
Par.3 Replace " ...verification has been done..." with "veri= fication can be done".
Par.4 Replace ",generated in a fully verifiable way," with "= that are generated in a fully verifiable way".

6. Acknowledgements
Par1. Replace "is by Mike" with "were defined/specified/etc.= by Mike".
Par1. Replace "are in RFC 7748" with " are documented/specif= ied/etc. in RFC 7748".

Thank you,
Orit.






--
Best regards,
Kathleen
--001a11415e88da9e86053e49c967-- From nobody Fri Oct 7 10:33:44 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1D5129661 for ; Fri, 7 Oct 2016 10:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.42 X-Spam-Level: X-Spam-Status: No, score=-6.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5Zhv1eEo_ER for ; Fri, 7 Oct 2016 10:33:40 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (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 962BD129493 for ; Fri, 7 Oct 2016 10:33:40 -0700 (PDT) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id 70DDE96499BB7 for ; Fri, 7 Oct 2016 17:33:37 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u97HXdUE005691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 7 Oct 2016 17:33:39 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id u97HXJUR031450 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 7 Oct 2016 17:33:38 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.124]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0301.000; Fri, 7 Oct 2016 13:33:34 -0400 From: "Hu, Jun (Nokia - US)" To: IPsecME WG Thread-Topic: vendor support of RFC7427 Thread-Index: AdIgwO7tRgE5exa4RkO04FEvfTSIKw== Date: Fri, 7 Oct 2016 17:33:33 +0000 Message-ID: <876523B00C3F9D47BFD2B654D63DBF92BEAA73FA@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_876523B00C3F9D47BFD2B654D63DBF92BEAA73FAUS70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: [IPsec] vendor support of RFC7427 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 17:33:42 -0000 --_000_876523B00C3F9D47BFD2B654D63DBF92BEAA73FAUS70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I plan to support RFC7427 on my product, however as part of inter-op planni= ng, I'd like to know current industry support status for it; The only implementation I know so far is Strongswan which supported it sinc= e ver5.3; It will be highly appreciated if you could share your product status or roa= dmap on this RFC ------ Hu Jun IP Routing, IP/Optical Networks, Nokia New Email: jun.hu@nokia.com --_000_876523B00C3F9D47BFD2B654D63DBF92BEAA73FAUS70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I plan to support RFC7427 on my product, h= owever as part of inter-op planning, I’d like to know current industr= y support status for it;

The only implementation I know so far is S= trongswan which supported it since ver5.3;

It will be highly appreciated if you could= share your product status or roadmap on this RFC

 

------

Hu Jun

IP Routing, IP/Optical Networks, Nokia

New Email: jun.hu@nokia.com

 

--_000_876523B00C3F9D47BFD2B654D63DBF92BEAA73FAUS70UWXCHMBA05z_-- From nobody Fri Oct 7 10:58:50 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7D3129694 for ; Fri, 7 Oct 2016 10:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.994 X-Spam-Level: X-Spam-Status: No, score=-4.994 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDu-hk1wrMLB for ; Fri, 7 Oct 2016 10:58:47 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BC361296AA for ; Fri, 7 Oct 2016 10:58:47 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3srHM91QfRz3mw; Fri, 7 Oct 2016 19:58:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1475863125; bh=h18cjZAvvGwpSakeO2cLaUxZZtCLF22wqhcMkbsaXPA=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=PLMt0l58e7FIcWf971kSn2HJ46NulHgwtsd0DFHdY5dBpm6M717anklG1f2HeIvW1 l1hVo37A6H1MtAsL967c2bU/wa4i3MEztocGRYrnQo4QFqAKZoyeXazylfGeeRMK0P pXj52tCrDCfiHcRUJwz7fMwtb6hJQ9HKhuWmui9s= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id JhkWJl2NPfVX; Fri, 7 Oct 2016 19:58:43 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 7 Oct 2016 19:58:43 +0200 (CEST) Received: from [25.19.82.228] (unknown [24.114.73.137]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id B7F015C839; Fri, 7 Oct 2016 13:58:40 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca B7F015C839 Content-Type: multipart/alternative; boundary=Apple-Mail-5607D0BA-02C8-47CA-A1D6-A791513B004F Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (14A456) In-Reply-To: <876523B00C3F9D47BFD2B654D63DBF92BEAA73FA@US70UWXCHMBA05.zam.alcatel-lucent.com> Date: Fri, 7 Oct 2016 13:58:39 -0400 Content-Transfer-Encoding: 7bit Message-Id: <92992DC1-D132-4B8F-8944-529AB2D8727F@nohats.ca> References: <876523B00C3F9D47BFD2B654D63DBF92BEAA73FA@US70UWXCHMBA05.zam.alcatel-lucent.com> To: "Hu, Jun (Nokia - US)" Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] vendor support of RFC7427 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 17:58:49 -0000 --Apple-Mail-5607D0BA-02C8-47CA-A1D6-A791513B004F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable For libreswan, support is planned Q1 2017 Sent from my iPhone > On Oct 7, 2016, at 13:33, Hu, Jun (Nokia - US) wrote: >=20 > Hi, > I plan to support RFC7427 on my product, however as part of inter-op plann= ing, I=E2=80=99d like to know current industry support status for it; > The only implementation I know so far is Strongswan which supported it sin= ce ver5.3; > It will be highly appreciated if you could share your product status or ro= admap on this RFC > =20 > ------ > Hu Jun > IP Routing, IP/Optical Networks, Nokia > New Email: jun.hu@nokia.com > =20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail-5607D0BA-02C8-47CA-A1D6-A791513B004F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
For libreswan, support is planned Q1 2= 017

Sent from my iPhone

On Oct 7, 2016, at 13:33, Hu, J= un (Nokia - US) <jun.hu@nokia.com= > wrote:

=

Hi,

I plan to support RFC7427 on my product, how= ever as part of inter-op planning, I=E2=80=99d like to know current industry= support status for it;

The only implementation I know so far is Str= ongswan which supported it since ver5.3;

It will be highly appreciated if you could s= hare your product status or roadmap on this RFC

 

------

Hu Jun

IP Routing, IP/Optical Networks, Nokia<= /span>

New Email: jun= .hu@nokia.com

 

____________________= ___________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mai= lman/listinfo/ipsec
= --Apple-Mail-5607D0BA-02C8-47CA-A1D6-A791513B004F-- From nobody Fri Oct 7 11:18:02 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB22129498 for ; Fri, 7 Oct 2016 11:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CecD60JMJg14 for ; Fri, 7 Oct 2016 11:17:59 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (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 4EE50128B44 for ; Fri, 7 Oct 2016 11:17:59 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id 7F190C154EC8B; Fri, 7 Oct 2016 18:17:55 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u97IHu2f012865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Oct 2016 18:17:57 GMT Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u97IHt4K030307 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Oct 2016 18:17:56 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.124]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0301.000; Fri, 7 Oct 2016 14:17:55 -0400 From: "Hu, Jun (Nokia - US)" To: Paul Wouters Thread-Topic: [IPsec] vendor support of RFC7427 Thread-Index: AdIgwO7tRgE5exa4RkO04FEvfTSIKwAJQbWAAAe1rTA= Date: Fri, 7 Oct 2016 18:17:54 +0000 Message-ID: <876523B00C3F9D47BFD2B654D63DBF92BEAA7C1B@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <876523B00C3F9D47BFD2B654D63DBF92BEAA73FA@US70UWXCHMBA05.zam.alcatel-lucent.com> <92992DC1-D132-4B8F-8944-529AB2D8727F@nohats.ca> In-Reply-To: <92992DC1-D132-4B8F-8944-529AB2D8727F@nohats.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_876523B00C3F9D47BFD2B654D63DBF92BEAA7C1BUS70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] vendor support of RFC7427 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 18:18:02 -0000 --_000_876523B00C3F9D47BFD2B654D63DBF92BEAA7C1BUS70UWXCHMBA05z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzLg0KDQpGcm9tOiBQYXVsIFdvdXRlcnMgW21haWx0bzpwYXVsQG5vaGF0cy5jYV0NClNl bnQ6IEZyaWRheSwgT2N0b2JlciAwNywgMjAxNiAxMDo1OSBBTQ0KVG86IEh1LCBKdW4gKE5va2lh IC0gVVMpDQpDYzogSVBzZWNNRSBXRw0KU3ViamVjdDogUmU6IFtJUHNlY10gdmVuZG9yIHN1cHBv cnQgb2YgUkZDNzQyNw0KDQpGb3IgbGlicmVzd2FuLCBzdXBwb3J0IGlzIHBsYW5uZWQgUTEgMjAx Nw0KDQpTZW50IGZyb20gbXkgaVBob25lDQoNCk9uIE9jdCA3LCAyMDE2LCBhdCAxMzozMywgSHUs IEp1biAoTm9raWEgLSBVUykgPGp1bi5odUBub2tpYS5jb208bWFpbHRvOmp1bi5odUBub2tpYS5j b20+PiB3cm90ZToNCkhpLA0KSSBwbGFuIHRvIHN1cHBvcnQgUkZDNzQyNyBvbiBteSBwcm9kdWN0 LCBob3dldmVyIGFzIHBhcnQgb2YgaW50ZXItb3AgcGxhbm5pbmcsIEnigJlkIGxpa2UgdG8ga25v dyBjdXJyZW50IGluZHVzdHJ5IHN1cHBvcnQgc3RhdHVzIGZvciBpdDsNClRoZSBvbmx5IGltcGxl bWVudGF0aW9uIEkga25vdyBzbyBmYXIgaXMgU3Ryb25nc3dhbiB3aGljaCBzdXBwb3J0ZWQgaXQg c2luY2UgdmVyNS4zOw0KSXQgd2lsbCBiZSBoaWdobHkgYXBwcmVjaWF0ZWQgaWYgeW91IGNvdWxk IHNoYXJlIHlvdXIgcHJvZHVjdCBzdGF0dXMgb3Igcm9hZG1hcCBvbiB0aGlzIFJGQw0KDQotLS0t LS0NCkh1IEp1bg0KSVAgUm91dGluZywgSVAvT3B0aWNhbCBOZXR3b3JrcywgTm9raWENCk5ldyBF bWFpbDoganVuLmh1QG5va2lhLmNvbTxtYWlsdG86anVuLmh1QG5va2lhLmNvbT4NCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklQc2VjIG1haWxpbmcg bGlzdA0KSVBzZWNAaWV0Zi5vcmc8bWFpbHRvOklQc2VjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYw0K --_000_876523B00C3F9D47BFD2B654D63DBF92BEAA7C1BUS70UWXCHMBA05z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJO b2tpYSBQdXJlIFRleHQiOw0KCXBhbm9zZS0xOjIgMTEgNSA0IDQgNiAyIDYgMyAzO30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik5va2lhIFB1cmUgVGV4dCBMaWdodCI7DQoJcGFub3NlLTE6 MiAxMSAzIDQgNCA2IDIgNiAzIDM7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovk vZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJOb2tpYSBQdXJlIFRleHQgTGlnaHQiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJOb2tpYSBQdXJlIFRleHQgTGlnaHQiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjI1aW4gMS4waW4gMS4yNWlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtOb2tpYSBQdXJlIFRleHQgTGlnaHQmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O05va2lhIFB1 cmUgVGV4dCBMaWdodCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IFBhdWwgV291dGVycyBbbWFpbHRvOnBhdWxAbm9oYXRzLmNhXQ0KPGJy Pg0KPGI+U2VudDo8L2I+IEZyaWRheSwgT2N0b2JlciAwNywgMjAxNiAxMDo1OSBBTTxicj4NCjxi PlRvOjwvYj4gSHUsIEp1biAoTm9raWEgLSBVUyk8YnI+DQo8Yj5DYzo8L2I+IElQc2VjTUUgV0c8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJUHNlY10gdmVuZG9yIHN1cHBvcnQgb2YgUkZDNzQy NzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5G b3IgbGlicmVzd2FuLCBzdXBwb3J0IGlzIHBsYW5uZWQgUTEgMjAxNzxicj4NCjxicj4NClNlbnQg ZnJvbSBteSBpUGhvbmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gT2N0IDcsIDIw MTYsIGF0IDEzOjMzLCBIdSwgSnVuIChOb2tpYSAtIFVTKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmp1 bi5odUBub2tpYS5jb20iPmp1bi5odUBub2tpYS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O05va2lhIFB1cmUgVGV4dCBMaWdodCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5IaSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Tm9raWEgUHVyZSBUZXh0IExpZ2h0 JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkkgcGxhbiB0byBzdXBwb3J0IFJGQzc0Mjcg b24gbXkgcHJvZHVjdCwgaG93ZXZlciBhcyBwYXJ0IG9mIGludGVyLW9wIHBsYW5uaW5nLCBJ4oCZ ZCBsaWtlIHRvIGtub3cgY3VycmVudCBpbmR1c3RyeSBzdXBwb3J0IHN0YXR1cyBmb3IgaXQ7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O05va2lhIFB1cmUgVGV4dCBMaWdodCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5UaGUgb25seSBpbXBsZW1lbnRhdGlvbiBJIGtub3cgc28gZmFyIGlzIFN0cm9u Z3N3YW4gd2hpY2ggc3VwcG9ydGVkIGl0IHNpbmNlIHZlcjUuMzs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Tm9raWEgUHVyZSBUZXh0IExpZ2h0JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkl0IHdp bGwgYmUgaGlnaGx5IGFwcHJlY2lhdGVkIGlmIHlvdSBjb3VsZCBzaGFyZSB5b3VyIHByb2R1Y3Qg c3RhdHVzIG9yIHJvYWRtYXAgb24gdGhpcyBSRkMNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtOb2tpYSBQ dXJlIFRleHQgTGlnaHQmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O05va2lhIFB1cmUgVGV4dCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4tLS0tLS08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Tm9raWEgUHVyZSBUZXh0JnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkh1IEp1bjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtOb2tpYSBQdXJlIFRleHQm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SVAgUm91dGluZywgSVAvT3B0aWNhbCBOZXR3 b3JrcywgTm9raWE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Tm9raWEgUHVyZSBUZXh0JnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPk5ldyBFbWFpbDoNCjxhIGhyZWY9Im1haWx0bzpqdW4uaHVAbm9r aWEuY29tIj5qdW4uaHVAbm9raWEuY29tPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KSVBzZWMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklQc2VjQGlldGYu b3JnIj5JUHNlY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lwc2VjPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_876523B00C3F9D47BFD2B654D63DBF92BEAA7C1BUS70UWXCHMBA05z_-- From nobody Fri Oct 7 14:09:13 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BB3129540 for ; Fri, 7 Oct 2016 14:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Myf4Gs6_gs2u for ; Fri, 7 Oct 2016 14:09:09 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (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 72C6912941E for ; Fri, 7 Oct 2016 14:09:09 -0700 (PDT) Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id 685D9795CD0DE; Fri, 7 Oct 2016 21:09:04 +0000 (GMT) Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u97L97xo024796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Oct 2016 21:09:08 GMT Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u97L97VV024420 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Oct 2016 21:09:07 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.124]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0301.000; Fri, 7 Oct 2016 17:09:08 -0400 From: "Hu, Jun (Nokia - US)" To: Tommy Pauly , Valery Smyslov , "Yoav Nir" Thread-Topic: [IPsec] New version of TCP Encapsulation draft, request for adoption Thread-Index: AQHRoLQbhmlKoxjITU+aiNyunbfH4p+ssGmAgAA064CAD3ujAIAAb1NwgAW3a4CA2/AG4A== Date: Fri, 7 Oct 2016 21:09:06 +0000 Message-ID: <876523B00C3F9D47BFD2B654D63DBF92BEAA7FCD@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <2C8840EB-AC99-401F-971A-2962B71FCC08@apple.com> <9CC56746-DCA5-42F0-8FBC-B3F5391989E6@apple.com> In-Reply-To: <9CC56746-DCA5-42F0-8FBC-B3F5391989E6@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IPsecME WG , Daniel Migault , Paul Wouters Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for adoption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2016 21:09:11 -0000 I was reading the draft again, and had similar problem as below; Draft states that SA state should be independent of TCP state and it allows= multiple TCP sessions between two peers even when there is only one IKE_SA= ; I assume this means for a given tunnel, different SA could belong to differ= ent TCP session, e.g. IKE_SA uses TCP session-1, CHILD_SA uses TCP session-= 2; however does this mean draft allows multiple TCP sessions for a given SA? I= guess not, if that's the case, then it should be stated clearly in the dra= ft that for a given SA, only one TCP session is allowed; In case of when the original initiator lost TCP session and create a new on= e, the responder should update its TCP_session-to-SA binding after it recei= ves a valid IKE/ESP packet is received on the new TCP session and close the= old one, send TCP RST > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tommy Pauly ... > > Then, I think some text should be added describing a situation when > > the original responder having a valid (from its point of view) TCP > > session receives a request from original initiator for a new TCP > > session. This may happen if original initiator looses TCP state for > > some reason (RST from an attacker, temporary network failure etc.). > > In this case the responder will have two TCP sessions associated with > > the IKE SA. Clearly, the new one should be used for further > > communications, but only after it is proven to be authentic (some > > protected message is received over it). But what the responder should d= o > with the old TCP session? > > Keep it? Send FIN? Send RST? Just discard? > > >=20 > In general, the approach of the draft is to clearly separate the TCP stat= e from > the IKE session state. If you look at Section 6, it specifically allows f= or multiple > TCP connections between two peers even if there is only one IKE SA betwee= n > them. If one of them becomes redundant (because the other peer opened up = a > new TCP flow for some reason), it would make sense to close the other in = a > usual way. I think this can be left to the implementation, but either a F= IN or RST > would be appropriate rather than a discard. We can add that to future ver= sions. >=20 From nobody Sat Oct 8 10:30:18 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E4F1295D4 for ; Sat, 8 Oct 2016 10:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrFsFDtuJCZJ for ; Sat, 8 Oct 2016 10:30:14 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 3C22512954F for ; Sat, 8 Oct 2016 10:30:13 -0700 (PDT) X-AuditID: c618062d-743ff700000009b8-90-57f92fffb9e4 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by (Symantec Mail Security) with SMTP id B3.44.02488.FFF29F75; Sat, 8 Oct 2016 19:42:26 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0319.002; Sat, 8 Oct 2016 13:30:09 -0400 From: Daniel Migault To: IPsecME WG Thread-Topic: New Version Notification for draft-mglt-ipsecme-implicit-iv-01.txt Thread-Index: AQHSIYeTU8P9UXdAQkyoR5dtCYRpaaCezcvA Date: Sat, 8 Oct 2016 17:30:09 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C117F98570@eusaamb107.ericsson.se> References: <147594692832.28921.7850239516371972090.idtracker@ietfa.amsl.com> In-Reply-To: <147594692832.28921.7850239516371972090.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyuXRPlC6Twc9wg6NdJhb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrYlCgV9ohVzTq5laWA8IdLFyMkhIWAisXveFrYuRi4OIYEN jBKdu1vZIZxljBKfLmxgAqliEzCSaDvUD5Tg4BARkJeYeSMTxBQWCJQ4c8YTpEJEIEji58HT jBC2kUTL/U9sIDaLgIrE2ScbWEBsXgFfiVWrm5hBbCEge/+NPiaQMZwCfhInXwuBhBkFxCS+ n1oDtpRZQFzi1pP5TBBnCkgs2XOeGcIWlXj5+B8rhK0k8fH3fLDDmAU0Jdbv0odoVZSY0v2Q HWKroMTJmU9YJjCKzEIydRZCxywkHbOQdCxgZFnFyFFaXJCTm25ksIkRGNbHJNh0dzDen+55 iFGAg1GJh3fBo+/hQqyJZcWVuYcYJTiYlUR4rbV+hgvxpiRWVqUW5ccXleakFh9ilOZgURLn jVt9P1xIID2xJDU7NbUgtQgmy8TBKdXAyPno4ZuQSc9Ptin6PXjz6doL5n+sDvs8vkyZ12IY 9St5gR7P36d/f9cdPcy8fUb75osi6aJBC50TCzyFZoQHW4S4VWgt1NlX0ST72Hfmoymi6qZL /5fofAtnVvDpTvNwnXF8abor1/amo3KNSzXSZBL2us3Qdkg9wKHf91xCpXX92Z5MBlZzJZbi jERDLeai4kQAZD0QrGcCAAA= Archived-At: Subject: [IPsec] FW: New Version Notification for draft-mglt-ipsecme-implicit-iv-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2016 17:30:17 -0000 SGksIA0KDQpCYXNlZCBvbiB0aGUgZmVlZCBiYWNrcyBhbmQgdGhlIGRpc2N1c3Npb25zIGZyb20g dGhlIHByZXZpb3VzIElFVEYsIHNlZSB0aGUgdXBkYXRlZCB2ZXJzaW9uIG9mIG91ciBkcmFmdC4g V2UgYmVsaWV2ZSB0aGUgZG9jdW1lbnQgaXMgaW4gZ29vZCBzaGFwZSB0byBiZWNvbWUgYSBXRyBk b2N1bWVudC4gDQoNCkZlZWwgZnJlZSB0byBzdXBwb3J0IHRoZSBkcmFmdCBhbmQgYXMgdXN1YWxs eSwgY29tbWVudHMgYXJlIHdlbGNvbWUhICANCg0KQlIsIA0KRGFuaWVsIA0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86 aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFNhdHVyZGF5LCBPY3RvYmVyIDA4LCAy MDE2IDc6MTUgUE0NClRvOiBUb2JpYXMgR3VnZ2Vtb3MgPHRvYmlhcy5ndWdnZW1vc0BnbWFpbC5j b20+OyBZb2F2IE5pciA8eW5pci5pZXRmQGdtYWlsLmNvbT47IERhbmllbCBNaWdhdWx0IDxkYW5p ZWwubWlnYXVsdEBlcmljc3Nvbi5jb20+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LW1nbHQtaXBzZWNtZS1pbXBsaWNpdC1pdi0wMS50eHQNCg0KDQpBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQtbWdsdC1pcHNlY21lLWltcGxpY2l0LWl2LTAxLnR4dA0KaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBEYW5pZWwgTWlnYXVsdCBhbmQgcG9zdGVk IHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1tZ2x0LWlwc2VjbWUtaW1w bGljaXQtaXYNClJldmlzaW9uOgkwMQ0KVGl0bGU6CQlJbXBsaWNpdCBJViBmb3IgQ291bnRlci1i YXNlZCBDaXBoZXJzIGluIElQc2VjDQpEb2N1bWVudCBkYXRlOgkyMDE2LTEwLTA4DQpHcm91cDoJ CUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQk2DQpVUkw6ICAgICAgICAgICAgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW1nbHQtaXBzZWNtZS1pbXBsaWNp dC1pdi0wMS50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1tZ2x0LWlwc2VjbWUtaW1wbGljaXQtaXYvDQpIdG1saXplZDogICAgICAgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1nbHQtaXBzZWNtZS1pbXBsaWNpdC1pdi0w MQ0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1tZ2x0LWlwc2VjbWUtaW1wbGljaXQtaXYtMDENCg0KQWJzdHJhY3Q6DQogICBJUHNlYyBFU1Ag c2VuZHMgYW4gaW5pdGlhbGl6YXRpb24gdmVjdG9yIChJVikgb3Igbm9uY2UgaW4gZWFjaA0KICAg cGFja2V0LCBhZGRpbmcgOCBvciAxNiBvY3RldHMuICBTb21lIGFsZ29yaXRobXMgc3VjaCBhcyBB RVMtR0NNLCBBRVMtDQogICBDQ00sIEFFUy1DVFIgYW5kIENoYUNoYTIwLVBvbHkxMzA1IHJlcXVp cmUgYSB1bmlxdWUgbm9uY2UgYnV0IGRvIG5vdA0KICAgcmVxdWlyZSBhbiB1bnByZWRpY3RhYmxl IG5vbmNlLiAgV2hlbiB1c2luZyBzdWNoIGFsZ29yaXRobXMgdGhlDQogICBwYWNrZXQgY291bnRl ciB2YWx1ZSBjYW4gYmUgdXNlZCB0byBnZW5lcmF0ZSBhIG5vbmNlLCBzYXZpbmcgOCBvY3RldHMN CiAgIHBlciBwYWNrZXQuICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBob3cgdG8gZG8gdGhpcy4N Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50 aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5p ZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Sun Oct 9 14:26:14 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B3E127735; Sun, 9 Oct 2016 14:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.996 X-Spam-Level: X-Spam-Status: No, score=-4.996 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=-2.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iosN7fncc_B; Sun, 9 Oct 2016 14:26:11 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1FC2120726; Sun, 9 Oct 2016 14:26:10 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3ssbsW2wbVz37R; Sun, 9 Oct 2016 23:26:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1476048367; bh=KCWs2n+3PH62jgm+SZTNK28s2vkQamtEBeKJNebH1FM=; h=Date:From:To:cc:Subject; b=qngpQN8eT+MBlxdTbcmWGkTU651cr50NwVYn+clIBnX5zJsuDht96+ckbHLu4FEmZ qNIk6poa/TsJ5jo5JJOotCChCoTA9cz++pk0WN8vrIP/oUnFEIkBr2+l64w3F/KAh2 dU5Y1u9TkdDMlMwp672OLpponCLe0bs3Tb11ybbw= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id KaP8RvndbxbF; Sun, 9 Oct 2016 23:26:05 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 9 Oct 2016 23:26:05 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 82F505C837; Sun, 9 Oct 2016 17:26:02 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 82F505C837 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6CC0E406A900; Sun, 9 Oct 2016 17:26:02 -0400 (EDT) Date: Sun, 9 Oct 2016 17:26:02 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Archived-At: Cc: saag@ietf.org Subject: [IPsec] trapdoor'ed DH (and RFC-5114 again) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2016 21:26:13 -0000 Released a few days ago: http://eprint.iacr.org/2016/961 A kilobit hidden SNFS discrete logarithm computation Joshua Fried and Pierrick Gaudry and Nadia Heninger and Emmanuel Thom We perform a special number field sieve discrete logarithm computation in a 1024-bit prime field. To our knowledge, this is the first kilobit-sized discrete logarithm computation ever reported for prime fields. This computation took a little over two months of calendar time on an academic cluster using the open-source CADO-NFS software. Basically, this paper shows how to make a DH group of 1024 modp with a backdoor, in two months of academic computing resources, The paper mentions 5114 a few times: RFC 5114 [33] specifies a number of groups for use with Diffie-Hellman, and states that the parameters were drawn from NIST test data, but neither the NIST test data [39] nor RFC 5114 itself contain the seeds used to generate the finite field parameters And concludes: Both from this perspective, and from our more modern one, dismissing the risk of trapdoored primes in real usage appears to have been a mistake, as the apparent difficulties encountered by the trapdoor designer in 1992 turn out to be easily circumvented. A more conservative design decision for FIPS 186 would have required mandatory seed publication instead of making it optional. As a result, there are opaque, standardized 1024-bit and 2048-bit primes in wide use today that cannot be properly verified. This is the strongest statement yet that I've seen to not trust any of the RFC-5114 groups. The latest 4307bis document has these groups (22-24) as SHOULD NOT, stating: Group 22, 23 and 24 or 1024-bit MODP Group with 160-bit, and 2048-bit MODP Group with 224-bit and 256-bit Prime Order Subgroup have small subgroups, which means that checks specified in the "Additional Diffie-Hellman Test for the IKEv2" [RFC6989] section 2.2 first bullet point MUST be done when these groups are used. These groups are also not safe-primes. The seeds for these groups have not been publicly released, resulting in reduced trust in these groups. These groups were proposed as alternatives for group 2 and 14 but never saw wide deployment. It is expected in the near future to be further downgraded to MUST NOT. I'm proposing it is time to change this to MUST NOT for 4307bis. Possibly, we should do this via SAAG in general, and then follow SAAG's advise in IPSECME. Is there _any_ reason why group 22-24 should not be MUST NOT ? Paul From nobody Sun Oct 9 23:47:49 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCF912945A for ; Sun, 9 Oct 2016 23:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.797 X-Spam-Level: X-Spam-Status: No, score=0.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.496, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-ILyy_eWPD2 for ; Sun, 9 Oct 2016 23:47:46 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1225A128E18 for ; Sun, 9 Oct 2016 23:47:45 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id b81so109646146lfe.1 for ; Sun, 09 Oct 2016 23:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version; bh=PmloE0wz5wZ+FoSBNNg8Lyj/LDIw2R0oC/jUYvU8kj8=; b=INoEz004LjUMlzB9gOD/AE5pknJRNjKvsP54CKW6lXBa/7ydkLbDz/wLYne+YlhtKb /ehc1qdvXIicCsHuNjbV1l4Tuya6Z9viKE5Cu6vzeOcwbev5SdJj1EqH9oWD4OJRvHSU KMD3iKByeTU3dgmsLlnP6JY7fhvQN4tXxD1OJ7gTxf8ieubVaK5FJLjBjs6lJSZ1VDZV T9mKXFvDL9WKGquFpECFrm5QX71ELuDERQV1aFFtdliRQBbE5o6rbw480GSpbpSq/KDP qrYHpOAfTZDzCDQkDqUFPm4MeVIJGj1elHWvy6HWhDCnDtjLxWNHPMb2PWuF0DYZb3/l I9mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:references:subject:date :mime-version; bh=PmloE0wz5wZ+FoSBNNg8Lyj/LDIw2R0oC/jUYvU8kj8=; b=Ec5oU+0y6eGL6ggNQKdhpRYqJDr0zTEJvbEtyCxkEAPypxRAwjERvZYUjwnCGUu++R 7B601o3y7VJyrZb8c8uTx6xzs3bWz4ipC7bplORYMDyCKp4EqYVlF0Id4ovdXby16fq+ MQZALLVOOWAEOky+1LS0mSD3yNyf3/9M09X6QRhFgZzSoy81X4uikWqC9qTbx8EdW+Hz +6K8CgFwuDMuaqxx8j+yDd6IrV7x8hnzC9i1AefXbaC5eiZ4Fl9qJc/DwofsFhUC9D11 Q95nHKYQbdAOKO/2J8yLwOfv0vFRDU+DUAS/ER+P+BLFlHSNpH4c5YJLYgb1oqou+atW lyQA== X-Gm-Message-State: AA6/9RleZ2m/8MOqkg5moUwxtTQuI/8UADMt8ZVJiZ3ogdVFJVg/eNr8REUCgWnCCIB9sA== X-Received: by 10.25.1.136 with SMTP id 130mr14611330lfb.159.1476082063755; Sun, 09 Oct 2016 23:47:43 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id y7sm5752169lfd.18.2016.10.09.23.47.42 (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Sun, 09 Oct 2016 23:47:42 -0700 (PDT) Message-ID: <2FBB5ECC7B8043F2B4E1A6141B3D4FE1@buildpc> From: "Valery Smyslov" To: "Hu, Jun \(Nokia - US\)" , "IPsecME WG" References: <876523B00C3F9D47BFD2B654D63DBF92BEAA73FA@US70UWXCHMBA05.zam.alcatel-lucent.com> Date: Mon, 10 Oct 2016 09:47:38 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0141_01D222DB.5622A920" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Subject: Re: [IPsec] vendor support of RFC7427 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 06:47:49 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0141_01D222DB.5622A920 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, we (ELVIS-PLUS) support RFC7427 for over a year and we are interoperable = with Strongswan. However, see my message about some interoperability problems: https://www.ietf.org/mail-archive/web/ipsec/current/msg10840.html This issue is scheduled for discussion on ipsecme meeting in Seoul. Regards, Valery Smyslov. ----- Original Message -----=20 From: Hu, Jun (Nokia - US)=20 To: IPsecME WG=20 Sent: Friday, October 07, 2016 8:33 PM Subject: [IPsec] vendor support of RFC7427 Hi, I plan to support RFC7427 on my product, however as part of inter-op = planning, I'd like to know current industry support status for it; The only implementation I know so far is Strongswan which supported it = since ver5.3; It will be highly appreciated if you could share your product status = or roadmap on this RFC=20 =20 ------ Hu Jun IP Routing, IP/Optical Networks, Nokia New Email: jun.hu@nokia.com =20 -------------------------------------------------------------------------= ----- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0141_01D222DB.5622A920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
we (ELVIS-PLUS) support RFC7427 for over a year and = we are=20 interoperable with Strongswan.
 
However, see my message about some interoperability=20 problems:
https://www.ietf.org/mail-archive/web/ipsec/current/msg10840.html
 
This issue is scheduled for discussion on ipsecme = meeting in=20 Seoul.
 
Regards,
Valery Smyslov.
----- Original Message -----
From:=20 Hu, Jun = (Nokia -=20 US)
Sent: Friday, October 07, 2016 = 8:33=20 PM
Subject: [IPsec] vendor support = of=20 RFC7427

Hi,

I plan to = support=20 RFC7427 on my product, however as part of inter-op planning, I=92d = like to know=20 current industry support status for it;

The only=20 implementation I know so far is Strongswan which supported it since=20 ver5.3;

It will be = highly=20 appreciated if you could share your product status or roadmap on this = RFC=20

 

------

Hu=20 Jun

IP Routing, = IP/Optical=20 Networks, Nokia

New Email:=20 jun.hu@nokia.com

 

_______________________________________________
IPsec = mailing=20 = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
= ------=_NextPart_000_0141_01D222DB.5622A920-- From nobody Mon Oct 10 00:05:51 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4B412944C for ; Mon, 10 Oct 2016 00:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.235 X-Spam-Level: * X-Spam-Status: No, score=1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.496, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XGWVBv6YMFT for ; Mon, 10 Oct 2016 00:05:47 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 105BF128E18 for ; Mon, 10 Oct 2016 00:05:47 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id x79so110920140lff.0 for ; Mon, 10 Oct 2016 00:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-transfer-encoding; bh=wvZ/jM4fJohoIkqJ1v3FK6BjxoBKc6gKVei4hYvz/3g=; b=vFo+WPoL79PeRG3GaKbwuBisJn1t05GKCzhyvXmKS1+ChDdw+FcnDY5r4Ij2u6OfJe HKr/wg6LhG07/iAM7tSAUQPzXJZzxxrSNZR2DX9sZCQ+qAAb3szVk0cwAusRYUa7lC3N 8C2uFZO2yJxHhrMIN0OAjZvCmy/eP96EvsPBHA3UKi2Z3wY+2iBuptmCjiSejG0xN5S+ xN/B4IWZePca3XG/D6wKLvYMTbIqroPz7x8t4+iXyN1GwdBZ1BjiNDBRZ3238sBGtdfP GSFEg+Mr1QrkS1XWIbRaEDbP3HZ16JAVt+rWYJtQCQ9w/eMHTN1rVJicjYDWbJMMI+lP AtKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:references:subject:date :mime-version:content-transfer-encoding; bh=wvZ/jM4fJohoIkqJ1v3FK6BjxoBKc6gKVei4hYvz/3g=; b=fPs/vxfG+xmTOJ741ZPcdc8HL+lB2yO1q5bV19Q75ku3p6w8QSfbceDNI0J6tgeW9r ID2eWrV4C9YKm1ZCAniWXAf0vjbB5BB+iAY4pVN9iIDtjcrH68OyQf+g0232RiEvMA1c iDz/qEo8j0Xa6no0bFZsTXhxHYQF/H6AEAmNzpPzNLQiARQV57St8RmOAQuB+8IqoGvD 0gOtHsndo/CqIKerH2KYSfqA+E3sZUH7ehk6q30mtENTGUUshoRxn+bCmN2LdK4oWfIX FBjDBP5SVeVOg90ihfFtL5APukKnc4cqwVqWUS5l4zsosldX41a8FKTH85APRq5LjQp5 SeJg== X-Gm-Message-State: AA6/9Rl9GfHM3FWYOuyyuJrkdLlbLMBBctcMHsKmh418+UGd04un6uk+c0NyhckmEJP8VQ== X-Received: by 10.25.152.83 with SMTP id a80mr14908103lfe.144.1476083144975; Mon, 10 Oct 2016 00:05:44 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id r123sm5710610lff.28.2016.10.10.00.05.43 (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Mon, 10 Oct 2016 00:05:44 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Daniel Migault" , "IPsecME WG" References: <147594692832.28921.7850239516371972090.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C117F98570@eusaamb107.ericsson.se> Date: Mon, 10 Oct 2016 10:05:40 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Subject: Re: [IPsec] FW: New Version Notification fordraft-mglt-ipsecme-implicit-iv-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 07:05:50 -0000 Hi Daniel, I think you should add a text in the Security Considerations that these transforms MUST NOT be used in situations where there is a chance that Sequence Numbers repeat. The most prominent example where it can happen - multicast ESP SA with multiple senders. Regards, Valery. > Hi, > > Based on the feed backs and the discussions from the previous IETF, see the updated version of our draft. We believe > the document is in good shape to become a WG document. > > Feel free to support the draft and as usually, comments are welcome! > > BR, > Daniel > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Saturday, October 08, 2016 7:15 PM > To: Tobias Guggemos ; Yoav Nir ; Daniel Migault > > Subject: New Version Notification for draft-mglt-ipsecme-implicit-iv-01.txt > > > A new version of I-D, draft-mglt-ipsecme-implicit-iv-01.txt > has been successfully submitted by Daniel Migault and posted to the IETF repository. > > Name: draft-mglt-ipsecme-implicit-iv > Revision: 01 > Title: Implicit IV for Counter-based Ciphers in IPsec > Document date: 2016-10-08 > Group: Individual Submission > Pages: 6 > URL: https://www.ietf.org/internet-drafts/draft-mglt-ipsecme-implicit-iv-01.txt > Status: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ > Htmlized: https://tools.ietf.org/html/draft-mglt-ipsecme-implicit-iv-01 > Diff: https://www.ietf.org/rfcdiff?url2=draft-mglt-ipsecme-implicit-iv-01 > > Abstract: > IPsec ESP sends an initialization vector (IV) or nonce in each > packet, adding 8 or 16 octets. Some algorithms such as AES-GCM, AES- > CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not > require an unpredictable nonce. When using such algorithms the > packet counter value can be used to generate a nonce, saving 8 octets > per packet. This document describes how to do this. > > > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are > available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Oct 10 06:18:09 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCBEC129695; Mon, 10 Oct 2016 06:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8_2Uu8QZIGO; Mon, 10 Oct 2016 06:18:01 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0121.outbound.protection.outlook.com [23.103.200.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0DE1129691; Mon, 10 Oct 2016 06:18:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=baB4jZYdUmXlF5QI+qELhIG8honQOMHPTpXF/p4G94U=; b=0RtdCqB0gVpPD3jh14TDibwkBoU+KgzMBLlmQKmchASq9f5i/zwD2Ktr1If3qykfiQ6IbeeHwbJP0awfoPFtBkV3QtpeeMNxbVNaTuMWlCnb48vlYBnb2p3ppEOSOzfLbFUK3+ZeBYgKYTAAyeb8VWr5YkdzEc8Nd6TMY9G9Gi4= Received: from DM5PR09MB1467.namprd09.prod.outlook.com (10.173.171.21) by DM5PR09MB1467.namprd09.prod.outlook.com (10.173.171.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Mon, 10 Oct 2016 13:18:00 +0000 Received: from DM5PR09MB1467.namprd09.prod.outlook.com ([10.173.171.21]) by DM5PR09MB1467.namprd09.prod.outlook.com ([10.173.171.21]) with mapi id 15.01.0659.020; Mon, 10 Oct 2016 13:18:00 +0000 From: "Dang, Quynh (Fed)" To: "paul@nohats.ca" , "ipsec@ietf.org WG" Thread-Topic: [IPsec] trapdoor'ed DH (and RFC-5114 again) Thread-Index: AQHSInPJr2kIoqyUikWZMRu8WhAVkaChpsd0 Date: Mon, 10 Oct 2016 13:18:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.222.157] x-ms-office365-filtering-correlation-id: d0e508ed-f092-4dff-1977-08d3f10fdbdc x-microsoft-exchange-diagnostics: 1; DM5PR09MB1467; 7:fSMgSVHOD2TeoAHiPWDYR9T1R20Y+ObI3kHbSPpZSVdqaNbpnqdJ2gfPWAuWie/FZSo1Q1AOXMbT4Rx1TBbyI5U6RF/q9v18tD7IlnOrFekRNkg0boOxoVg7GSgy3c6VZBdsGiCO6KMp+UiJlU0m28KV2/4+VfdFewQRzPqoDntgSaumeSDqLo7qqQzesPX+ipXS4GXyuayJ1WRkF7C9eR3y5Wx1GjiTIIlJNiz7i3RV/N3WeLEOxAqZ1NAyvRnuwS8RDoqfJmL6yAC2zBWhay8lFwU8WuW1J6+4EEdMhuuK8ANR1RrsFIhgh+L32+bmqy1gKi8td6IBmVWMpdrk8V4B+Irl7U87t5VRh+U9xak= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM5PR09MB1467; x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:DM5PR09MB1467; BCL:0; PCL:0; RULEID:; SRVR:DM5PR09MB1467; x-forefront-prvs: 0091C8F1EB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(189002)(377454003)(33656002)(77096005)(2501003)(8676002)(9686002)(16236675004)(2900100001)(15975445007)(101416001)(50986999)(54356999)(99286002)(81166006)(81156014)(189998001)(4326007)(19627405001)(76176999)(106116001)(97736004)(19625215002)(105586002)(106356001)(5001770100001)(74316002)(3900700001)(8936002)(87936001)(7736002)(2906002)(7846002)(10400500002)(7906003)(3660700001)(16297215004)(5002640100001)(19580395003)(68736007)(19580405001)(2950100002)(6116002)(3280700002)(6606003)(586003)(5660300001)(345774005)(86362001)(3846002)(76576001)(92566002)(11100500001)(19617315012)(66066001)(7696004)(102836003)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR09MB1467; H:DM5PR09MB1467.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR09MB146726177114D0FD30F871C2F3DB0DM5PR09MB1467namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2016 13:18:00.1217 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR09MB1467 Archived-At: Cc: "saag@ietf.org" Subject: Re: [IPsec] trapdoor'ed DH (and RFC-5114 again) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 13:18:05 -0000 --_000_DM5PR09MB146726177114D0FD30F871C2F3DB0DM5PR09MB1467namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Paul, Thank you for sharing the paper. A conclusion of the paper was "Our results are yet another reminder that 10= 24-bit primes should be considered insecure for the security of cryptosyste= ms based on the hardness of discrete logarithms. The discrete logarithm com= putation for our backdoored prime was only feasible because of the 1024-bit= size, and the most effective protection against any backdoor of this type = has always been to use key sizes for which any computation is infeasible. N= IST recommended transitioning away from 1024-bit key sizes for DSA, RSA, an= d Diffie-Hellman in 2010 [6]." NIST has been urging users to move away from groups with 1024- bit p and 16= 0-bit q for many years now. In our document, we stated that group generators "should" provide their see= ds. The reason for having "should" instead of "shall (must)" was that anyon= e could run our suggested method to generate their own group. A user who ge= nerates his/her own group for her/his own application could have a choice o= f publishing the seed or not. If a user had a contractor/third party to ge= nerate a group for him/her, he or she could ask for all documentation about= the whole process. Quynh. ________________________________ From: IPsec on behalf of Paul Wouters Sent: Sunday, October 9, 2016 5:26 PM To: ipsec@ietf.org WG Cc: saag@ietf.org Subject: [IPsec] trapdoor'ed DH (and RFC-5114 again) Released a few days ago: http://eprint.iacr.org/2016/961 A kilobit hidden SNFS discrete logarithm computation Joshua Fried and Pierrick Gaudry and Nadia Heninger and Emmanuel T= hom=E9 We perform a special number field sieve discrete logarithm computation in a 1024-bit prime field. To our knowledge, this is the first kilobit-sized discrete logarithm computation ever reported for prime fields. This computation took a little over two months of calendar time on an academic cluster using the open-source CADO-NFS software. Basically, this paper shows how to make a DH group of 1024 modp with a backdoor, in two months of academic computing resources, The paper mentions 5114 a few times: RFC 5114 [33] specifies a number of groups for use with Diffie-Hellman, and states that the parameters were drawn from NIST test data, but neither the NIST test data [39] nor RFC 5114 itself contain the seeds used to generate the finite field parameters And concludes: Both from this perspective, and from our more modern one, dismissi= ng the risk of trapdoored primes in real usage appears to have been a mis= take, as the apparent difficulties encountered by the trapdoor designer = in 1992 turn out to be easily circumvented. A more conservative design dec= ision for FIPS 186 would have required mandatory seed publication instea= d of making it optional. As a result, there are opaque, standardized 1= 024-bit and 2048-bit primes in wide use today that cannot be properly veri= fied. This is the strongest statement yet that I've seen to not trust any of the RFC-5114 groups. The latest 4307bis document has these groups (22-24) as SHOULD NOT, stating: Group 22, 23 and 24 or 1024-bit MODP Group with 160-bit, and 2048-bit MODP Group with 224-bit and 256-bit Prime Order Subgroup have small subgroups, which means that checks specified in the "Additional Diffie-Hellman Test for the IKEv2" [RFC6989] section 2.2 first bullet point MUST be done when these groups are used. These groups are also not safe-primes. The seeds for these groups have not been publicly released, resulting in reduced trust in these groups. These groups were proposed as alternatives for group 2 and 14 but never saw wide deployment. It is expected in the near future to be further downgraded to MUST NOT. I'm proposing it is time to change this to MUST NOT for 4307bis. Possibly, we should do this via SAAG in general, and then follow SAAG's advise in IPSECME. Is there _any_ reason why group 22-24 should not be MUST NOT ? Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_DM5PR09MB146726177114D0FD30F871C2F3DB0DM5PR09MB1467namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Paul, 


Thank you for sharing the paper. 


A conclusion of the paper was "Our results are yet another re= minder that 1024-bit primes should be considered insecure for the security = of cryptosystems based on the hardness of discrete logarithms. The discrete= logarithm computation for our backdoored prime was only feasible because of the 1024-bit size, and the most effecti= ve protection against any backdoor of this type has always been to use key = sizes for which any computation is infeasible. NIST recommended transitioni= ng away from 1024-bit key sizes for DSA, RSA, and Diffie-Hellman in 2010 [6]."


NIST has been urging users to move away from groups with 1024- bit= p and 160-bit q  for many years now. 


In our document, we stated that group generators "should"= ; provide their seeds. The reason for having "should" instead of = "shall (must)" was that anyone could run our suggested method to = generate their own group. A user who generates his/her own group for her/his own application could have a choice of publishing the seed or = not.  If a user had a contractor/third party to generate a group for h= im/her, he or she could ask for all documentation about the whole process.&= nbsp;


Quynh. 



From: IPsec <ipsec-bou= nces@ietf.org> on behalf of Paul Wouters <paul@nohats.ca>
Sent: Sunday, October 9, 2016 5:26 PM
To: ipsec@ietf.org WG
Cc: saag@ietf.org
Subject: [IPsec] trapdoor'ed DH (and RFC-5114 again)
 

Released a few days ago:

         http://eprint.iacr.org/2016/961

         A kilobit hidden SNFS disc= rete logarithm computation
         Joshua Fried and Pierrick = Gaudry and Nadia Heninger and Emmanuel Thom=E9

         We perform a special numbe= r field sieve discrete logarithm
         computation in a 1024-bit = prime field. To our knowledge, this
         is the first kilobit-sized= discrete logarithm computation ever
         reported for prime fields.= This computation took a little over
         two months of calendar tim= e on an academic cluster using the
         open-source CADO-NFS softw= are.

Basically, this paper shows how to make a DH group of 1024 modp
with a backdoor, in two months of academic computing resources,

The paper mentions 5114 a few times:

         RFC 5114 [33] specifies a = number of groups for use with
         Diffie-Hellman, and states= that the parameters were drawn
         from NIST test data, but n= either the NIST test data [39] nor
         RFC 5114 itself contain th= e seeds used to generate the finite
         field parameters

And concludes:

         Both from this perspective= , and from our more modern one, dismissing the
         risk of trapdoored primes = in real usage appears to have been a mistake,
         as the apparent difficulti= es encountered by the trapdoor designer in 1992
         turn out to be easily circ= umvented. A more conservative design decision
         for FIPS 186 would have re= quired mandatory seed publication instead of
         making it optional.  = As a result, there are opaque, standardized 1024-bit
         and 2048-bit primes in wid= e use today that cannot be properly verified.

This is the strongest statement yet that I've seen to not trust any
of the RFC-5114 groups.

The latest 4307bis document has these groups (22-24) as SHOULD NOT,
stating:

         Group 22, 23 and 24 or 102= 4-bit MODP Group with 160-bit, and
         2048-bit MODP Group with 2= 24-bit and 256-bit Prime Order Subgroup
         have small subgroups, whic= h means that checks specified in the
         "Additional Diffie-He= llman Test for the IKEv2" [RFC6989] section
         2.2 first bullet point MUS= T be done when these groups are used.
         These groups are also not = safe-primes.  The seeds for these groups
         have not been publicly rel= eased, resulting in reduced trust in
         these groups.  These = groups were proposed as alternatives for
         group 2 and 14 but never s= aw wide deployment.  It is expected
         in the near future to be f= urther downgraded to MUST NOT.

I'm proposing it is time to change this to MUST NOT for 4307bis.

Possibly, we should do this via SAAG in general, and then follow SAAG's
advise in IPSECME.

Is there _any_ reason why group 22-24 should not be MUST NOT ?

Paul

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--_000_DM5PR09MB146726177114D0FD30F871C2F3DB0DM5PR09MB1467namp_-- From nobody Mon Oct 10 08:33:38 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D5B12971B; Mon, 10 Oct 2016 08:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.996 X-Spam-Level: X-Spam-Status: No, score=-4.996 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=-2.996] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ugvnpKkDGOT; Mon, 10 Oct 2016 08:33:32 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F88D129715; Mon, 10 Oct 2016 08:33:32 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3st40B2Tgbz1HJ; Mon, 10 Oct 2016 17:33:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1476113610; bh=GyymlYO9vWhfnP2Bu0V2eC91dSAQdNsi3P89VFu+Gf0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=CYdW3peqO7BzwTq+tB9TyZgJ8zT0cpHoym9GPtRA4PbffKEbUCn+4jkGhOHEhbO5D S0lR96mU6113QMPXpBQw+2IaUOBXVt1NZ2dR8vP/q4rkZOxj/DGzOFGlY9ske3mthq MMxlsoTN0WAKqcWNIpA2LafQnv/jAtV2672y07Po= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id x8nnBCBaOUxx; Mon, 10 Oct 2016 17:33:29 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 10 Oct 2016 17:33:29 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 98E4019C338; Mon, 10 Oct 2016 11:33:26 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 98E4019C338 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 90ACA40D3581; Mon, 10 Oct 2016 11:33:26 -0400 (EDT) Date: Mon, 10 Oct 2016 11:33:26 -0400 (EDT) From: Paul Wouters To: "Dang, Quynh (Fed)" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: "ipsec@ietf.org WG" , "saag@ietf.org" Subject: Re: [IPsec] trapdoor'ed DH (and RFC-5114 again) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 15:33:34 -0000 On Mon, 10 Oct 2016, Dang, Quynh (Fed) wrote: > A conclusion of the paper was "Our results are yet another reminder that 1024-bit primes should be considered insecure for the security of cryptosystems based on the hardness of discrete > logarithms. The discrete logarithm computation for our backdoored prime was only feasible because of the 1024-bit size, and the most effective protection against any backdoor of this > type has always been to use key sizes for which any computation is infeasible. NIST recommended transitioning away from 1024-bit key sizes for DSA, RSA, and Diffie-Hellman in 2010 [6]." > > NIST has been urging users to move away from groups with 1024- bit p and 160-bit q formany years now. Sure. > In our document, we stated that group generators "should" provide their seeds. The reason for having "should" instead of "shall (must)" was that anyone could run our suggested method to > generate their own group. A user who generates his/her own group for her/his own application could have a choice of publishing the seed or not. If a user had a contractor/third party to > generate a group for him/her, he or she could ask for all documentation about the whole process. But why should I trust the RFC-5114 2048-bit MODP Group with 256-bit Prime Order Subgroup? The problem of not knowing the seed remains the same. We just think the NSA does not have a mathemathical advantage over academia, but that's still a big unknown. And for IKE, you cannot just generate your own groups. Paul From nobody Mon Oct 10 10:09:45 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36EA8129749 for ; Mon, 10 Oct 2016 10:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jj1sGJRz_if8 for ; Mon, 10 Oct 2016 10:09:41 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (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 90FB012974A for ; Mon, 10 Oct 2016 10:09:41 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id 4FE55DD9F8CA8; Mon, 10 Oct 2016 17:09:38 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u9AH9eE2002124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Oct 2016 17:09:40 GMT Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u9AH9etW009104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Oct 2016 17:09:40 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.124]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0301.000; Mon, 10 Oct 2016 13:09:40 -0400 From: "Hu, Jun (Nokia - US)" To: Valery Smyslov , IPsecME WG Thread-Topic: [IPsec] vendor support of RFC7427 Thread-Index: AdIgwO7tRgE5exa4RkO04FEvfTSIKwCAUjZSABWKLvA= Date: Mon, 10 Oct 2016 17:09:41 +0000 Message-ID: <876523B00C3F9D47BFD2B654D63DBF92BEAABEF8@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <876523B00C3F9D47BFD2B654D63DBF92BEAA73FA@US70UWXCHMBA05.zam.alcatel-lucent.com> <2FBB5ECC7B8043F2B4E1A6141B3D4FE1@buildpc> In-Reply-To: <2FBB5ECC7B8043F2B4E1A6141B3D4FE1@buildpc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_876523B00C3F9D47BFD2B654D63DBF92BEAABEF8US70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] vendor support of RFC7427 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 17:09:44 -0000 --_000_876523B00C3F9D47BFD2B654D63DBF92BEAABEF8US70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, already noticed that thread, will have some comments on that thread From: Valery Smyslov [mailto:svanru@gmail.com] Sent: Sunday, October 09, 2016 11:48 PM To: Hu, Jun (Nokia - US); IPsecME WG Subject: Re: [IPsec] vendor support of RFC7427 Hi, we (ELVIS-PLUS) support RFC7427 for over a year and we are interoperable wi= th Strongswan. However, see my message about some interoperability problems: https://www.ietf.org/mail-archive/web/ipsec/current/msg10840.html This issue is scheduled for discussion on ipsecme meeting in Seoul. Regards, Valery Smyslov. ----- Original Message ----- From: Hu, Jun (Nokia - US) To: IPsecME WG Sent: Friday, October 07, 2016 8:33 PM Subject: [IPsec] vendor support of RFC7427 Hi, I plan to support RFC7427 on my product, however as part of inter-op planni= ng, I'd like to know current industry support status for it; The only implementation I know so far is Strongswan which supported it sinc= e ver5.3; It will be highly appreciated if you could share your product status or roa= dmap on this RFC ------ Hu Jun IP Routing, IP/Optical Networks, Nokia New Email: jun.hu@nokia.com ________________________________ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_876523B00C3F9D47BFD2B654D63DBF92BEAABEF8US70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks, already noticed that= thread, will have some comments on that thread

 

From: Valery S= myslov [mailto:svanru@gmail.com]
Sent: Sunday, October 09, 2016 11:48 PM
To: Hu, Jun (Nokia - US); IPsecME WG
Subject: Re: [IPsec] vendor support of RFC7427

 

Hi,

 

we (ELVIS-PLUS) support RFC7427 for = over a year and we are interoperable with Strongswan.

 

However, see my message about some i= nteroperability problems:

 

This issue is scheduled for discussi= on on ipsecme meeting in Seoul.

 

Regards,=

Valery Smyslov.

----- Original Message -----

To: IPsecME WG <= o:p>

Sent: Friday, Oc= tober 07, 2016 8:33 PM

Subject: [IPsec]= vendor support of RFC7427

 

Hi,

I plan to support RFC7427 on my product, h= owever as part of inter-op planning, I’d like to know current industr= y support status for it;

The only implementation I know so far is S= trongswan which supported it since ver5.3;

It will be highly appreciated if you could= share your product status or roadmap on this RFC

 

------

Hu Jun

IP Routing, IP/Optical Networks, Nokia

New Email: jun.hu@nokia.com<= /p>

 

____________________________________= ___________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.or= g/mailman/listinfo/ipsec

--_000_876523B00C3F9D47BFD2B654D63DBF92BEAABEF8US70UWXCHMBA05z_-- From nobody Mon Oct 10 17:42:32 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9F11297B4 for ; Mon, 10 Oct 2016 17:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3ZvCWIF91py for ; Mon, 10 Oct 2016 17:42:29 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC957124281 for ; Mon, 10 Oct 2016 17:42:28 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id r30so9870365ioi.1 for ; Mon, 10 Oct 2016 17:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=rLScub/0QH/3R5ttQ9ekf2iU0/KjldGzphm72Y2DdK0=; b=GWHjT6IfMWgCfqoKP9QkRKYqxSUmmCbjz+7cE3+WFwqiJdS8pRwXbPCXBlkD0fkJL7 wHaTgzN57PqnmCf9w6HKpUZUI7B6nLepCdHTBlHgbj56wkZ4xOZ1PqBWXKZ2que3whm9 /cBzPggHqzNCF2LOOPCeUTF8A4EKaOYhZPpaBp7Z5ROZ0mSd18D0NsGSVWCi0SQh1rDq 6GC1Pny7EXrAUZef3AaMgNeLGeMgKJx+9imBrHEZbzFh67WIhVG/MVUbvRZrGj5XbDyR HmJUgINpLNUiR4hcHFTYFUg75izi2uDn1BhZmBHSXo7soKBDl7FET8n2WElTQ/a/iMsG AtjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=rLScub/0QH/3R5ttQ9ekf2iU0/KjldGzphm72Y2DdK0=; b=BrRkb39hLjx7oSmWlC6vZQyq6Y731xEwXda46+dRl4RpZVoadVMrKmwtditJaauNOO N5dx1py0/S1vUnPO8BZf66lYeBbg5o/UMUWN9TLkGyQ2C0cPWYMCf0Hq8fegmqBAy2Hh vGSLLqFolTxYnub9vEcRDX/AmHsWmduP0t0IN7dpcS5onLgFUTVkfq5WxxO/jkYCQkoo p/0JemHW4oEx//+8MR5nxguGhdfHYNPt2k2pdbTv8D91xjuaTJtwK2OtwwY8mKGRwwDn ebc5z6JGyfgzCGSYK2eNG+ArsosKT/TWmLyrQVm+C2wZeTtLRYO36GtWFY+rOcHQSpXl xgdg== X-Gm-Message-State: AA6/9Rkeqav60V1pBD1q3HaZYxPvZjc9B6cZnW6g1UdBrtV+S9QkQKS0tJeSvsbprvcodpmz+6PyyP9+bByljA== X-Received: by 10.107.29.21 with SMTP id d21mr2490204iod.10.1476146548206; Mon, 10 Oct 2016 17:42:28 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.188.4 with HTTP; Mon, 10 Oct 2016 17:42:27 -0700 (PDT) In-Reply-To: References: <147594692832.28921.7850239516371972090.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C117F98570@eusaamb107.ericsson.se> From: Daniel Migault Date: Mon, 10 Oct 2016 20:42:27 -0400 X-Google-Sender-Auth: XiYisKQ71epGR6n0VCML4Q0pYq0 Message-ID: To: Valery Smyslov Content-Type: multipart/alternative; boundary=001a1140a4faa49730053e8c26c2 Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] FW: New Version Notification fordraft-mglt-ipsecme-implicit-iv-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 00:42:31 -0000 --001a1140a4faa49730053e8c26c2 Content-Type: text/plain; charset=UTF-8 Absolutely, we need to re-inforce this statement in the security consideration. This will be done in the next version. Thanks for the clarification! BR, Daniel On Mon, Oct 10, 2016 at 3:05 AM, Valery Smyslov wrote: > Hi Daniel, > > I think you should add a text in the Security Considerations that these > transforms MUST NOT be used in situations where there is a chance that > Sequence Numbers repeat. The most prominent example where it can happen - > multicast ESP SA with multiple senders. > > Regards, > Valery. > > > > Hi, >> >> Based on the feed backs and the discussions from the previous IETF, see >> the updated version of our draft. We believe the document is in good shape >> to become a WG document. >> >> Feel free to support the draft and as usually, comments are welcome! >> >> BR, >> Daniel >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Saturday, October 08, 2016 7:15 PM >> To: Tobias Guggemos ; Yoav Nir < >> ynir.ietf@gmail.com>; Daniel Migault >> Subject: New Version Notification for draft-mglt-ipsecme-implicit-iv >> -01.txt >> >> >> A new version of I-D, draft-mglt-ipsecme-implicit-iv-01.txt >> has been successfully submitted by Daniel Migault and posted to the IETF >> repository. >> >> Name: draft-mglt-ipsecme-implicit-iv >> Revision: 01 >> Title: Implicit IV for Counter-based Ciphers in IPsec >> Document date: 2016-10-08 >> Group: Individual Submission >> Pages: 6 >> URL: https://www.ietf.org/internet- >> drafts/draft-mglt-ipsecme-implicit-iv-01.txt >> Status: https://datatracker.ietf.org/ >> doc/draft-mglt-ipsecme-implicit-iv/ >> Htmlized: https://tools.ietf.org/html/d >> raft-mglt-ipsecme-implicit-iv-01 >> Diff: https://www.ietf.org/rfcdiff? >> url2=draft-mglt-ipsecme-implicit-iv-01 >> >> Abstract: >> IPsec ESP sends an initialization vector (IV) or nonce in each >> packet, adding 8 or 16 octets. Some algorithms such as AES-GCM, AES- >> CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not >> require an unpredictable nonce. When using such algorithms the >> packet counter value can be used to generate a nonce, saving 8 octets >> per packet. This document describes how to do this. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> The IETF Secretariat >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --001a1140a4faa49730053e8c26c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Absolutely, we need to re-inforce this statement= in the security consideration. This will be done in the next version. Than= ks for the clarification!

BR,
Daniel=C2=A0

On Mon, Oct 10, = 2016 at 3:05 AM, Valery Smyslov <svanru@gmail.com> wrote:
=
Hi Daniel,

I think you should add a text in the Security Considerations that these
transforms MUST NOT be used in situations where there is a chance that
Sequence Numbers repeat. The most prominent example where it can happen - multicast ESP SA with multiple senders.

Regards,
Valery.



Hi,

Based on the feed backs and the discussions from the previous IETF, see the= updated version of our draft. We believe the document is in good shape to = become a WG document.

Feel free to support the draft and as usually, comments are welcome!

BR,
Daniel

-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Saturday, October 08, 2016 7:15 PM
To: Tobias Guggemos <tobias.guggemos@gmail.com>; Yoav Nir <ynir.ietf@gmail.com>; Dani= el Migault <daniel.migault@ericsson.com>
Subject: New Version Notification for draft-mglt-ipsecme-implicit-iv-0= 1.txt


A new version of I-D, draft-mglt-ipsecme-implicit-iv-01.txt
has been successfully submitted by Daniel Migault and posted to the IETF re= pository.

Name: draft-mglt-ipsecme-implicit-iv
Revision: 01
Title: Implicit IV for Counter-based Ciphers in IPsec
Document date: 2016-10-08
Group: Individual Submission
Pages: 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mglt-ip= secme-implicit-iv-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit= -iv/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://tools.ietf.org/html/draft-mglt-ipsecme-implicit-iv-01 Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-mglt-ipsecme-= implicit-iv-01

Abstract:
=C2=A0 IPsec ESP sends an initialization vector (IV) or nonce in each
=C2=A0 packet, adding 8 or 16 octets.=C2=A0 Some algorithms such as AES-GCM= , AES-
=C2=A0 CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not=
=C2=A0 require an unpredictable nonce.=C2=A0 When using such algorithms the=
=C2=A0 packet counter value can be used to generate a nonce, saving 8 octet= s
=C2=A0 per packet.=C2=A0 This document describes how to do this.




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

The IETF Secretariat

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--001a1140a4faa49730053e8c26c2-- From nobody Tue Oct 11 12:37:44 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FBC1294B7; Tue, 11 Oct 2016 12:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQ9nLC_pfRz5; Tue, 11 Oct 2016 12:37:39 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56046129544; Tue, 11 Oct 2016 12:37:39 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id o81so5070915wma.1; Tue, 11 Oct 2016 12:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=S0rFZVpvYmwX2L+LaRQ31Bd25hMpVio+vgF1XASejio=; b=ykpIYQELmXliSpqI4YVVoDFFSSH2s6oy1sMGFCgC+7x+LUzLb3jgSRAWXn7vaTNjUb gJwdn9b7+faklJI7nVRZqUeq1c3qNCHEetqJEWy+hGEXdrxdq2rwdOPr96u9xTwukfC/ Es1LQAO7XB3v/GufFQO0++WPX9gzOOlbPPab/vR7TKt5r3nlGHG3saSEdNpmkemG3GZ5 8mA386HvLWg7kCSWAwJooWuh8t7s9+ZRmE0/n4p3ojYIbMc0dKGrkkFjMk1dZK7z4kmG to6SAeEACebiu4YW05EwHQN8qnCVMR4W75KPnX47k78znmez3kiTC6xHqtoeZpcaQUZM KlWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=S0rFZVpvYmwX2L+LaRQ31Bd25hMpVio+vgF1XASejio=; b=H881TPppkr51rhQbCqxGnS3lHOAbK7GhgkRXH3Xf8nXPCgHM0bg+ZnulU3be7DHSRP 7jwotd5Qz88H+7ZZKd6Q2p1SFtRY/bPwwKWBAnwqS950drO0Lgsup5ZGyQv4i4QJ4+Kd oa22HUOHXiUFw6sIXT2oBmjZsHI90RFb73Ea2mdT03J4H7vPYYH6vBnZ3I9B12LjiN+p 7B3oQ6S8nJWuQzj9iaL6KAc4k9kiEMrV1tVUVoEybT1n/0c3zguHWQIr/d29Z8qALBW5 XP/6bCmOiR8ElsX2OPxoUtAAw98bfOwca64uPpwg9UGFNAor5zl3zc12E9uZuVfaEgjU dH6g== X-Gm-Message-State: AA6/9Rm5gaLoOhPK9CQSTE3tssLR+vwOiBlfiOWjZMkJJg28OMXQxgQ824IKUa6BIfo0eA== X-Received: by 10.28.155.133 with SMTP id d127mr310724wme.110.1476214657810; Tue, 11 Oct 2016 12:37:37 -0700 (PDT) Received: from [192.168.1.13] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id vx7sm8748950wjc.1.2016.10.11.12.37.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Oct 2016 12:37:36 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_44AD3DFD-770B-4618-95A7-5EF49552C4DA" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Tue, 11 Oct 2016 22:37:34 +0300 In-Reply-To: To: Kathleen Moriarty References: X-Mailer: Apple Mail (2.3226) Archived-At: Cc: "ipsec@ietf.org" , Orit Levin , "draft-ietf-ipsecme-safecurves.all@ietf.org" , General Area Review Team Subject: Re: [IPsec] Gen-ART Last Call review of draft-ietf-ipsecme-safecurves-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 19:37:42 -0000 --Apple-Mail=_44AD3DFD-770B-4618-95A7-5EF49552C4DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for that. For some reason gmail sent this to the spam folder. Yoav > On 7 Oct 2016, at 20:32, Kathleen Moriarty = wrote: >=20 > Orit, >=20 > Thanks for the review, making sure the editor see this. >=20 > Kathleen >=20 > On Tue, Sep 27, 2016 at 5:30 PM, Orit Levin > wrote: > I am the assigned Gen-ART reviewer for this draft. The General Area = Review Team (Gen-ART) reviews all IETF documents being processed by the = IESG for the IETF Chair. Please treat these comments just like any = other last call comments. >=20 > For more information, please see the FAQ at = >. >=20 > Document: review of draft-ietf-ipsecme-safecurves-04 > Reviewer: Orit Levin (mailto:oritl@microsoft.com = ) > Review Date: 2016-09-27 > IETF LC End Date: 2016-09-29 > IESG Telechat date: unknown >=20 > Summary: > This draft is basically ready for publication, but has nits that = should be fixed before publication. The nits are purely editorial, but = fixing them will improve the document's readability. >=20 > 1. Introduction > Par.1 "key agreement (Diffie-Hellman)" : Replace with "key agreement = using Diffie-Hellman". > Par.2 "That document": Replace with the name of the document to make = clear which one is "that" document. > Par.2 "free from": Replace with "resilient to". >=20 > 2. Curve25519 and Curve448 > Add at the start "Implementations of Curve25519 and Curve448 = MUST/SHALL follow the steps described in this section." > Par.1 Replace "are inherited from" with "are compliant with". > Par.2 Replace "goes as" with "is performed as" >=20 > 3. Use and Negotiation in IKEv2 > Consider replacing TBA1/TBA2 throughout the section with [to be = replaced with TBA1/TBA2 according to the IANA assignment]. > 3.2 Consider replace the first sentence with > "Receiving and handling of incompatible point formats MUST comply with = [or MUST follow] considerations/procedures described in section 5 of = [RFC7748]." >=20 > 4. Security Considerations > Par.1 Replace the paragraph text to > "For high-performance constant-time implementations, it is RECOMMENDED = to use Curve25519 and Curve448 which were designed for this purpose. = Implementers MUST/SHOULD NOT attempt to improve performance by reusing = supposedly ephemeral key pair across multiple key exchanges [because = ...]." > Par.3 In " ... the process used to pick these curves..." replace = "these" with the names to avoid confusion. > Par.3 Replace " ...verification has been done..." with "verification = can be done". > Par.4 Replace ",generated in a fully verifiable way," with "that are = generated in a fully verifiable way". >=20 > 6. Acknowledgements > Par1. Replace "is by Mike" with "were defined/specified/etc. by Mike". > Par1. Replace "are in RFC 7748" with " are documented/specified/etc. = in RFC 7748". >=20 > Thank you, > Orit. >=20 >=20 >=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen --Apple-Mail=_44AD3DFD-770B-4618-95A7-5EF49552C4DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Thanks for that.

For some reason gmail sent this to the spam folder.

Yoav

On 7 Oct 2016, at 20:32, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Orit,

Thanks for the review, making sure the editor see = this.

Kathleen

On Tue, Sep 27, 2016 at 5:30 PM, = Orit Levin <oritl@microsoft.com> wrote:
I am the assigned = Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) = reviews all IETF documents being processed by the IESG for the IETF = Chair.  Please treat these comments just like any other last call = comments.

For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: review of draft-ietf-ipsecme-safecurves-04
Reviewer: Orit Levin (mailto:oritl@microsoft.com)
Review Date: 2016-09-27
IETF LC End Date: 2016-09-29
IESG Telechat date: unknown

Summary:
This draft is basically ready for publication, but has nits that should = be fixed before publication. The nits are purely editorial, but fixing = them will improve the document's readability.

1. Introduction
Par.1 "key agreement (Diffie-Hellman)" : Replace with "key agreement = using Diffie-Hellman".
Par.2 "That document": Replace with the name of the document to make = clear which one is "that" document.
Par.2 "free from": Replace with "resilient to".

2. Curve25519 and Curve448
Add at the start "Implementations of Curve25519 and Curve448 MUST/SHALL = follow the steps described in this section."
Par.1 Replace "are inherited from" with "are compliant with".
Par.2 Replace "goes as" with "is performed as"

3. Use and Negotiation in IKEv2
Consider replacing TBA1/TBA2 throughout the section with [to be replaced = with TBA1/TBA2 according to the IANA assignment].
3.2 Consider replace the first sentence with
"Receiving and handling of incompatible point formats MUST comply with = [or MUST follow] considerations/procedures described in section 5 of = [RFC7748]."

4. Security Considerations
Par.1 Replace the paragraph text to
"For high-performance constant-time implementations, it is RECOMMENDED = to use Curve25519 and Curve448 which were designed for this purpose. = Implementers MUST/SHOULD NOT attempt to improve performance by reusing = supposedly ephemeral key pair across multiple key exchanges [because = ...]."
Par.3 In " ... the process used to pick these curves..." replace "these" = with the names to avoid confusion.
Par.3 Replace " ...verification has been done..." with "verification can = be done".
Par.4 Replace ",generated in a fully verifiable way," with "that are = generated in a fully verifiable way".

6. Acknowledgements
Par1. Replace "is by Mike" with "were defined/specified/etc. by = Mike".
Par1. Replace "are in RFC 7748" with " are documented/specified/etc. in = RFC 7748".

Thank you,
Orit.






--

Best = regards,
Kathleen

= --Apple-Mail=_44AD3DFD-770B-4618-95A7-5EF49552C4DA-- From nobody Tue Oct 11 12:37:51 2016 Return-Path: X-Original-To: expand-draft-ietf-ipsecme-safecurves.all@virtual.ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 41647129554; Tue, 11 Oct 2016 12:37:42 -0700 (PDT) X-Original-To: xfilter-draft-ietf-ipsecme-safecurves.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-ipsecme-safecurves.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FBC1294B7; Tue, 11 Oct 2016 12:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQ9nLC_pfRz5; Tue, 11 Oct 2016 12:37:39 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56046129544; Tue, 11 Oct 2016 12:37:39 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id o81so5070915wma.1; Tue, 11 Oct 2016 12:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=S0rFZVpvYmwX2L+LaRQ31Bd25hMpVio+vgF1XASejio=; b=ykpIYQELmXliSpqI4YVVoDFFSSH2s6oy1sMGFCgC+7x+LUzLb3jgSRAWXn7vaTNjUb gJwdn9b7+faklJI7nVRZqUeq1c3qNCHEetqJEWy+hGEXdrxdq2rwdOPr96u9xTwukfC/ Es1LQAO7XB3v/GufFQO0++WPX9gzOOlbPPab/vR7TKt5r3nlGHG3saSEdNpmkemG3GZ5 8mA386HvLWg7kCSWAwJooWuh8t7s9+ZRmE0/n4p3ojYIbMc0dKGrkkFjMk1dZK7z4kmG to6SAeEACebiu4YW05EwHQN8qnCVMR4W75KPnX47k78znmez3kiTC6xHqtoeZpcaQUZM KlWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=S0rFZVpvYmwX2L+LaRQ31Bd25hMpVio+vgF1XASejio=; b=H881TPppkr51rhQbCqxGnS3lHOAbK7GhgkRXH3Xf8nXPCgHM0bg+ZnulU3be7DHSRP 7jwotd5Qz88H+7ZZKd6Q2p1SFtRY/bPwwKWBAnwqS950drO0Lgsup5ZGyQv4i4QJ4+Kd oa22HUOHXiUFw6sIXT2oBmjZsHI90RFb73Ea2mdT03J4H7vPYYH6vBnZ3I9B12LjiN+p 7B3oQ6S8nJWuQzj9iaL6KAc4k9kiEMrV1tVUVoEybT1n/0c3zguHWQIr/d29Z8qALBW5 XP/6bCmOiR8ElsX2OPxoUtAAw98bfOwca64uPpwg9UGFNAor5zl3zc12E9uZuVfaEgjU dH6g== X-Gm-Message-State: AA6/9Rm5gaLoOhPK9CQSTE3tssLR+vwOiBlfiOWjZMkJJg28OMXQxgQ824IKUa6BIfo0eA== X-Received: by 10.28.155.133 with SMTP id d127mr310724wme.110.1476214657810; Tue, 11 Oct 2016 12:37:37 -0700 (PDT) Received: from [192.168.1.13] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id vx7sm8748950wjc.1.2016.10.11.12.37.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Oct 2016 12:37:36 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_44AD3DFD-770B-4618-95A7-5EF49552C4DA" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Tue, 11 Oct 2016 22:37:34 +0300 In-Reply-To: To: Kathleen Moriarty References: X-Mailer: Apple Mail (2.3226) Resent-From: Resent-To: ynir.ietf@gmail.com, simon@josefsson.org, david.waltermire@nist.gov, kivinen@iki.fi, Kathleen.Moriarty.ietf@gmail.com, stephen.farrell@cs.tcd.ie, "Tero Kivinen" , ipsec@ietf.org Resent-Message-Id: <20161011193742.41647129554@ietfa.amsl.com> Resent-Date: Tue, 11 Oct 2016 12:37:42 -0700 (PDT) Archived-At: Cc: "ipsec@ietf.org" , Orit Levin , "draft-ietf-ipsecme-safecurves.all@ietf.org" , General Area Review Team Subject: Re: [IPsec] Gen-ART Last Call review of draft-ietf-ipsecme-safecurves-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 19:37:42 -0000 --Apple-Mail=_44AD3DFD-770B-4618-95A7-5EF49552C4DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for that. For some reason gmail sent this to the spam folder. Yoav > On 7 Oct 2016, at 20:32, Kathleen Moriarty = wrote: >=20 > Orit, >=20 > Thanks for the review, making sure the editor see this. >=20 > Kathleen >=20 > On Tue, Sep 27, 2016 at 5:30 PM, Orit Levin > wrote: > I am the assigned Gen-ART reviewer for this draft. The General Area = Review Team (Gen-ART) reviews all IETF documents being processed by the = IESG for the IETF Chair. Please treat these comments just like any = other last call comments. >=20 > For more information, please see the FAQ at = >. >=20 > Document: review of draft-ietf-ipsecme-safecurves-04 > Reviewer: Orit Levin (mailto:oritl@microsoft.com = ) > Review Date: 2016-09-27 > IETF LC End Date: 2016-09-29 > IESG Telechat date: unknown >=20 > Summary: > This draft is basically ready for publication, but has nits that = should be fixed before publication. The nits are purely editorial, but = fixing them will improve the document's readability. >=20 > 1. Introduction > Par.1 "key agreement (Diffie-Hellman)" : Replace with "key agreement = using Diffie-Hellman". > Par.2 "That document": Replace with the name of the document to make = clear which one is "that" document. > Par.2 "free from": Replace with "resilient to". >=20 > 2. Curve25519 and Curve448 > Add at the start "Implementations of Curve25519 and Curve448 = MUST/SHALL follow the steps described in this section." > Par.1 Replace "are inherited from" with "are compliant with". > Par.2 Replace "goes as" with "is performed as" >=20 > 3. Use and Negotiation in IKEv2 > Consider replacing TBA1/TBA2 throughout the section with [to be = replaced with TBA1/TBA2 according to the IANA assignment]. > 3.2 Consider replace the first sentence with > "Receiving and handling of incompatible point formats MUST comply with = [or MUST follow] considerations/procedures described in section 5 of = [RFC7748]." >=20 > 4. Security Considerations > Par.1 Replace the paragraph text to > "For high-performance constant-time implementations, it is RECOMMENDED = to use Curve25519 and Curve448 which were designed for this purpose. = Implementers MUST/SHOULD NOT attempt to improve performance by reusing = supposedly ephemeral key pair across multiple key exchanges [because = ...]." > Par.3 In " ... the process used to pick these curves..." replace = "these" with the names to avoid confusion. > Par.3 Replace " ...verification has been done..." with "verification = can be done". > Par.4 Replace ",generated in a fully verifiable way," with "that are = generated in a fully verifiable way". >=20 > 6. Acknowledgements > Par1. Replace "is by Mike" with "were defined/specified/etc. by Mike". > Par1. Replace "are in RFC 7748" with " are documented/specified/etc. = in RFC 7748". >=20 > Thank you, > Orit. >=20 >=20 >=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen --Apple-Mail=_44AD3DFD-770B-4618-95A7-5EF49552C4DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Thanks for that.

For some reason gmail sent this to the spam folder.

Yoav

On 7 Oct 2016, at 20:32, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Orit,

Thanks for the review, making sure the editor see = this.

Kathleen

On Tue, Sep 27, 2016 at 5:30 PM, = Orit Levin <oritl@microsoft.com> wrote:
I am the assigned = Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) = reviews all IETF documents being processed by the IESG for the IETF = Chair.  Please treat these comments just like any other last call = comments.

For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: review of draft-ietf-ipsecme-safecurves-04
Reviewer: Orit Levin (mailto:oritl@microsoft.com)
Review Date: 2016-09-27
IETF LC End Date: 2016-09-29
IESG Telechat date: unknown

Summary:
This draft is basically ready for publication, but has nits that should = be fixed before publication. The nits are purely editorial, but fixing = them will improve the document's readability.

1. Introduction
Par.1 "key agreement (Diffie-Hellman)" : Replace with "key agreement = using Diffie-Hellman".
Par.2 "That document": Replace with the name of the document to make = clear which one is "that" document.
Par.2 "free from": Replace with "resilient to".

2. Curve25519 and Curve448
Add at the start "Implementations of Curve25519 and Curve448 MUST/SHALL = follow the steps described in this section."
Par.1 Replace "are inherited from" with "are compliant with".
Par.2 Replace "goes as" with "is performed as"

3. Use and Negotiation in IKEv2
Consider replacing TBA1/TBA2 throughout the section with [to be replaced = with TBA1/TBA2 according to the IANA assignment].
3.2 Consider replace the first sentence with
"Receiving and handling of incompatible point formats MUST comply with = [or MUST follow] considerations/procedures described in section 5 of = [RFC7748]."

4. Security Considerations
Par.1 Replace the paragraph text to
"For high-performance constant-time implementations, it is RECOMMENDED = to use Curve25519 and Curve448 which were designed for this purpose. = Implementers MUST/SHOULD NOT attempt to improve performance by reusing = supposedly ephemeral key pair across multiple key exchanges [because = ...]."
Par.3 In " ... the process used to pick these curves..." replace "these" = with the names to avoid confusion.
Par.3 Replace " ...verification has been done..." with "verification can = be done".
Par.4 Replace ",generated in a fully verifiable way," with "that are = generated in a fully verifiable way".

6. Acknowledgements
Par1. Replace "is by Mike" with "were defined/specified/etc. by = Mike".
Par1. Replace "are in RFC 7748" with " are documented/specified/etc. in = RFC 7748".

Thank you,
Orit.






--

Best = regards,
Kathleen

= --Apple-Mail=_44AD3DFD-770B-4618-95A7-5EF49552C4DA-- From nobody Tue Oct 11 12:46:44 2016 Return-Path: X-Original-To: expand-draft-ietf-ipsecme-safecurves.all@virtual.ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 484B8129687; Tue, 11 Oct 2016 12:46:40 -0700 (PDT) X-Original-To: xfilter-draft-ietf-ipsecme-safecurves.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-ipsecme-safecurves.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1709E1294B7; Tue, 11 Oct 2016 12:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDQ2CYP0OqCk; Tue, 11 Oct 2016 12:46:30 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD237129696; Tue, 11 Oct 2016 12:46:24 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id b201so5770082wmb.0; Tue, 11 Oct 2016 12:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xlXcGvCVxU7LMc35h9jVCF5SfHO94GwGEktQh2AdOqc=; b=oLB+7v7jMFDPi65uypkfu3ssPp3DbLKlT92SecCcpKRcF0faG3OQH7FCT0cCDkQ4Eo EK5Z/uPb8OD07hGPxHLGQm6UyG8M1hJLo+vhcusRi8ZBhOIZPDiqAO4BRo5QocgkyYab tRIDJIon+HWNQjsVCF0Fc7s0aIJcCTCfoMYYN5EItH4yHMmCZ1835+v87z7olZk6qpUM hpaxZONlrb4IPjpmxrx91ZoBHwzjeUZglV8S8ll9FHHLZ+bfKDRqOufE49N0dkVteE1Q Erp7DZ+rpzmhlRNPKMwYehBKWuRzDMbBtbT98yu+4j9sYtMN5D21Z7O25uzf0xUwYWW3 wR1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xlXcGvCVxU7LMc35h9jVCF5SfHO94GwGEktQh2AdOqc=; b=alqu+TnEYcpqxuwk2IAiwGNHpvAdAf1mrKwFopgrX+9CUx3WqYvgfif94pFuGaQJdj NPvhhGIb2gUdDqpu1pcNJCscTnhNwj8j86r20kxQN3E6Vc0Wy+WCvEQUE0UopPhoWpYV +B6FjU0WTqNzEtclczxLy+AOpNQ8Tv3Dt/SHOpe03LlJs8Dt84w2mKZd9nhz8snCyh8+ upxcLgpt4FbmXEDqZragLIQisV9XsIdPi730ukdToXjEoO4EcV+mhiHicfKRkj4e0/mW vTQE1bM9ArfPVcNq2tdJg/I8/x61QPOsjOEOP5V3ZHVvpSFujrdEOhI4//Kzw36mpgpQ ocDg== X-Gm-Message-State: AA6/9Rnr/t7FfusUkptuvaTfqC7RjdWQWgSfZbydMYX/3rv2UDy8NuiHNhlgBemRf4tCHw== X-Received: by 10.28.91.201 with SMTP id p192mr338521wmb.60.1476215183311; Tue, 11 Oct 2016 12:46:23 -0700 (PDT) Received: from [192.168.1.13] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id f127sm433246wma.5.2016.10.11.12.46.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Oct 2016 12:46:22 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Yoav Nir In-Reply-To: Date: Tue, 11 Oct 2016 22:46:19 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0634F364-C8D4-45EB-9FD8-214FD9C1E72E@gmail.com> References: To: Orit Levin X-Mailer: Apple Mail (2.3226) Resent-From: Resent-To: ynir.ietf@gmail.com, simon@josefsson.org, david.waltermire@nist.gov, kivinen@iki.fi, Kathleen.Moriarty.ietf@gmail.com, stephen.farrell@cs.tcd.ie, "Tero Kivinen" , ipsec@ietf.org Resent-Message-Id: <20161011194640.484B8129687@ietfa.amsl.com> Resent-Date: Tue, 11 Oct 2016 12:46:40 -0700 (PDT) Archived-At: Cc: General Area Review Team , "draft-ietf-ipsecme-safecurves.all@ietf.org" Subject: Re: [IPsec] Gen-ART Last Call review of draft-ietf-ipsecme-safecurves-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 19:46:40 -0000 Hi, Orit. I accepted most of your suggestions with a few exceptions below: > On 28 Sep 2016, at 0:30, Orit Levin wrote: >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area = Review Team (Gen-ART) reviews all IETF documents being processed by the = IESG for the IETF Chair. Please treat these comments just like any = other last call comments. >=20 > For more information, please see the FAQ at = . >=20 > Document: review of draft-ietf-ipsecme-safecurves-04 > Reviewer: Orit Levin (mailto:oritl@microsoft.com)=20 > Review Date: 2016-09-27 > IETF LC End Date: 2016-09-29=20 > IESG Telechat date: unknown >=20 > Summary: > This draft is basically ready for publication, but has nits that = should be fixed before publication. The nits are purely editorial, but = fixing them will improve the document's readability. >=20 > 1. Introduction > Par.1 "key agreement (Diffie-Hellman)" : Replace with "key agreement = using Diffie-Hellman". > Par.2 "That document": Replace with the name of the document to make = clear which one is "that" document. > Par.2 "free from": Replace with "resilient to". >=20 > 2. Curve25519 and Curve448 > Add at the start "Implementations of Curve25519 and Curve448 = MUST/SHALL follow the steps described in this section." > Par.1 Replace "are inherited from" with "are compliant with". > Par.2 Replace "goes as" with "is performed as" >=20 > 3. Use and Negotiation in IKEv2 > Consider replacing TBA1/TBA2 throughout the section with [to be = replaced with TBA1/TBA2 according to the IANA assignment]. I have left this as is. This worked for me in the past. I will make sure = these were replaced during AUTH48. > 3.2 Consider replace the first sentence with=20 > "Receiving and handling of incompatible point formats MUST comply with = [or MUST follow] considerations/procedures described in section 5 of = [RFC7748].=E2=80=9D I ended up with this: 3.2. Recipient Tests Receiving and handling of incompatible point formats MUST follow the considerations described in section 5 of [RFC7748]. In particular, receiving entities MUST mask the most-significant bit in the final byte for X25519 (but not X448), and implementations MUST accept non- canonical values. >=20 > 4. Security Considerations > Par.1 Replace the paragraph text to > "For high-performance constant-time implementations, it is RECOMMENDED = to use Curve25519 and Curve448 which were designed for this purpose. = Implementers MUST/SHOULD NOT attempt to improve performance by reusing = supposedly ephemeral key pair across multiple key exchanges [because = ...].=E2=80=9D Your suggested text says that reusing ephemeral keys is a bad thing. = Reading over the original text I can see that it could be interpreted = like that. This was not our intention. Reusing ephemeral keys is OK. You = MUST use a constant-time implementation because otherwise each use of = the same ephemeral key may leak a few bits. So if you are reusing the = keys, it is especially important to use constant-time implementations, = whereas if you only used each key once, it would be kind-of OK to use = any implementation. I=E2=80=99ve reworded the paragraph as follows: Curve25519 and Curve448 are designed to facilitate the production of high-performance constant-time implementations. Implementors are encouraged to use a constant-time implementation of the functions. This point is of crucial importance especially if the implementation chooses to reuse its ephemeral key pair in many key exchanges for performance reasons. > Par.3 In " ... the process used to pick these curves..." replace = "these" with the names to avoid confusion. > Par.3 Replace " ...verification has been done..." with "verification = can be done". > Par.4 Replace ",generated in a fully verifiable way," with "that are = generated in a fully verifiable way". >=20 > 6. Acknowledgements > Par1. Replace "is by Mike" with "were defined/specified/etc. by Mike". > Par1. Replace "are in RFC 7748" with " are documented/specified/etc. = in RFC 7748". >=20 > Thank you, > Orit. >=20 >=20 >=20 From nobody Tue Oct 11 12:48:48 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8851294B7; Tue, 11 Oct 2016 12:48:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147621532757.32066.2999466581600136490.idtracker@ietfa.amsl.com> Date: Tue, 11 Oct 2016 12:48:47 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-safecurves-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 19:48:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : Curve25519 and Curve448 for IKEv2 Key Agreement Authors : Yoav Nir Simon Josefsson Filename : draft-ietf-ipsecme-safecurves-05.txt Pages : 7 Date : 2016-10-11 Abstract: This document describes the use of Curve25519 and Curve448 for ephemeral key exchange in the Internet Key Exchange (IKEv2) protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-safecurves/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-safecurves-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-safecurves-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 11 12:48:54 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F97D129690; Tue, 11 Oct 2016 12:48:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , "Tero Kivinen" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147621532765.32066.9619717109471219629.idtracker@ietfa.amsl.com> Date: Tue, 11 Oct 2016 12:48:47 -0700 Archived-At: Subject: [IPsec] New Version Notification - draft-ietf-ipsecme-safecurves-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 19:48:47 -0000 A new version (-05) has been submitted for draft-ietf-ipsecme-safecurves: https://www.ietf.org/internet-drafts/draft-ietf-ipsecme-safecurves-05.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-safecurves/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-safecurves-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Tue Oct 11 13:02:39 2016 Return-Path: X-Original-To: expand-draft-ietf-ipsecme-safecurves.all@virtual.ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 9F3781295A0; Tue, 11 Oct 2016 13:02:35 -0700 (PDT) X-Original-To: xfilter-draft-ietf-ipsecme-safecurves.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-ipsecme-safecurves.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74662129511; Tue, 11 Oct 2016 13:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBiZfDK7tQJd; Tue, 11 Oct 2016 13:02:32 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0136.outbound.protection.outlook.com [104.47.32.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A1A01295A0; Tue, 11 Oct 2016 13:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lzJBKngAcG/jdRYhnJqpLZ4WIWNOdc3viN27n1hFEtU=; b=jXWlVaab5jfq39V6wDP0zPqrAANlRGlJaNcZhJXVO0VpNtipHqrRHPk1dicVhO45cQw0/U9Sofoo0I3QGC/mBgEGFhIOA1R82uhzu5YHlI90hdcAANXIWq9g8Iq7R7uoRuqtlmznsXtPQR9VxG7rkcpmwoY7p3er2o0SHy/a5FQ= Received: from CY1PR0301MB2122.namprd03.prod.outlook.com (10.164.2.156) by CY1PR0301MB2122.namprd03.prod.outlook.com (10.164.2.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Tue, 11 Oct 2016 20:02:29 +0000 Received: from CY1PR0301MB2122.namprd03.prod.outlook.com ([10.164.2.156]) by CY1PR0301MB2122.namprd03.prod.outlook.com ([10.164.2.156]) with mapi id 15.01.0659.020; Tue, 11 Oct 2016 20:02:29 +0000 From: Orit Levin To: Yoav Nir Thread-Topic: Gen-ART Last Call review of draft-ietf-ipsecme-safecurves-04 Thread-Index: AdIYRMTnYgS2dtIPTa+wJMIZyuxSKALs13mAAACIvYA= Date: Tue, 11 Oct 2016 20:02:29 +0000 Message-ID: References: <0634F364-C8D4-45EB-9FD8-214FD9C1E72E@gmail.com> In-Reply-To: <0634F364-C8D4-45EB-9FD8-214FD9C1E72E@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=oritl@microsoft.com; x-originating-ip: [2001:4898:80e8:a::2d5] x-ms-office365-filtering-correlation-id: e38a6f1c-9869-4206-2d8f-08d3f21187b1 x-microsoft-exchange-diagnostics: 1; CY1PR0301MB2122; 7:8m5ZoMPQKHMQoDc4KWPj2SurMAeu4N5BLoFZv0fk7hwcvbJJbUpWpKuLrcNp9xUUIyzpL7TNGaTvBrO+f8jxhPfTg9H5YlwijW/hFL3sc4uqQtEOPYXxoTSEIm/QgN5eQQCSz8nqROJVgLKvDxClj0JPick6KNMqKN08/5GFVT5In90+w939O+gGaQVDT7NNyxI7GhHaGNzFAF5yXd3C6+TuWD347m4l3IywHcFbykS/p8S+kyf0wRtK24HEFHNQsWkeqbI0W9U0UkBw6oM7d2PgGLKA4czTggWgjh/x+GXhgY6hLiA7RwlOsSx/l+uUPdQAtT9cCskeYZi+7MGGc4c7DnBkUyFgq73Co7V5K1a28xZrtQkJNGSXCMzW+4K5 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB2122; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB2122; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB2122; x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377424004)(377454003)(199003)(13464003)(189002)(24454002)(7696004)(15975445007)(110136003)(81156014)(87936001)(101416001)(68736007)(8676002)(33656002)(10290500002)(6916009)(2900100001)(4326007)(5660300001)(92566002)(102836003)(230783001)(2906002)(8936002)(2950100002)(6116002)(81166006)(189998001)(122556002)(11100500001)(106356001)(586003)(50986999)(76576001)(54356999)(7736002)(3660700001)(76176999)(5002640100001)(305945005)(7846002)(97736004)(10090500001)(86612001)(5005710100001)(8990500004)(105586002)(99286002)(10400500002)(3280700002)(74316002)(86362001)(9686002)(19580395003)(19580405001)(77096005)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB2122; H:CY1PR0301MB2122.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2016 20:02:29.2802 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB2122 Resent-From: Resent-To: ynir.ietf@gmail.com, simon@josefsson.org, david.waltermire@nist.gov, kivinen@iki.fi, Kathleen.Moriarty.ietf@gmail.com, stephen.farrell@cs.tcd.ie, "Tero Kivinen" , ipsec@ietf.org Resent-Message-Id: <20161011200235.9F3781295A0@ietfa.amsl.com> Resent-Date: Tue, 11 Oct 2016 13:02:35 -0700 (PDT) Archived-At: Cc: General Area Review Team , "draft-ietf-ipsecme-safecurves.all@ietf.org" Subject: Re: [IPsec] Gen-ART Last Call review of draft-ietf-ipsecme-safecurves-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 20:02:35 -0000 VGhhbmtzLCBZb2F2IQ0KVGhpcyBhZGRyZXNzZXMgYWxsIG15IGNvbW1lbnRzLg0KQmVzdCwNCk9y aXQuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBZb2F2IE5pciBbbWFpbHRv OnluaXIuaWV0ZkBnbWFpbC5jb21dIA0KU2VudDogVHVlc2RheSwgT2N0b2JlciAxMSwgMjAxNiAx Mjo0NiBQTQ0KVG86IE9yaXQgTGV2aW4gPG9yaXRsQG1pY3Jvc29mdC5jb20+DQpDYzogZHJhZnQt aWV0Zi1pcHNlY21lLXNhZmVjdXJ2ZXMuYWxsQGlldGYub3JnOyBHZW5lcmFsIEFyZWEgUmV2aWV3 IFRlYW0gPGdlbi1hcnRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogR2VuLUFSVCBMYXN0IENhbGwg cmV2aWV3IG9mIGRyYWZ0LWlldGYtaXBzZWNtZS1zYWZlY3VydmVzLTA0DQoNCkhpLCBPcml0Lg0K DQpJIGFjY2VwdGVkIG1vc3Qgb2YgeW91ciBzdWdnZXN0aW9ucyB3aXRoIGEgZmV3IGV4Y2VwdGlv bnMgYmVsb3c6DQoNCj4gT24gMjggU2VwIDIwMTYsIGF0IDA6MzAsIE9yaXQgTGV2aW4gPG9yaXRs QG1pY3Jvc29mdC5jb20+IHdyb3RlOg0KPiANCj4gSSBhbSB0aGUgYXNzaWduZWQgR2VuLUFSVCBy ZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIEdlbmVyYWwgQXJlYSBSZXZpZXcgVGVhbSAoR2Vu LUFSVCkgcmV2aWV3cyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJ RVNHIGZvciB0aGUgSUVURiBDaGFpci4gIFBsZWFzZSB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0 IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCj4gDQo+IEZvciBtb3JlIGluZm9y bWF0aW9uLCBwbGVhc2Ugc2VlIHRoZSBGQVEgYXQgPGh0dHA6Ly93aWtpLnRvb2xzLmlldGYub3Jn L2FyZWEvZ2VuL3RyYWMvd2lraS9HZW5BcnRmYXE+Lg0KPiANCj4gRG9jdW1lbnQ6IHJldmlldyBv ZiBkcmFmdC1pZXRmLWlwc2VjbWUtc2FmZWN1cnZlcy0wNA0KPiBSZXZpZXdlcjogT3JpdCBMZXZp biAobWFpbHRvOm9yaXRsQG1pY3Jvc29mdC5jb20pIFJldmlldyBEYXRlOiANCj4gMjAxNi0wOS0y NyBJRVRGIExDIEVuZCBEYXRlOiAyMDE2LTA5LTI5IElFU0cgVGVsZWNoYXQgZGF0ZTogdW5rbm93 bg0KPiANCj4gU3VtbWFyeToNCj4gVGhpcyBkcmFmdCBpcyBiYXNpY2FsbHkgcmVhZHkgZm9yIHB1 YmxpY2F0aW9uLCBidXQgaGFzIG5pdHMgdGhhdCBzaG91bGQgYmUgZml4ZWQgYmVmb3JlIHB1Ymxp Y2F0aW9uLiBUaGUgbml0cyBhcmUgcHVyZWx5IGVkaXRvcmlhbCwgYnV0IGZpeGluZyB0aGVtIHdp bGwgaW1wcm92ZSB0aGUgZG9jdW1lbnQncyByZWFkYWJpbGl0eS4NCj4gDQo+IDEuIEludHJvZHVj dGlvbg0KPiBQYXIuMSAia2V5IGFncmVlbWVudCAoRGlmZmllLUhlbGxtYW4pIiA6IFJlcGxhY2Ug d2l0aCAia2V5IGFncmVlbWVudCB1c2luZyBEaWZmaWUtSGVsbG1hbiIuDQo+IFBhci4yICJUaGF0 IGRvY3VtZW50IjogUmVwbGFjZSB3aXRoIHRoZSBuYW1lIG9mIHRoZSBkb2N1bWVudCB0byBtYWtl IGNsZWFyIHdoaWNoIG9uZSBpcyAidGhhdCIgZG9jdW1lbnQuDQo+IFBhci4yICJmcmVlIGZyb20i OiBSZXBsYWNlIHdpdGggInJlc2lsaWVudCB0byIuDQo+IA0KPiAyLiBDdXJ2ZTI1NTE5IGFuZCBD dXJ2ZTQ0OA0KPiBBZGQgYXQgdGhlIHN0YXJ0ICJJbXBsZW1lbnRhdGlvbnMgb2YgQ3VydmUyNTUx OSBhbmQgQ3VydmU0NDggTVVTVC9TSEFMTCBmb2xsb3cgdGhlIHN0ZXBzIGRlc2NyaWJlZCBpbiB0 aGlzIHNlY3Rpb24uIg0KPiBQYXIuMSBSZXBsYWNlICJhcmUgaW5oZXJpdGVkIGZyb20iIHdpdGgg ImFyZSBjb21wbGlhbnQgd2l0aCIuDQo+IFBhci4yIFJlcGxhY2UgImdvZXMgYXMiIHdpdGggImlz IHBlcmZvcm1lZCBhcyINCj4gDQo+IDMuIFVzZSBhbmQgTmVnb3RpYXRpb24gaW4gSUtFdjINCj4g Q29uc2lkZXIgcmVwbGFjaW5nIFRCQTEvVEJBMiB0aHJvdWdob3V0IHRoZSBzZWN0aW9uIHdpdGgg W3RvIGJlIHJlcGxhY2VkIHdpdGggVEJBMS9UQkEyIGFjY29yZGluZyB0byB0aGUgSUFOQSBhc3Np Z25tZW50XS4NCg0KSSBoYXZlIGxlZnQgdGhpcyBhcyBpcy4gVGhpcyB3b3JrZWQgZm9yIG1lIGlu IHRoZSBwYXN0LiBJIHdpbGwgbWFrZSBzdXJlIHRoZXNlIHdlcmUgcmVwbGFjZWQgZHVyaW5nIEFV VEg0OC4NCg0KPiAzLjIgQ29uc2lkZXIgcmVwbGFjZSB0aGUgZmlyc3Qgc2VudGVuY2Ugd2l0aCAi UmVjZWl2aW5nIGFuZCBoYW5kbGluZyANCj4gb2YgaW5jb21wYXRpYmxlIHBvaW50IGZvcm1hdHMg TVVTVCBjb21wbHkgd2l0aCBbb3IgTVVTVCBmb2xsb3ddIGNvbnNpZGVyYXRpb25zL3Byb2NlZHVy ZXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gNSBvZiBbUkZDNzc0OF0u4oCdDQoNCkkgZW5kZWQgdXAg d2l0aCB0aGlzOg0KMy4yLiAgUmVjaXBpZW50IFRlc3RzDQoNCiAgIFJlY2VpdmluZyBhbmQgaGFu ZGxpbmcgb2YgaW5jb21wYXRpYmxlIHBvaW50IGZvcm1hdHMgTVVTVCBmb2xsb3cgdGhlDQogICBj b25zaWRlcmF0aW9ucyBkZXNjcmliZWQgaW4gc2VjdGlvbiA1IG9mIFtSRkM3NzQ4XS4gIEluIHBh cnRpY3VsYXIsDQogICByZWNlaXZpbmcgZW50aXRpZXMgTVVTVCBtYXNrIHRoZSBtb3N0LXNpZ25p ZmljYW50IGJpdCBpbiB0aGUgZmluYWwNCiAgIGJ5dGUgZm9yIFgyNTUxOSAoYnV0IG5vdCBYNDQ4 KSwgYW5kIGltcGxlbWVudGF0aW9ucyBNVVNUIGFjY2VwdCBub24tDQogICBjYW5vbmljYWwgdmFs dWVzLg0KDQo+IA0KPiA0LiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KPiBQYXIuMSBSZXBsYWNl IHRoZSBwYXJhZ3JhcGggdGV4dCB0bw0KPiAiRm9yIGhpZ2gtcGVyZm9ybWFuY2UgY29uc3RhbnQt dGltZSBpbXBsZW1lbnRhdGlvbnMsIGl0IGlzIFJFQ09NTUVOREVEIHRvIHVzZSBDdXJ2ZTI1NTE5 IGFuZCBDdXJ2ZTQ0OCB3aGljaCB3ZXJlIGRlc2lnbmVkIGZvciB0aGlzIHB1cnBvc2UuIEltcGxl bWVudGVycyBNVVNUL1NIT1VMRCBOT1QgYXR0ZW1wdCB0byBpbXByb3ZlIHBlcmZvcm1hbmNlIGJ5 IHJldXNpbmcgc3VwcG9zZWRseSBlcGhlbWVyYWwga2V5IHBhaXIgYWNyb3NzIG11bHRpcGxlIGtl eSBleGNoYW5nZXMgW2JlY2F1c2UgLi4uXS7igJ0NCg0KWW91ciBzdWdnZXN0ZWQgdGV4dCBzYXlz IHRoYXQgcmV1c2luZyBlcGhlbWVyYWwga2V5cyBpcyBhIGJhZCB0aGluZy4gUmVhZGluZyBvdmVy IHRoZSBvcmlnaW5hbCB0ZXh0IEkgY2FuIHNlZSB0aGF0IGl0IGNvdWxkIGJlIGludGVycHJldGVk IGxpa2UgdGhhdC4gVGhpcyB3YXMgbm90IG91ciBpbnRlbnRpb24uIFJldXNpbmcgZXBoZW1lcmFs IGtleXMgaXMgT0suIFlvdSBNVVNUIHVzZSBhIGNvbnN0YW50LXRpbWUgaW1wbGVtZW50YXRpb24g YmVjYXVzZSBvdGhlcndpc2UgZWFjaCB1c2Ugb2YgdGhlIHNhbWUgZXBoZW1lcmFsIGtleSBtYXkg bGVhayBhIGZldyBiaXRzLiBTbyBpZiB5b3UgYXJlIHJldXNpbmcgdGhlIGtleXMsIGl0IGlzIGVz cGVjaWFsbHkgaW1wb3J0YW50IHRvIHVzZSBjb25zdGFudC10aW1lIGltcGxlbWVudGF0aW9ucywg d2hlcmVhcyBpZiB5b3Ugb25seSB1c2VkIGVhY2gga2V5IG9uY2UsIGl0IHdvdWxkIGJlIGtpbmQt b2YgT0sgdG8gdXNlIGFueSBpbXBsZW1lbnRhdGlvbi4gIEnigJl2ZSByZXdvcmRlZCB0aGUgcGFy YWdyYXBoIGFzIGZvbGxvd3M6DQoNCiAgIEN1cnZlMjU1MTkgYW5kIEN1cnZlNDQ4IGFyZSBkZXNp Z25lZCB0byBmYWNpbGl0YXRlIHRoZSBwcm9kdWN0aW9uIG9mDQogICBoaWdoLXBlcmZvcm1hbmNl IGNvbnN0YW50LXRpbWUgaW1wbGVtZW50YXRpb25zLiAgSW1wbGVtZW50b3JzIGFyZQ0KICAgZW5j b3VyYWdlZCB0byB1c2UgYSBjb25zdGFudC10aW1lIGltcGxlbWVudGF0aW9uIG9mIHRoZSBmdW5j dGlvbnMuDQogICBUaGlzIHBvaW50IGlzIG9mIGNydWNpYWwgaW1wb3J0YW5jZSBlc3BlY2lhbGx5 IGlmIHRoZSBpbXBsZW1lbnRhdGlvbg0KICAgY2hvb3NlcyB0byByZXVzZSBpdHMgZXBoZW1lcmFs IGtleSBwYWlyIGluIG1hbnkga2V5IGV4Y2hhbmdlcyBmb3INCiAgIHBlcmZvcm1hbmNlIHJlYXNv bnMuDQoNCg0KPiBQYXIuMyBJbiAiIC4uLiB0aGUgcHJvY2VzcyB1c2VkIHRvIHBpY2sgdGhlc2Ug Y3VydmVzLi4uIiByZXBsYWNlICJ0aGVzZSIgd2l0aCB0aGUgbmFtZXMgdG8gYXZvaWQgY29uZnVz aW9uLg0KPiBQYXIuMyBSZXBsYWNlICIgLi4udmVyaWZpY2F0aW9uIGhhcyBiZWVuIGRvbmUuLi4i IHdpdGggInZlcmlmaWNhdGlvbiBjYW4gYmUgZG9uZSIuDQo+IFBhci40IFJlcGxhY2UgIixnZW5l cmF0ZWQgaW4gYSBmdWxseSB2ZXJpZmlhYmxlIHdheSwiIHdpdGggInRoYXQgYXJlIGdlbmVyYXRl ZCBpbiBhIGZ1bGx5IHZlcmlmaWFibGUgd2F5Ii4NCj4gDQo+IDYuIEFja25vd2xlZGdlbWVudHMN Cj4gUGFyMS4gUmVwbGFjZSAiaXMgYnkgTWlrZSIgd2l0aCAid2VyZSBkZWZpbmVkL3NwZWNpZmll ZC9ldGMuIGJ5IE1pa2UiLg0KPiBQYXIxLiBSZXBsYWNlICJhcmUgaW4gUkZDIDc3NDgiIHdpdGgg IiBhcmUgZG9jdW1lbnRlZC9zcGVjaWZpZWQvZXRjLiBpbiBSRkMgNzc0OCIuDQo+IA0KPiBUaGFu ayB5b3UsDQo+IE9yaXQuDQo+IA0KPiANCj4gDQoNCg== From nobody Tue Oct 11 15:00:27 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA981293FC for ; Tue, 11 Oct 2016 15:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gur3QA4iwPl2 for ; Tue, 11 Oct 2016 15:00:23 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-02.alcatel-lucent.com [135.245.18.30]) (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 AEF5A1293E8 for ; Tue, 11 Oct 2016 15:00:21 -0700 (PDT) Received: from us70uumx4.dmz.alcatel-lucent.com (unknown [135.245.18.16]) by Websense Email Security Gateway with ESMTPS id 874DE618F0927; Tue, 11 Oct 2016 22:00:17 +0000 (GMT) Received: from us70uusmtp4.zam.alcatel-lucent.com (us70uusmtp4.zam.alcatel-lucent.com [135.5.2.66]) by us70uumx4.dmz.alcatel-lucent.com (GMO) with ESMTP id u9BM0Kp3002004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Oct 2016 22:00:20 GMT Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id u9BLxpY9014011 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Oct 2016 22:00:19 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.124]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0301.000; Tue, 11 Oct 2016 18:00:04 -0400 From: "Hu, Jun (Nokia - US)" To: Tommy Pauly , Valery Smyslov , "Yoav Nir" Thread-Topic: [IPsec] New version of TCP Encapsulation draft, request for adoption Thread-Index: AQHRoLQbhmlKoxjITU+aiNyunbfH4p+ssGmAgAA064CAD3ujAIAAb1NwgAW3a4CA2/AG4IAGXBjA Date: Tue, 11 Oct 2016 22:00:06 +0000 Message-ID: <876523B00C3F9D47BFD2B654D63DBF92BEAADAF2@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <2C8840EB-AC99-401F-971A-2962B71FCC08@apple.com> <9CC56746-DCA5-42F0-8FBC-B3F5391989E6@apple.com> <876523B00C3F9D47BFD2B654D63DBF92BEAA7FCD@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: <876523B00C3F9D47BFD2B654D63DBF92BEAA7FCD@US70UWXCHMBA05.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IPsecME WG , Daniel Migault , Paul Wouters Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for adoption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 22:00:26 -0000 Any comments to my questions below? Does draft allows multiple TCP sessions for a given SA? Or it should be onl= y one TCP session allowed for a given SA? > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Hu, Jun (Nokia -= US) > Sent: Friday, October 07, 2016 2:09 PM > To: Tommy Pauly; Valery Smyslov; Yoav Nir > Cc: IPsecME WG; Daniel Migault; Paul Wouters > Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for > adoption >=20 > I was reading the draft again, and had similar problem as below; Draft st= ates > that SA state should be independent of TCP state and it allows multiple T= CP > sessions between two peers even when there is only one IKE_SA; I assume t= his > means for a given tunnel, different SA could belong to different TCP sess= ion, > e.g. IKE_SA uses TCP session-1, CHILD_SA uses TCP session-2; however does > this mean draft allows multiple TCP sessions for a given SA? I guess not,= if > that's the case, then it should be stated clearly in the draft that for a= given SA, > only one TCP session is allowed; In case of when the original initiator l= ost TCP > session and create a new one, the responder should update its TCP_session= - > to-SA binding after it receives a valid IKE/ESP packet is received on the= new > TCP session and close the old one, send TCP RST >=20 > > -----Original Message----- > > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tommy Pauly > ... >=20 > > > Then, I think some text should be added describing a situation when > > > the original responder having a valid (from its point of view) TCP > > > session receives a request from original initiator for a new TCP > > > session. This may happen if original initiator looses TCP state for > > > some reason (RST from an attacker, temporary network failure etc.). > > > In this case the responder will have two TCP sessions associated > > > with the IKE SA. Clearly, the new one should be used for further > > > communications, but only after it is proven to be authentic (some > > > protected message is received over it). But what the responder > > > should do > > with the old TCP session? > > > Keep it? Send FIN? Send RST? Just discard? > > > > > > > In general, the approach of the draft is to clearly separate the TCP > > state from the IKE session state. If you look at Section 6, it > > specifically allows for multiple TCP connections between two peers > > even if there is only one IKE SA between them. If one of them becomes > > redundant (because the other peer opened up a new TCP flow for some > > reason), it would make sense to close the other in a usual way. I > > think this can be left to the implementation, but either a FIN or RST w= ould be > appropriate rather than a discard. We can add that to future versions. > > >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Oct 11 17:34:46 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 630011296AC for ; Tue, 11 Oct 2016 17:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.297 X-Spam-Level: X-Spam-Status: No, score=-7.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TXBZfwszYe8 for ; Tue, 11 Oct 2016 17:34:42 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 EF613129405 for ; Tue, 11 Oct 2016 17:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1476232481; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+x9PMkelD7ZIObhzEZNVtE92lnSs8cvQQQ1Tg5lT3Ro=; b=kzPjNvZO61SXMMb8jqvHk8IcSTgFnT9bPqUhQA82uQZ8pex1ZEI55OLgUgNqgNOX YUDaZVqIAAPigVJOj9uP2OZfFKeHqapwMvVr9L8NWV66rQDAR4w1bOvPYcHU4moz xVX3bCa6kE2azSA0BMIMdxq6GyIn8qEfB0ZLPwTJpBWKDdpELHGxSZ3xk/tJyo4I uWWnhN8jFMrnVFEw6jH6G6G1KjF8ZYU6yaCQqvhrEjCXkyMO/Mkq9hy8Sb2baAaV HFrx+QTry8AY22yUcai/z6RyKe4zhsET8N/toUafLoa3UfHIhzZqJGhU326KdbDb JhKBAPb2Art6RPYuiIliCg==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id DF.99.07001.1258DF75; Tue, 11 Oct 2016 17:34:41 -0700 (PDT) X-AuditID: 11973e12-c47ff70000001b59-1e-57fd8521b5ec Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by relay5.apple.com (Apple SCV relay) with SMTP id 53.F3.27929.0258DF75; Tue, 11 Oct 2016 17:34:41 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_9Hc5tNjFfHFI7/KYBlbH5w)" Received: from [17.226.23.47] (unknown [17.226.23.47]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OEW006XGS9SLI60@nwk-mmpp-sz09.apple.com>; Tue, 11 Oct 2016 17:34:40 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Date: Tue, 11 Oct 2016 17:34:39 -0700 In-reply-to: <876523B00C3F9D47BFD2B654D63DBF92BEAADAF2@US70UWXCHMBA05.zam.alcatel-lucent.com> To: "Hu, Jun (Nokia - US)" References: <2C8840EB-AC99-401F-971A-2962B71FCC08@apple.com> <9CC56746-DCA5-42F0-8FBC-B3F5391989E6@apple.com> <876523B00C3F9D47BFD2B654D63DBF92BEAA7FCD@US70UWXCHMBA05.zam.alcatel-lucent.com> <876523B00C3F9D47BFD2B654D63DBF92BEAADAF2@US70UWXCHMBA05.zam.alcatel-lucent.com> X-Mailer: Apple Mail (2.3212) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUi2FAYoavY+jfc4Hm7ocWU6XvYLPZvecFm 8eHvBEaL97cuMVnc+DCTzWLpsQ9MDmwev75eZfPYOesuu8eSJT+ZPL7PY/K4C1QTwBrFZZOS mpNZllqkb5fAlTF55wXWgqUxFQ0/r7A2MH7y7WLk5JAQMJG4teM8UxcjF4eQwF5GiRfPl7PD JLZt+cUCkTjIKDFt6jmwBK+AoMSPyfeAEhwczAJhEl3PPCBqOpgkFs69xA4SFxaQkNi8JxGk nE1AReL4tw3MEK02EstnNDBBlARLTGmzBwmzCKhKnJx+A6yEUyBe4t3t58wgI5kFNjNKTHny FywhIqAr8f30SzYQW0jgC7PE6kuREHfKSiw6foUVpEFCoJld4tuCT+wTGIVmITl1FsKpIGFm AS2J749aocLyEgfPy0KENSWe3fvEDmFrSzx5d4F1ASPbKkah3MTMHN3MPBO9xIKCnFS95Pzc TYygWJpuJ7SD8dQqq0OMAhyMSjy8Oz79CRdiTSwrrsw9xCjNwaIkzqtZ8TdcSCA9sSQ1OzW1 ILUovqg0J7X4ECMTB6dUA2OYc7Uaa432xVyOHwl3g+82TmU//oQrMXKKTPqKNUKHX25kWdSe O/fvw69Gk14Z7fLJWnwxzPmjXZjFGt4p8qdumPtUy9hwaYRXv4yRcT39mDPiynXu70v23NC6 4XpgisreQ1duylW6+/5mXzqv32/ak+/F655Jme3Q3bk/SyRN6L/m7WdFK54osRRnJBpqMRcV JwIARWxAqYYCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJIsWRmVeSWpSXmKPExsUi2FAcoKvY+jfcYNdBJosp0/ewWezf8oLN 4sPfCYwW729dYrK48WEmm8XSYx+YHNg8fn29yuaxc9Zddo8lS34yeXyfx+RxF6gmgDWKyyYl NSezLLVI3y6BK2PyzgusBUtjKhp+XmFtYPzk28XIySEhYCKxbcsvFghbTOLCvfVsXYxcHEIC Bxklpk09xw6S4BUQlPgx+R5QEQcHs0CYRNczD4iaDiaJhXMvsYPEhQUkJDbvSQQpZxNQkTj+ bQMzRKuNxPIZDUwQJcESU9rsQcIsAqoSJ6ffACvhFIiXeHf7OTPISGaBzYwSU578BUuICOhK fD/9kg3EFhL4wiyx+lIkxJ2yEouOX2GdwCgwC8l1sxCuAwkzC2hJfH/UChWWlzh4XhYirCnx 7N4ndghbW+LJuwusCxjZVjEKFKXmJFaa6iUWFOSk6iXn525iBMdEYcQOxv/LrA4xCnAwKvHw 7vj0J1yINbGsuDL3EKMEB7OSCK9Pw99wId6UxMqq1KL8+KLSnNTiQ4wTGYGenMgsJZqcD4zY vJJ4QxMTAxNjYzNjY3MTc1oKK4nzSiUDXSSQnliSmp2aWpBaBHMUEwenVAOjY/pOjUOOkb3P Sg2kxKT3fFrhbqnIUPVh5xzZRw2KEbc/T/yiy3Bio9tPb66TUY5Wc///1UliY3VxfStj8auR /1Lej9hLgof9V9tPOJDxKlQrl3Nad88J3yqX5SFLV4ZYv1lf/8PcV0HyiP7NlEP6Gf0pVStO veL4btHEPGV/V/HHGw/OVNsosRRnJBpqMRcVJwIA8Lrax/wCAAA= Archived-At: Cc: IPsecME WG , Valery Smyslov , Paul Wouters , Daniel Migault , Yoav Nir Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for adoption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 00:34:44 -0000 --Boundary_(ID_9Hc5tNjFfHFI7/KYBlbH5w) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Please see section 6: Multiple TCP connections between the initiator and the responder are allowed, but their use must take into account the initiator capabilities and the deployment model such as to connect to multiple gateways handling different ESP SAs when deployed in a high availability model. It is also possible to negotiate multiple IKE SAs over the same TCP connection. The processing of the TCP packets is the same whether its within a single or multiple TCP connections. We believe this text is fairly direct in specifying that multiple IKE SAs can go over a single TCP stream, and that multiple TCP streams are allowed for a single IKE SA/Child SA set. There is no dependency between the TCP streams and the IKE or Child SAs. We recommend a 1-to-1 correspondence for simplicity, but there is no technical limitation. The TCP streams should not necessarily be closed or reset if the SA sends data on a different flow. Thanks, Tommy > On Oct 11, 2016, at 3:00 PM, Hu, Jun (Nokia - US) wrote: > > Any comments to my questions below? > Does draft allows multiple TCP sessions for a given SA? Or it should be only one TCP session allowed for a given SA? > >> -----Original Message----- >> From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Hu, Jun (Nokia - US) >> Sent: Friday, October 07, 2016 2:09 PM >> To: Tommy Pauly; Valery Smyslov; Yoav Nir >> Cc: IPsecME WG; Daniel Migault; Paul Wouters >> Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for >> adoption >> >> I was reading the draft again, and had similar problem as below; Draft states >> that SA state should be independent of TCP state and it allows multiple TCP >> sessions between two peers even when there is only one IKE_SA; I assume this >> means for a given tunnel, different SA could belong to different TCP session, >> e.g. IKE_SA uses TCP session-1, CHILD_SA uses TCP session-2; however does >> this mean draft allows multiple TCP sessions for a given SA? I guess not, if >> that's the case, then it should be stated clearly in the draft that for a given SA, >> only one TCP session is allowed; In case of when the original initiator lost TCP >> session and create a new one, the responder should update its TCP_session- >> to-SA binding after it receives a valid IKE/ESP packet is received on the new >> TCP session and close the old one, send TCP RST >> >>> -----Original Message----- >>> From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tommy Pauly >> ... >> >>>> Then, I think some text should be added describing a situation when >>>> the original responder having a valid (from its point of view) TCP >>>> session receives a request from original initiator for a new TCP >>>> session. This may happen if original initiator looses TCP state for >>>> some reason (RST from an attacker, temporary network failure etc.). >>>> In this case the responder will have two TCP sessions associated >>>> with the IKE SA. Clearly, the new one should be used for further >>>> communications, but only after it is proven to be authentic (some >>>> protected message is received over it). But what the responder >>>> should do >>> with the old TCP session? >>>> Keep it? Send FIN? Send RST? Just discard? >>>> >>> >>> In general, the approach of the draft is to clearly separate the TCP >>> state from the IKE session state. If you look at Section 6, it >>> specifically allows for multiple TCP connections between two peers >>> even if there is only one IKE SA between them. If one of them becomes >>> redundant (because the other peer opened up a new TCP flow for some >>> reason), it would make sense to close the other in a usual way. I >>> think this can be left to the implementation, but either a FIN or RST would be >> appropriate rather than a discard. We can add that to future versions. >>> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Boundary_(ID_9Hc5tNjFfHFI7/KYBlbH5w) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
Please see section 6:

 Multiple TCP =
connections between the initiator and the responder are
   allowed, but their use must take into account the initiator
   capabilities and the deployment model such as to connect to multiple
   gateways handling different ESP SAs when deployed in a high
   availability model.  It is also possible to negotiate multiple IKE
   SAs over the same TCP connection.

   The processing of the TCP packets is the same whether its within a
   single or multiple TCP connections.

We believe this text is =
fairly direct in specifying that multiple IKE SAs can go over a single =
TCP stream, and that multiple TCP streams are allowed for a single =
IKE SA/Child SA set. There is no dependency between the TCP streams and =
the IKE or Child SAs. We recommend a 1-to-1 correspondence for =
simplicity, but there is no technical limitation. The TCP =
streams should not necessarily be closed or reset if the SA sends =
data on a different flow.

Thanks,
Tommy


On Oct 11, 2016, at 3:00 PM, = Hu, Jun (Nokia - US) <jun.hu@nokia.com> wrote:

Any = comments to my questions below?
Does draft allows multiple = TCP sessions for a given SA? Or it should be only one TCP session = allowed for a given SA?

-----Original Message-----
From: = IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Hu, Jun = (Nokia - US)
Sent: Friday, October 07, 2016 2:09 PM
To: Tommy Pauly; Valery Smyslov; Yoav Nir
Cc: = IPsecME WG; Daniel Migault; Paul Wouters
Subject: Re: = [IPsec] New version of TCP Encapsulation draft, request for
adoption

I was reading the draft = again, and had similar problem as below; Draft states
that = SA state should be independent of TCP state and it allows multiple = TCP
sessions between two peers even when there is only one = IKE_SA; I assume this
means for a given tunnel, different = SA could belong to different TCP session,
e.g. IKE_SA uses = TCP session-1, CHILD_SA uses TCP session-2; however does
this mean draft allows multiple TCP sessions for a given SA? = I guess not, if
that's the case, then it should be stated = clearly in the draft that for a given SA,
only one TCP = session is allowed; In case of when the original initiator lost TCP
session and create a new one, the responder should update its = TCP_session-
to-SA binding after it receives a valid = IKE/ESP packet is received on the new
TCP session and = close the old one, send TCP RST

-----Original Message-----
From: = IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tommy = Pauly
...

Then, I think some text should be added describing a = situation when
the original responder having a valid (from = its point of view) TCP
session receives a request from = original initiator for a new TCP
session. This may happen = if original initiator looses TCP state for
some reason = (RST from an attacker, temporary network failure etc.).
In = this case the responder will have two TCP sessions associated
with the IKE SA. Clearly, the new one should be used for = further
communications, but only after it is proven to be = authentic (some
protected message is received over it). = But what the responder
should do
with the old TCP session?
Keep it? Send FIN? Send = RST? Just discard?


In general, the approach of the draft is to clearly separate = the TCP
state from the IKE session state. If you look at = Section 6, it
specifically allows for multiple TCP = connections between two peers
even if there is only one = IKE SA between them. If one of them becomes
redundant = (because the other peer opened up a new TCP flow for some
reason), it would make sense to close the other in a usual = way. I
think this can be left to the implementation, but = either a FIN or RST would be
appropriate = rather than a discard. We can add that to future versions.


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Boundary_(ID_9Hc5tNjFfHFI7/KYBlbH5w)-- From nobody Tue Oct 11 20:43:04 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3691296B1 for ; Tue, 11 Oct 2016 20:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXbnv1QZrl1d for ; Tue, 11 Oct 2016 20:42:59 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (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 D3A2512945B for ; Tue, 11 Oct 2016 20:42:58 -0700 (PDT) Received: from us70uumx3.dmz.alcatel-lucent.com (unknown [135.245.18.15]) by Websense Email Security Gateway with ESMTPS id EB67677F3427; Wed, 12 Oct 2016 03:42:56 +0000 (GMT) Received: from us70uusmtp3.zam.alcatel-lucent.com (us70uusmtp3.zam.alcatel-lucent.com [135.5.2.65]) by us70uumx3.dmz.alcatel-lucent.com (GMO) with ESMTP id u9C3gvCC019463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Oct 2016 03:42:57 GMT Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id u9C3gucf017662 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Oct 2016 03:42:57 GMT Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.124]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0301.000; Tue, 11 Oct 2016 23:42:56 -0400 From: "Hu, Jun (Nokia - US)" To: "tpauly@apple.com" Thread-Topic: [IPsec] New version of TCP Encapsulation draft, request for adoption Thread-Index: AQHRoLQbhmlKoxjITU+aiNyunbfH4p+ssGmAgAA064CAD3ujAIAAb1NwgAW3a4CA2/AG4IAGXBjAgABup4D//+8w4A== Date: Wed, 12 Oct 2016 03:42:55 +0000 Message-ID: <876523B00C3F9D47BFD2B654D63DBF92BEAADC6B@US70UWXCHMBA05.zam.alcatel-lucent.com> References: <2C8840EB-AC99-401F-971A-2962B71FCC08@apple.com> <9CC56746-DCA5-42F0-8FBC-B3F5391989E6@apple.com> <876523B00C3F9D47BFD2B654D63DBF92BEAA7FCD@US70UWXCHMBA05.zam.alcatel-lucent.com> <876523B00C3F9D47BFD2B654D63DBF92BEAADAF2@US70UWXCHMBA05.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_876523B00C3F9D47BFD2B654D63DBF92BEAADC6BUS70UWXCHMBA05z_" MIME-Version: 1.0 Archived-At: Cc: IPsecME WG , Valery Smyslov , Paul Wouters , Daniel Migault , Yoav Nir Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for adoption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 03:43:02 -0000 --_000_876523B00C3F9D47BFD2B654D63DBF92BEAADC6BUS70UWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >From the section 6 text, my understanding is draft allows multiple TCP conn= ections for a given tunnel which includes multiple CHILD_SAs; however it is= not clear to me that draft also allows multiple TCP session for a single S= A, is there any use case of having multiple TCP sessions for a single CHILD= _SA? From: tpauly@apple.com [mailto:tpauly@apple.com] Sent: Tuesday, October 11, 2016 5:35 PM To: Hu, Jun (Nokia - US) Cc: Valery Smyslov; Yoav Nir; IPsecME WG; Daniel Migault; Paul Wouters Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for ad= option Please see section 6: Multiple TCP connections between the initiator and the responder are allowed, but their use must take into account the initiator capabilities and the deployment model such as to connect to multiple gateways handling different ESP SAs when deployed in a high availability model. It is also possible to negotiate multiple IKE SAs over the same TCP connection. The processing of the TCP packets is the same whether its within a single or multiple TCP connections. We believe this text is fairly direct in specifying that multiple IKE SAs c= an go over a single TCP stream, and that multiple TCP streams are allowed f= or a single IKE SA/Child SA set. There is no dependency between the TCP str= eams and the IKE or Child SAs. We recommend a 1-to-1 correspondence for sim= plicity, but there is no technical limitation. The TCP streams should not n= ecessarily be closed or reset if the SA sends data on a different flow. Thanks, Tommy On Oct 11, 2016, at 3:00 PM, Hu, Jun (Nokia - US) > wrote: Any comments to my questions below? Does draft allows multiple TCP sessions for a given SA? Or it should be onl= y one TCP session allowed for a given SA? -----Original Message----- From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Hu, Jun (Nokia - U= S) Sent: Friday, October 07, 2016 2:09 PM To: Tommy Pauly; Valery Smyslov; Yoav Nir Cc: IPsecME WG; Daniel Migault; Paul Wouters Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for adoption I was reading the draft again, and had similar problem as below; Draft stat= es that SA state should be independent of TCP state and it allows multiple TCP sessions between two peers even when there is only one IKE_SA; I assume thi= s means for a given tunnel, different SA could belong to different TCP sessio= n, e.g. IKE_SA uses TCP session-1, CHILD_SA uses TCP session-2; however does this mean draft allows multiple TCP sessions for a given SA? I guess not, i= f that's the case, then it should be stated clearly in the draft that for a g= iven SA, only one TCP session is allowed; In case of when the original initiator los= t TCP session and create a new one, the responder should update its TCP_session- to-SA binding after it receives a valid IKE/ESP packet is received on the n= ew TCP session and close the old one, send TCP RST -----Original Message----- From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tommy Pauly ... Then, I think some text should be added describing a situation when the original responder having a valid (from its point of view) TCP session receives a request from original initiator for a new TCP session. This may happen if original initiator looses TCP state for some reason (RST from an attacker, temporary network failure etc.). In this case the responder will have two TCP sessions associated with the IKE SA. Clearly, the new one should be used for further communications, but only after it is proven to be authentic (some protected message is received over it). But what the responder should do with the old TCP session? Keep it? Send FIN? Send RST? Just discard? In general, the approach of the draft is to clearly separate the TCP state from the IKE session state. If you look at Section 6, it specifically allows for multiple TCP connections between two peers even if there is only one IKE SA between them. If one of them becomes redundant (because the other peer opened up a new TCP flow for some reason), it would make sense to close the other in a usual way. I think this can be left to the implementation, but either a FIN or RST would= be appropriate rather than a discard. We can add that to future versions. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_876523B00C3F9D47BFD2B654D63DBF92BEAADC6BUS70UWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From the se= ction 6 text, my understanding is draft allows multiple TCP connections for= a given tunnel which includes multiple CHILD_SAs; however it is not clear to me that draft also allows multiple TCP session for a si= ngle SA, is there any use case of having multiple TCP sessions for a single= CHILD_SA?

 =

 =

From: tpauly@a= pple.com [mailto:tpauly@apple.com]
Sent: Tuesday, October 11, 2016 5:35 PM
To: Hu, Jun (Nokia - US)
Cc: Valery Smyslov; Yoav Nir; IPsecME WG; Daniel Migault; Paul Woute= rs
Subject: Re: [IPsec] New version of TCP Encapsulation draft, request= for adoption

 

Please see section 6:

 

 Mu=
ltiple TCP connections between the initiator and the responder are
&nb=
sp;  allowed, but their use must take into account the initiator<=
/o:p>
&nb=
sp;  capabilities and the deployment model such as to connect to multi=
ple
&nb=
sp;  gateways handling different ESP SAs when deployed in a high<=
/o:p>
&nb=
sp;  availability model.  It is also possible to negotiate multip=
le IKE
&nb=
sp;  SAs over the same TCP connection.
 
&nb=
sp;  The processing of the TCP packets is the same whether its within =
a
&nb=
sp;  single or multiple TCP connections.

 
We believe this text is fairly d=
irect in specifying that multiple IKE SAs can go over a single TCP stream, =
and that multiple TCP streams are allowed for a single IKE SA/Child SA=
 set. There is no dependency between the TCP streams and the IKE or Child S=
As. We recommend a 1-to-1 correspondence for simplicity, but there is no te=
chnical limitation. The TCP streams should not necessarily be closed o=
r reset if the SA sends data on a different flow.

 
Thanks,
Tommy

 

 

On Oct 11, 2016, at 3:00 PM, Hu, Jun (Nokia - US) &l= t;jun.hu@nokia.com> wrote:<= /o:p>

 

Any comments to my questions below?
Does draft allows multiple TCP sessions for a given SA? Or it should be onl= y one TCP session allowed for a given SA?


-----Original Message-----
From: IPsec [mailto:ipsec-bounces= @ietf.org] On Behalf Of Hu, Jun (Nokia - US)
Sent: Friday, October 07, 2016 2:09 PM
To: Tommy Pauly; Valery Smyslov; Yoav Nir
Cc: IPsecME WG; Daniel Migault; Paul Wouters
Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for adoption

I was reading the draft again, and had similar problem as below; Draft stat= es
that SA state should be independent of TCP state and it allows multiple TCP=
sessions between two peers even when there is only one IKE_SA; I assume thi= s
means for a given tunnel, different SA could belong to different TCP sessio= n,
e.g. IKE_SA uses TCP session-1, CHILD_SA uses TCP session-2; however does this mean draft allows multiple TCP sessions for a given SA? I guess not, i= f
that's the case, then it should be stated clearly in the draft that for a g= iven SA,
only one TCP session is allowed; In case of when the original initiator los= t TCP
session and create a new one, the responder should update its TCP_session-<= br> to-SA binding after it receives a valid IKE/ESP packet is received on the n= ew
TCP session and close the old one, send TCP RST


-----Original Message-----
From: IPsec [mailto:ipsec-bounces= @ietf.org] On Behalf Of Tommy Pauly

...


Then, I think some text should be added describing a= situation when
the original responder having a valid (from its point of view) TCP
session receives a request from original initiator for a new TCP
session. This may happen if original initiator looses TCP state for
some reason (RST from an attacker, temporary network failure etc.).
In this case the responder will have two TCP sessions associated
with the IKE SA. Clearly, the new one should be used for further
communications, but only after it is proven to be authentic (some
protected message is received over it). But what the responder
should do

with the old TCP session?

Keep it? Send FIN? Se= nd RST? Just discard?


In general, the approach of the draft is to clearly separate the TCP
state from the IKE session state. If you look at Section 6, it
specifically allows for multiple TCP connections between two peers
even if there is only one IKE SA between them. If one of them becomes
redundant (because the other peer opened up a new TCP flow for some
reason), it would make sense to close the other in a usual way. I
think this can be left to the implementation, but either a FIN or RST would= be

appropriate rather than a discard. We can add that t= o future versions.

 


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.or= g/mailman/listinfo/ipsec


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.or= g/mailman/listinfo/ipsec

 

--_000_876523B00C3F9D47BFD2B654D63DBF92BEAADC6BUS70UWXCHMBA05z_-- From nobody Wed Oct 12 06:45:42 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088D0129480 for ; Wed, 12 Oct 2016 06:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.898 X-Spam-Level: X-Spam-Status: No, score=-4.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNZxPSRECmG0 for ; Wed, 12 Oct 2016 06:45:32 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC1741294FD for ; Wed, 12 Oct 2016 06:45:31 -0700 (PDT) Received: (qmail 1562 invoked from network); 12 Oct 2016 15:38:48 +0200 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 12 Oct 2016 15:38:47 +0200 To: Valery Smyslov , Yoav Nir References: <147465789941.20366.13358533684157949770.idtracker@ietfa.amsl.com> <674D263A-4EF8-4F8A-8320-1224FABAD10C@gmail.com> <701DC5E23DC747588D7047D73A87D855@chichi> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: Date: Wed, 12 Oct 2016 15:38:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <701DC5E23DC747588D7047D73A87D855@chichi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-ddos-protection@ietf.org, The IESG , David Waltermire Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-ipsecme-ddos-protection-09=3A_=28with_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 13:45:34 -0000 Hi Valery, sorry for the late reply (holidays :-) ) See below. On 25.09.2016 22:20, Valery Smyslov wrote: > Hi Mirja, Yoav, > > I agree with Yoav's answers, just want to clarify a few things. See below > (I removed the comments where I have nothing to add to Yoav's answers). > >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> Some questions: >>> >>> 1) sec 7.1.2: If there is a puzzle but no cookie, maybe the initiator >>> should ignore it and try to send reply without the puzzle solution, as >>> there might be still a change to get served…? If it then received another >>> packet with puzzle it can still solve it and reply. >> >> A response that contains neither COOKIE nor INVALID_KE_PAYLOAD nor the regular payloads like SA is invalid according >> to RFC 7296. >> That is one reason why we chose to keep the COOKIE notification and add a PUZZLE notification rather than put both >> pieces of >> data in the new notification. A response with only PUZZLE and no COOKIE is invalid and should be treated as such. >> So after some (not specified anywhere) time, the Initiator should start a new IKE_SA_INIT exchange, hoping that this >> time the >> Responder returns a valid response. > > Actually, the Initiator sends requests, not responses. So, if the Initiator ignores > invalid response from the Responder, then the only thing it can do is to wait > some time and sends another request (or just retransmit the sent request in hope > that invalid response was from an attacker who wants to break IKE SA establishment). > If the situation doesn't improve (the Initiator continues to receive invalid responses), > then the Initator has nothing to do but give up. > > I just want to emphasise that Mirja's suggestion (ignore invalid response) is exactly > what the draft suggests to do in this case, as Yoav correctly outlined. Isn't it clear enough from the > document? Should we add more clarifications? I guess add one sentence stating this explicitly cant hurt? > >>> 3) also sec 7.1.4: Does the following sentence really makes sense? How >>> doe the responser know? Maybe just remove it? >>> „The more time the Initiator spent solving the puzzles, the higher >>> priority it should receive.“ >> >> The Responder cannot know. It can only assume based on the expected number of steps in finding a solution with a >> certain number of trailing zero bits. > > The Responder can also measure the time between the puzzle request and > the reception of puzzle solution (and the Responder can do this in a stateless manner). > Sure this measurment cannot be accurate, because it includes RTT, but it > can be used as additional input to the prioritizing algorithm (along > with puzzle difficulty and the number of times the puzzle was requested). > But in general the prioritizing algorithm is a local matter of Responder > and the draft doesn't mandatae it in any way. In this case I would recommend a short warning that if the response time is measured as an estimated for the processing time, network delay should be taken into account. > >>> 5) sec 7.2.2 says „If the IKE_SA_INIT response message contains the >>> PUZZLE notification and the Initiator supports puzzles, it MUST solve the >>> puzzle.“ >>> Should this be „IKE_SA_AUTH“ here instead of „IKE_SA_INIT“? >>> Otherwise it contradicts sec 7.1.2 („The Initiator MAY ignore the PUZZLE >>> notification…“) >> >> Sure. Seems to be a typo. > > No, that's not a typo. Note, that unlike IKE_SA_INIT exchange the IKE_AUTH exchange > cannot be restarted. So, if we want the puzzle solution to be in IKE_AUTH request > (that is sent by the Initiator), the puzzle must be given to the Initiator earlier, > i.e. in the preceding response from the Responder, i.e. in the IKE_SA_INIT response. > So the text is correct. > > However, I understand Mirja's source of confusion - in IKEv2 there are > three different kinds of IKE_SA_INIT responses ("regular", COOKIE and > INVALID_KE_PAYLOAD) and unfortunately RFC7296 doesn't give them distinct > names - they all are IKE_SA_INIT response. So, there is no contradiction with > 7.1.2, because 7.1.2 tells about IKE_SA_INIT response that contain COOKIE request > (and PUZZLE request), while 7.2.2 tells about "regular" IKE_SA_INIT response, > i.e. that contains SA, KE, NONCE payloads etc. So, while in the first case > the Initiator can ignore puzzle request (if PUZZLE is present in a response containing COOKIE) > and still have a chance to be served, in the second case it cannot ignore puzzle request > (when PUZZLE is present in a "regular" IKE_SA_INIT response). > > Do you think it is not clear enough and more clarifications are needed? If it's possible to clarify this without data to much text about RFC7296 that would clearly help! Thanks, Mirja > > Regards, > Valery. > From nobody Wed Oct 12 07:22:10 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F22129535; Wed, 12 Oct 2016 07:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.796 X-Spam-Level: X-Spam-Status: No, score=0.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.496, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxV_dpwGzLlY; Wed, 12 Oct 2016 07:22:07 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62DE912944D; Wed, 12 Oct 2016 07:22:07 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id x79so80445816lff.0; Wed, 12 Oct 2016 07:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-transfer-encoding; bh=Wn7B8o1zSMgMlEv51V1D+dslEGAHNO7UlA8ZtlkpNZU=; b=k2Eb874ytF6HF/Mc9RhAy7nc9x8JK2YEa6vLBvIg1bzXbYJVkR9+jC2t0Jt9zAPj1q AgfCG1MgpzXR0hDnvfnQ9wUGSDP8ktpwEvBvyNxPTmwMGghFOseVRXJWMppPNfNvF1sP JZio2JulVq/+Z+Okt8u2n5SvP6hSss7Dv3iSMK87wTmL11NGIJmQQAquw6/b7KowgnZj fLKLpawlxef2uTm8GhI99NGM09I6mtqj8SeHm20NgArYXaJ/iv7UPMtm2d51UMoiJeMb JUE1w38Zjg6P4POcQPCGyznbunr76gcBy+HoZnZstSB+3XpPQ6ljPhKqDKXbcRBl+gKx QPkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=Wn7B8o1zSMgMlEv51V1D+dslEGAHNO7UlA8ZtlkpNZU=; b=gxdg3lkBmS309HV6F6EJiuuwv8whAPnluMnWyw9MFn4a/9YQQV0cdAYlu1AYakLFJH Pi3boXqbIjTwF0tMSrFdvvLDI/pW7YGIKoVVvU8mwscWklhbn8JERk44IZD8Lga368h/ 7JtxTZqoMOT855niVFRVGqzWP+IwFqphfMONqY+Pwrkdeq8qsnHnRnm+3DPLQMEA2BsI W8nFI8Q0m2dXBFDKAcFhIYxoU0uuuM2cFK5457i8+SVmA8/aumtGVXcqAZ8BhquagYp7 zVEuuxX+KUOZZWCLuG1rVr5MoaAleknOh1whCylAbG/Wt8czWlImKK5x5Cog7vQ99Xk7 lJdw== X-Gm-Message-State: AA6/9RkJC3PRQ9gqiBU3cnA0MA35qH4cTAgVMmyHwekwS80r7brCPSx8t8lyynz9Gn1pEg== X-Received: by 10.25.169.208 with SMTP id s199mr1683665lfe.58.1476282125408; Wed, 12 Oct 2016 07:22:05 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id x16sm2314163lff.15.2016.10.12.07.22.04 (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Wed, 12 Oct 2016 07:22:04 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Yoav Nir" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= References: <147465789941.20366.13358533684157949770.idtracker@ietfa.amsl.com> <674D263A-4EF8-4F8A-8320-1224FABAD10C@gmail.com> <701DC5E23DC747588D7047D73A87D855@chichi> Date: Wed, 12 Oct 2016 17:22:03 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-ddos-protection@ietf.org, The IESG , David Waltermire Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-ipsecme-ddos-protection-09=3A_=28with_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 14:22:09 -0000 Hi Mirja, please see inline. The draft is already in RFC Editor's queue, so please see our reasonings for addressing your comments (we add one clarifications and ignored two other cases, please see why). Regards, Valery. > Hi Valery, > > sorry for the late reply (holidays :-) ) > > See below. > > On 25.09.2016 22:20, Valery Smyslov wrote: >> Hi Mirja, Yoav, >> >> I agree with Yoav's answers, just want to clarify a few things. See below >> (I removed the comments where I have nothing to add to Yoav's answers). >> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> Some questions: >>>> >>>> 1) sec 7.1.2: If there is a puzzle but no cookie, maybe the initiator >>>> should ignore it and try to send reply without the puzzle solution, as >>>> there might be still a change to get served…? If it then received another >>>> packet with puzzle it can still solve it and reply. >>> >>> A response that contains neither COOKIE nor INVALID_KE_PAYLOAD nor the regular payloads like SA is invalid according >>> to RFC 7296. >>> That is one reason why we chose to keep the COOKIE notification and add a PUZZLE notification rather than put both >>> pieces of >>> data in the new notification. A response with only PUZZLE and no COOKIE is invalid and should be treated as such. >>> So after some (not specified anywhere) time, the Initiator should start a new IKE_SA_INIT exchange, hoping that this >>> time the >>> Responder returns a valid response. >> >> Actually, the Initiator sends requests, not responses. So, if the Initiator ignores >> invalid response from the Responder, then the only thing it can do is to wait >> some time and sends another request (or just retransmit the sent request in hope >> that invalid response was from an attacker who wants to break IKE SA establishment). >> If the situation doesn't improve (the Initiator continues to receive invalid responses), >> then the Initator has nothing to do but give up. >> >> I just want to emphasise that Mirja's suggestion (ignore invalid response) is exactly >> what the draft suggests to do in this case, as Yoav correctly outlined. Isn't it clear enough from the >> document? Should we add more clarifications? > > I guess add one sentence stating this explicitly cant hurt? I think the draft is very clear: In this case the Initiator MUST ignore the received message and continue to wait until either a valid PUZZLE notification is received or the retransmission timer fires. If it fails to receive a valid message after several retransmissions of IKE_SA_INIT requests, then it means that something is wrong and the IKE SA cannot be established. This text is completely in line with RFC7296 (Section 2.21.1): Because all error notifications are completely unauthenticated, the recipient should continue trying for some time before giving up. The recipient should not immediately act based on the error notification unless corrective actions are defined in this specification, such as for COOKIE, INVALID_KE_PAYLOAD, and INVALID_MAJOR_VERSION. They both tell that the Initiator must not act immediately on receiving malformed packet or error notification in IKE_SA_INIT since this packets are unauthenticated. Instead, the Initiator must try to get a valid response by retransmitting the request for some time and give up only if no valid response is received. So, I frankly don't see how we can improve the text. If you have the text you think is really important to add, then please provide it. >>>> 3) also sec 7.1.4: Does the following sentence really makes sense? How >>>> doe the responser know? Maybe just remove it? >>>> „The more time the Initiator spent solving the puzzles, the higher >>>> priority it should receive.“ >>> >>> The Responder cannot know. It can only assume based on the expected number of steps in finding a solution with a >>> certain number of trailing zero bits. >> >> The Responder can also measure the time between the puzzle request and >> the reception of puzzle solution (and the Responder can do this in a stateless manner). >> Sure this measurment cannot be accurate, because it includes RTT, but it >> can be used as additional input to the prioritizing algorithm (along >> with puzzle difficulty and the number of times the puzzle was requested). >> But in general the prioritizing algorithm is a local matter of Responder >> and the draft doesn't mandatae it in any way. > > In this case I would recommend a short warning that if the response time is measured as an estimated for the > processing time, network delay should be taken into account. The Responder has no reliable means to separate RTT from the time the Initiator spent for solving the puzzle. The Responder can only suggest that if, for example, the puzzle solution was returned in 10 seconds, then it probably took ~9 seconds for solving the puzzle and ~1 second for network delay. But it could happen that network quality is poor and in reality the figures are just opposite. Since the Responder cannot reliably "distill" CPU consumption time, I think this warning wouldn't help implementers. The time spent for solving a puzzle is just an additional input data for Responder's decision, but definitely not the primary one, which is the puzzle's difficulty. >>>> 5) sec 7.2.2 says „If the IKE_SA_INIT response message contains the >>>> PUZZLE notification and the Initiator supports puzzles, it MUST solve the >>>> puzzle.“ >>>> Should this be „IKE_SA_AUTH“ here instead of „IKE_SA_INIT“? >>>> Otherwise it contradicts sec 7.1.2 („The Initiator MAY ignore the PUZZLE >>>> notification…“) >>> >>> Sure. Seems to be a typo. >> >> No, that's not a typo. Note, that unlike IKE_SA_INIT exchange the IKE_AUTH exchange >> cannot be restarted. So, if we want the puzzle solution to be in IKE_AUTH request >> (that is sent by the Initiator), the puzzle must be given to the Initiator earlier, >> i.e. in the preceding response from the Responder, i.e. in the IKE_SA_INIT response. >> So the text is correct. >> >> However, I understand Mirja's source of confusion - in IKEv2 there are >> three different kinds of IKE_SA_INIT responses ("regular", COOKIE and >> INVALID_KE_PAYLOAD) and unfortunately RFC7296 doesn't give them distinct >> names - they all are IKE_SA_INIT response. So, there is no contradiction with >> 7.1.2, because 7.1.2 tells about IKE_SA_INIT response that contain COOKIE request >> (and PUZZLE request), while 7.2.2 tells about "regular" IKE_SA_INIT response, >> i.e. that contains SA, KE, NONCE payloads etc. So, while in the first case >> the Initiator can ignore puzzle request (if PUZZLE is present in a response containing COOKIE) >> and still have a chance to be served, in the second case it cannot ignore puzzle request >> (when PUZZLE is present in a "regular" IKE_SA_INIT response). >> >> Do you think it is not clear enough and more clarifications are needed? > > If it's possible to clarify this without data to much text about RFC7296 that would clearly help! We've added a clarification in 7.2.2 that regular IKE_SA_INIT response is meant (containing SA, KE, NONCE etc. payloads). > Thanks, > Mirja > > > >> >> Regards, >> Valery. >> From nobody Wed Oct 12 07:36:52 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B251295FB for ; Wed, 12 Oct 2016 07:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.898 X-Spam-Level: X-Spam-Status: No, score=-4.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxrSwnu8LBAn for ; Wed, 12 Oct 2016 07:36:48 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03637129532 for ; Wed, 12 Oct 2016 07:36:47 -0700 (PDT) Received: (qmail 3676 invoked from network); 12 Oct 2016 16:30:04 +0200 Received: from public-docking-pat-etx-mapped-0029.ethz.ch (HELO ?10.2.118.142?) (195.176.110.254) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 12 Oct 2016 16:30:03 +0200 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: "Mirja Kuehlewind (IETF)" X-Priority: 3 In-Reply-To: Date: Wed, 12 Oct 2016 16:30:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <06BB2F81-F197-4914-871D-080973741D6C@kuehlewind.net> References: <147465789941.20366.13358533684157949770.idtracker@ietfa.amsl.com> <674D263A-4EF8-4F8A-8320-1224FABAD10C@gmail.com> <701DC5E23DC747588D7047D73A87D855@chichi> To: Valery Smyslov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: ipsecme-chairs@ietf.org, draft-ietf-ipsecme-ddos-protection@ietf.org, Yoav Nir , ipsec@ietf.org, The IESG , David Waltermire Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-ipsecme-ddos-protection-09=3A_=28with_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 14:36:51 -0000 Hi Valery, okay. Didn=E2=80=99t see that it=E2=80=99s already in the RFC editor = queue.=20 One more comment below but no big issue. So everything you do is fine. > Am 12.10.2016 um 16:22 schrieb Valery Smyslov : >=20 > Hi Mirja, >=20 > please see inline. The draft is already in RFC Editor's queue, so = please > see our reasonings for addressing your comments (we add one = clarifications > and ignored two other cases, please see why). >=20 > Regards, > Valery. >=20 >> Hi Valery, >>=20 >> sorry for the late reply (holidays :-) ) >>=20 >> See below. >>=20 >> On 25.09.2016 22:20, Valery Smyslov wrote: >>> Hi Mirja, Yoav, >>>=20 >>> I agree with Yoav's answers, just want to clarify a few things. See = below >>> (I removed the comments where I have nothing to add to Yoav's = answers). >>>=20 >>>>> = ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>> Some questions: >>>>>=20 >>>>> 1) sec 7.1.2: If there is a puzzle but no cookie, maybe the = initiator >>>>> should ignore it and try to send reply without the puzzle = solution, as >>>>> there might be still a change to get served=E2=80=A6? If it then = received another >>>>> packet with puzzle it can still solve it and reply. >>>>=20 >>>> A response that contains neither COOKIE nor INVALID_KE_PAYLOAD nor = the regular payloads like SA is invalid according >>>> to RFC 7296. >>>> That is one reason why we chose to keep the COOKIE notification and = add a PUZZLE notification rather than put both >>>> pieces of >>>> data in the new notification. A response with only PUZZLE and no = COOKIE is invalid and should be treated as such. >>>> So after some (not specified anywhere) time, the Initiator should = start a new IKE_SA_INIT exchange, hoping that this >>>> time the >>>> Responder returns a valid response. >>>=20 >>> Actually, the Initiator sends requests, not responses. So, if the = Initiator ignores >>> invalid response from the Responder, then the only thing it can do = is to wait >>> some time and sends another request (or just retransmit the sent = request in hope >>> that invalid response was from an attacker who wants to break IKE SA = establishment). >>> If the situation doesn't improve (the Initiator continues to receive = invalid responses), >>> then the Initator has nothing to do but give up. >>>=20 >>> I just want to emphasise that Mirja's suggestion (ignore invalid = response) is exactly >>> what the draft suggests to do in this case, as Yoav correctly = outlined. Isn't it clear enough from the >>> document? Should we add more clarifications? >>=20 >> I guess add one sentence stating this explicitly cant hurt? >=20 > I think the draft is very clear: >=20 > In this case the > Initiator MUST ignore the received message and continue to wait until > either a valid PUZZLE notification is received or the retransmission > timer fires. If it fails to receive a valid message after several > retransmissions of IKE_SA_INIT requests, then it means that something > is wrong and the IKE SA cannot be established. >=20 > This text is completely in line with RFC7296 (Section 2.21.1): >=20 > Because all error notifications are completely > unauthenticated, the recipient should continue trying for some time > before giving up. The recipient should not immediately act based on > the error notification unless corrective actions are defined in this > specification, such as for COOKIE, INVALID_KE_PAYLOAD, and > INVALID_MAJOR_VERSION. >=20 > They both tell that the Initiator must not act immediately on = receiving > malformed packet or error notification in IKE_SA_INIT since this > packets are unauthenticated. Instead, the Initiator must try to > get a valid response by retransmitting the request for some time > and give up only if no valid response is received. >=20 > So, I frankly don't see how we can improve the text. If you have > the text you think is really important to add, then please provide it. >=20 >>>>> 3) also sec 7.1.4: Does the following sentence really makes sense? = How >>>>> doe the responser know? Maybe just remove it? >>>>> =E2=80=9EThe more time the Initiator spent solving the puzzles, = the higher >>>>> priority it should receive.=E2=80=9C >>>>=20 >>>> The Responder cannot know. It can only assume based on the expected = number of steps in finding a solution with a >>>> certain number of trailing zero bits. >>>=20 >>> The Responder can also measure the time between the puzzle request = and >>> the reception of puzzle solution (and the Responder can do this in a = stateless manner). >>> Sure this measurment cannot be accurate, because it includes RTT, = but it >>> can be used as additional input to the prioritizing algorithm (along >>> with puzzle difficulty and the number of times the puzzle was = requested). >>> But in general the prioritizing algorithm is a local matter of = Responder >>> and the draft doesn't mandatae it in any way. >>=20 >> In this case I would recommend a short warning that if the response = time is measured as an estimated for the processing time, network delay = should be taken into account. >=20 > The Responder has no reliable means to separate RTT > from the time the Initiator spent for solving the puzzle. > The Responder can only suggest that if, for example, the puzzle = solution > was returned in 10 seconds, then it probably took ~9 seconds for = solving > the puzzle and ~1 second for network delay. But it could happen that > network quality is poor and in reality the figures are just opposite. > Since the Responder cannot reliably "distill" CPU consumption time, > I think this warning wouldn't help implementers. The time spent for = solving a puzzle > is just an additional input data for Responder's decision, but = definitely > not the primary one, which is the puzzle's difficulty. I agree. If there is no RTT estimate available at all, I would actually = rather recommend to not use the response time at all and remove this = sentence. However not a big issue anyway. What I meant by a warning is = to explicitly say that this information might no be super useful as the = network delay is not known=E2=80=A6 Mirja >=20 >>>>> 5) sec 7.2.2 says =E2=80=9EIf the IKE_SA_INIT response message = contains the >>>>> PUZZLE notification and the Initiator supports puzzles, it MUST = solve the >>>>> puzzle.=E2=80=9C >>>>> Should this be =E2=80=9EIKE_SA_AUTH=E2=80=9C here instead of = =E2=80=9EIKE_SA_INIT=E2=80=9C? >>>>> Otherwise it contradicts sec 7.1.2 (=E2=80=9EThe Initiator MAY = ignore the PUZZLE >>>>> notification=E2=80=A6=E2=80=9C) >>>>=20 >>>> Sure. Seems to be a typo. >>>=20 >>> No, that's not a typo. Note, that unlike IKE_SA_INIT exchange the = IKE_AUTH exchange >>> cannot be restarted. So, if we want the puzzle solution to be in = IKE_AUTH request >>> (that is sent by the Initiator), the puzzle must be given to the = Initiator earlier, >>> i.e. in the preceding response from the Responder, i.e. in the = IKE_SA_INIT response. >>> So the text is correct. >>>=20 >>> However, I understand Mirja's source of confusion - in IKEv2 there = are >>> three different kinds of IKE_SA_INIT responses ("regular", COOKIE = and >>> INVALID_KE_PAYLOAD) and unfortunately RFC7296 doesn't give them = distinct >>> names - they all are IKE_SA_INIT response. So, there is no = contradiction with >>> 7.1.2, because 7.1.2 tells about IKE_SA_INIT response that contain = COOKIE request >>> (and PUZZLE request), while 7.2.2 tells about "regular" IKE_SA_INIT = response, >>> i.e. that contains SA, KE, NONCE payloads etc. So, while in the = first case >>> the Initiator can ignore puzzle request (if PUZZLE is present in a = response containing COOKIE) >>> and still have a chance to be served, in the second case it cannot = ignore puzzle request >>> (when PUZZLE is present in a "regular" IKE_SA_INIT response). >>>=20 >>> Do you think it is not clear enough and more clarifications are = needed? >>=20 >> If it's possible to clarify this without data to much text about = RFC7296 that would clearly help! >=20 > We've added a clarification in 7.2.2 that regular IKE_SA_INIT response = is meant > (containing SA, KE, NONCE etc. payloads). >=20 >=20 >> Thanks, >> Mirja >>=20 >>=20 >>=20 >>>=20 >>> Regards, >>> Valery. >=20 From nobody Wed Oct 12 11:51:08 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B7412952B for ; Wed, 12 Oct 2016 11:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmrIvLLknAtM for ; Wed, 12 Oct 2016 11:51:04 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 EF45612951E for ; Wed, 12 Oct 2016 11:51:03 -0700 (PDT) X-AuditID: c6180641-2580a98000000a0b-90-57fe31b19ba1 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by (Symantec Mail Security) with SMTP id 5A.9B.02571.1B13EF75; Wed, 12 Oct 2016 14:50:57 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0319.002; Wed, 12 Oct 2016 14:51:01 -0400 From: Daniel Migault To: IPsecME WG Thread-Topic: New Version Notification for draft-mglt-ipsecme-diet-esp-02.txt Thread-Index: AQHSJLBUBZ6aLz02xESyWK8EDhZSUaClWmwA///JvGA= Date: Wed, 12 Oct 2016 18:50:59 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C117F9AFA6@eusaamb107.ericsson.se> References: <147629427337.6345.10026955385959604828.idtracker@ietfa.amsl.com> <000401d224b0$60508760$20f19620$@mnm-team.org> In-Reply-To: <000401d224b0$60508760$20f19620$@mnm-team.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyuXRPiO5Gw3/hBo/WW1js3/KCzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGcu+32YsmCRa0fblN3sD4xmRLkYODgkBE4m9l8q6GDk5hAQ2 MEqseGHRxcgFZC9nlFh6ZTMjSIJNwEii7VA/O0i9iIC8xMwbmSBhYQEfiUlT+8FKRAR8JZa+ nssMYVtJnP2xlg2knEVAVWJLix5ImBeo5MzidkaIVXUS3Tf2MoHYnALWEldeHmcDsRkFxCS+ n1oDFmcWEJe49WQ+mC0hICCxZM95ZghbVOLl43+sELaSxMff88EuYxbQlFi/Sx+iVVFiSvdD doi1ghInZz5hmcAoMgvJ1FkIHbOQdMxC0rGAkWUVI0dpcUFObrqR4SZGYFgfk2Bz3MG4t9fz EKMAB6MSD+8Czn/hQqyJZcWVuYcYJTiYlUR49zQDhXhTEiurUovy44tKc1KLDzFKc7AoifNe D7kfLiSQnliSmp2aWpBaBJNl4uCUamDsXhZnzsWo+N/FiOFknMGdtDLrki6Jffk9Jh4/ZISU LrLrFa3J3BsQFp4Rzm5WYvZymu1eU0UuzYKL+kUCnRcd52WonK1nY5jp5R19Q1aFadKBD157 mhbpCEmUak7k8/SyebWWaZ8Ub7GMUKhqL5tn8BcjiTMdC3M0ilSbXtYKnN4y2XKFEktxRqKh FnNRcSIAb7/mn2cCAAA= Archived-At: Subject: [IPsec] FW: New Version Notification for draft-mglt-ipsecme-diet-esp-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 18:51:07 -0000 SGksIA0KDQpQbGVhc2UgZmluZCBhbiB1cGRhdGUgdmVyc2lvbiBvZiB0aGUgZGlldC1lc3AgZG9j dW1lbnQgd2UgZGlzY3Vzc2VkIGluIEJlcmxpbi4gVGhlIHNjb3BlIG9mIHRoZSBjb21wcmVzc2lv biBoYXMgYmVlbiBleHRlbmRlZCwgYW5kIHRoZSBjb21wcmVzc2lvbiBzaW1wbGlmaWVkLiBXZSBh bHNvIHByb3ZpZGVkIGV4YW1wbGUgaW4gdGhlIGFwcGVuZGl4IHNlY3Rpb24uDQoNCkNvbW1lbnRz IGFyZSB3ZWxjb21lIGFzIHVzdWFsIQ0KDQpCUiwgDQpEYW5pZWwNCg0KLS0tLS1VcnNwcsO8bmds aWNoZSBOYWNocmljaHQtLS0tLQ0KVm9uOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KR2VzZW5kZXQ6IE1pdHR3b2NoLCAxMi4gT2t0 b2JlciAyMDE2IDE5OjQ1DQpBbjogQ2Fyc3RlbiBCb3JtYW5uIDxjYWJvQHR6aS5vcmc+OyBEYW5p ZWwgTWlnYXVsdCA8ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tPjsgVG9iaWFzIEd1Z2dlbW9z IDxndWdnZW1vc0Btbm0tdGVhbS5vcmc+DQpCZXRyZWZmOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LW1nbHQtaXBzZWNtZS1kaWV0LWVzcC0wMi50eHQNCg0KDQpBIG5ldyB2ZXJz aW9uIG9mIEktRCwgZHJhZnQtbWdsdC1pcHNlY21lLWRpZXQtZXNwLTAyLnR4dA0KaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBEYW5pZWwgTWlnYXVsdCBhbmQgcG9zdGVkIHRvIHRo ZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1tZ2x0LWlwc2VjbWUtZGlldC1lc3AN ClJldmlzaW9uOgkwMg0KVGl0bGU6CQlFU1AgSGVhZGVyIENvbXByZXNzaW9uIGFuZCBEaWV0LUVT UA0KRG9jdW1lbnQgZGF0ZToJMjAxNi0xMC0wNA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Np b24NClBhZ2VzOgkJNDMNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtbWdsdC1pcHNlY21lLWRpZXQtZXNwLTAyLnR4dA0KU3RhdHVzOiAg ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1nbHQtaXBzZWNt ZS1kaWV0LWVzcC8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtbWdsdC1pcHNlY21lLWRpZXQtZXNwLTAyDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW1nbHQtaXBzZWNtZS1kaWV0LWVzcC0wMg0K DQpBYnN0cmFjdDoNCiAgIEVTUCBIZWFkZXIgQ29tcHJlc3Npb24gKEVIQykgZGVmaW5lcyBhIGZs ZXhpYmxlIGZyYW1ld29yayB0byBjb21wcmVzcw0KICAgY29tbXVuaWNhdGlvbnMgcHJvdGVjdGVk IHdpdGggSVBzZWMvRVNQLiAgQ29tcHJlc3Npb24gYW5kDQogICBkZWNvbXByZXNzaW9uIGlzIGRl ZmluZWQgYnkgRUhDIFJ1bGVzIG9yY2hlc3RyYXRlZCBieSBFSEMgU3RyYXRlZ2llcy4NCg0KICAg VGhlIGRvY3VtZW50IHNwZWNpZmllcyB0aGUgRGlldC1FU1AgRUhDIFN0cmF0ZWd5IGFuZCBhc3Nv Y2lhdGVkIEVIQw0KICAgUnVsZXMuICBEaWV0LUVTUCBjb21wcmVzc2VzIHVwIHRvIDMyIGJ5dGVz IHBlciBwYWNrZXQgZm9yIHRyYWRpdGlvbmFsDQogICBJUHY2IFZQTiBhbmQgdXAgdG8gNjYgYnl0 ZXMgZm9yIElQdjYgVlBOIHNldCBvdmVyIGEgc2luZ2xlIFRDUCBvciBVRFANCiAgIHNlc3Npb24u DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVu dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMu aWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0K From nobody Thu Oct 13 00:41:34 2016 Return-Path: X-Original-To: expand-draft-ietf-ipsecme-safecurves.all@virtual.ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id DB5C5128DF6; Thu, 13 Oct 2016 00:41:29 -0700 (PDT) X-Original-To: xfilter-draft-ietf-ipsecme-safecurves.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-ipsecme-safecurves.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB0C129424; Thu, 13 Oct 2016 00:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTWFOaLmmgOm; Thu, 13 Oct 2016 00:41:28 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 13B9D128DF6; Thu, 13 Oct 2016 00:41:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5E80A2CCAE; Thu, 13 Oct 2016 10:41:27 +0300 (EEST) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOL-lK3zE1L7; Thu, 13 Oct 2016 10:41:26 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id D3ABA2CC40; Thu, 13 Oct 2016 10:41:26 +0300 (EEST) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A82033C3-B6DB-4E59-BEC6-8577205FC15F"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: Date: Thu, 13 Oct 2016 10:41:25 +0300 Message-Id: References: <0634F364-C8D4-45EB-9FD8-214FD9C1E72E@gmail.com> To: Orit Levin , Yoav Nir X-Mailer: Apple Mail (2.1878.6) Resent-From: Resent-To: ynir.ietf@gmail.com, simon@josefsson.org, david.waltermire@nist.gov, kivinen@iki.fi, Kathleen.Moriarty.ietf@gmail.com, stephen.farrell@cs.tcd.ie, "Tero Kivinen" , ipsec@ietf.org Resent-Message-Id: <20161013074129.DB5C5128DF6@ietfa.amsl.com> Resent-Date: Thu, 13 Oct 2016 00:41:29 -0700 (PDT) Archived-At: Cc: General Area Review Team , "draft-ietf-ipsecme-safecurves.all@ietf.org" Subject: Re: [IPsec] Gen-ART Last Call review of draft-ietf-ipsecme-safecurves-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 07:41:30 -0000 --Apple-Mail=_A82033C3-B6DB-4E59-BEC6-8577205FC15F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Orit & Yoav, thanks much for the review and edits. I have balloted = no-obj for this document for the tonight=92s IESG telechat. Jari --Apple-Mail=_A82033C3-B6DB-4E59-BEC6-8577205FC15F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJX/zqmAAoJEM80gCTQU46qOuQP/jNwRj01irCUrl/TNrcWvRrb 5ipuiNOwERa4cCuSuEOhDmZ8M6OFl6cYYx/3t3ipSMKHfPZsRtt0kaVXP7aMiu/t mKdCCbxwA3cp7TQa+bVl5tnsjWv6A7zE7C6Td3rreeoH+HT9gNoFoyBJEbMMP3dA fW5a1HByVvAhlFtS9zuwiT3P1+XKnqznpES3L0LbvZLFDO0zM2hS6EBpGohNIIi2 +NhuNnLb1ghejAh8SOL/4vwLLnYP5Hdys0SOtFzISK9TiyHZrk9iwsjPlwbG04Z0 FNIVzl5iZ2RN/q1PEfFLgvBFATAU/HqbTTGtopb70sBYQe15RANALPtRm7oRbkzX WfCnlyKjwWrSdrR65gNPDz31yXtm1FLkzUTmEou7FU/FzPvkZXMS96Icl6ENll+G kyjk7Mei94DED4/PsnkAjZs88xMdwoMbkS4pMvZyfLgOFvkN5W62+29kbu3N7k5h 4I+fw5yRUFiMysPskN465cO+PRCyEJqQpozhpqhhFanWzguIbQ2pQSUvazGlkKrc yVdelcrDOxo8c4ET1mVkEEO43a6XZeeCxHl8sF+fvF5+XxeszmlwJEOM9UpQcRwc t0p8seMdSGgv5ImiEix8OsnnJ7A9RnGzR7qXP/bBsmy2ppfSxaHJcodc8ytTBqqN HbTkvpH3ECsUGQWuym0n =oiDs -----END PGP SIGNATURE----- --Apple-Mail=_A82033C3-B6DB-4E59-BEC6-8577205FC15F-- From nobody Thu Oct 13 04:50:51 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B340A129464; Thu, 13 Oct 2016 04:50:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147635944969.2874.17979129045296855264.idtracker@ietfa.amsl.com> Date: Thu, 13 Oct 2016 04:50:49 -0700 Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-safecurves@ietf.org, kivinen@iki.fi Subject: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-safecurves-05: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 11:50:50 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-ipsecme-safecurves-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-safecurves/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - Wouldn't it be good to encourage minimising re-use of public values for multiple key exchanges? As-is, the text sort-of encourages use for "many key exchanges" in section 4. - Sorry if I'm forgetting how we handle this in IPsec, but is an implementation of this RFC expected to support both curves? I think it'd be ok to say that 25519 is a MUST for folks doing, this but that 448 is optional. I'm also fine if we mean that implementing this means you have to support both btw but you don't say (here) that that's the case. From nobody Thu Oct 13 05:04:40 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7457412943B; Thu, 13 Oct 2016 05:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLf_XcL0tQrx; Thu, 13 Oct 2016 05:04:35 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86E8D129426; Thu, 13 Oct 2016 05:04:31 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u9DC4I8R014998 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 13 Oct 2016 15:04:18 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u9DC4IqM026752; Thu, 13 Oct 2016 15:04:18 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22527.30786.897423.123891@fireball.acr.fi> Date: Thu, 13 Oct 2016 15:04:18 +0300 From: Tero Kivinen To: "Stephen Farrell" In-Reply-To: <147635944969.2874.17979129045296855264.idtracker@ietfa.amsl.com> References: <147635944969.2874.17979129045296855264.idtracker@ietfa.amsl.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 11 min X-Total-Time: 10 min Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, The IESG , draft-ietf-ipsecme-safecurves@ietf.org Subject: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-safecurves-05: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 12:04:39 -0000 Stephen Farrell writes: > Stephen Farrell has entered the following ballot position for > draft-ietf-ipsecme-safecurves-05: Yes > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > - Sorry if I'm forgetting how we handle this in IPsec, > but is an implementation of this RFC expected to support > both curves? I think it'd be ok to say that 25519 is a > MUST for folks doing, this but that 448 is optional. I'm > also fine if we mean that implementing this means you > have to support both btw but you don't say (here) that > that's the case. In IPsec we do not specify any requirement levels in the actual algorithm documents. The algorithm documents just allocate the IANA numbers and specify how they algorithms are used. Then we have separate documents (new versions soon to be in front of IESG) specifying the actual mandatory to implement algorithms. Whether some implementation supports this new RFC is something that does not have well define answer, as people could say they implement this RFC if they support one or other, or both curves. Usually people are just saying they support algorithm RFC if they support one algorithm from there. I.e., vendors usually say they support RFC2451, even if they only support 3DES from there, and might not support CAST-128, RC5, IDEA and Blowfish. Anyways the mandatory to implement ciphers are specified in the rfc4307bis [1] and rfc7321bis [2]. These curves are not mentioned there, so they are still going to be MAY. When we are going to update 4307bis again then we are most likely going to make them SHOULD+ or even MUST (if there is enough implementations actually implementing them at that point). [1] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ [2] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-rfc7321bis/ -- kivinen@iki.fi From nobody Thu Oct 13 05:07:36 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07142128874; Thu, 13 Oct 2016 05:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.297 X-Spam-Level: X-Spam-Status: No, score=-7.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcNNnNJnj75P; Thu, 13 Oct 2016 05:07:31 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02BD129426; Thu, 13 Oct 2016 05:07:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C2AEBBE4D; Thu, 13 Oct 2016 13:07:28 +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 cBYoa1xLP8rb; Thu, 13 Oct 2016 13:07:28 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2C6A4BE32; Thu, 13 Oct 2016 13:07:28 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1476360448; bh=xvV8JhDdHzhHQ2BCYSbSZIUAFiVZUFAEEj5dqhGDUAk=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=eoFpjWAyvR140bnUDLm7v6uu4pMVNFHJitcG2w9lliwhgYLKoSNQh2Tyiw6+lq45B +27iHnCLDvZm31rzHJZcjqnBtaNGNaw++k+bqgPLXseYG2G4otRnCz1mcc23YfGy9k fRzdv/F7sg13CMyVhk0U4djAFU8XIyxmwYQ03y6A= To: Tero Kivinen References: <147635944969.2874.17979129045296855264.idtracker@ietfa.amsl.com> <22527.30786.897423.123891@fireball.acr.fi> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <04fc9ee1-283a-3232-9fb7-dd3c4100bf58@cs.tcd.ie> Date: Thu, 13 Oct 2016 13:07:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <22527.30786.897423.123891@fireball.acr.fi> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000303040404090403030202" Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, The IESG , draft-ietf-ipsecme-safecurves@ietf.org Subject: Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-safecurves-05: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 12:07:34 -0000 This is a cryptographically signed message in MIME format. --------------ms000303040404090403030202 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Tero and sorry for forgetting:-) Cheers, S. On 13/10/16 13:04, Tero Kivinen wrote: > Stephen Farrell writes: >> Stephen Farrell has entered the following ballot position for >> draft-ietf-ipsecme-safecurves-05: Yes >> >> ----------------------------------------------------------------------= >> COMMENT: >> ----------------------------------------------------------------------= >> - Sorry if I'm forgetting how we handle this in IPsec, >> but is an implementation of this RFC expected to support >> both curves? I think it'd be ok to say that 25519 is a >> MUST for folks doing, this but that 448 is optional. I'm >> also fine if we mean that implementing this means you >> have to support both btw but you don't say (here) that >> that's the case. >=20 > In IPsec we do not specify any requirement levels in the actual > algorithm documents. The algorithm documents just allocate the IANA > numbers and specify how they algorithms are used. >=20 > Then we have separate documents (new versions soon to be in front of > IESG) specifying the actual mandatory to implement algorithms. >=20 > Whether some implementation supports this new RFC is something that > does not have well define answer, as people could say they implement > this RFC if they support one or other, or both curves. Usually people > are just saying they support algorithm RFC if they support one > algorithm from there. I.e., vendors usually say they support RFC2451, > even if they only support 3DES from there, and might not support > CAST-128, RC5, IDEA and Blowfish. >=20 > Anyways the mandatory to implement ciphers are specified in the > rfc4307bis [1] and rfc7321bis [2]. >=20 > These curves are not mentioned there, so they are still going to be > MAY. When we are going to update 4307bis again then we are most likely > going to make them SHOULD+ or even MUST (if there is enough > implementations actually implementing them at that point). >=20 > [1] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ > [2] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-rfc7321bis/ >=20 --------------ms000303040404090403030202 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEwMTMx MjA3MjhaMC8GCSqGSIb3DQEJBDEiBCBJkZs1glr781xiAOe7MSJPN3oMQXC7E7jp2FQFpM17 djBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBeZnjcYjMoZsq0J8p9K9aGd/VenEfbH6JtfHPwN7YQDnMatOpp8xPu t3QPUR/XaXu5wt3YYB9XF84oHnyADJ9J+gOXwMsYSAy+vLE8dXpxip81EtDzaA76R2RIU3pf du/XKOEioKG+1x7WFDMLMPXV80EOhSPJBIORdtSPMkVG0eR+hV+kdUK0whaYyD/uuTNBp+Lm z1wkEPfHWeC11pX55QL0UptYt6mzernlsjtBM+2lNkc/quE8m/l1S8qxSFGK1g9/JIp9XSmV YzFayeezOGBQgCDpnuf52gxmcuphL0ICbbuVdzTxnXM1z7OxmAhFkRqvVs1ipi37x/WvxqR3 AAAAAAAA --------------ms000303040404090403030202-- From nobody Thu Oct 13 05:27:49 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2CD12964A; Thu, 13 Oct 2016 05:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M70OiqqncsRK; Thu, 13 Oct 2016 05:27:46 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D5021294A4; Thu, 13 Oct 2016 05:27:46 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id s49so40648369qta.0; Thu, 13 Oct 2016 05:27:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2tvuPVd/Gko/k3TD5qZB9DUvnQ+9+FIx09iDJXHN96I=; b=euYSXLDasnx7MhNnPfOh/iK6WkylETKFRtvNH5fge8rekckg6jKgW/Fy6BXdk5RqtA 06WxF/AN8OUkPUO8nyV2AyXv/ZuM6DcSRxkh4sFFmMNcASC3i059CXrS9yUkYj0F5yeo mG1comKxrSjvtuHR1jtHTp4A5M6nzR1L6iWKPO92wBx8Z68uX2M0naFBD1Rigr7SaKDh A+m/71f1NfIfrb839CN/XRcpVyIAO7PyX7EP5Vz0JIfqhv8wzob0sNSPa0OQz2SOuT/Z 5BT8npR8pJWZQIs5jSagxDMC4dMLba5jn5uzQObmE7VT+tsdggTabnope9QOSb4OQds5 CAXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2tvuPVd/Gko/k3TD5qZB9DUvnQ+9+FIx09iDJXHN96I=; b=XIaFgI43BXF2svnAdzm1NnhvkXnqR8OMs7KNl3vX0yHt5vZ5+bznS4v3CgdOwZc/4t cnc9bP39bD2b1ZaaXNYOl1j3aTSfkOE5hL+GEnPi/gmaHoiCItKQ8gBdoIkcOe1BE+Jo OLcsCNav+inA6fYzJbmUhmVGkl+nJnFClybSpsR1deOB0BTBz6qWbVyhXliZExSYv/C0 bt/47zWxxlTcXwznjIrfVV4ray9811aSIlbxOqO41EjTNp26t3fXVlTN/MVVrjKYJKil 4BEuGX5JJqZ789n/PJduN7DeqbT5EXoSDNS0U1JiHZhGURHaydMW/C2YIHfdc7tm89++ 8sRg== X-Gm-Message-State: AA6/9RkHMeV+Y5G++mKfFgl8pD2Hwbg2y+iD3Z/u7cN8ANfOfYy4faWtTwJsqNB+Dgvanw== X-Received: by 10.28.66.149 with SMTP id k21mr1992439wmi.106.1476361662273; Thu, 13 Oct 2016 05:27:42 -0700 (PDT) Received: from [172.24.251.108] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id rv12sm22228160wjb.29.2016.10.13.05.27.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Oct 2016 05:27:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Yoav Nir In-Reply-To: <147635944969.2874.17979129045296855264.idtracker@ietfa.amsl.com> Date: Thu, 13 Oct 2016 15:27:39 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2C57AD9C-33F3-4C9B-8C1F-27FEE35B9A97@gmail.com> References: <147635944969.2874.17979129045296855264.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.3226) Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, The IESG , Tero Kivinen , draft-ietf-ipsecme-safecurves@ietf.org Subject: Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-safecurves-05: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 12:27:48 -0000 Hi, Stephen >=20 > - Wouldn't it be good to encourage minimising re-use of > public values for multiple key exchanges? As-is, the text > sort-of encourages use for "many key exchanges" in > section 4. I don=E2=80=99t think so. Re-use reduces the computation cost of an IKE = Responder (or TLS server) without sacrificing security. There was some = discussion of this in CFRG, but I see that it didn=E2=80=99t make it = into RFC 7748, so all I can find is some StackExchange question ([1]). It does make the static keypair valuable. It is definitely not a good = idea to store the private key on-disk and keep it forever, but = generating a new key once in a while and discarding the old key is = usually a good compromise there. Anyway key-pair reuse is established practice. Using constant-time = implementations is essential to making this practice safe, and the = Security Considerations sections says just that. Yoav [1] = http://crypto.stackexchange.com/questions/11012/reuse-of-a-dh-ecdh-public-= key= From nobody Thu Oct 13 05:36:41 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B91212974A; Thu, 13 Oct 2016 05:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.297 X-Spam-Level: X-Spam-Status: No, score=-7.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beWzgtReYfXd; Thu, 13 Oct 2016 05:36:38 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4465129748; Thu, 13 Oct 2016 05:36:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 280EBBE83; Thu, 13 Oct 2016 13:36:36 +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 4arRO1UKxq6R; Thu, 13 Oct 2016 13:36:36 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 86442BE7C; Thu, 13 Oct 2016 13:36:35 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1476362195; bh=aIcMFHlHbMcPGXBvvjhLnFjEtrz2SLN5s5Y72gTNR1M=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=vzMGhU2c7G8EHwl704Pr/9cWmSwbeqBR8ijFMP0pgiCdHCjraKYmEAoSI7gSHFbUd RtpKm1+F9Jn9EWxvA7kDBbnyZ506jLOFo9kASSIvJy5NxwfrlKBBcJo9G4ybCbHeVr FbcNGxn1rw9vfidE0AnMkN5My3tSNokJrFNVcAYk= To: Yoav Nir References: <147635944969.2874.17979129045296855264.idtracker@ietfa.amsl.com> <2C57AD9C-33F3-4C9B-8C1F-27FEE35B9A97@gmail.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <96cc045f-cc86-543e-3670-604e49a160b1@cs.tcd.ie> Date: Thu, 13 Oct 2016 13:36:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <2C57AD9C-33F3-4C9B-8C1F-27FEE35B9A97@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040304090306050702040600" Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, The IESG , Tero Kivinen , draft-ietf-ipsecme-safecurves@ietf.org Subject: Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-safecurves-05: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 12:36:40 -0000 This is a cryptographically signed message in MIME format. --------------ms040304090306050702040600 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 13/10/16 13:27, Yoav Nir wrote: > Hi, Stephen >=20 >>=20 >> - Wouldn't it be good to encourage minimising re-use of public >> values for multiple key exchanges? As-is, the text sort-of >> encourages use for "many key exchanges" in section 4. >=20 > I don=E2=80=99t think so.=20 Fair enough, though when I said "minimise" I didn't mean "never re-use." But all you say below is correct, so not that big a deal, but I do think it'd be better to explicitly encourage implementers to roll their private values as often as makes sense in their situation. S. > Re-use reduces the computation cost of an IKE > Responder (or TLS server) without sacrificing security. There was > some discussion of this in CFRG, but I see that it didn=E2=80=99t make = it > into RFC 7748, so all I can find is some StackExchange question > ([1]). >=20 > It does make the static keypair valuable. It is definitely not a good > idea to store the private key on-disk and keep it forever, but > generating a new key once in a while and discarding the old key is > usually a good compromise there. >=20 > Anyway key-pair reuse is established practice. Using constant-time > implementations is essential to making this practice safe, and the > Security Considerations sections says just that. >=20 > Yoav >=20 > [1] > http://crypto.stackexchange.com/questions/11012/reuse-of-a-dh-ecdh-publ= ic-key > --------------ms040304090306050702040600 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEwMTMx MjM2MzVaMC8GCSqGSIb3DQEJBDEiBCDIsI+4YodDKgfNKBbthSWtRldoJrtiCZpLrJZhJ6gz VjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQA0+4yiQ4OwZUBivn15/z5k8F6H5QbzRVQV2Hv24r8Mg3cl2icFSSAk JUWseHDrfQuaMJowkhOZhArmO5hQU2e64TpTvsFFAFkd88q+EGpBlWnG7UOigi4lqChvF5kl NpqW6IXVLKy46ER7MY4YrNbM24QOk6B8YJb0CFzbFIl6ctJmyyENDeMcm6M3rrZVxaFm6K+J Gsdkuz//ETPNYycNTAqtPgnbLo+rx6doFvqLcbybQxNLC6aryu5PjIigQpN4b6P3KHbFXOkO i7AgLAcy3SUUod6SqEotqQkG/lECZXe6f9MgzYjWFLGRs/es0ax4jwnRPmmf+i/j7IRWPrNZ AAAAAAAA --------------ms040304090306050702040600-- From nobody Thu Oct 13 08:47:43 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E416B127077; Thu, 13 Oct 2016 08:47:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , "Tero Kivinen" X-Test-IDTracker: no X-IETF-IDTracker: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147637366292.2921.5441996205173068599.idtracker@ietfa.amsl.com> Date: Thu, 13 Oct 2016 08:47:42 -0700 From: IETF Secretariat Archived-At: Subject: [IPsec] ID Tracker State Update Notice: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 15:47:43 -0000 IESG state changed to Approved-announcement to be sent from Waiting for AD Go-Ahead ID Tracker URL: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-safecurves/ From nobody Mon Oct 17 08:30:59 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCD812952C; Mon, 17 Oct 2016 08:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTFqmvSoCI_r; Mon, 17 Oct 2016 08:30:53 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 2B835129864; Mon, 17 Oct 2016 08:30:53 -0700 (PDT) X-AuditID: c1b4fb2d-5b107980000009f7-ac-5804eeabc8de Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id B3.A2.02551.BAEE4085; Mon, 17 Oct 2016 17:30:51 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.139]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0319.002; Mon, 17 Oct 2016 17:30:50 +0200 From: John Mattsson To: Paul Wouters , "ipsec@ietf.org WG" Thread-Topic: [IPsec] trapdoor'ed DH (and RFC-5114 again) Thread-Index: AQHSInPGicgFRx0r+0aIJTg4zs5+RKCs0pWA Date: Mon, 17 Oct 2016 15:30:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.7.160722 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEIsWRmVeSWpSXmKPExsUyM2K7tO7qdywRBncmKVjs3/KCzeL9rUtM FlP6O5kcmD2WLPnJ5PF9HlMAUxSXTUpqTmZZapG+XQJXRvu/x0wFGxQqDnetZ25gPCLfxcjJ ISFgIrH8w37WLkYuDiGB9YwSn+f9hnKWMEosPXmRHaSKTcBAYu6eBjYQW0TAXWLXjw5GEJtZ QFni7Z8nTCC2sICFRNf01ywQNZYSE+5tA4pzANlGEj2PxEHCLAKqEvc/fmEGsXkFzCV+dHwG Gy8kYC/xoW0RmM0p4CCx7dx6sBpGATGJ76fWMEGsEpe49WQ+E8TRAhJL9pxnhrBFJV4+/scK YosK6Ek8+/ycHSKuJLHo9mewE5gFNCXW79KHGGMtceD6VjYIW1FiSvdDdohzBCVOznzCMoFR fBaSbbMQumch6Z6FpHsWku4FjKyrGEWLU4uLc9ONjPVSizKTi4vz8/TyUks2MQJj7uCW37o7 GFe/djzEKMDBqMTDm3CTJUKINbGsuDL3EKMEB7OSCO/l+0Ah3pTEyqrUovz4otKc1OJDjNIc LErivGYr74cLCaQnlqRmp6YWpBbBZJk4OKUaGNdWH1oaWSx3f/5fQ8vFpV2FewM3Tr9r6clT 37b+uvyVP2XqPzVm7C26FPSkh0NwZ/Srt2EZ4ipXU+JO+QV3Rl8ucTAVT3leP/lum8TaiNAd UzMbVn5LuX77jrDDdjvd/KU/LqZ2zdxv3p8/6+jNGf8XP10jO+cK/yy//SoHD1hMDw6dvKr4 b5MSS3FGoqEWc1FxIgCbIIDltQIAAA== Archived-At: Cc: "saag@ietf.org" Subject: Re: [IPsec] trapdoor'ed DH (and RFC-5114 again) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 15:30:55 -0000 PiBJJ20gcHJvcG9zaW5nIGl0IGlzIHRpbWUgdG8gY2hhbmdlIHRoaXMgdG8gTVVTVCBOT1QgZm9y IDQzMDdiaXMuDQoNCg0KDQorMSANCg0KT24gMDkvMTAvMTYgMjM6MjYsICJJUHNlYyBvbiBiZWhh bGYgb2YgUGF1bCBXb3V0ZXJzIg0KPGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9m IHBhdWxAbm9oYXRzLmNhPiB3cm90ZToNCg0KPg0KPlJlbGVhc2VkIGEgZmV3IGRheXMgYWdvOg0K Pg0KPiAJaHR0cDovL2VwcmludC5pYWNyLm9yZy8yMDE2Lzk2MQ0KPg0KPiAJQSBraWxvYml0IGhp ZGRlbiBTTkZTIGRpc2NyZXRlIGxvZ2FyaXRobSBjb21wdXRhdGlvbg0KPiAJSm9zaHVhIEZyaWVk IGFuZCBQaWVycmljayBHYXVkcnkgYW5kIE5hZGlhIEhlbmluZ2VyIGFuZCBFbW1hbnVlbCBUaG9t w6kNCj4NCj4gCVdlIHBlcmZvcm0gYSBzcGVjaWFsIG51bWJlciBmaWVsZCBzaWV2ZSBkaXNjcmV0 ZSBsb2dhcml0aG0NCj4gCWNvbXB1dGF0aW9uIGluIGEgMTAyNC1iaXQgcHJpbWUgZmllbGQuIFRv IG91ciBrbm93bGVkZ2UsIHRoaXMNCj4gCWlzIHRoZSBmaXJzdCBraWxvYml0LXNpemVkIGRpc2Ny ZXRlIGxvZ2FyaXRobSBjb21wdXRhdGlvbiBldmVyDQo+IAlyZXBvcnRlZCBmb3IgcHJpbWUgZmll bGRzLiBUaGlzIGNvbXB1dGF0aW9uIHRvb2sgYSBsaXR0bGUgb3Zlcg0KPiAJdHdvIG1vbnRocyBv ZiBjYWxlbmRhciB0aW1lIG9uIGFuIGFjYWRlbWljIGNsdXN0ZXIgdXNpbmcgdGhlDQo+IAlvcGVu LXNvdXJjZSBDQURPLU5GUyBzb2Z0d2FyZS4NCj4NCj5CYXNpY2FsbHksIHRoaXMgcGFwZXIgc2hv d3MgaG93IHRvIG1ha2UgYSBESCBncm91cCBvZiAxMDI0IG1vZHANCj53aXRoIGEgYmFja2Rvb3Is IGluIHR3byBtb250aHMgb2YgYWNhZGVtaWMgY29tcHV0aW5nIHJlc291cmNlcywNCj4NCj5UaGUg cGFwZXIgbWVudGlvbnMgNTExNCBhIGZldyB0aW1lczoNCj4NCj4gCVJGQyA1MTE0IFszM10gc3Bl Y2lmaWVzIGEgbnVtYmVyIG9mIGdyb3VwcyBmb3IgdXNlIHdpdGgNCj4gCURpZmZpZS1IZWxsbWFu LCBhbmQgc3RhdGVzIHRoYXQgdGhlIHBhcmFtZXRlcnMgd2VyZSBkcmF3bg0KPiAJZnJvbSBOSVNU IHRlc3QgZGF0YSwgYnV0IG5laXRoZXIgdGhlIE5JU1QgdGVzdCBkYXRhIFszOV0gbm9yDQo+IAlS RkMgNTExNCBpdHNlbGYgY29udGFpbiB0aGUgc2VlZHMgdXNlZCB0byBnZW5lcmF0ZSB0aGUgZmlu aXRlDQo+IAlmaWVsZCBwYXJhbWV0ZXJzDQo+DQo+QW5kIGNvbmNsdWRlczoNCj4NCj4gCUJvdGgg ZnJvbSB0aGlzIHBlcnNwZWN0aXZlLCBhbmQgZnJvbSBvdXIgbW9yZSBtb2Rlcm4gb25lLCBkaXNt aXNzaW5nIHRoZQ0KPiAJcmlzayBvZiB0cmFwZG9vcmVkIHByaW1lcyBpbiByZWFsIHVzYWdlIGFw cGVhcnMgdG8gaGF2ZSBiZWVuIGEgbWlzdGFrZSwNCj4gCWFzIHRoZSBhcHBhcmVudCBkaWZmaWN1 bHRpZXMgZW5jb3VudGVyZWQgYnkgdGhlIHRyYXBkb29yIGRlc2lnbmVyIGluDQo+MTk5Mg0KPiAJ dHVybiBvdXQgdG8gYmUgZWFzaWx5IGNpcmN1bXZlbnRlZC4gQSBtb3JlIGNvbnNlcnZhdGl2ZSBk ZXNpZ24gZGVjaXNpb24NCj4gCWZvciBGSVBTIDE4NiB3b3VsZCBoYXZlIHJlcXVpcmVkIG1hbmRh dG9yeSBzZWVkIHB1YmxpY2F0aW9uIGluc3RlYWQgb2YNCj4gCW1ha2luZyBpdCBvcHRpb25hbC4g IEFzIGEgcmVzdWx0LCB0aGVyZSBhcmUgb3BhcXVlLCBzdGFuZGFyZGl6ZWQNCj4xMDI0LWJpdA0K PiAJYW5kIDIwNDgtYml0IHByaW1lcyBpbiB3aWRlIHVzZSB0b2RheSB0aGF0IGNhbm5vdCBiZSBw cm9wZXJseSB2ZXJpZmllZC4NCj4NCj5UaGlzIGlzIHRoZSBzdHJvbmdlc3Qgc3RhdGVtZW50IHll dCB0aGF0IEkndmUgc2VlbiB0byBub3QgdHJ1c3QgYW55DQo+b2YgdGhlIFJGQy01MTE0IGdyb3Vw cy4NCj4NCj5UaGUgbGF0ZXN0IDQzMDdiaXMgZG9jdW1lbnQgaGFzIHRoZXNlIGdyb3VwcyAoMjIt MjQpIGFzIFNIT1VMRCBOT1QsDQo+c3RhdGluZzoNCj4NCj4gCUdyb3VwIDIyLCAyMyBhbmQgMjQg b3IgMTAyNC1iaXQgTU9EUCBHcm91cCB3aXRoIDE2MC1iaXQsIGFuZA0KPiAJMjA0OC1iaXQgTU9E UCBHcm91cCB3aXRoIDIyNC1iaXQgYW5kIDI1Ni1iaXQgUHJpbWUgT3JkZXIgU3ViZ3JvdXANCj4g CWhhdmUgc21hbGwgc3ViZ3JvdXBzLCB3aGljaCBtZWFucyB0aGF0IGNoZWNrcyBzcGVjaWZpZWQg aW4gdGhlDQo+IAkiQWRkaXRpb25hbCBEaWZmaWUtSGVsbG1hbiBUZXN0IGZvciB0aGUgSUtFdjIi IFtSRkM2OTg5XSBzZWN0aW9uDQo+IAkyLjIgZmlyc3QgYnVsbGV0IHBvaW50IE1VU1QgYmUgZG9u ZSB3aGVuIHRoZXNlIGdyb3VwcyBhcmUgdXNlZC4NCj4gCVRoZXNlIGdyb3VwcyBhcmUgYWxzbyBu b3Qgc2FmZS1wcmltZXMuCVRoZSBzZWVkcyBmb3IgdGhlc2UgZ3JvdXBzDQo+IAloYXZlIG5vdCBi ZWVuIHB1YmxpY2x5IHJlbGVhc2VkLCByZXN1bHRpbmcgaW4gcmVkdWNlZCB0cnVzdCBpbg0KPiAJ dGhlc2UgZ3JvdXBzLiAgVGhlc2UgZ3JvdXBzIHdlcmUgcHJvcG9zZWQgYXMgYWx0ZXJuYXRpdmVz IGZvcg0KPiAJZ3JvdXAgMiBhbmQgMTQgYnV0IG5ldmVyIHNhdyB3aWRlIGRlcGxveW1lbnQuICBJ dCBpcyBleHBlY3RlZA0KPiAJaW4gdGhlIG5lYXIgZnV0dXJlIHRvIGJlIGZ1cnRoZXIgZG93bmdy YWRlZCB0byBNVVNUIE5PVC4NCj4NCj5JJ20gcHJvcG9zaW5nIGl0IGlzIHRpbWUgdG8gY2hhbmdl IHRoaXMgdG8gTVVTVCBOT1QgZm9yIDQzMDdiaXMuDQo+DQo+UG9zc2libHksIHdlIHNob3VsZCBk byB0aGlzIHZpYSBTQUFHIGluIGdlbmVyYWwsIGFuZCB0aGVuIGZvbGxvdyBTQUFHJ3MNCj5hZHZp c2UgaW4gSVBTRUNNRS4NCj4NCj5JcyB0aGVyZSBfYW55XyByZWFzb24gd2h5IGdyb3VwIDIyLTI0 IHNob3VsZCBub3QgYmUgTVVTVCBOT1QgPw0KPg0KPlBhdWwNCj4NCj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPklQc2VjIG1haWxpbmcgbGlzdA0KPklQ c2VjQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNl Yw0KDQo= From nobody Mon Oct 17 08:54:28 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5491129883; Mon, 17 Oct 2016 08:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nTQz8u1tWcWj; Mon, 17 Oct 2016 08:54:22 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 458551295B1; Mon, 17 Oct 2016 08:54:21 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id 4so54784434itv.0; Mon, 17 Oct 2016 08:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jASj6BiLK9m1/kugc2btQsvRkMBemNYRfscQHniTBYA=; b=Bx+jnFlyv0UcWaM+gvr0EJz2/Lj1YXNvbmQyVeCBvaAYtp/670lWYKNoHs/IkdMzVR ZBU4OzZJOPWkGUBKRy8uqgPzyEk+OXWKHv6hDggqlC3WVh4dM2Od0KeC5/rhdkeeRIhY e68b7WQA6Jo01YgLIVwBjGwQdTbajDTuryqbR/XFXgHmI/ByPrDdpauMOhhs12UHMgur 4DQc3HBwufC2663sWEXux6Iy61ZcnvVw0E11hAEDzV8A7PkNBOuX/iFSln16Rm+oZBbH K9N3/TTpS439vr1Wgk2oNNPKjEtbPlaaRCGw3AsUv7sGK2oEZ2+ac2sXe4/MbYPJGq94 OZ5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jASj6BiLK9m1/kugc2btQsvRkMBemNYRfscQHniTBYA=; b=YBi+vaikM0X8QBN8cWBT1jxdRUeNgd6JrQv6gOdnAAzkOtYE8i1nrisuUXAig5xxv3 qaEGf8K+kVV3o5XY2wGJbyLUZff4pkaTftfiXLVBoYf+u4UKs75e8s2UuhNiEGOQI1QG EiK9vIVmR11ob4CfzClvjhKlYVfXM+gYv/XPvx0UX6yW4XyiofrFV6yb+Ax9svWWJ6nF DZwQdyspFpTv7bqoZG1uIONgJog6PK+lkuHwbEPCwbUewMrAZWzEkABOyQLlhZ8brdAu 7KOhqPcrYJzWEnEGrLbr/yunB0VNxftfbYKPXztQyF2oBK6BhB87YUp6XJGXP4g6RYsj H1CQ== X-Gm-Message-State: AA6/9RnEfWM/9llKKreZBLgSbthjIWPHD7carEZJWe/INy8MyloqktKxE2ge7mYkHZULcGTALIBRaXPiXOHlSQ== X-Received: by 10.36.254.200 with SMTP id w191mr9913833ith.101.1476719660461; Mon, 17 Oct 2016 08:54:20 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.188.4 with HTTP; Mon, 17 Oct 2016 08:54:19 -0700 (PDT) In-Reply-To: References: From: Daniel Migault Date: Mon, 17 Oct 2016 11:54:19 -0400 X-Google-Sender-Auth: gLMcNedO7nuRXi1KTa6eaA-Ihd0 Message-ID: To: John Mattsson Content-Type: multipart/alternative; boundary=94eb2c03473ecb737b053f1196a6 Archived-At: Cc: "ipsec@ietf.org WG" , Paul Wouters , "saag@ietf.org" Subject: Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 15:54:27 -0000 --94eb2c03473ecb737b053f1196a6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In fact is there anyone opposing their status becomes MUST NOT in rfc4307bis. On Mon, Oct 17, 2016 at 11:30 AM, John Mattsson wrote: > > I'm proposing it is time to change this to MUST NOT for 4307bis. > > > > +1 > > On 09/10/16 23:26, "IPsec on behalf of Paul Wouters" > wrote: > > > > >Released a few days ago: > > > > http://eprint.iacr.org/2016/961 > > > > A kilobit hidden SNFS discrete logarithm computation > > Joshua Fried and Pierrick Gaudry and Nadia Heninger and Emmanuel > Thom=C3=A9 > > > > We perform a special number field sieve discrete logarithm > > computation in a 1024-bit prime field. To our knowledge, this > > is the first kilobit-sized discrete logarithm computation ever > > reported for prime fields. This computation took a little over > > two months of calendar time on an academic cluster using the > > open-source CADO-NFS software. > > > >Basically, this paper shows how to make a DH group of 1024 modp > >with a backdoor, in two months of academic computing resources, > > > >The paper mentions 5114 a few times: > > > > RFC 5114 [33] specifies a number of groups for use with > > Diffie-Hellman, and states that the parameters were drawn > > from NIST test data, but neither the NIST test data [39] nor > > RFC 5114 itself contain the seeds used to generate the finite > > field parameters > > > >And concludes: > > > > Both from this perspective, and from our more modern one, > dismissing the > > risk of trapdoored primes in real usage appears to have been a > mistake, > > as the apparent difficulties encountered by the trapdoor designer > in > >1992 > > turn out to be easily circumvented. A more conservative design > decision > > for FIPS 186 would have required mandatory seed publication > instead of > > making it optional. As a result, there are opaque, standardized > >1024-bit > > and 2048-bit primes in wide use today that cannot be properly > verified. > > > >This is the strongest statement yet that I've seen to not trust any > >of the RFC-5114 groups. > > > >The latest 4307bis document has these groups (22-24) as SHOULD NOT, > >stating: > > > > Group 22, 23 and 24 or 1024-bit MODP Group with 160-bit, and > > 2048-bit MODP Group with 224-bit and 256-bit Prime Order Subgroup > > have small subgroups, which means that checks specified in the > > "Additional Diffie-Hellman Test for the IKEv2" [RFC6989] section > > 2.2 first bullet point MUST be done when these groups are used. > > These groups are also not safe-primes. The seeds for these group= s > > have not been publicly released, resulting in reduced trust in > > these groups. These groups were proposed as alternatives for > > group 2 and 14 but never saw wide deployment. It is expected > > in the near future to be further downgraded to MUST NOT. > > > >I'm proposing it is time to change this to MUST NOT for 4307bis. > > > >Possibly, we should do this via SAAG in general, and then follow SAAG's > >advise in IPSECME. > > > >Is there _any_ reason why group 22-24 should not be MUST NOT ? > > > >Paul > > > >_______________________________________________ > >IPsec mailing list > >IPsec@ietf.org > >https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --94eb2c03473ecb737b053f1196a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In fact is there anyone opposing their status becomes MUST= NOT in rfc4307bis.

On Mon, Oct 17, 2016 at 11:30 AM, John Mattsson <john= .mattsson@ericsson.com> wrote:
> I'm proposing it is time to change this to MU= ST NOT for 4307bis.



+1

On 09/10/16 23:26, "IPsec on behalf of Paul Wouters"
<ipsec-bounces@ietf.org on behalf of paul@nohats.ca> wrote:

>
>Released a few days ago:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0http://eprint.iacr.org/2016/961
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0A kilobit hidden SNFS discrete logarithm com= putation
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Joshua Fried and Pierrick Gaudry and Nadia H= eninger and Emmanuel Thom=C3=A9
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0We perform a special number field sieve disc= rete logarithm
>=C2=A0 =C2=A0 =C2=A0 =C2=A0computation in a 1024-bit prime field. To ou= r knowledge, this
>=C2=A0 =C2=A0 =C2=A0 =C2=A0is the first kilobit-sized discrete logarith= m computation ever
>=C2=A0 =C2=A0 =C2=A0 =C2=A0reported for prime fields. This computation = took a little over
>=C2=A0 =C2=A0 =C2=A0 =C2=A0two months of calendar time on an academic c= luster using the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0open-source CADO-NFS software.
>
>Basically, this paper shows how to make a DH group of 1024 modp
>with a backdoor, in two months of academic computing resources,
>
>The paper mentions 5114 a few times:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 5114 [33] specifies a number of groups f= or use with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Diffie-Hellman, and states that the paramete= rs were drawn
>=C2=A0 =C2=A0 =C2=A0 =C2=A0from NIST test data, but neither the NIST te= st data [39] nor
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 5114 itself contain the seeds used to ge= nerate the finite
>=C2=A0 =C2=A0 =C2=A0 =C2=A0field parameters
>
>And concludes:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Both from this perspective, and from our mor= e modern one, dismissing the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0risk of trapdoored primes in real usage appe= ars to have been a mistake,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0as the apparent difficulties encountered by = the trapdoor designer in
>1992
>=C2=A0 =C2=A0 =C2=A0 =C2=A0turn out to be easily circumvented. A more c= onservative design decision
>=C2=A0 =C2=A0 =C2=A0 =C2=A0for FIPS 186 would have required mandatory s= eed publication instead of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0making it optional.=C2=A0 As a result, there= are opaque, standardized
>1024-bit
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and 2048-bit primes in wide use today that c= annot be properly verified.
>
>This is the strongest statement yet that I've seen to not trust any=
>of the RFC-5114 groups.
>
>The latest 4307bis document has these groups (22-24) as SHOULD NOT,
>stating:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Group 22, 23 and 24 or 1024-bit MODP Group w= ith 160-bit, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A02048-bit MODP Group with 224-bit and 256-bit= Prime Order Subgroup
>=C2=A0 =C2=A0 =C2=A0 =C2=A0have small subgroups, which means that check= s specified in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"Additional Diffie-Hellman Test for the= IKEv2" [RFC6989] section
>=C2=A0 =C2=A0 =C2=A0 =C2=A02.2 first bullet point MUST be done when the= se groups are used.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0These groups are also not safe-primes.=C2=A0= The seeds for these groups
>=C2=A0 =C2=A0 =C2=A0 =C2=A0have not been publicly released, resulting i= n reduced trust in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0these groups.=C2=A0 These groups were propos= ed as alternatives for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0group 2 and 14 but never saw wide deployment= .=C2=A0 It is expected
>=C2=A0 =C2=A0 =C2=A0 =C2=A0in the near future to be further downgraded = to MUST NOT.
>
>I'm proposing it is time to change this to MUST NOT for 4307bis. >
>Possibly, we should do this via SAAG in general, and then follow SAAG&#= 39;s
>advise in IPSECME.
>
>Is there _any_ reason why group 22-24 should not be MUST NOT ?
>
>Paul
>
>_______________________________________________
>IPsec mailing list
>IPsec@ietf.org
>https://www.ietf.org/mailman/listinfo/ipsec<= br>
_______________________= ________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

--94eb2c03473ecb737b053f1196a6-- From nobody Mon Oct 17 09:05:27 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F55112962F; Mon, 17 Oct 2016 09:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XpHvHhB66OY; Mon, 17 Oct 2016 09:05:23 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89A801294BB; Mon, 17 Oct 2016 09:05:23 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id 2so182025679vkb.3; Mon, 17 Oct 2016 09:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=JLpv+h0dfj0KdiZ6VhOkZP7YYZSx42POxmRvfjxveME=; b=o6hcg8VdhEGQOGZVtAfzVOW5RPKLb+nIrDXbtmY9CbxCYO1W8fEJdT2XGVzNHccH87 nBFHeLkWGhs/BrdkgUH2i8d3o5a1ImjyTSWGYlKe3wZNLqnwqXQrOB96kkNBCAfzl+MT O+TXyFOj9M8IZl3QtpJRoHxOsmeUIgHQCPAAv/DAZLeQapf619nxADD1RX3NUPY7DoRB sWnpdMJ+HW7Bbsi0e2a3c0zFkpzrt2OEfJSjDCXR21P2eLz9yK6TkspO2i8Gfc1qpoDv Het4O7e8tyogzrQbvET8dRKs7IA9R8bCAiQjXn3YLZrR7944KRwcYJgUgjUds5KJkYpy dU7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=JLpv+h0dfj0KdiZ6VhOkZP7YYZSx42POxmRvfjxveME=; b=Xp7SnNKixo27qydqoT+SMCiwBotel1G2b3QeDHERLSvt0i9fztKYA+1ebsKJ0Lo5hi TkVAJgvoJozx1Fzb5hIoN4QV0FiuexkI17BoN/1w5MDJNA1fmJEk+6gwh06tJfYM9Bjq E/21XsRZ7vwGvYg2hDEJwxzagyDgQnrt7kPTlsr1uDpsfvqaclfkF1+/YGGzwsFa5DoG hntLZG2ACmM9Om3NzB37XDe4Ycq5flHuGEA8hdl0JbAEzOGm8wC1AQRE/qfX05YN7HL+ cR+0/Rnulk1jS/Broo9+ej5ZrOxbME8AeQZ6b6BEIDAvgHjvvSAu5frpVhlv9d8YCMcl w7EA== X-Gm-Message-State: AA6/9RlxwrMsKXCETCCvSBM4R16sH7RG7phlzBoSR3uh7mi7RVRnXil7HnKrDCqOsPKO3Q== X-Received: by 10.194.113.35 with SMTP id iv3mr11384928wjb.169.1476720322535; Mon, 17 Oct 2016 09:05:22 -0700 (PDT) Received: from [192.168.1.13] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id n5sm54012058wjv.35.2016.10.17.09.05.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Oct 2016 09:05:21 -0700 (PDT) From: Yoav Nir Message-Id: <8C717FB2-DDC2-452E-AEC3-115B1E1397CF@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_78200560-BB3F-48D5-886E-80A7CC99F720" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Mon, 17 Oct 2016 19:05:18 +0300 In-Reply-To: To: Daniel Migault References: X-Mailer: Apple Mail (2.3226) Archived-At: Cc: "ipsec@ietf.org WG" , Paul Wouters , Security Area Advisory Group , John Mattsson Subject: Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 16:05:26 -0000 --Apple-Mail=_78200560-BB3F-48D5-886E-80A7CC99F720 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m not entirely comfortable with calling something a MUST NOT = when all we have is conjecture, but I have no love and no need of those = DH groups. I don=E2=80=99t believe anyone else depends on these groups (at least in = IPsec), so I=E2=80=99m fine with such a change. Yoav > On 17 Oct 2016, at 18:54, Daniel Migault = wrote: >=20 > In fact is there anyone opposing their status becomes MUST NOT in = rfc4307bis. >=20 > On Mon, Oct 17, 2016 at 11:30 AM, John Mattsson = > wrote: > > I'm proposing it is time to change this to MUST NOT for 4307bis. >=20 >=20 >=20 > +1 >=20 > On 09/10/16 23:26, "IPsec on behalf of Paul Wouters" > on behalf of = paul@nohats.ca > wrote: >=20 > > > >Released a few days ago: > > > > http://eprint.iacr.org/2016/961 = > > > > A kilobit hidden SNFS discrete logarithm computation > > Joshua Fried and Pierrick Gaudry and Nadia Heninger and = Emmanuel Thom=C3=A9 > > > > We perform a special number field sieve discrete logarithm > > computation in a 1024-bit prime field. To our knowledge, this > > is the first kilobit-sized discrete logarithm computation ever > > reported for prime fields. This computation took a little over > > two months of calendar time on an academic cluster using the > > open-source CADO-NFS software. > > > >Basically, this paper shows how to make a DH group of 1024 modp > >with a backdoor, in two months of academic computing resources, > > > >The paper mentions 5114 a few times: > > > > RFC 5114 [33] specifies a number of groups for use with > > Diffie-Hellman, and states that the parameters were drawn > > from NIST test data, but neither the NIST test data [39] nor > > RFC 5114 itself contain the seeds used to generate the finite > > field parameters > > > >And concludes: > > > > Both from this perspective, and from our more modern one, = dismissing the > > risk of trapdoored primes in real usage appears to have been a = mistake, > > as the apparent difficulties encountered by the trapdoor = designer in > >1992 > > turn out to be easily circumvented. A more conservative design = decision > > for FIPS 186 would have required mandatory seed publication = instead of > > making it optional. As a result, there are opaque, = standardized > >1024-bit > > and 2048-bit primes in wide use today that cannot be properly = verified. > > > >This is the strongest statement yet that I've seen to not trust any > >of the RFC-5114 groups. > > > >The latest 4307bis document has these groups (22-24) as SHOULD NOT, > >stating: > > > > Group 22, 23 and 24 or 1024-bit MODP Group with 160-bit, and > > 2048-bit MODP Group with 224-bit and 256-bit Prime Order = Subgroup > > have small subgroups, which means that checks specified in the > > "Additional Diffie-Hellman Test for the IKEv2" [RFC6989] = section > > 2.2 first bullet point MUST be done when these groups are = used. > > These groups are also not safe-primes. The seeds for these = groups > > have not been publicly released, resulting in reduced trust in > > these groups. These groups were proposed as alternatives for > > group 2 and 14 but never saw wide deployment. It is expected > > in the near future to be further downgraded to MUST NOT. > > > >I'm proposing it is time to change this to MUST NOT for 4307bis. > > > >Possibly, we should do this via SAAG in general, and then follow = SAAG's > >advise in IPSECME. > > > >Is there _any_ reason why group 22-24 should not be MUST NOT ? > > > >Paul > > > >_______________________________________________ > >IPsec mailing list > >IPsec@ietf.org > >https://www.ietf.org/mailman/listinfo/ipsec = >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag = >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_78200560-BB3F-48D5-886E-80A7CC99F720 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80=99m not entirely comfortable with calling something a = MUST NOT when all we have is conjecture, but I have no love and no need = of those DH groups.

I = don=E2=80=99t believe anyone else depends on these groups (at least in = IPsec), so I=E2=80=99m fine with such a change.

Yoav

On = 17 Oct 2016, at 18:54, Daniel Migault <daniel.migault@ericsson.com> wrote:

In fact is there anyone opposing their status becomes MUST = NOT in rfc4307bis.

On Mon, Oct 17, 2016 at 11:30 AM, = John Mattsson <john.mattsson@ericsson.com> wrote:
> = I'm proposing it is time to change this to MUST NOT for 4307bis.



+1

On 09/10/16 23:26, "IPsec on behalf of Paul Wouters"
<ipsec-bounces@ietf.org on behalf of paul@nohats.ca> = wrote:

>
>Released a few days ago:
>
>       http://eprint.iacr.org/2016/961
>
>       A kilobit hidden SNFS discrete logarithm = computation
>       Joshua Fried and Pierrick Gaudry and = Nadia Heninger and Emmanuel Thom=C3=A9
>
>       We perform a special number field sieve = discrete logarithm
>       computation in a 1024-bit prime field. To = our knowledge, this
>       is the first kilobit-sized discrete = logarithm computation ever
>       reported for prime fields. This = computation took a little over
>       two months of calendar time on an = academic cluster using the
>       open-source CADO-NFS software.
>
>Basically, this paper shows how to make a DH group of 1024 modp
>with a backdoor, in two months of academic computing resources,
>
>The paper mentions 5114 a few times:
>
>       RFC 5114 [33] specifies a number of = groups for use with
>       Diffie-Hellman, and states that the = parameters were drawn
>       from NIST test data, but neither the NIST = test data [39] nor
>       RFC 5114 itself contain the seeds used to = generate the finite
>       field parameters
>
>And concludes:
>
>       Both from this perspective, and from our = more modern one, dismissing the
>       risk of trapdoored primes in real usage = appears to have been a mistake,
>       as the apparent difficulties encountered = by the trapdoor designer in
>1992
>       turn out to be easily circumvented. A = more conservative design decision
>       for FIPS 186 would have required = mandatory seed publication instead of
>       making it optional.  As a result, = there are opaque, standardized
>1024-bit
>       and 2048-bit primes in wide use today = that cannot be properly verified.
>
>This is the strongest statement yet that I've seen to not trust = any
>of the RFC-5114 groups.
>
>The latest 4307bis document has these groups (22-24) as SHOULD = NOT,
>stating:
>
>       Group 22, 23 and 24 or 1024-bit MODP = Group with 160-bit, and
>       2048-bit MODP Group with 224-bit and = 256-bit Prime Order Subgroup
>       have small subgroups, which means that = checks specified in the
>       "Additional Diffie-Hellman Test for the = IKEv2" [RFC6989] section
>       2.2 first bullet point MUST be done when = these groups are used.
>       These groups are also not = safe-primes.  The seeds for these groups
>       have not been publicly released, = resulting in reduced trust in
>       these groups.  These groups were = proposed as alternatives for
>       group 2 and 14 but never saw wide = deployment.  It is expected
>       in the near future to be further = downgraded to MUST NOT.
>
>I'm proposing it is time to change this to MUST NOT for 4307bis.
>
>Possibly, we should do this via SAAG in general, and then follow = SAAG's
>advise in IPSECME.
>
>Is there _any_ reason why group 22-24 should not be MUST NOT ?
>
>Paul
>
>_______________________________________________
>IPsec mailing list
>IPsec@ietf.org
>https://www.ietf.org/mailman/listinfo/ipsec

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

_______________________________________________
IPsec = mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Apple-Mail=_78200560-BB3F-48D5-886E-80A7CC99F720-- From nobody Mon Oct 17 09:19:43 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 332981298BD; Mon, 17 Oct 2016 09:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 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.431] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kc8VW-tjYgt1; Mon, 17 Oct 2016 09:19:35 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE9011298B7; Mon, 17 Oct 2016 09:19:34 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3syNh44ZChz3Yt; Mon, 17 Oct 2016 18:19:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1476721172; bh=6TUKiCH8pES+vr+948o0XR2Nz1mleXLEEQyDTonH4TY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Ns7z33VgkFZBuVQuHTJUqcqMJeu8rZrHnlPZU6jfTD2fZXc+I6GoYmmeXlGddsFW8 m50B40imzYHb4CeLMaQMecBxwYEp7kavGNFX6NU7OV4m7l5jZrreXNZk1om3bqJTil PJgk/rcxDLJXIH8GTjYM+G4WkeVYckKcnsSiJPMM= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id FY58Ssjx8pBd; Mon, 17 Oct 2016 18:19:29 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 17 Oct 2016 18:19:29 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id E28FE4533F1; Mon, 17 Oct 2016 12:19:26 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca E28FE4533F1 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DA03C4163767; Mon, 17 Oct 2016 12:19:26 -0400 (EDT) Date: Mon, 17 Oct 2016 12:19:26 -0400 (EDT) From: Paul Wouters To: Yoav Nir , Stephen Kent In-Reply-To: <8C717FB2-DDC2-452E-AEC3-115B1E1397CF@gmail.com> Message-ID: References: <8C717FB2-DDC2-452E-AEC3-115B1E1397CF@gmail.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: "ipsec@ietf.org WG" , Security Area Advisory Group Subject: Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 16:19:42 -0000 On Mon, 17 Oct 2016, Yoav Nir wrote: > I’m not entirely comfortable with calling something a MUST NOT when all we have is conjecture, It's a little more than conjecture. 1) It has been proven that malicious 1024 bit DH values can be generated by academia that cannot be independantly discovered. Therefore any nationstate with access to the same theory and more CPU power could have done this years ago. 2) We have the RFC 5114 values who'se original authors/sponsors are not disclosing how these were generated. 1) + 2) means we cannot know if these values were trapdoor'ed. If BBN/NIST/NSA wants to share how they seeded these values, we can all publicly decide if we can keep using these or not. Without such information, it just becomes an unnecessary risk to take. Adding Steve Kent, co-author of RFC-5114, to the CC: so that he has the opportunity to share what he knows about the origins of these values and their seeds. > but I have no love and no need of those DH groups. > I don’t believe anyone else depends on these groups (at least in IPsec), so I’m fine with such a change. Thanks, Paul > Yoav > > On 17 Oct 2016, at 18:54, Daniel Migault wrote: > > In fact is there anyone opposing their status becomes MUST NOT in rfc4307bis. > > On Mon, Oct 17, 2016 at 11:30 AM, John Mattsson wrote: > > I'm proposing it is time to change this to MUST NOT for 4307bis. > > > > +1 > > On 09/10/16 23:26, "IPsec on behalf of Paul Wouters" > wrote: > > > > >Released a few days ago: > > > >       http://eprint.iacr.org/2016/961 > > > >       A kilobit hidden SNFS discrete logarithm computation > >       Joshua Fried and Pierrick Gaudry and Nadia Heninger and Emmanuel Thomé > > > >       We perform a special number field sieve discrete logarithm > >       computation in a 1024-bit prime field. To our knowledge, this > >       is the first kilobit-sized discrete logarithm computation ever > >       reported for prime fields. This computation took a little over > >       two months of calendar time on an academic cluster using the > >       open-source CADO-NFS software. > > > >Basically, this paper shows how to make a DH group of 1024 modp > >with a backdoor, in two months of academic computing resources, > > > >The paper mentions 5114 a few times: > > > >       RFC 5114 [33] specifies a number of groups for use with > >       Diffie-Hellman, and states that the parameters were drawn > >       from NIST test data, but neither the NIST test data [39] nor > >       RFC 5114 itself contain the seeds used to generate the finite > >       field parameters > > > >And concludes: > > > >       Both from this perspective, and from our more modern one, dismissing the > >       risk of trapdoored primes in real usage appears to have been a mistake, > >       as the apparent difficulties encountered by the trapdoor designer in > >1992 > >       turn out to be easily circumvented. A more conservative design decision > >       for FIPS 186 would have required mandatory seed publication instead of > >       making it optional.  As a result, there are opaque, standardized > >1024-bit > >       and 2048-bit primes in wide use today that cannot be properly verified. > > > >This is the strongest statement yet that I've seen to not trust any > >of the RFC-5114 groups. > > > >The latest 4307bis document has these groups (22-24) as SHOULD NOT, > >stating: > > > >       Group 22, 23 and 24 or 1024-bit MODP Group with 160-bit, and > >       2048-bit MODP Group with 224-bit and 256-bit Prime Order Subgroup > >       have small subgroups, which means that checks specified in the > >       "Additional Diffie-Hellman Test for the IKEv2" [RFC6989] section > >       2.2 first bullet point MUST be done when these groups are used. > >       These groups are also not safe-primes.  The seeds for these groups > >       have not been publicly released, resulting in reduced trust in > >       these groups.  These groups were proposed as alternatives for > >       group 2 and 14 but never saw wide deployment.  It is expected > >       in the near future to be further downgraded to MUST NOT. > > > >I'm proposing it is time to change this to MUST NOT for 4307bis. > > > >Possibly, we should do this via SAAG in general, and then follow SAAG's > >advise in IPSECME. > > > >Is there _any_ reason why group 22-24 should not be MUST NOT ? > > > >Paul > > > >_______________________________________________ > >IPsec mailing list > >IPsec@ietf.org > >https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > From nobody Mon Oct 17 09:27:09 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801A91298BC for ; Mon, 17 Oct 2016 09:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.732 X-Spam-Level: X-Spam-Status: No, score=-4.732 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UMV61i42qHW for ; Mon, 17 Oct 2016 09:27:04 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 825EC12989E for ; Mon, 17 Oct 2016 09:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1476721624; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=E7iJ+IEtnYtcrYM+FXz0OTwWkujHtws1mCelcUH3HWo=; b=EgafHkWr/X84Ct0hHl2er2tcIP+guYjmgAQiLQEpt2RNvE+Fjb0BAIG3Swm7QRgb FElHXgiXWZOPvG5L/DXMdiKPbahJkiRY8DUWaQGgLvlDDrGAbbBYSBzUGl82058w IQlHHnqgZEtgUsvl5/GROUs1s0rr7sO7GmWk5fu/rp+hFaXpe81M8nS6NMpN8IRJ o6L8XoUNKLppXZw9BmHzZWeNgCBxJNZLOro8isMpxUWBoMoy0Y8Rokp97ws9XyuV WCk2HrH+LH3Xz5yZE7E+6YCzXdDqr+5TuVjphVYc4t+7hT2kPUekbu5B9CJwo7qC KFCTVi3FxWK93/Qo7gslow==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 82.9B.07001.8DBF4085; Mon, 17 Oct 2016 09:27:04 -0700 (PDT) X-AuditID: 11973e12-23e0e9a000001b59-5f-5804fbd8df8e Received: from nwk-mmpp-sz07.apple.com (nwk-mmpp-sz07.apple.com [17.128.115.240]) by relay6.apple.com (Apple SCV relay) with SMTP id 9E.96.23613.8DBF4085; Mon, 17 Oct 2016 09:27:04 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_TYkKN+8EKwq/pa/xf1yC0w)" Received: from [17.226.23.78] (unknown [17.226.23.78]) by nwk-mmpp-sz07.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OF700LWH9P3T330@nwk-mmpp-sz07.apple.com>; Mon, 17 Oct 2016 09:27:03 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <6A77A7C8-F191-4CC6-BB1A-F626D70B5EC9@apple.com> Date: Mon, 17 Oct 2016 09:27:03 -0700 In-reply-to: <2DD56D786E600F45AC6BDE7DA4E8A8C117F9AFA6@eusaamb107.ericsson.se> To: Daniel Migault References: <147629427337.6345.10026955385959604828.idtracker@ietfa.amsl.com> <000401d224b0$60508760$20f19620$@mnm-team.org> <2DD56D786E600F45AC6BDE7DA4E8A8C117F9AFA6@eusaamb107.ericsson.se> X-Mailer: Apple Mail (2.3242) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUi2FAYpXvjN0uEwbN5whZTpu9hs9i/5QWb A5PHr69X2TyWLPnJFMAUxWWTkpqTWZZapG+XwJWx9s4O9oJPqRUztm9haWDcFd7FyMkhIWAi MfXoSdYuRi4OIYG9jBLfnzxlgUkcaP3BDJE4xCixumsPO0iCV0BQ4sfke0BFHBzMAmES0xeL Q9R0MEk0tR5gB4kLC0hIbN6TCFLOJqAicfzbBmaIVhuJJ1132SBKwiR6H3iChFkEVCU2NjwH m84p4Cfx7PtssBOYBeQlev9vZASxRQQMJF5O2MkGd87RNxAzJQRkJZZvuM0IYR9gk1h7zmwC o9AsJJfOQrgUwlSXmDIldxbYBm2JJ+8usELYahILfy9iQhZfwMi2ilEoNzEzRzczz0QvsaAg J1UvOT93EyMoCqbbCe1gPLXK6hCjAAejEg/vhissEUKsiWXFlbmHGKU5WJTEeb8mM0YICaQn lqRmp6YWpBbFF5XmpBYfYmTi4JRqYJy8RcY7J+/h8nh5fd28Zqfv2Wvn2MTO5HjMqF1165JG WhjfU591JxNfcP1mqryZqFZTrX3jVTHXt8RHzhs33fj3ZP69trQfUSq+YcfP637/ln/45J53 j84zf0qcp/j9zDPFhMyMJWc8j4Rd4H+zXPnjgpcRGlv7taunLnjez7D7Znuocjyz8UclluKM REMt5qLiRAAo3ujkYwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOIsWRmVeSWpSXmKPExsUi2FD8QffGb5YIgxcHuS2mTN/DZrF/yws2 ByaPX1+vsnksWfKTKYApissmJTUnsyy1SN8ugStj7Z0d7AWfUitmbN/C0sC4K7yLkZNDQsBE 4kDrD2YIW0ziwr31bF2MXBxCAocYJVZ37WEHSfAKCEr8mHyPpYuRg4NZIExi+mJxiJoOJomm 1gPsIHFhAQmJzXsSQcrZBFQkjn/bwAzRaiPxpOsuG0RJmETvA0+QMIuAqsTGhudg0zkF/CSe fZ/NAmIzC8hL9P7fyAhiiwgYSLycsBPhnKNvNkDdKSuxfMNtxgmMArOQXDcL4ToIU11iypTc WWBTtSWevLvACmGrSSz8vYgJWXwBI9sqRoGi1JzESjO9xIKCnFS95PzcTYzgcC6M2sHYsNzq EKMAB6MSD2/EJZYIIdbEsuLKXKCTOJiVRHhXfgIK8aYkVlalFuXHF5XmpBYfYpzICPTkRGYp 0eR8YLTllcQbmpgYmBgbmxkbm5uY01JYSZyXr/FfuJBAemJJanZqakFqEcxRTBycUg2M4o9v 8TK/ZdopKCcf+CV2er/ubvXnKyz+flKPZ6m55cr1Vd70p7LDUplvsTUiU6xdrCrcHC/FLfrk LaX5osF+xePnpx2mcGT+e5/9g+Pz9aT9O58ryJb/TrwW62QsYS7F4m30I2yCinptgOv5S0mb 3V6qsBW2fezK9q5JZP4Vz9RVvJft31wlluKMREMt5qLiRABSUoUJ2gIAAA== Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] New Version Notification for draft-mglt-ipsecme-diet-esp-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 16:27:07 -0000 --Boundary_(ID_TYkKN+8EKwq/pa/xf1yC0w) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi Daniel, Thanks for sending this out! Definitely very interesting stuff. I like = the new focus on how to compress UDP/TCP within Diet-ESP. Some of the introduction text could use some clarification/wordsmithing: IPsec/ESP has not been designed to reduce the networking overhead of the communications. In fact saving bandwidth comes with additional operation that may affect or impact large infrastructure where bandwidth usage is not an issue. On the other hand, IoT emerged with completely different constraints. IoT communications are different in many ways and a few important differences may be that sending any extra byte impact significantly the life time of these devices. In addition, these devices are also expected to be sleeping nodes where communications are hardly based on sessions as we used to. Perhaps could be: IPsec/ESP was not designed to reduce the networking overhead of the communications. In fact, reducing bandwidth often adds = computational overhead that may negatively impact large infrastructures in which bandwidth usage is not a constraint. On the other hand, IoT devices = have completely different constraints. In IoT communications, sending any extra bytes can significantly impact the battery life of devices. = These devices are also often expected to be sleeping nodes, for which IPsec = sessions have a very different meaning. I think the work on the appendices to provide more full examples of how = the packets are compressed is very effective. Thanks for adding that. I = did find it a bit confusing that the packet diagrams don=E2=80=99t give = a clear picture of the effect of encryption on inner packet data. In the = RFC 4303 diagrams, the =E2=80=98inner=E2=80=99 portions are all = summarized as =E2=80=98Payload Data=E2=80=99, which is the content that = is encrypted. In your diagrams, we see the decrypted content written = out. Perhaps there is some labelling on the figures you can add to make = that a bit clearer? Thanks, Tommy > On Oct 12, 2016, at 11:50 AM, Daniel Migault = wrote: >=20 > Hi,=20 >=20 > Please find an update version of the diet-esp document we discussed in = Berlin. The scope of the compression has been extended, and the = compression simplified. We also provided example in the appendix = section. >=20 > Comments are welcome as usual! >=20 > BR,=20 > Daniel >=20 > -----Urspr=C3=BCngliche Nachricht----- > Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Gesendet: Mittwoch, 12. Oktober 2016 19:45 > An: Carsten Bormann ; Daniel Migault = ; Tobias Guggemos > Betreff: New Version Notification for = draft-mglt-ipsecme-diet-esp-02.txt >=20 >=20 > A new version of I-D, draft-mglt-ipsecme-diet-esp-02.txt > has been successfully submitted by Daniel Migault and posted to the = IETF repository. >=20 > Name: draft-mglt-ipsecme-diet-esp > Revision: 02 > Title: ESP Header Compression and Diet-ESP > Document date: 2016-10-04 > Group: Individual Submission > Pages: 43 > URL: = https://www.ietf.org/internet-drafts/draft-mglt-ipsecme-diet-esp-02.txt > Status: = https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/ > Htmlized: = https://tools.ietf.org/html/draft-mglt-ipsecme-diet-esp-02 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-mglt-ipsecme-diet-esp-02 >=20 > Abstract: > ESP Header Compression (EHC) defines a flexible framework to = compress > communications protected with IPsec/ESP. Compression and > decompression is defined by EHC Rules orchestrated by EHC = Strategies. >=20 > The document specifies the Diet-ESP EHC Strategy and associated EHC > Rules. Diet-ESP compresses up to 32 bytes per packet for = traditional > IPv6 VPN and up to 66 bytes for IPv6 VPN set over a single TCP or = UDP > session. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Boundary_(ID_TYkKN+8EKwq/pa/xf1yC0w) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable
Hi Daniel,

Thanks for sending this out! Definitely = very interesting stuff. I like the new focus on how to compress UDP/TCP = within Diet-ESP.

Some of the introduction text could use some = clarification/wordsmithing:

IPsec/ESP has not been designed to reduce =
the networking overhead of
   the communications.  In fact saving bandwidth comes with additional
   operation that may affect or impact large infrastructure where
   bandwidth usage is not an issue.  On the other hand, IoT emerged with
   completely different constraints.  IoT communications are different
   in many ways and a few important differences may be that sending any
   extra byte impact significantly the life time of these devices.  In
   addition, these devices are also expected to be sleeping nodes where
   communications are hardly based on sessions as we used to.

Perhaps could = be:

IPsec/ESP was not =
designed to reduce the networking overhead of
   the communications.  In fact, reducing bandwidth often adds =
computational
   overhead that may negatively impact large infrastructures in which
   bandwidth usage is not a constraint.  On the other hand, IoT devices =
have
   completely different constraints.  In IoT communications, sending any
   extra bytes can significantly impact the battery life of =
devices.  These devices
   are also often expected to be sleeping =
nodes, for which IPsec sessions
   have a very different =
meaning.


I think the work on the = appendices to provide more full examples of how the packets are = compressed is very effective. Thanks for adding that. I did find it a = bit confusing that the packet diagrams don=E2=80=99t give a clear = picture of the effect of encryption on inner packet data. In the RFC = 4303 diagrams, the =E2=80=98inner=E2=80=99 portions are all summarized = as =E2=80=98Payload Data=E2=80=99, which is the content that is = encrypted. In your diagrams, we see the decrypted content written out. = Perhaps there is some labelling on the figures you can add to make that = a bit clearer?

Thanks,
Tommy

On = Oct 12, 2016, at 11:50 AM, Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi, =

Please find an update version of the = diet-esp document we discussed in Berlin. The scope of the compression = has been extended, and the compression simplified. We also provided = example in the appendix section.

Comments = are welcome as usual!

BR,
Daniel

-----Urspr=C3=BCngliche = Nachricht-----
Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Gesendet: = Mittwoch, 12. Oktober 2016 19:45
An: Carsten Bormann = <cabo@tzi.org>; = Daniel Migault <daniel.migault@ericsson.com>; Tobias Guggemos <guggemos@mnm-team.org>
Betreff: New = Version Notification for draft-mglt-ipsecme-diet-esp-02.txt


A new version of I-D, = draft-mglt-ipsecme-diet-esp-02.txt
has been successfully = submitted by Daniel Migault and posted to the IETF repository.

Name: draft-mglt-ipsecme-diet-esp
Revision: 02
Title: ESP = Header Compression and Diet-ESP
Document date: = 2016-10-04
Group: Individual Submission
Pages:= = 43
URL: =            https://www.ietf.org/internet-drafts/draft-mglt-ipsecme-diet-es= p-02.txt
Status: =         https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/
Htmlized:       https://tools.ietf.org/html/draft-mglt-ipsecme-diet-esp-02<= br class=3D"">Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-mglt-ipsecme-diet-esp= -02

Abstract:
=   ESP Header Compression (EHC) defines a flexible framework to = compress
  communications protected with = IPsec/ESP.  Compression and
=   decompression is defined by EHC Rules orchestrated by EHC = Strategies.

  The document = specifies the Diet-ESP EHC Strategy and associated EHC
=   Rules.  Diet-ESP compresses up to 32 bytes per packet = for traditional
  IPv6 VPN and up to 66 bytes = for IPv6 VPN set over a single TCP or UDP
=   session.




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

The IETF = Secretariat


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Boundary_(ID_TYkKN+8EKwq/pa/xf1yC0w)-- From nobody Mon Oct 17 09:29:59 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47EA1298B1 for ; Mon, 17 Oct 2016 09:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.732 X-Spam-Level: X-Spam-Status: No, score=-4.732 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJHxtmiZxylw for ; Mon, 17 Oct 2016 09:29:55 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 1107112945A for ; Mon, 17 Oct 2016 09:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1476721794; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6aYzlm/tqE7jujxK1C/UX2MMQgSeAFo8OzqYj5QSRV8=; b=ep3kJOPa7pKkmrP9Bj+jShR4znBkF7q8tTrHIvZyzaKu09jV8IMi+5vtAJwQ4sUY uLGzGD/7w+QfSokfS5D+pCkrABfV27Yha8ifcXKAj5v0yox17piE4PKWTzXOGAYO eHm83mIKLF6zFaFXEJyZ/lnjKXiZtxUe2O2oxX4k4tWbwySChLmvfrFtOBpp9dRQ BeOB5m59YoZlpr8CpjXp+fcZU9uF+govDgr/gIMdUWcXhnwjbqF3O/RokSX0ZkIY SnZB5f9DoFDVvkp7RIRk/dM0DnrkGh1opIRpsqAO+x2pV94XHn3a4RzBP4WGa8Ve kpG0tOMmxcFV55ZOnkP/6g==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 6C.0C.07001.28CF4085; Mon, 17 Oct 2016 09:29:54 -0700 (PDT) X-AuditID: 11973e12-23e0e9a000001b59-27-5804fc827b21 Received: from nwk-mmpp-sz07.apple.com (nwk-mmpp-sz07.apple.com [17.128.115.240]) by relay6.apple.com (Apple SCV relay) with SMTP id 21.C9.23613.28CF4085; Mon, 17 Oct 2016 09:29:54 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_v8ZTgkBfb6MK3gmp5W0b9g)" Received: from [17.226.23.78] (unknown [17.226.23.78]) by nwk-mmpp-sz07.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OF700KGQ9TU9A40@nwk-mmpp-sz07.apple.com>; Mon, 17 Oct 2016 09:29:54 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <16DBB009-9480-4F39-8E59-9DC0FAA2D270@apple.com> Date: Mon, 17 Oct 2016 09:29:54 -0700 In-reply-to: <876523B00C3F9D47BFD2B654D63DBF92BEAADC6B@US70UWXCHMBA05.zam.alcatel-lucent.com> To: "Hu, Jun (Nokia - US)" References: <2C8840EB-AC99-401F-971A-2962B71FCC08@apple.com> <9CC56746-DCA5-42F0-8FBC-B3F5391989E6@apple.com> <876523B00C3F9D47BFD2B654D63DBF92BEAA7FCD@US70UWXCHMBA05.zam.alcatel-lucent.com> <876523B00C3F9D47BFD2B654D63DBF92BEAADAF2@US70UWXCHMBA05.zam.alcatel-lucent.com> <876523B00C3F9D47BFD2B654D63DBF92BEAADC6B@US70UWXCHMBA05.zam.alcatel-lucent.com> X-Mailer: Apple Mail (2.3242) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUi2FAYpdv0hyXCYP0UU4sp0/ewWezf8oLN 4sPfCYwW729dYrK48WEmm8XSYx+YHNg8fn29yuaxc9Zddo8lS34yeXyfx+RxF6gmgDWKyyYl NSezLLVI3y6BK+NQ2y3mgj3HGSs+n/rE1sB4czVjFyMHh4SAicSFddVdjFwcQgJ7GSU+T1/J 0sXICRZffOc8M0TiEKPErd+P2UESvAKCEj8m3wMrYhYIk2iY+ZgRoqiDSeLX2glsIFOFBSQk Nu9JBKlhE1CROP5tAzNEr43EzRdvmCBKgiWmtNmDmCwCqhLTt/iAVHAKxEs8er2MDWQis8Bm Rokr21+xgSREBHQlvp9+CWYLCfxikVjVWANxp6zE8g23wU6QEPjPJjFt8QfmCYxCs5CcOgvJ qbOA9jELqEtMmZILEdaWePLuAiuErSax8PciJmTxBYxsqxiFchMzc3Qz80z0EgsKclL1kvNz NzGC4mm6ndAOxlOrrA4xCnAwKvHwbrjCEiHEmlhWXJl7iFGag0VJnPdrMmOEkEB6Yklqdmpq QWpRfFFpTmrxIUYmDk6pBsbA/GviM+ueCwtKLUpbsHhb5W6e9iOH7zpOW35/LXvRrcMSl1/v OHTbf2vhzu/cq2Kybqr1Tw+X6c4PN81fVbllilhOkFYu27PAADlx7fn2/U/VllvXv8+L4jPs 1WXs4G/9rMu2cON2F8vKquoZ7beqCjQr4xMuTXFgNp9Rc2Fpwr1zMcrFkkosxRmJhlrMRcWJ AC5NXMyIAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUi2FD8QbfpD0uEwebV+hZTpu9hs9i/5QWb xYe/Exgt3t+6xGRx48NMNoulxz4wObB5/Pp6lc1j56y77B5Llvxk8vg+j8njLlBNAGsUl01K ak5mWWqRvl0CV8ahtlvMBXuOM1Z8PvWJrYHx5mrGLkZODgkBE4nFd84zQ9hiEhfurWfrYuTi EBI4xChx6/djdpAEr4CgxI/J91hAbGaBMImGmY8ZIYo6mCR+rZ0A1MHBISwgIbF5TyJIDZuA isTxbxuYIXptJG6+eMMEURIsMaXNHsRkEVCVmL7FB6SCUyBe4tHrZWBrmQU2M0pc2f6KDSQh IqAr8f30SzBbSOAXi8SqxhqIO2Ullm+4zTiBUWAWkutmIbluFtAKZgF1iSlTciHC2hJP3l1g hbDVJBb+XsSELL6AkW0Vo0BRak5ipZleYkFBTqpecn7uJkZwZBRG7WBsWG51iFGAg1GJhzfi EkuEEGtiWXFlLjCIOJiVRHhXfgIK8aYkVlalFuXHF5XmpBYfYpzICPTkRGYp0eR8YNzmlcQb mpgYmBgbmxkbm5uY01JYSZyXr/FfuJBAemJJanZqakFqEcxRTBycUg2MOf3bLPUlpHZePygh +q68UeGWmlS+3d1NyQGbO7c53/ub+FvjeUrHB35B287LYUsZy09LHzTPDNp3iFlBOViu7Mih n6fTZt9d36tuf5zZoab8dsqc9eLd2348UL8wVWrO8fMpFf/XvbyUfUo/kSdzzbKHajcnTlwS 6h+rL967oI6nYl8xw7m1SizFGYmGWsxFxYkAbDnk1f8CAAA= Archived-At: Cc: IPsecME WG , Valery Smyslov , Paul Wouters , Daniel Migault , Yoav Nir Subject: Re: [IPsec] New version of TCP Encapsulation draft, request for adoption X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 16:29:58 -0000 --Boundary_(ID_v8ZTgkBfb6MK3gmp5W0b9g) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi Jun, You=E2=80=99re correct that the draft does not specifically call out = using multiple TCP connections for a single Child SA. It explains that = one reason to use multiple TCP connections is to handle =E2=80=9Cconnect[i= ng] to multiple gateways handling different ESP SAs=E2=80=9D, which is = the one-child-SA-per-TCP model. There is nothing in the protocol = prohibiting using multiple TCP connections for a single child SA; what = is your main use case here? Is there something that you find useful in = that that could perhaps help inform this clarifying text? Tommy > On Oct 11, 2016, at 8:42 PM, Hu, Jun (Nokia - US) = wrote: >=20 > =46rom the section 6 text, my understanding is draft allows multiple = TCP connections for a given tunnel which includes multiple CHILD_SAs; = however it is not clear to me that draft also allows multiple TCP = session for a single SA, is there any use case of having multiple TCP = sessions for a single CHILD_SA? > =20 > =20 > From: tpauly@apple.com [mailto:tpauly@apple.com]=20 > Sent: Tuesday, October 11, 2016 5:35 PM > To: Hu, Jun (Nokia - US) > Cc: Valery Smyslov; Yoav Nir; IPsecME WG; Daniel Migault; Paul Wouters > Subject: Re: [IPsec] New version of TCP Encapsulation draft, request = for adoption > =20 > Please see section 6: > =20 > Multiple TCP connections between the initiator and the responder are > allowed, but their use must take into account the initiator > capabilities and the deployment model such as to connect to = multiple > gateways handling different ESP SAs when deployed in a high > availability model. It is also possible to negotiate multiple IKE > SAs over the same TCP connection. > =20 > The processing of the TCP packets is the same whether its within a > single or multiple TCP connections. >=20 > We believe this text is fairly direct in specifying that multiple IKE = SAs can go over a single TCP stream, and that multiple TCP streams are = allowed for a single IKE SA/Child SA set. There is no dependency between = the TCP streams and the IKE or Child SAs. We recommend a 1-to-1 = correspondence for simplicity, but there is no technical limitation. The = TCP streams should not necessarily be closed or reset if the SA sends = data on a different flow. >=20 > Thanks, > Tommy > =20 > =20 > On Oct 11, 2016, at 3:00 PM, Hu, Jun (Nokia - US) > wrote: > =20 > Any comments to my questions below? > Does draft allows multiple TCP sessions for a given SA? Or it should = be only one TCP session allowed for a given SA? >=20 >=20 > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org = ] On Behalf Of Hu, Jun (Nokia - US) > Sent: Friday, October 07, 2016 2:09 PM > To: Tommy Pauly; Valery Smyslov; Yoav Nir > Cc: IPsecME WG; Daniel Migault; Paul Wouters > Subject: Re: [IPsec] New version of TCP Encapsulation draft, request = for > adoption >=20 > I was reading the draft again, and had similar problem as below; Draft = states > that SA state should be independent of TCP state and it allows = multiple TCP > sessions between two peers even when there is only one IKE_SA; I = assume this > means for a given tunnel, different SA could belong to different TCP = session, > e.g. IKE_SA uses TCP session-1, CHILD_SA uses TCP session-2; however = does > this mean draft allows multiple TCP sessions for a given SA? I guess = not, if > that's the case, then it should be stated clearly in the draft that = for a given SA, > only one TCP session is allowed; In case of when the original = initiator lost TCP > session and create a new one, the responder should update its = TCP_session- > to-SA binding after it receives a valid IKE/ESP packet is received on = the new > TCP session and close the old one, send TCP RST >=20 >=20 > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org = ] On Behalf Of Tommy Pauly > ... >=20 >=20 > Then, I think some text should be added describing a situation when > the original responder having a valid (from its point of view) TCP > session receives a request from original initiator for a new TCP > session. This may happen if original initiator looses TCP state for > some reason (RST from an attacker, temporary network failure etc.). > In this case the responder will have two TCP sessions associated > with the IKE SA. Clearly, the new one should be used for further > communications, but only after it is proven to be authentic (some > protected message is received over it). But what the responder > should do > with the old TCP session? >=20 > Keep it? Send FIN? Send RST? Just discard? >=20 >=20 > In general, the approach of the draft is to clearly separate the TCP > state from the IKE session state. If you look at Section 6, it > specifically allows for multiple TCP connections between two peers > even if there is only one IKE SA between them. If one of them becomes > redundant (because the other peer opened up a new TCP flow for some > reason), it would make sense to close the other in a usual way. I > think this can be left to the implementation, but either a FIN or RST = would be > appropriate rather than a discard. We can add that to future versions. >=20 > =20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = > =20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = --Boundary_(ID_v8ZTgkBfb6MK3gmp5W0b9g) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable
Hi Jun,

You=E2=80=99re correct that the draft = does not specifically call out using multiple TCP connections for a = single Child SA. It explains that one reason to use multiple TCP = connections is to handle =E2=80=9Cconnect[ing] to multiple gateways = handling different ESP SAs=E2=80=9D, which is the one-child-SA-per-TCP = model. There is nothing in the protocol prohibiting using multiple TCP = connections for a single child SA; what is your main use case here? Is = there something that you find useful in that that could perhaps help = inform this clarifying text?

Tommy

On Oct 11, 2016, at 8:42 PM, Hu, Jun (Nokia - US) <jun.hu@nokia.com> = wrote:

=46rom the section 6 = text, my understanding is draft allows multiple TCP connections for a = given tunnel which includes multiple CHILD_SAs; however it is not clear = to me that draft also allows multiple TCP session for a single SA, is = there any use case of having multiple TCP sessions for a single = CHILD_SA?
 
 
From: tpauly@apple.com [mailto:tpauly@apple.com] 
Sent: Tuesday, October 11, 2016 = 5:35 PM
To: Hu, Jun (Nokia - US)
Cc: Valery Smyslov; Yoav Nir; = IPsecME WG; Daniel Migault; Paul Wouters
Subject: Re: [IPsec] New version of = TCP Encapsulation draft, request for adoption
 
Please see section 6:
 
 Multiple TCP connections between =
the initiator and the responder are
   allowed, but their = use must take into account the initiator
   =
capabilities and the deployment model such as to connect to multiple
   =
gateways handling different ESP SAs when deployed in a high
   =
availability model.  It is also possible to negotiate multiple =
IKE
   SAs over the same TCP connection.
 
   The processing of the TCP packets is the same =
whether its within a
   single or multiple =
TCP connections.

We believe =
this text is fairly direct in specifying that multiple IKE SAs can go =
over a single TCP stream, and that multiple TCP streams are allowed =
for a single IKE SA/Child SA set. There is no dependency between the TCP =
streams and the IKE or Child SAs. We recommend a 1-to-1 correspondence =
for simplicity, but there is no technical limitation. The TCP =
streams should not necessarily be closed or reset if the SA sends =
data on a different flow.

Thanks,
Tommy
 
 
On = Oct 11, 2016, at 3:00 PM, Hu, Jun (Nokia - US) <jun.hu@nokia.com> = wrote:
 
Any comments to my = questions below?
Does draft allows multiple TCP sessions = for a given SA? Or it should be only one TCP session allowed for a given = SA?


-----Original Message-----
From: IPsec [mailto:ipsec-bounces@ietf.org]= On Behalf Of Hu, Jun (Nokia - US)
Sent: Friday, October = 07, 2016 2:09 PM
To: Tommy Pauly; Valery Smyslov; Yoav = Nir
Cc: IPsecME WG; Daniel Migault; Paul Wouters
Subject: Re: [IPsec] New version of TCP Encapsulation draft, = request for
adoption

I was = reading the draft again, and had similar problem as below; Draft = states
that SA state should be independent of TCP state = and it allows multiple TCP
sessions between two peers even = when there is only one IKE_SA; I assume this
means for a = given tunnel, different SA could belong to different TCP session,
e.g. IKE_SA uses TCP session-1, CHILD_SA uses TCP session-2; = however does
this mean draft allows multiple TCP sessions = for a given SA? I guess not, if
that's the case, then it = should be stated clearly in the draft that for a given SA,
only one TCP session is allowed; In case of when the original = initiator lost TCP
session and create a new one, the = responder should update its TCP_session-
to-SA binding = after it receives a valid IKE/ESP packet is received on the new
TCP session and close the old one, send TCP RST


-----Original Message-----
From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tommy = Pauly
...

Then, = I think some text should be added describing a situation when
the original responder having a valid (from its point of = view) TCP
session receives a request from original = initiator for a new TCP
session. This may happen if = original initiator looses TCP state for
some reason (RST = from an attacker, temporary network failure etc.).
In this = case the responder will have two TCP sessions associated
with the IKE SA. Clearly, the new one should be used for = further
communications, but only after it is proven to be = authentic (some
protected message is received over it). = But what the responder
should do
with the old TCP session?

Keep it? = Send FIN? Send RST? Just discard?


In general, the approach = of the draft is to clearly separate the TCP
state from the = IKE session state. If you look at Section 6, it
specifically= allows for multiple TCP connections between two peers
even = if there is only one IKE SA between them. If one of them becomes
redundant (because the other peer opened up a new TCP flow = for some
reason), it would make sense to close the other = in a usual way. I
think this can be left to the = implementation, but either a FIN or RST would be
appropriate rather than a discard. We can add that to future = versions.

 

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
 
_______________________________________________
IPsec mailing = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Boundary_(ID_v8ZTgkBfb6MK3gmp5W0b9g)-- From nobody Mon Oct 17 09:33:44 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E3F129964 for ; Mon, 17 Oct 2016 09:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.732 X-Spam-Level: X-Spam-Status: No, score=-4.732 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwCoa-46-kpo for ; Mon, 17 Oct 2016 09:33:40 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 CC5B8129962 for ; Mon, 17 Oct 2016 09:33:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1476722020; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=OC4IsorXQV6XUgpzSkz5V4Y84oEbia09I/V6aNUbL4Q=; b=tdxR66aUbMrDw9Er1G9WPyOXdLqKbknfZK3XlSt13vUFKvtmy4vWwT4mqNRDTQ0h Qjac48p3uLX9H6NYWl54F/f7qcnsEHEbqnxlpJYv8ONKqCTg1nVf9DJTRV09DMJL i1kiiAgkkk81zTRVVvO95iydsWXjShj6FrDdP5/jimVmOtZbRq/Pe8z92prc8PLc 6e1frlnwUmxmGWgtwLA3Z6BF6KE+VADCgJj1SGV8mLjnBbxqHDgJFw3zYJ4YSr1j JLaQfOLxN7WZO2nQeNNbOryVpwmrUgLBvOkPNt34drBCoyZqaZ4y1tNu7XnA+VG+ dS4XCaREsI180GoGxCYeyA==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 5D.DC.07001.46DF4085; Mon, 17 Oct 2016 09:33:40 -0700 (PDT) X-AuditID: 11973e12-23e0e9a000001b59-8e-5804fd6406fb Received: from nwk-mmpp-sz07.apple.com (nwk-mmpp-sz07.apple.com [17.128.115.240]) by relay6.apple.com (Apple SCV relay) with SMTP id 88.2D.23613.46DF4085; Mon, 17 Oct 2016 09:33:40 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_WE/f0gxOU6L3bagplOjPqw)" Received: from [17.226.23.78] (unknown [17.226.23.78]) by nwk-mmpp-sz07.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OF700L9QA04T340@nwk-mmpp-sz07.apple.com>; Mon, 17 Oct 2016 09:33:40 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <9BC86578-38FF-45D5-8A21-887A224E772D@apple.com> Date: Mon, 17 Oct 2016 09:33:39 -0700 In-reply-to: <145AF2E4-1622-4177-89EC-FFDD146BEFD4@apple.com> To: IPsecME WG , Paul Hoffman , Tero Kivinen , Daniel Migault References: <147448964321.14590.5635818993002735779.idtracker@ietfa.amsl.com> <145AF2E4-1622-4177-89EC-FFDD146BEFD4@apple.com> X-Mailer: Apple Mail (2.3242) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUi2FAYpZvylyXC4Ox0NYsp0/ewWezf8oLN 4uj552wWt9Z/YbV4f+sSkwOrx6+vV9k8liz5yeRx+OtCFo/v85g8Ps++yhzAGsVlk5Kak1mW WqRvl8CVcW/rLaaCadEVPSe2MjYwPgjoYuTgkBAwkbjRY9bFyMUhJLCXUeLyiglsMPH52y0g 4ocYJR58OszYxcjJwSsgKPFj8j0WEJtZIEzi2OQPYLaQQAeTxLtmVpBeYQEJic17EkHCbAIq Ese/bWCGaLWROH7uKlSJucStuWCdLAKqEkdbG5hAbE4BW4lpE2cwQ0xXlDi45igryAkiAlMY JU7suMYCcU8Do8THhvVgVRICshLLN9xmBElICHxnk9i1dCn7BEahWUhunYXk1llAy5kF1CWm TMmFCGtLPHl3gRXCVpNY+HsRE7L4Aka2VYxCuYmZObqZeSZ6iQUFOal6yfm5mxhBETTdTmgH 46lVVocYBTgYlXh4N1xhiRBiTSwrrsw9xCjNwaIkzvs1mTFCSCA9sSQ1OzW1ILUovqg0J7X4 ECMTB6dUA+M0wdB/2rPKtmlXh852KS2VXnLaQ8Zz0YVDM0NUePaq7E+/uuyOjN/ziPXd51+l MPiVypxI/TdTcCY/G2eq22u73W33w92ll0fFcYQbMV1OfHev7ROboNJ5+ytrTML9HPmydPfc DK+b5flh58QCvpvvebV0XQrP9hwNP894QIw3Um/5vcLz8kosxRmJhlrMRcWJABgbnpmBAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKIsWRmVeSWpSXmKPExsUi2FD8QTflL0uEwaKjchZTpu9hs9i/5QWb xdHzz9ksbq3/wmrx/tYlJgdWj19fr7J5LFnyk8nj8NeFLB7f5zF5fJ59lTmANYrLJiU1J7Ms tUjfLoEr497WW0wF06Irek5sZWxgfBDQxcjBISFgIjF/u0UXIyeQKSZx4d56ti5GLg4hgUOM Eg8+HWYESfAKCEr8mHyPBcRmFgiTODb5A5gtJNDBJPGumRVkjrCAhMTmPYkgYTYBFYnj3zYw Q7TaSBw/dxWqxFzi1lywThYBVYmjrQ1MIDangK3EtIkzmCGmK0ocXHOUFeQEEYEpjBIndlxj gbingVHiY8N6ZohDZSWWb7jNOIFRYBaS82YhOW8W0D5mAXWJKVNyIcLaEk/eXWCFsNUkFv5e xIQsvoCRbRWjQFFqTmKlmV5iQUFOql5yfu4mRnAsFEbtYGxYbnWIUYCDUYmHN+ISS4QQa2JZ cWUuMIw4mJVEePn/AIV4UxIrq1KL8uOLSnNSiw8xTmQEenMis5Rocj4wUvNK4g1NTAxMjI3N jI3NTcxpKawkzsvX+C9cSCA9sSQ1OzW1ILUI5igmDk6pBkYfR3kHweYAto8ap+enVhntOcAQ nWWW/Ch6utyXkrsTtv/Yv/8Ga9lEmQN+4nfzrcrPH5i+oFtx8+8V9Y0ya3oiTUptjFn37j9/ cXXekvebLyVknpmRpP5zSepZkenfo3mz1UIu368V55t0ftWkIoeoZ3P+Hj12IfyvXJXGmr3t E3YzNb3+JJyoxFKckWioxVxUnAgA15UUOPgCAAA= Archived-At: Cc: Paul Wouters Subject: Re: [IPsec] New Version of Split DNS for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 16:33:42 -0000 --Boundary_(ID_WE/f0gxOU6L3bagplOjPqw) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hello, I=E2=80=99d like to see if there were any further comments on this = draft. We incorporated the feedback we got from Paul H, Tero, and = Daniel=E2=80=94can you review the recent version and see if the changes = look good? Thanks, Tommy > On Sep 21, 2016, at 2:23 PM, Tommy Pauly wrote: >=20 > Hello all, >=20 > We've posted a new version of draft-pauly-ipsecme-split-dns = (https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-02 = ). >=20 > The changes in this version include: >=20 > - Textual clarification based on input from Daniel and Tero > - Clarification of DNSSEC payload types > - Update on the content and structure of the INTERNAL_DNSSEC_TA = attribute > - How to associate DNSSEC values with specific domains > - Naming changes (IPSec -> IPsec, Split-DNS -> Split DNS) >=20 > We believe this should be ready for adoption and moving forward, to = follow the charter. Please review and provide your input! >=20 > Thanks, > Tommy >=20 >=20 >> Begin forwarded message: >>=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for = draft-pauly-ipsecme-split-dns-02.txt >> Date: September 21, 2016 at 1:27:23 PM PDT >> To: Tommy Pauly >, Paul = Wouters > >>=20 >>=20 >> A new version of I-D, draft-pauly-ipsecme-split-dns-02.txt >> has been successfully submitted by Tommy Pauly and posted to the >> IETF repository. >>=20 >> Name: draft-pauly-ipsecme-split-dns >> Revision: 02 >> Title: Split DNS Configuration for IKEv2=20 >> Document date: 2016-09-21 >> Group: Individual Submission >> Pages: 12 >> URL: = https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-split-dns-02.txt = >> Status: = https://datatracker.ietf.org/doc/draft-pauly-ipsecme-split-dns/ = >> Htmlized: = https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-02 = >> Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-pauly-ipsecme-split-dns-02 = >>=20 >> Abstract: >> This document defines two Configuration Payload Attribute Types for >> the IKEv2 protocol that add support for private DNS domains. These >> domains should be resolved using DNS servers reachable through an >> IPsec connection, while leaving all other DNS resolution unchanged. >> This approach of resolving a subset of domains using non-public DNS >> servers is referred to as "Split DNS". >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org = . >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Boundary_(ID_WE/f0gxOU6L3bagplOjPqw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable
Hello,

I=E2=80=99d like to see if there were = any further comments on this draft. We incorporated the feedback we got = from Paul H, Tero, and Daniel=E2=80=94can you review the recent version = and see if the changes look good?

Thanks,
Tommy


On Sep 21, 2016, at 2:23 PM, Tommy Pauly = <tpauly@apple.com> wrote:

Hello all,

We've posted a new version of draft-pauly-ipsecme-split-dns = (https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-02).

The = changes in this version include:

- Textual clarification based on input = from Daniel and Tero
- Clarification of DNSSEC = payload types
- Update on the content and = structure of the INTERNAL_DNSSEC_TA attribute
- How to = associate DNSSEC values with specific domains
- = Naming changes (IPSec -> IPsec, Split-DNS -> Split DNS)

We believe this should = be ready for adoption and moving forward, to follow the charter. Please = review and provide your input!

Thanks,
Tommy


Begin = forwarded message:

From: internet-drafts@ietf.org
Subject: New Version Notification for = draft-pauly-ipsecme-split-dns-02.txt
Date: September 21, 2016 at 1:27:23 PM PDT
To: Tommy Pauly <tpauly@apple.com>, = Paul Wouters <pwouters@redhat.com>


A new version = of I-D, draft-pauly-ipsecme-split-dns-02.txt
has been = successfully submitted by Tommy Pauly and posted to the
IETF= repository.

Name: = draft-pauly-ipsecme-split-dns
Revision: 02
Title:= = Split DNS Configuration for IKEv2
Document = date: = 2016-09-21
Group: Individual Submission
Pages:= = 12
URL: =            https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-split-= dns-02.txt
Status: =         https://datatracker.ietf.org/doc/draft-pauly-ipsecme-split-dns/=
Htmlized:       https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-02
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-pauly-ipsecme-split-d= ns-02

Abstract:
=   This document defines two Configuration Payload Attribute = Types for
  the IKEv2 protocol that add support = for private DNS domains.  These
  domains = should be resolved using DNS servers reachable through an
=   IPsec connection, while leaving all other DNS resolution = unchanged.
  This approach of resolving a = subset of domains using non-public DNS
=   servers is referred to as "Split DNS".




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

The IETF Secretariat


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Boundary_(ID_WE/f0gxOU6L3bagplOjPqw)-- From nobody Mon Oct 17 11:00:26 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E6D129476; Mon, 17 Oct 2016 11:00:20 -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: 6.34.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147672722057.4523.8802745926109170628.idtracker@ietfa.amsl.com> Date: Mon, 17 Oct 2016 11:00:20 -0700 Archived-At: Cc: ipsecme-chairs@ietf.org, draft-ietf-ipsecme-safecurves@ietf.org, Tero Kivinen , ipsec@ietf.org, Kathleen.Moriarty.ietf@gmail.com, The IESG , rfc-editor@rfc-editor.org Subject: [IPsec] Protocol Action: 'Curve25519 and Curve448 for IKEv2 Key Agreement' to Proposed Standard (draft-ietf-ipsecme-safecurves-05.txt) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2016 18:00:20 -0000 The IESG has approved the following document: - 'Curve25519 and Curve448 for IKEv2 Key Agreement' (draft-ietf-ipsecme-safecurves-05.txt) as Proposed Standard This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-safecurves/ Technical Summary This document describes the use of Curve25519 and Curve448 for ephemeral key exchange in the Internet Key Exchange (IKEv2) protocol. Working Group Summary The document did not get many comments in the IPsecME working group. However, this document mostly reuses RFC7748 content defining the Diffie-Hellman groups, as such, this was expected. This document defines how those groups are used in the IKE. Document Quality Although there are no implementations yet, some are planned and are pending on the IANA allocations. Personnel Kathleen Moriarty is the responsible Area Director. Tero Kivinen is the document shepherd. IANA Note IANA is requested to assign two values from the IKEv2 "Transform Type 4 - Diffie-Hellman Group Transform IDs" registry. From nobody Tue Oct 18 03:33:39 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8AC1295F0; Tue, 18 Oct 2016 03:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 995m5imHtauK; Tue, 18 Oct 2016 03:33:35 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 806B9129421; Tue, 18 Oct 2016 03:33:35 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u9IAXTj8010256 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 Oct 2016 13:33:29 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u9IAXSoR020344; Tue, 18 Oct 2016 13:33:28 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22533.64120.595277.953942@fireball.acr.fi> Date: Tue, 18 Oct 2016 13:33:28 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <8C717FB2-DDC2-452E-AEC3-115B1E1397CF@gmail.com> References: <8C717FB2-DDC2-452E-AEC3-115B1E1397CF@gmail.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 13 min X-Total-Time: 34 min Archived-At: Cc: "ipsec@ietf.org WG" , Daniel Migault , Paul Wouters , Security Area Advisory Group , John Mattsson Subject: Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 10:33:37 -0000 Yoav Nir writes: > I=E2=80=99m not entirely comfortable with calling something a MUST NO= T when all we > have is conjecture, but I have no love and no need of those DH groups= =2E Same here, and it also makes it so that we cannot say our implementation is conforming rfc4307bis, even when we do already have support for AES, SHA2, 2048-bit DH, i.e. all the mandatory to implement algorithms in the new document, but we do also have code to propose the RFC5114 MODP groups, if user configures them to be used. Changing that is of course is very easy to do in implementation, but before this is deployed etc will take some time, and there is change, that some customer has explictly configure RFC5114 2048-bit MODP group in use, and by removing that we suddenly break their existing configuration. It is always annoying to explain to customer why we explictly broke their existing configurations unless there is real security reason for it. Looking that the paper, this only applies to the 1024-bit MODP group in RFC5114, even the paper says that 2048-bit MODP groups are safe, even if they would have same backdoor. We are already downgrading normal 1024-bit MODP group to SHOULD NOT, and this would make it two reasons to make RFC5114 1024-bit MODP group to SHOULD NOT (too short, and might be backdoored), so perhaps the compromize can be to make RFC5114 1024-bit MODP group number 22 to MUST NOT, and keep the groups 23-24 as SHOULD NOTs. Anyways we need to modify the rfc4307bis text and add reference to this paper, as one more reason why groups 22-24 MUST NOT/SHOULD NOT be used. > I don=E2=80=99t believe anyone else depends on these groups (at least= in > IPsec), so I=E2=80=99m fine with such a change. I do not think people depend on them, but I assume there is quite a lot of implementations there that can be configured to use them if explictly asked, thus making them MUST NOT will make it so that those implementations will not be conforming rfc4307bis. --=20 kivinen@iki.fi From nobody Tue Oct 18 05:47:44 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7356912957A; Tue, 18 Oct 2016 05:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRlkkTXbDSxY; Tue, 18 Oct 2016 05:47:39 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C45BA12949A; Tue, 18 Oct 2016 05:47:38 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id n189so290132883qke.0; Tue, 18 Oct 2016 05:47:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ghH067bqQRQTItA31F/3FfdTaq7a2laQaCUAsqFRmhE=; b=h/rdnq1avW/NtGqWSWHFCapwrwLoRhgCV+pGM20ac5sZ79/22/IVvDskzYEzs0bCFk DPUVRmsL2/1wIK4qsqjWcyBHuqsvoi6TCyHiLRlc4qrkQucZoFx5IZRPb3+lay5YlnJ+ qJRTUw7Jtbu8qaFOIRgsQDkX9E4rFXLx4HG5OIhxvTadJrNAuy1Z1V4R17Oqf4INhB0U 1U+kWjdSbt8KFc5dLLsDmC1yPpwGK/JDU2VLDnABsjrLo1ZEBzyKr1S5So+jIsER8R4j 39dL5Jgi0HDBBOCzs0OaY6DoFP31Y6Z1A0fQ5NJZKDHyVhdTEEvxf4Vo1nAinb+mkhlh lAHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ghH067bqQRQTItA31F/3FfdTaq7a2laQaCUAsqFRmhE=; b=ly75vOVx5Mm/HRS819BZS7XRjQLWJSKzryCUyTxrvP/6B2XqgGK1hZ0Vn0soN4MRQA S9nn/Lw1t+kbFdR3GeDjEwebEExti/uhBBOyxKUSiJ+th8CWGlXC57e8gHZqK6dlPMk7 1/hue9uMoo1dYkK+gJODNuilN7WJbhcbfYRT5wR8MAegGptANucPv237A9RwUWAJFi3F bNH6seOzl4M8Cqks8KOK3GR2YNMXp9R++d+1vlA2TNWHsYABkLjrRRNjCVk99D+B6nUS ZzCTuUWcxu5jZwAXk5W70X4Kda3Pxb8VTdcgAht4QWmsbN3pqYDOsd6+A9LWtobf+hK5 ODOQ== X-Gm-Message-State: AA6/9RkhKoG/ni8pFeZeECVYTfLtIYtHp5iIrtlTEmEwoV83BV0JHtEJchyY097U5GImLw== X-Received: by 10.194.143.47 with SMTP id sb15mr162095wjb.110.1476794857890; Tue, 18 Oct 2016 05:47:37 -0700 (PDT) Received: from [172.24.250.180] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id g17sm62596505wjs.38.2016.10.18.05.47.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Oct 2016 05:47:37 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Yoav Nir In-Reply-To: Date: Tue, 18 Oct 2016 15:47:34 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8C717FB2-DDC2-452E-AEC3-115B1E1397CF@gmail.com> To: Paul Wouters X-Mailer: Apple Mail (2.3226) Archived-At: Cc: "ipsec@ietf.org WG" , Stephen Kent , Security Area Advisory Group Subject: Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 12:47:40 -0000 > On 17 Oct 2016, at 19:19, Paul Wouters wrote: >=20 > On Mon, 17 Oct 2016, Yoav Nir wrote: >=20 >> I=E2=80=99m not entirely comfortable with calling something a MUST = NOT when all we have is conjecture, >=20 > It's a little more than conjecture. >=20 > 1) It has been proven that malicious 1024 bit DH values can be = generated > by academia that cannot be independantly discovered. Therefore any > nationstate with access to the same theory and more CPU power could > have done this years ago. Someone can trapdoor 1024-bit values, therefore someone else can = trapdoor 2048-bit values. > 2) We have the RFC 5114 values who'se original authors/sponsors are = not > disclosing how these were generated. >=20 > 1) + 2) means we cannot know if these values were trapdoor=E2=80=99ed. Yeah, we cannot know. That=E2=80=99s why it=E2=80=99s conjecture. Yoav From nobody Tue Oct 18 05:50:33 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAEE31295CE; Tue, 18 Oct 2016 05:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.631 X-Spam-Level: X-Spam-Status: No, score=-4.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvPhuDFPYf58; Tue, 18 Oct 2016 05:50:29 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E5A3129638; Tue, 18 Oct 2016 05:50:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1476795026; x=1508331026; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Qq5MhfuybKkuTjy4zDv3JmgTzxXlX2h3KcIusIgFYOk=; b=VhqR0GnotjnSQI2jhVlL/lDqvKzcCahj2plH/HN7SWpAe3B/gnk6kj3Z 7AqKDw+wSpm80qdODbLpxVaXiCSO5mY+DqN+PpRRRmA0Gk62vYbhqCymy kpB96Xar50GPjBr5vDRE0JPTKmaPbri8IgOh2pMALdnMNdfvFclSUpsY7 jKKwN+wr5RcKypQniPckq0SFFgI+qoKKUCZEX3DbHa6T8AQm3d3/eb/+i BLmYcbanaF8FDYnsp4UuAQe3oy0auXHOIzsuNY/RC3C/jm8qnLGj+vulJ eBH8AaQqnxykDBRLSbdKjaDC5LgGxoJYy6+Chl9ThMzTWIXL7PooTN8Zm w==; X-IronPort-AV: E=Sophos;i="5.31,361,1473076800"; d="scan'208";a="110827870" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.4 - Outgoing - Outgoing Received: from uxcn13-ogg-c.uoa.auckland.ac.nz ([10.6.2.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Oct 2016 01:50:24 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-c.UoA.auckland.ac.nz (10.6.2.24) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 19 Oct 2016 01:50:24 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Wed, 19 Oct 2016 01:50:24 +1300 From: Peter Gutmann To: Yoav Nir , Paul Wouters Thread-Topic: [saag] [IPsec] trapdoor'ed DH (and RFC-5114 again) Thread-Index: AQHSKJBVMii7pwSBmUObyTN/Wey1dKCr+WYAgAFXIwCAANqPSA== Date: Tue, 18 Oct 2016 12:50:24 +0000 Message-ID: <1476795020698.67090@cs.auckland.ac.nz> References: <8C717FB2-DDC2-452E-AEC3-115B1E1397CF@gmail.com> , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org WG" , Security Area Advisory Group Subject: Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 12:50:33 -0000 Yoav Nir writes:=0A= =0A= >Someone can trapdoor 1024-bit values, therefore someone else can trapdoor= =0A= >2048-bit values.=0A= =0A= Yep, space aliens. However I'm really not too worried about those at the= =0A= moment.=0A= =0A= Peter.=0A= From nobody Tue Oct 18 05:51:51 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064281295CE; Tue, 18 Oct 2016 05:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jul0Ar7mhDYy; Tue, 18 Oct 2016 05:51:48 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FF43129A3C; Tue, 18 Oct 2016 05:51:48 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id t193so136651087ywc.2; Tue, 18 Oct 2016 05:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KGETESt+xk5jcXV/fNQJ+b/toJkcA1oGvPawuV3zgLA=; b=MHb7z4s5D5viuGD0tyMTPcRRjXNL6/RfzUcSxxEG3ivrbgdYj9+Qy/kubqfZrXvfcO +hi0/RPQutMU0zCIbXYvuqkqvPEveTl8I8MGHjWChYqCs4yg5LYHNcHMQt2P1qqMtBvq 7TrMZnXynlhZajGvHv18fgQn82KEq/SfGUfmeCq3CcLh7zMY4LnHGxM/UV3AHpzelkZZ CJhnz1Wiko2LFMUxk3P3z1HYbCI0lzYJIL4DnOmydhFigdi5pqW4XffWsHxIppZ1tuL4 jePEzKdYxGEFOr1RGwBUqzS2yO5a2sorF0YH5TsnuAJYtql3tUimzI3fGdjKwXe12MGV C2Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KGETESt+xk5jcXV/fNQJ+b/toJkcA1oGvPawuV3zgLA=; b=m4IDMA/hzlJVkv38DemJJ3nGqYAwx2Qv/S2RjFor3TTjBSgn0uRMAgxrhmA5f8wG4r HHgfSzfs8dywqtDWrQTO6zKzlRmDIsrtrxtVxMPtte3I1LJKX5KjHfrF5H9n3cKo1UA1 IAQuR+k4b7iHJ7DMTdFp4c7/WDWe6t67d9457Oc8m9N1mc2fliZ9MPQZsskwtc6gCTbX YJF27LDKF64Na5o3PYKHUiQ9EnAmD1N7l+wfUbj35mjZXZfc7DegB3SNp6M71qWJBwFk Adar25EWqk+VC0jjwUt4CCmRwor+xcwHKGFgzeF1KwGjA4Bk+EaLKFci0qIBBj8W91mo Aq9w== X-Gm-Message-State: AA6/9RnWyiCR8nXdMymZ2yVA9MvDboZ3oR9NBJQ2kK0rA80JNZbDo1U9xo4dNkHsoV04Lg== X-Received: by 10.28.25.68 with SMTP id 65mr581529wmz.93.1476795107817; Tue, 18 Oct 2016 05:51:47 -0700 (PDT) Received: from [172.24.250.180] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id o1sm62694963wjh.9.2016.10.18.05.51.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Oct 2016 05:51:47 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Yoav Nir In-Reply-To: <22533.64120.595277.953942@fireball.acr.fi> Date: Tue, 18 Oct 2016 15:51:45 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <913F2EDE-2945-4036-A555-51611F8CF5AC@gmail.com> References: <8C717FB2-DDC2-452E-AEC3-115B1E1397CF@gmail.com> <22533.64120.595277.953942@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3226) Archived-At: Cc: "ipsec@ietf.org WG" , Daniel Migault , Paul Wouters , Security Area Advisory Group , John Mattsson Subject: Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 12:51:50 -0000 > On 18 Oct 2016, at 13:33, Tero Kivinen wrote: >=20 > Yoav Nir writes: >> I=E2=80=99m not entirely comfortable with calling something a MUST = NOT when all we >> have is conjecture, but I have no love and no need of those DH = groups. >=20 > Same here, and it also makes it so that we cannot say our > implementation is conforming rfc4307bis, even when we do already have > support for AES, SHA2, 2048-bit DH, i.e. all the mandatory to > implement algorithms in the new document, but we do also have code to > propose the RFC5114 MODP groups, if user configures them to be used. I don=E2=80=99t think that=E2=80=99s the right way to interpret = compliance with RFC4307bis. If you can configure your implementation to = support only algorithms that are MUST, SHOULD, or MAY in the document, = then you can configure your implementation to comply with 4307bis. I = don=E2=80=99t think implementation compliance requires pulling out code. Our implementation allows the user to key in long hex strings to = construct MODP groups that are not available out of the box. With your = interpretation we can never be compliant because they can always make up = their own 512-bit group and add that to the available groups. Yoav From nobody Tue Oct 18 06:24:43 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D08129A6A; Tue, 18 Oct 2016 06:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISPAotSbBZ5x; Tue, 18 Oct 2016 06:24:38 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D842129A64; Tue, 18 Oct 2016 06:24:38 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u9IDOYn9013841 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 Oct 2016 16:24:34 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u9IDOYgB029757; Tue, 18 Oct 2016 16:24:34 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22534.8850.6018.431180@fireball.acr.fi> Date: Tue, 18 Oct 2016 16:24:34 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <913F2EDE-2945-4036-A555-51611F8CF5AC@gmail.com> References: <8C717FB2-DDC2-452E-AEC3-115B1E1397CF@gmail.com> <22533.64120.595277.953942@fireball.acr.fi> <913F2EDE-2945-4036-A555-51611F8CF5AC@gmail.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 10 min Archived-At: Cc: "ipsec@ietf.org WG" , Daniel Migault , Paul Wouters , Security Area Advisory Group , John Mattsson Subject: Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 13:24:39 -0000 Yoav Nir writes: > > Same here, and it also makes it so that we cannot say our > > implementation is conforming rfc4307bis, even when we do already ha= ve > > support for AES, SHA2, 2048-bit DH, i.e. all the mandatory to > > implement algorithms in the new document, but we do also have code = to > > propose the RFC5114 MODP groups, if user configures them to be used= =2E >=20 > I don=E2=80=99t think that=E2=80=99s the right way to interpret compl= iance with > RFC4307bis. If you can configure your implementation to support only > algorithms that are MUST, SHOULD, or MAY in the document, then you > can configure your implementation to comply with 4307bis. I don=E2=80= =99t > think implementation compliance requires pulling out code.=20 When rfc4307bis says MUST NOT do DES, and MUST NOT do 768-bit MODP, I assume that to be conforming to that document, user is not able to configure DES with 768-bit MODP group. Of course MUST NOTs are difficult as it is really hard to show where in your code you implement this specific MUST NOT (yes, there was one customer asking us to point out where in code we implement each MUST NOTs). > Our implementation allows the user to key in long hex strings to > construct MODP groups that are not available out of the box. With > your interpretation we can never be compliant because they can > always make up their own 512-bit group and add that to the available > groups.=20 That is different issue, as this is SHOULD feature in the RFC7296: parameters, up to certain size limits. In support of this goal, all= implementations of IKEv2 SHOULD include a management facility that allows specification (by a user or system administrator) of Diffie- Hellman parameters (the generator, modulus, and exponent lengths and= values) for new Diffie-Hellman groups. Implementations SHOULD provide a management interface through which these parameters and th= e associated Transform IDs may be entered (by a user or system administrator), to enable negotiating such groups. Also there is nothing in the rfc4307bis saying that that is MUST NOT... On the otherhand if someone uses that interface to configure the 768-bit MODP group 1, then he is going against MUST NOT in rfc4307bis, and his system is longer conforming... It might be good idea to limit that interface so it will not allow any groups which are shorter than 1024-bits, just so users cannot do stupid things...=20 --=20 kivinen@iki.fi From nobody Tue Oct 18 07:00:00 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B43F129652; Tue, 18 Oct 2016 06:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 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.431] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vR81q48XOYIz; Tue, 18 Oct 2016 06:59:57 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84EC61295B9; Tue, 18 Oct 2016 06:59:57 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3syxXT3QN7z3sH; Tue, 18 Oct 2016 15:59:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1476799193; bh=9cbKUN4mebjwxETfoj6knxzTT8JPSdVSaMj8iOcpyUY=; h=Date:From:To:Subject; b=YX6t5jBCshbExNj2QL1iQ1j4KdVwdVLFIg46kE0KCG5wzGnzZ3nU0jn661LbXdYgK Qwn1oL3VEAF7iisTQ915ib0917VuqshtYaDdUzj7XdF8QUA11aOt6Gt5Ek9BwEfYUk WVuj6zgEDwKwJcc3fFQ0SCPk9djO6Rp58oiod4SI= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id sKenIa_sPEmK; Tue, 18 Oct 2016 15:59:51 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 18 Oct 2016 15:59:51 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 4D0B812EAEE; Tue, 18 Oct 2016 09:59:49 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 4D0B812EAEE Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 366DA47616DE; Tue, 18 Oct 2016 09:59:49 -0400 (EDT) Date: Tue, 18 Oct 2016 09:59:49 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" , Security Area Advisory Group Message-ID: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: [IPsec] Yet another RFC-5114 attack X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 13:59:59 -0000 https://eprint.iacr.org/2016/995.pdf Several recent standards, including NIST SP 800- 56A and RFC 5114, advocate the use of “DSA” parameters for Diffie-Hellman key exchange. While it is possible to use such parameters securely, additional validation checks are necessary to prevent well-known and potentially devastating attacks. In this paper, we observe that many Diffie-Hellman implementations do not properly validate key exchange inputs. Combined with other protocol properties and implementation choices, this can radically decrease security. We measure the prevalence of these parameter choices in the wild for HTTPS, POP3S, SMTP with STARTTLS, SSH, IKEv1, and IKEv2, finding millions of hosts using DSA and other non-“safe” primes for Diffie-Hellman key exchange, many of them in combination with potentially vulnerable behaviors. We examine over 20 open-source cryptographic libraries and applications and observe that until January 2016, not a single one validated subgroup orders by default. This paper also actually understood the difficulties of IKE scanning! And kudos to the authors for looking into so much deployment and open source software! Paul From nobody Tue Oct 18 07:31:34 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291AA12965B; Tue, 18 Oct 2016 07:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULpn3J0G1XnY; Tue, 18 Oct 2016 07:31:28 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF4D5129445; Tue, 18 Oct 2016 07:31:27 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id f128so282609461qkb.1; Tue, 18 Oct 2016 07:31:27 -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-transfer-encoding; bh=oKH8Nl/9xEsHjf+N1I04x1a2XYvJnHG5MAWmfBXHDlg=; b=ql6p8J3fFQFDubYr7cG5AZ66waMCUF/TaUB86F5VXYh9cNTmOKawqB+7qP4h1iz1os j/cIW9Kfl6Iceuktg4XZ634PlOWF0DeTYJ9iL4UHvM8JX/gxoLUyw9GoY52EPyVidaH2 fikMaRCTWci0bBFtBbysCE5D/mGXG8fuR5zxpbmoSWj4mH+gCii8v0h+erlAGeG4Xins 7Pqm7uCDqRG9WUgbZ9GCLHynW4VnQq+iSAToLiXuvVG9p10mdlSDaKZ9oHj9w3iXkkPs re/vc2zRMoF1CZUfeDCsBAz95wwAsI1qMyh7aMSECdzYpSeXzrL/4nFR5fwy6EGVOBBF 2RoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=oKH8Nl/9xEsHjf+N1I04x1a2XYvJnHG5MAWmfBXHDlg=; b=CVyg57aeEN7b3+apClh2JqaxHYkjYpnjApOlxoeiafOk7IA3PE6zZ5vvzCK3x6gO7i gIbzkJp8nVoT6h6kfaT2wbJM5VOo79kLnmWrZ5CMj4yI2sBfLou0ALeJmPPZvCF4BK02 AeK1AxvwFafbyN8paVxgsSfbF4LyGD3fmx1fginZ0c/xAq9OkR63I8HCDIuBa9946Ppi nHnYmbOCdlWQf0Vi3oYl4m5CWs5BiDObs8PLZhO26GNW2hfs7nNXgveFnQRf0tlgNJ0E TLFNpiJkWOhLVqt3v6DYzPF+eUfRwoufZ3rjyTA1VjeyfiD+B39aY2JdbKoy1TOZJjKC xd0Q== X-Gm-Message-State: AA6/9Rn5LSHazeYdBZqFUJQO3TC4kolPTVBgQxwMBerW6dQaW5ErOpjwBxJaz5GxCKSCAB7SQR9B97HQ2tRJRw== X-Received: by 10.55.96.7 with SMTP id u7mr904150qkb.189.1476801071198; Tue, 18 Oct 2016 07:31:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.171.87 with HTTP; Tue, 18 Oct 2016 07:31:10 -0700 (PDT) In-Reply-To: <22533.64120.595277.953942@fireball.acr.fi> References: <8C717FB2-DDC2-452E-AEC3-115B1E1397CF@gmail.com> <22533.64120.595277.953942@fireball.acr.fi> From: Watson Ladd Date: Tue, 18 Oct 2016 07:31:10 -0700 Message-ID: To: Tero Kivinen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "ipsec@ietf.org WG" , Paul Wouters , Security Area Advisory Group , Yoav Nir Subject: Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 14:31:30 -0000 On Tue, Oct 18, 2016 at 3:33 AM, Tero Kivinen wrote: > Yoav Nir writes: >> I=E2=80=99m not entirely comfortable with calling something a MUST NOT w= hen all we >> have is conjecture, but I have no love and no need of those DH groups. > > Same here, and it also makes it so that we cannot say our > implementation is conforming rfc4307bis, even when we do already have > support for AES, SHA2, 2048-bit DH, i.e. all the mandatory to > implement algorithms in the new document, but we do also have code to > propose the RFC5114 MODP groups, if user configures them to be used. > > Changing that is of course is very easy to do in implementation, but > before this is deployed etc will take some time, and there is change, > that some customer has explictly configure RFC5114 2048-bit MODP group > in use, and by removing that we suddenly break their existing > configuration. In sane protocols the default MTI ciphersuite is always ready to be used for exactly this reason. IKE's extensively flexible configuration knobset was not a good idea for this reason. > > It is always annoying to explain to customer why we explictly broke > their existing configurations unless there is real security reason for > it. Looking that the paper, this only applies to the 1024-bit MODP > group in RFC5114, even the paper says that 2048-bit MODP groups are > safe, even if they would have same backdoor. > > We are already downgrading normal 1024-bit MODP group to SHOULD NOT, > and this would make it two reasons to make RFC5114 1024-bit MODP group > to SHOULD NOT (too short, and might be backdoored), so perhaps the > compromize can be to make RFC5114 1024-bit MODP group number 22 to > MUST NOT, and keep the groups 23-24 as SHOULD NOTs. This seems reasonable to me. > > Anyways we need to modify the rfc4307bis text and add reference to > this paper, as one more reason why groups 22-24 MUST NOT/SHOULD NOT be > used. > >> I don=E2=80=99t believe anyone else depends on these groups (at least in >> IPsec), so I=E2=80=99m fine with such a change. > > I do not think people depend on them, but I assume there is quite a > lot of implementations there that can be configured to use them if > explictly asked, thus making them MUST NOT will make it so that those > implementations will not be conforming rfc4307bis. That's sort of the point. We want these implementations to NOT support these groups, just as RC4 die-die-die meant TLS implementations no longer support RC4. > -- > kivinen@iki.fi > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Tue Oct 18 07:39:00 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E7412966E; Tue, 18 Oct 2016 07:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 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.431] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tw6dXZJO6jvr; Tue, 18 Oct 2016 07:38:58 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87D30129666; Tue, 18 Oct 2016 07:38:58 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3syyPW5zm6z460; Tue, 18 Oct 2016 16:38:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1476801535; bh=p56O4yJHvQP5FylKbPSDiuJ/v74okE/mz0bDpNt3bD8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=YedRdoR1AZGQUt01FsOy8CHNbKbD3VdqqCbspFdizH8ezeauZv7xwP554aJv57I3j 9tDlvEYfJUKvuUoS3Qo4I7Nc3wuHFUJyGaf/FP2nfLDZhWOIKNYBRPNouWdJcc/LT3 ZkWc1Xes+Uaxr3k9yW6xAqiy9W8k7GYpu74u/LDU= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id vRFKyLbBXv4M; Tue, 18 Oct 2016 16:38:55 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 18 Oct 2016 16:38:54 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0C21D12EAEE; Tue, 18 Oct 2016 10:38:53 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 0C21D12EAEE Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 06E614163767; Tue, 18 Oct 2016 10:38:52 -0400 (EDT) Date: Tue, 18 Oct 2016 10:38:52 -0400 (EDT) From: Paul Wouters To: Yoav Nir In-Reply-To: Message-ID: References: <8C717FB2-DDC2-452E-AEC3-115B1E1397CF@gmail.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: "ipsec@ietf.org WG" , Stephen Kent , Security Area Advisory Group Subject: Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 14:38:59 -0000 On Tue, 18 Oct 2016, Yoav Nir wrote: >> It's a little more than conjecture. >> >> 1) It has been proven that malicious 1024 bit DH values can be generated >> by academia that cannot be independantly discovered. Therefore any >> nationstate with access to the same theory and more CPU power could >> have done this years ago. > > Someone can trapdoor 1024-bit values, therefore someone else can trapdoor 2048-bit values. > >> 2) We have the RFC 5114 values who'se original authors/sponsors are not >> disclosing how these were generated. >> >> 1) + 2) means we cannot know if these values were trapdoor’ed. > > Yeah, we cannot know. That’s why it’s conjecture. conjecture: 1. an opinion or conclusion formed on the basis of incomplete information. I have complete information for "one cannot detect trapdoors without knowing seed" Paul From nobody Tue Oct 18 07:47:07 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761941294A7; Tue, 18 Oct 2016 07:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9r39hOuNwoZu; Tue, 18 Oct 2016 07:47:05 -0700 (PDT) Received: from bos-mailout2.raytheon.com (bos-mailout2.raytheon.com [199.46.198.208]) (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 E029C12948C; Tue, 18 Oct 2016 07:47:04 -0700 (PDT) Received: from ma-mailout10.rtnmail.ray.com (ma-mailout10.rtnmail.ray.com [147.25.130.27]) by bos-mailout2.raytheon.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id u9IEl0pY024719 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 Oct 2016 14:47:02 GMT Received: from smtp.bbn.com ([128.33.1.81]) by ma-mailout10.rtnmail.ray.com (8.15.0.59/8.15.0.59) with ESMTPS id u9IEl0Ie002381 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NOT); Tue, 18 Oct 2016 14:47:00 GMT Received: from ssh.bbn.com ([192.1.122.15]:43572 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1bwVfQ-000CJu-Az; Tue, 18 Oct 2016 10:47:00 -0400 From: Stephen Kent To: Paul Wouters , Yoav Nir References: <8C717FB2-DDC2-452E-AEC3-115B1E1397CF@gmail.com> Message-ID: <551e6c5c-0db7-62d5-da31-b99f26475010@bbn.com> Date: Tue, 18 Oct 2016 10:47:00 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-CC: saag@ietf.org, ipsec@ietf.org, ynir.ietf@gmail.com, paul@nohats.ca X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-18_07:, , signatures=0 Archived-At: Cc: "ipsec@ietf.org WG" , Security Area Advisory Group Subject: Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 14:47:06 -0000 Paul, It's been over 8 years since this RFC was published, and I have not looked at it since then. My recollection is that we wrote 5114 because an IPsec developer approached me and said that he wanted to support these groups in a product. He said that he wanted test vectors for the groups, consistent with what we have done for many other algs. I persuaded Matt to generate the RFC because it was a relatively easy task a good way for Matt to get acquainted with the RFC process. As to your question, I have no info about how the NIST DH values were generated. However, I do agree with Yoav and Tero that it seems unduly prejudicial to declare these to be a MUST NOT. The fact that one can generate trap-doored DH values that cannot be detected is not the same as having proof that a given set of values have been generated in that fashion. Moreover, if one interprets a MUST NOT in this context to mean that an implementation supporting any of these groups is non-compliant, then that unfairly penalizes existing implementations, as Tero noted. Moreover, if the concern raised by the paper (which I have read) is with MODP groups of size 1024 (or smaller), only 1 of the groups in 5114 fits that criteria (section 2.1). I have not tracked the status of these NIST groups re evaluation criteria like FIPS 140-2. If these groups are approved for use in products evaluated under that FIPS (I don't know if they are), deprecating them creates a possible conundrum for vendors who want to comply with RFCs and with FIPS evaluation criteria. Thus I suggest a less dramatic response than declaring all of the groups in 5114 to be MUST NOT. I'm not a vendor of any crypto products (these days), and I've never been a crypto mathematician. So my views are based only on what I recall about the creation of 5114 and about IETF crytpo standards practices in general. Steve From nobody Tue Oct 18 11:47:23 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261CB12970F; Tue, 18 Oct 2016 11:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ow-3dArfaL1A; Tue, 18 Oct 2016 11:47:16 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 F35C01294A4; Tue, 18 Oct 2016 11:47:15 -0700 (PDT) X-AuditID: c1b4fb25-15fff7000000793b-2e-58066e310a27 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id EA.EF.31035.13E66085; Tue, 18 Oct 2016 20:47:14 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.139]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0319.002; Tue, 18 Oct 2016 20:46:30 +0200 From: John Mattsson To: Stephen Kent , Paul Wouters , Yoav Nir Thread-Topic: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again) Thread-Index: AQHSKU6CHJtC8inrDUW+5swoRbNe7qCujeeA Date: Tue, 18 Oct 2016 18:46:29 +0000 Message-ID: References: <8C717FB2-DDC2-452E-AEC3-115B1E1397CF@gmail.com> <551e6c5c-0db7-62d5-da31-b99f26475010@bbn.com> In-Reply-To: <551e6c5c-0db7-62d5-da31-b99f26475010@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.7.160722 x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKIsWRmVeSWpSXmKPExsUyM2K7k65RHluEQedscYv9W16wWWyczWjx /tYlJosp/Z1MFkuPfWByYPWYej7UY+esu+weS5b8ZPL4Po8pgCWKyyYlNSezLLVI3y6BK+No 81X2gmlKFTvbchsYlyh2MXJySAiYSPTuPMvWxcjFISSwnlHixoxdjBDOEkaJyYeWsYBUsQkY SMzd08AGYosIJEicunCEGcRmFoiQmHV0DyOILSxgL/Hy2wyoGgeJSbMOskLYRhIbNn0Fs1kE VCWOXDgAZvMKmEss6VjCBLHsLJPE4ksrwZo5Bawl9iw/CraYUUBM4vupNUwQy8Qlbj2ZzwRx toDEkj3nmSFsUYmXj/+BDRUV0JN49vk5O0RcSWLF9ktAx3EA9WpKrN+lDzHGWmJdxw2o+xUl pnQ/ZIe4R1Di5MwnLBMYxWch2TYLoXsWku5ZSLpnIelewMi6ilG0OLU4KTfdyFgvtSgzubg4 P08vL7VkEyMwMg9u+a26g/HyG8dDjAIcjEo8vArJbBFCrIllxZW5hxglOJiVRHhvpQGFeFMS K6tSi/Lji0pzUosPMUpzsCiJ85qtvB8uJJCeWJKanZpakFoEk2Xi4JRqYAw76i2TnjH9XdrK ucrHpfYsuDjjeeTEgOMqFxZt6/YqTanc+PWy4ibmmPsT7C7qxt5pqK8T+ZbH0TH76LNrvo75 jwU7l12Ov7unJ+uopMziuXfM2FUyuK3MNgU8/Jdc9uH1B9ZO+WszU4P1rCPrk2d6q1sYsp1e 9LV2340bXXFl259uTp5YNl2JpTgj0VCLuag4EQCi4DoqyAIAAA== Archived-At: Cc: "ipsec@ietf.org WG" , Security Area Advisory Group Subject: Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2016 18:47:18 -0000 TmV3IHBhcGVyIOKAnE1lYXN1cmluZyBzbWFsbCBzdWJncm91cCBhdHRhY2tzIGFnYWluc3QgRGlm ZmllLUhlbGxtYW7igJ0NCg0KaHR0cHM6Ly9lcHJpbnQuaWFjci5vcmcvMjAxNi85OTUucGRmDQoN Cg0K4oCcQ3J5cHRvZ3JhcGhpYyByZWNvbW1lbmRhdGlvbnMgZnJvbSBzdGFuZGFyZHMgY29tbWl0 dGVlcyBhcmUgb2Z0ZW4gdG9vDQp3ZWFrIG9yIHZhZ3Vl4oCdDQoNCuKAnEhvd2V2ZXIsIHRoZSB0 YW5nbGUgb2YgUkZDcyBhbmQgc3RhbmRhcmRzIGF0dGVtcHRpbmcgdG8gZGVmaW5lIGN1cnJlbnQN CmJlc3QgcHJhY3RpY2VzIGluIGtleSBnZW5lcmF0aW9uIGFuZCBwYXJhbWV0ZXIgc2l6aW5nIGRv IG5vdCBwYWludCBhIGNsZWFyDQpwaWN0dXJlLCBhbmQgaW5zdGVhZCBkZXNjcmliZSBjb21wbGV4 IGNvbWJpbmF0aW9ucyBvZiBhcHByb2FjaGVzIGFuZA0KcGFyYW1ldGVycywgZXhwb3NpbmcgdGhl IGZyYWdpbGl0eSBvZiB0aGUgY3J5cHRvZ3JhcGhpYyBlY29zeXN0ZW0uIEFzIGENCnJlc3VsdCwg ZGV2ZWxvcGVycyBvZnRlbiBmb3JnZXQgb3IgaWdub3JlIGVkZ2UgY2FzZXMsIGxlYXZpbmcgbWFu eQ0KaW1wbGVtZW50YXRpb25zIG9mIERpZmZpZS1IZWxsbWFuIHRvbyBjbG9zZSB0byB2dWxuZXJh YmxlIg0KDQrigJxBcyB3ZSBzaG93IGluIHRoaXMgcGFwZXIsIGZpbml0ZS1maWVsZCBiYXNlZCBE aWZmaWUtSGVsbG1hbiBoYXMgbWFueSBlZGdlDQpjYXNlcyB0aGF0IG1ha2UgaXRzIGNvcnJlY3Qg dXNlIGRpZmZpY3VsdCwgYW5kIHdoaWNoIG9jY2FzaW9uYWxseSBhcmlzZSBhcw0KYnVncyBhdCB0 aGUgcHJvdG9jb2wgbGV2ZWwu4oCdDQoNCuKAnEFzIGEgY29uY3JldGUgcmVjb21tZW5kYXRpb24s IG1vZGVybiBEaWZmaWUtSGVsbG1hbiBpbXBsZW1lbnRhdGlvbnMNCnNob3VsZCBwcmVmZXIgZWxs aXB0aWMgY3VydmUgZ3JvdXBzIG92ZXIgc2FmZSBjdXJ2ZXMgd2l0aCBwcm9wZXIgcG9pbnQNCnZh bGlkYXRpb24u4oCdDQoNCi9Kb2huDQoNCg0KT24gMTgvMTAvMTYgMTY6NDcsICJJUHNlYyBvbiBi ZWhhbGYgb2YgU3RlcGhlbiBLZW50Ig0KPGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxm IG9mIGtlbnRAYmJuLmNvbT4gd3JvdGU6DQoNCj5QYXVsLA0KPg0KPkl0J3MgIGJlZW4gb3ZlciA4 IHllYXJzIHNpbmNlIHRoaXMgUkZDIHdhcyBwdWJsaXNoZWQsIGFuZCBJIGhhdmUgbm90DQo+bG9v a2VkIGF0IGl0IHNpbmNlIHRoZW4uIE15IHJlY29sbGVjdGlvbiBpcyB0aGF0IHdlIHdyb3RlIDUx MTQgYmVjYXVzZQ0KPmFuIElQc2VjIGRldmVsb3BlciBhcHByb2FjaGVkIG1lIGFuZCBzYWlkIHRo YXQgaGUgd2FudGVkIHRvIHN1cHBvcnQNCj50aGVzZSBncm91cHMgaW4gYSBwcm9kdWN0LiBIZSBz YWlkIHRoYXQgaGUgd2FudGVkIHRlc3QgdmVjdG9ycyBmb3IgdGhlDQo+Z3JvdXBzLCBjb25zaXN0 ZW50IHdpdGggd2hhdCB3ZSBoYXZlIGRvbmUgZm9yIG1hbnkgb3RoZXIgYWxncy4gSQ0KPnBlcnN1 YWRlZCBNYXR0IHRvIGdlbmVyYXRlIHRoZSBSRkMgYmVjYXVzZSBpdCB3YXMgYSByZWxhdGl2ZWx5 IGVhc3kgdGFzaw0KPmEgZ29vZCB3YXkgZm9yIE1hdHQgdG8gZ2V0IGFjcXVhaW50ZWQgd2l0aCB0 aGUgUkZDIHByb2Nlc3MuDQo+DQo+QXMgdG8geW91ciBxdWVzdGlvbiwgSSBoYXZlIG5vIGluZm8g YWJvdXQgaG93IHRoZSBOSVNUIERIIHZhbHVlcyB3ZXJlDQo+Z2VuZXJhdGVkLiBIb3dldmVyLCBJ IGRvIGFncmVlIHdpdGggWW9hdiBhbmQgVGVybyB0aGF0IGl0IHNlZW1zIHVuZHVseQ0KPnByZWp1 ZGljaWFsIHRvIGRlY2xhcmUgdGhlc2UgdG8gYmUgYSBNVVNUIE5PVC4gVGhlIGZhY3QgdGhhdCBv bmUgY2FuDQo+Z2VuZXJhdGUgdHJhcC1kb29yZWQgREggdmFsdWVzIHRoYXQgY2Fubm90IGJlIGRl dGVjdGVkIGlzIG5vdCB0aGUgc2FtZQ0KPmFzIGhhdmluZyBwcm9vZiB0aGF0IGEgZ2l2ZW4gc2V0 IG9mIHZhbHVlcyBoYXZlIGJlZW4gZ2VuZXJhdGVkIGluIHRoYXQNCj5mYXNoaW9uLiBNb3Jlb3Zl ciwgaWYgb25lIGludGVycHJldHMgYSBNVVNUIE5PVCBpbiB0aGlzIGNvbnRleHQgdG8gbWVhbg0K PnRoYXQgYW4gaW1wbGVtZW50YXRpb24gc3VwcG9ydGluZyBhbnkgb2YgdGhlc2UgZ3JvdXBzIGlz IG5vbi1jb21wbGlhbnQsDQo+dGhlbiB0aGF0IHVuZmFpcmx5IHBlbmFsaXplcyBleGlzdGluZyBp bXBsZW1lbnRhdGlvbnMsIGFzIFRlcm8gbm90ZWQuDQo+TW9yZW92ZXIsIGlmIHRoZSBjb25jZXJu IHJhaXNlZCBieSB0aGUgcGFwZXIgKHdoaWNoIEkgaGF2ZSByZWFkKSBpcyB3aXRoDQo+TU9EUCBn cm91cHMgb2Ygc2l6ZSAxMDI0IChvciBzbWFsbGVyKSwgb25seSAxIG9mIHRoZSBncm91cHMgaW4g NTExNCBmaXRzDQo+dGhhdCBjcml0ZXJpYSAoc2VjdGlvbiAyLjEpLg0KPg0KPkkgaGF2ZSBub3Qg dHJhY2tlZCB0aGUgc3RhdHVzIG9mIHRoZXNlIE5JU1QgZ3JvdXBzIHJlIGV2YWx1YXRpb24NCj5j cml0ZXJpYSBsaWtlIEZJUFMgMTQwLTIuIElmIHRoZXNlIGdyb3VwcyBhcmUgYXBwcm92ZWQgZm9y IHVzZSBpbg0KPnByb2R1Y3RzIGV2YWx1YXRlZCB1bmRlciB0aGF0IEZJUFMgKEkgZG9uJ3Qga25v dyBpZiB0aGV5IGFyZSksDQo+ZGVwcmVjYXRpbmcgdGhlbSBjcmVhdGVzIGEgcG9zc2libGUgY29u dW5kcnVtIGZvciB2ZW5kb3JzIHdobyB3YW50IHRvDQo+Y29tcGx5IHdpdGggUkZDcyBhbmQgd2l0 aCBGSVBTIGV2YWx1YXRpb24gY3JpdGVyaWEuIFRodXMgSSBzdWdnZXN0IGENCj5sZXNzIGRyYW1h dGljIHJlc3BvbnNlIHRoYW4gZGVjbGFyaW5nIGFsbCBvZiB0aGUgZ3JvdXBzIGluIDUxMTQgdG8g YmUNCj5NVVNUIE5PVC4NCj4NCj5JJ20gbm90IGEgdmVuZG9yIG9mIGFueSBjcnlwdG8gcHJvZHVj dHMgKHRoZXNlIGRheXMpLCBhbmQgSSd2ZSBuZXZlcg0KPmJlZW4gYSBjcnlwdG8gbWF0aGVtYXRp Y2lhbi4gU28gbXkgdmlld3MgYXJlIGJhc2VkIG9ubHkgb24gd2hhdCBJIHJlY2FsbA0KPmFib3V0 IHRoZSBjcmVhdGlvbiBvZiA1MTE0IGFuZCBhYm91dCBJRVRGIGNyeXRwbyBzdGFuZGFyZHMgcHJh Y3RpY2VzIGluDQo+Z2VuZXJhbC4NCj4NCj5TdGV2ZQ0KPg0KPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+SVBzZWMgbWFpbGluZyBsaXN0DQo+SVBzZWNA aWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjDQoN Cg== From nobody Wed Oct 19 00:36:47 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B88C1294A0; Wed, 19 Oct 2016 00:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHLEFMja0WkS; Wed, 19 Oct 2016 00:36:42 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74014129545; Wed, 19 Oct 2016 00:36:42 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id z190so21325674qkc.2; Wed, 19 Oct 2016 00:36:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=HIxF59MK2DuOl4dxo3654M6kRnLRbR+P56SKo1VXaIs=; b=LokSx5uqt12inj+vhszxYr7IoGgaFrpjx5VCxuYQEeMdgxYPaB8kDzbXH+NqCsMK2r gxtIpZQw34513fOdaPpBI7S4cijY2UwWUf88iveLReSbdNH5IKr74mL/JfFXU1Ihppl0 S+wHBCn/J6Z1u5KqfwVxyPLoux+FuXa0QVrVzbhlhIwREtyQ0Szkh64z8Q+XNPcW5T03 +Uzw3IEqylwl6BoMJz9lkj3HHiuSjAc4DsbfhflGiG0FpJWV+hhuv9Ooq+eK/V7QfM2q 1OiN53IFHa8XaEXDFNG/t6mmrfbFXMHBK1ULCj/m1gAR/VbCc5bAhHXC/liH2FN0qjq9 TZ+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=HIxF59MK2DuOl4dxo3654M6kRnLRbR+P56SKo1VXaIs=; b=O28B8W4eiY5DmPWUaooTeXO0AXTvIc0bUo0q59s1Oi6J21sxqWh0GyIEI5lhQR1U02 bQvAWV3MdNd5BKkp+zeBma5kuW4zxmDYCUca3afLgVYjkULfBKPs7B/0VBI6F4Hyg4bb hhWFZl7bO9NXW0qWzsA6latFGzZP/IL6Fg8h4V+C+DvlL3ieD040yFdLDdiBqJkLRcD0 UvvE9xAW9rMpM+hNmf7BXe5e0uZ5/Xtghiyp6cC+gUcpRRZSjGKy1m55iqOHbGh+W0W9 mDN5eaqy+CG33+GMuLMJRIU4LSQgNaBSCZByWmC/1c9lbLE4KxJflAE1SjAVUWUI1NPb Klzg== X-Gm-Message-State: AA6/9RnWRbAwYWHnbq4fReX8XPecnDCqHg8PxkJ1eEWhx9qgZwJiq2C95iUFtUB3A39gfEJqLoJ2H1aTNTfhiA== X-Received: by 10.55.183.2 with SMTP id h2mr4334386qkf.134.1476862601598; Wed, 19 Oct 2016 00:36:41 -0700 (PDT) MIME-Version: 1.0 Sender: n.mavrogiannopoulos@gmail.com Received: by 10.12.169.91 with HTTP; Wed, 19 Oct 2016 00:36:01 -0700 (PDT) In-Reply-To: References: <8C717FB2-DDC2-452E-AEC3-115B1E1397CF@gmail.com> <551e6c5c-0db7-62d5-da31-b99f26475010@bbn.com> From: Nikos Mavrogiannopoulos Date: Wed, 19 Oct 2016 09:36:01 +0200 X-Google-Sender-Auth: R-oj_nSECVGoukBoc0OGmWZmvDU Message-ID: To: John Mattsson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "ipsec@ietf.org WG" , Paul Wouters , Stephen Kent , Yoav Nir , Security Area Advisory Group Subject: Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 07:36:44 -0000 On Tue, Oct 18, 2016 at 8:46 PM, John Mattsson wrote: > New paper =E2=80=9CMeasuring small subgroup attacks against Diffie-Hellma= n=E2=80=9D > https://eprint.iacr.org/2016/995.pdf > =E2=80=9CCryptographic recommendations from standards committees are ofte= n too > weak or vague=E2=80=9D > =E2=80=9CHowever, the tangle of RFCs and standards attempting to define c= urrent > best practices in key generation and parameter sizing do not paint a clea= r > picture, and instead describe complex combinations of approaches and > parameters, exposing the fragility of the cryptographic ecosystem. As a > result, developers often forget or ignore edge cases, leaving many > implementations of Diffie-Hellman too close to vulnerable" > > =E2=80=9CAs we show in this paper, finite-field based Diffie-Hellman has = many edge > cases that make its correct use difficult, and which occasionally arise a= s > bugs at the protocol level.=E2=80=9D > > =E2=80=9CAs a concrete recommendation, modern Diffie-Hellman implementati= ons > should prefer elliptic curve groups over safe curves with proper point > validation.=E2=80=9D I am not sure that the recommendations of this paper should be blindly trusted. There are some inaccurate facts about a library I work on [0], but a part of the abstract is also concerning: "We examine over 20 open-source cryptographic libraries and applications and observe that until January 2016, not a single one validated subgroup orders by default." That's objectively accurate, but the authors do not attempt to find out the actual issue behind it. Are all implementations bad, or there are obstacles in doing that? I am aware that TLS client implementations do not validate subgroup orders by default, because the group information provided by TLS is not sufficient to validate the subgroup order. It is simply impossible for them to do any validation. regards, Nikos [0]. https://lists.gnupg.org/pipermail/gnutls-devel/2016-October/008198.htm= l From nobody Wed Oct 19 01:13:23 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D49512956F; Wed, 19 Oct 2016 01:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKAM4LKduZPO; Wed, 19 Oct 2016 01:13:15 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 5E88C129560; Wed, 19 Oct 2016 01:13:15 -0700 (PDT) X-AuditID: c1b4fb3a-ab7ff7000000099a-62-58072b1920c0 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by (Symantec Mail Security) with SMTP id F9.C7.02458.91B27085; Wed, 19 Oct 2016 10:13:13 +0200 (CEST) Received: from ESESSMB307.ericsson.se ([169.254.7.139]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0319.002; Wed, 19 Oct 2016 10:13:12 +0200 From: John Mattsson To: Nikos Mavrogiannopoulos Thread-Topic: [saag] [IPsec] trapdoor'ed DH (and RFC-5114 again) Thread-Index: AQHSKduJ2W/sFWR35kmFUzWD99HoZqCvbiMA Date: Wed, 19 Oct 2016 08:13:12 +0000 Message-ID: References: <8C717FB2-DDC2-452E-AEC3-115B1E1397CF@gmail.com> <551e6c5c-0db7-62d5-da31-b99f26475010@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.7.160722 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUyM2K7ja6kNnuEQcdkNYv9W16wWWyczWix dOduVov3ty4xWUzp72SyWHrsA5MDm8fU86EeO2fdZfeYvK2R0WPJkp9MHt/nMQWwRnHZpKTm ZJalFunbJXBlHOxdwVbQJl2x8td69gbGNVJdjJwcEgImEk9+zWUFsYUE1jNKTHzD38XIBWQv YZSYMe0zC0iCTcBAYu6eBjYQW0RAV2LbmzvMIEXMAjsYJXYc+QFWJCxgL7HnejszRJGDxKel e9khbCOJORtOgzWzCKhK3Ox7D2RzcPAKmEvMXxAPsewQs8SbNR/A6jkFAiUWdW0Fm8koICbx /dQaJhCbWUBc4taT+UwQVwtILNlznhnCFpV4+fgf2AeiAnoSzz4/ZweZLyGgKLG8Xw7EZBbQ lFi/Sx/CtJbo3CcJMVBRYkr3Q7ClvAKCEidnPmGZwCg+C8muWQjNsxCaZyFpnoWkeQEj6ypG 0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2MwDg9uOW31Q7Gg88dDzEKcDAq8fAqJLNFCLEmlhVX 5h5ilOBgVhLhFdZgjxDiTUmsrEotyo8vKs1JLT7EKM3BoiTOa7byfriQQHpiSWp2ampBahFM lomDU6qB0UahTeR+nV/9IXWu1UfyIhUfzu9Yx9T7Ni399UPTuPWvd26dld/uV7y5duK9Gc/c pf3ivu8WkhLYlLd+bwQv35Kt0b1+6cvErFoEXnY1F4iLCuZv/rt8a/E8qfWnGx7YJK26MWdv 9qfty9ML2z+2/4/nW9audrucgSGspcF8WvRD0y8/WIULlViKMxINtZiLihMBxn1E0M8CAAA= Archived-At: Cc: "ipsec@ietf.org WG" , Paul Wouters , Stephen Kent , Yoav Nir , Security Area Advisory Group Subject: Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2016 08:13:17 -0000 SSBoYXZlIG5vdCByZWFkIHRoZSBwYXBlciBpbiBkZXRhaWwsIGJ1dCBJIGFncmVlIHdpdGggdGhl IGhpZ2ggbGV2ZWwNCmNvbmNsdXNpb25zLiBJZiBpdCB3ZXJlIG5vdCBmb3IgcXVhbnR1bSBjb21w dXRlcnMsIEkgdGhpbmsgSUVURiBzaG91bGQNCm1vdmUgdG8gY3VydmUyNTUxOSBhcyBxdWlja2x5 IGFzIHBvc3NpYmxlLiBXaXRoIHF1YW50dW0gY29tcHV0ZXJzIHRoZQ0KcGljdHVyZSBpcyBtb3Jl IGNvbXBsaWNhdGVkIGFzIEVDQyB3b3VsZCBhbnl3YXkgbmVlZCB0byBiZSByZXBsYWNlZCB3aXRo DQpQUUMgaW4gdGhlIG5vdCB0byBkaXN0YW50IGZ1dHVyZS4NCg0KQ2hlZXJzLA0KDQpKb2huDQoN Ck9uIDE5LzEwLzE2IDA5OjM2LCAibi5tYXZyb2dpYW5ub3BvdWxvc0BnbWFpbC5jb20gb24gYmVo YWxmIG9mIE5pa29zDQpNYXZyb2dpYW5ub3BvdWxvcyIgPG4ubWF2cm9naWFubm9wb3Vsb3NAZ21h aWwuY29tIG9uIGJlaGFsZiBvZg0Kbm1hdkBnbnV0bHMub3JnPiB3cm90ZToNCg0KPk9uIFR1ZSwg T2N0IDE4LCAyMDE2IGF0IDg6NDYgUE0sIEpvaG4gTWF0dHNzb24NCj48am9obi5tYXR0c3NvbkBl cmljc3Nvbi5jb20+IHdyb3RlOg0KPj4gTmV3IHBhcGVyIOKAnE1lYXN1cmluZyBzbWFsbCBzdWJn cm91cCBhdHRhY2tzIGFnYWluc3QgRGlmZmllLUhlbGxtYW7igJ0NCj4+IGh0dHBzOi8vZXByaW50 LmlhY3Iub3JnLzIwMTYvOTk1LnBkZg0KPj4g4oCcQ3J5cHRvZ3JhcGhpYyByZWNvbW1lbmRhdGlv bnMgZnJvbSBzdGFuZGFyZHMgY29tbWl0dGVlcyBhcmUgb2Z0ZW4gdG9vDQo+PiB3ZWFrIG9yIHZh Z3Vl4oCdDQo+PiDigJxIb3dldmVyLCB0aGUgdGFuZ2xlIG9mIFJGQ3MgYW5kIHN0YW5kYXJkcyBh dHRlbXB0aW5nIHRvIGRlZmluZSBjdXJyZW50DQo+PiBiZXN0IHByYWN0aWNlcyBpbiBrZXkgZ2Vu ZXJhdGlvbiBhbmQgcGFyYW1ldGVyIHNpemluZyBkbyBub3QgcGFpbnQgYQ0KPj5jbGVhcg0KPj4g cGljdHVyZSwgYW5kIGluc3RlYWQgZGVzY3JpYmUgY29tcGxleCBjb21iaW5hdGlvbnMgb2YgYXBw cm9hY2hlcyBhbmQNCj4+IHBhcmFtZXRlcnMsIGV4cG9zaW5nIHRoZSBmcmFnaWxpdHkgb2YgdGhl IGNyeXB0b2dyYXBoaWMgZWNvc3lzdGVtLiBBcyBhDQo+PiByZXN1bHQsIGRldmVsb3BlcnMgb2Z0 ZW4gZm9yZ2V0IG9yIGlnbm9yZSBlZGdlIGNhc2VzLCBsZWF2aW5nIG1hbnkNCj4+IGltcGxlbWVu dGF0aW9ucyBvZiBEaWZmaWUtSGVsbG1hbiB0b28gY2xvc2UgdG8gdnVsbmVyYWJsZSINCj4+DQo+ PiDigJxBcyB3ZSBzaG93IGluIHRoaXMgcGFwZXIsIGZpbml0ZS1maWVsZCBiYXNlZCBEaWZmaWUt SGVsbG1hbiBoYXMgbWFueQ0KPj5lZGdlDQo+PiBjYXNlcyB0aGF0IG1ha2UgaXRzIGNvcnJlY3Qg dXNlIGRpZmZpY3VsdCwgYW5kIHdoaWNoIG9jY2FzaW9uYWxseSBhcmlzZQ0KPj5hcw0KPj4gYnVn cyBhdCB0aGUgcHJvdG9jb2wgbGV2ZWwu4oCdDQo+Pg0KPj4g4oCcQXMgYSBjb25jcmV0ZSByZWNv bW1lbmRhdGlvbiwgbW9kZXJuIERpZmZpZS1IZWxsbWFuIGltcGxlbWVudGF0aW9ucw0KPj4gc2hv dWxkIHByZWZlciBlbGxpcHRpYyBjdXJ2ZSBncm91cHMgb3ZlciBzYWZlIGN1cnZlcyB3aXRoIHBy b3BlciBwb2ludA0KPj4gdmFsaWRhdGlvbi7igJ0NCj4NCj5JIGFtIG5vdCBzdXJlIHRoYXQgdGhl IHJlY29tbWVuZGF0aW9ucyBvZiB0aGlzIHBhcGVyIHNob3VsZCBiZSBibGluZGx5DQo+dHJ1c3Rl ZC4gVGhlcmUgYXJlIHNvbWUgaW5hY2N1cmF0ZSBmYWN0cyBhYm91dCBhIGxpYnJhcnkgSSB3b3Jr IG9uDQo+WzBdLCBidXQgYSBwYXJ0IG9mIHRoZSBhYnN0cmFjdCBpcyBhbHNvIGNvbmNlcm5pbmc6 DQo+IldlIGV4YW1pbmUgb3ZlciAyMCBvcGVuLXNvdXJjZSBjcnlwdG9ncmFwaGljIGxpYnJhcmll cyBhbmQNCj5hcHBsaWNhdGlvbnMgYW5kIG9ic2VydmUgdGhhdCB1bnRpbCBKYW51YXJ5IDIwMTYs IG5vdCBhIHNpbmdsZSBvbmUNCj52YWxpZGF0ZWQgc3ViZ3JvdXAgb3JkZXJzIGJ5IGRlZmF1bHQu Ig0KPg0KPlRoYXQncyBvYmplY3RpdmVseSBhY2N1cmF0ZSwgYnV0IHRoZSBhdXRob3JzIGRvIG5v dCBhdHRlbXB0IHRvIGZpbmQNCj5vdXQgdGhlIGFjdHVhbCBpc3N1ZSBiZWhpbmQgaXQuIEFyZSBh bGwgaW1wbGVtZW50YXRpb25zIGJhZCwgb3IgdGhlcmUNCj5hcmUgb2JzdGFjbGVzIGluIGRvaW5n IHRoYXQ/IEkgYW0gYXdhcmUgdGhhdCBUTFMgY2xpZW50DQo+aW1wbGVtZW50YXRpb25zIGRvIG5v dCB2YWxpZGF0ZSBzdWJncm91cCBvcmRlcnMgYnkgZGVmYXVsdCwgYmVjYXVzZQ0KPnRoZSBncm91 cCBpbmZvcm1hdGlvbiBwcm92aWRlZCBieSBUTFMgaXMgbm90IHN1ZmZpY2llbnQgdG8gdmFsaWRh dGUNCj50aGUgc3ViZ3JvdXAgb3JkZXIuIEl0IGlzIHNpbXBseSBpbXBvc3NpYmxlIGZvciB0aGVt IHRvIGRvIGFueQ0KPnZhbGlkYXRpb24uDQo+DQo+cmVnYXJkcywNCj5OaWtvcw0KPg0KPlswXS4g DQo+aHR0cHM6Ly9saXN0cy5nbnVwZy5vcmcvcGlwZXJtYWlsL2dudXRscy1kZXZlbC8yMDE2LU9j dG9iZXIvMDA4MTk4Lmh0bWwNCg0K From nobody Wed Oct 19 17:14:03 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63FD2129482; Wed, 19 Oct 2016 17:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.631 X-Spam-Level: X-Spam-Status: No, score=-4.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIILhSN-qSGf; Wed, 19 Oct 2016 17:13:53 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13530129454; Wed, 19 Oct 2016 17:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1476922432; x=1508458432; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7jnjkGM8SXztNQqASvFANc+VOjq3S978qdzlKjjG9Ug=; b=4jyXTUPD28MqkOHTzL+1tokb6qiHnKZ+C6/MmHtiwMbOXBmbqeTe4TaS 3lA9f2lSIM0f/TCaVRqDt4TziJfFOLuDWqDFHjMyMukbJc48UDwfjaaZF jDBCVmc3Ys+lOQn8/uXfTOcHFB57Qdxxo7gjXBQvd2Id4x80A8dP6IMO0 JtIUj/jA68xmhJSUvK0dqMeBd04r5pcsKC4eonTp21pUtQCmuitY/Aojz BBYDoMLsgXLW78G+y1kWEPW0dWzwctx2jr2GOUWt0Y/hWXoHwBx6hpapm 0wGtMYebvZufBJuer/js1X+OfKo/XdA9DzjRaXCMC8O4dl4lbAwq6UBpl w==; X-IronPort-AV: E=Sophos;i="5.31,516,1473076800"; d="scan'208";a="111224825" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.3 - Outgoing - Outgoing Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-ogg-b.UoA.auckland.ac.nz) ([10.6.2.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 20 Oct 2016 13:13:47 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-b.UoA.auckland.ac.nz (10.6.2.3) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 20 Oct 2016 13:13:47 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Thu, 20 Oct 2016 13:13:47 +1300 From: Peter Gutmann To: Nikos Mavrogiannopoulos , John Mattsson Thread-Topic: [saag] [IPsec] trapdoor'ed DH (and RFC-5114 again) Thread-Index: AQHSKduZ6MYx3bG8KE+aYJga50a7EKCweBnM Date: Thu, 20 Oct 2016 00:13:46 +0000 Message-ID: <1476922421060.41042@cs.auckland.ac.nz> References: <8C717FB2-DDC2-452E-AEC3-115B1E1397CF@gmail.com> <551e6c5c-0db7-62d5-da31-b99f26475010@bbn.com> , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org WG" , Paul Wouters , Security Area Advisory Group Subject: Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 00:13:57 -0000 Nikos Mavrogiannopoulos writes:=0A= =0A= >I am not sure that the recommendations of this paper should be blindly=0A= >trusted. There are some inaccurate facts about a library I work on [0], bu= t a=0A= >part of the abstract is also concerning: "We examine over 20 open-source= =0A= >cryptographic libraries and applications and observe that until January 20= 16,=0A= >not a single one validated subgroup orders by default."=0A= =0A= I've got some comments on it as well, are any of the authors on this list?= =0A= There are no email addresses given in the paper and I'm not sure that I sho= uld=0A= be spamming them all, or at least the ones I know... in any case the commen= ts=0A= may be of interest to others, so I've posted them here.=0A= =0A= Using shorter private exponents yields faster exponentiation times, and i= s a=0A= commonly implemented optimization. The justification for matching the ord= er=0A= of the subgroup q to the exponent size rather than making subgroup order = as=0A= large as possible is not documented anywhere in the standards documents.= =0A= =0A= It's not in any standards doc, but it's in HAC AFAIK, and originally came f= rom=0A= a paper by van Oorschot and Wiener. My code uses a curve-fitting mechanism= to=0A= choose the appropriate-size exponent for a given prime (implementation=0A= provided by Colin Plumb many years ago). Calling it a quadratic curve=0A= calculation is probably over-selling it a bit, it's just a way of matching = the=0A= exponent size to the prime size without having to include a large lookup=0A= table.=0A= =0A= For protocols like TLS and SSH that allow a server to unilaterally specif= y=0A= the group to use, this validation step is not possible for clients to=0A= perform for non-safe primes: there is no way for the server to communicat= e=0A= to the client the intended order of the group=0A= =0A= Actually it is for TLS, anything implementing the TLS-LTS draft [1] will=0A= communicate the group order and the client can then verify it.=0A= =0A= We observe that no implementation that we examined validated group order = for=0A= subgroups of order larger than two=0A= =0A= That's kind of a tautology there, both TLS and SSH make this impossible to = do.=0A= At the moment there's at least one implementation that does this, and possi= bly=0A= more (there are some proprietary vendor stacks doing -LTS, but since they'r= e=0A= for embedded devices and tend to be as minimalistic as possible - the most= =0A= popular ASN.1 library there is memcpy() - I wouldn't be surprised if they= =0A= skipped this particular check). So there's a minimum of one, and a maximum= of=0A= n.=0A= =0A= In addition, we observed that nearly every implementation uses short=0A= exponents by default,=0A= =0A= Yep, because they're the most efficient. This is what killed RFC 5114,=0A= they're the most inefficient (random) DH domain parameters ever published.= =0A= Which, in the long run, was probably a good thing since it strongly=0A= discouraged their use.=0A= =0A= They have been widely implemented in IPsec and TLS=0A= =0A= Not in TLS they ain't, for the reason given above. I realise there are=0A= oddball implementations out there that use or enable their use, but I would= n't=0A= say that counts as "widely used".=0A= =0A= This means a client has no feasible way to validate that the group sent b= y=0A= the server has the desired level of security or that a server=92s key exc= hange=0A= value is in the correct group for a non-safe prime.=0A= =0A= See the previous note, TLS-LTS provides this capability. If you're using t= he=0A= RFC 3526 DH params then you can also pretty easily recreate q from them, so= =0A= it's a simple change to apply this fix.=0A= =0A= (TLS-LTS also fixes a number of other issues in TLS 1.2 and earlier, it's n= ot=0A= only the DH fix that's in there).=0A= =0A= TABLE II: TLS Library Behavior=0A= =0A= I assume this was the item that Nikos was grumbling about :-). The two iss= ues=0A= are that the "Reuses exponent" entries are rather unclear and "Validates=0A= Subgroup" is somewhat tautological since standard TLS (without -LTS) doesn'= t=0A= allow you to do this, so the anwer is always "No". I assume for "Reuses=0A= exponent" the entry "Application dependent" means "it's not very clear from= =0A= the code", because my code certainly never reuses DH exponents. However, t= o=0A= see that you need to know that although each DH instance uses an { x, y } p= air=0A= that's fixed at the time of creation, no DH instance is ever reused in a TL= S=0A= or SSH session,=0A= =0A= (Nikos, if you want to do the subgroup checking with GnuTLS and interop-tes= t=0A= an implementation that provides subgroup info and does the required checkin= g,=0A= let me know and I'll put up a server. Same for anyone else, e.g. the OpenS= SL=0A= guys).=0A= =0A= implementations should follow the guidelines outlined in RFC 7919 for=0A= selecting finite field Diffie-Hellman primes=0A= =0A= Uh, no. 7919 is a my-way-or-the-highway spec, or more accurately my-way-or= -=0A= no-way. You can't say "I'd like to do DH-2048" as with SSH, you can only u= se=0A= the one value that 7919 specifies and if either side chooses some other=0A= DH-2048 value you're required to fall back to RSA. When this was discussed= on=0A= the TLS list, the general response, from those who commented, was that they= =0A= weren't going to use it because of this and other problems it had. Some of= =0A= these issues were brought up long ago (e.g. [2]), but ignored. So 7919 is= =0A= pretty much a non-starter.=0A= =0A= implementations should prefer =93safe=94 primes of documented provenance = of at=0A= least 2048 bit=0A= =0A= This is unfortunately easier to recommend than to do. For example my code= =0A= (and some other implementations I know of) recognise and fastpath known-goo= d=0A= values like the RFC 3526 ones, but you can't restrict yourself to only usin= g=0A= known-good values because too many sites use who-knows-what sort of values,= =0A= and you'd lose the ability to connect to a significant chunk of the net if = you=0A= get too exclusive.=0A= =0A= The real solution, and obviously I'm a bit biased here because I'm the auth= or=0A= (but then it was also an obvious problem that needed fixing), is to use -LT= S,=0A= which provides what you need to validate the DH parameters.=0A= =0A= Peter.=0A= =0A= [0] Not my footnote.=0A= [1] https://datatracker.ietf.org/doc/draft-gutmann-tls-lts.=0A= [2] https://www.ietf.org/mail-archive/web/tls/current/msg18697.html.=0A= From nobody Thu Oct 20 00:44:49 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87096129878 for ; Thu, 20 Oct 2016 00:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEEtIn664W9d for ; Thu, 20 Oct 2016 00:44:46 -0700 (PDT) Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC1E129427 for ; Thu, 20 Oct 2016 00:44:45 -0700 (PDT) Received: from TobiLenovo (ObiWan2.nm.ifi.lmu.de [141.84.218.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: guggemos.tobias.nm) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id 519B794A325; Thu, 20 Oct 2016 09:44:44 +0200 (CEST) From: "Tobias Guggemos" To: "'Valery Smyslov'" , "Daniel Migault" , "IPsecME WG" References: <147594692832.28921.7850239516371972090.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C117F98570@eusaamb107.ericsson.se> In-Reply-To: Date: Thu, 20 Oct 2016 09:44:45 +0200 Message-ID: <001e01d22aa5$d3ebc4a0$7bc34de0$@mnm-team.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHSIsTPc0J4zAXjlkKN6omZRo+LMaCxAzfw Content-Language: de Archived-At: Subject: Re: [IPsec] FW: New Version Notification fordraft-mglt-ipsecme-implicit-iv-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 07:44:48 -0000 Hey Valery, Thanks for the clarification, we'll add this statement in the draft! Just because I'm interested: For me, this seems to be a general problem = for implementing counter ciphers in multicast scenarios, regardless of implicit-iv or not.=20 Do you know how the IV is usually chosen in multicast-implementations?=20 Maybe we could add a recommendation in the draft. Thanks Tobias -----Urspr=FCngliche Nachricht----- Von: IPsec [mailto:ipsec-bounces@ietf.org] Im Auftrag von Valery Smyslov Gesendet: Montag, 10. Oktober 2016 09:06 An: Daniel Migault ; IPsecME WG Betreff: Re: [IPsec] FW: New Version Notification fordraft-mglt-ipsecme-implicit-iv-01.txt Hi Daniel, I think you should add a text in the Security Considerations that these transforms MUST NOT be used in situations where there is a chance that Sequence Numbers repeat. The most prominent example where it can happen = - multicast ESP SA with multiple senders. Regards, Valery. > Hi, > > Based on the feed backs and the discussions from the previous IETF,=20 > see the updated version of our draft. We believe the document is in = good shape to become a WG document. > > Feel free to support the draft and as usually, comments are welcome! > > BR, > Daniel > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Saturday, October 08, 2016 7:15 PM > To: Tobias Guggemos ; Yoav Nir=20 > ; Daniel Migault > Subject: New Version Notification for=20 > draft-mglt-ipsecme-implicit-iv-01.txt > > > A new version of I-D, draft-mglt-ipsecme-implicit-iv-01.txt > has been successfully submitted by Daniel Migault and posted to the = IETF repository. > > Name: draft-mglt-ipsecme-implicit-iv > Revision: 01 > Title: Implicit IV for Counter-based Ciphers in IPsec Document date:=20 > 2016-10-08 > Group: Individual Submission > Pages: 6 > URL: https://www.ietf.org/internet-drafts/draft-mglt-ipsecme-implicit-iv-01.tx= t > Status: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ > Htmlized: https://tools.ietf.org/html/draft-mglt-ipsecme-implicit-iv-01 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-mglt-ipsecme-implicit-iv-01 > > Abstract: > IPsec ESP sends an initialization vector (IV) or nonce in each > packet, adding 8 or 16 octets. Some algorithms such as AES-GCM, = AES- > CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not > require an unpredictable nonce. When using such algorithms the > packet counter value can be used to generate a nonce, saving 8 = octets > per packet. This document describes how to do this. > > > > > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Oct 20 01:16:02 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11191294D6 for ; Thu, 20 Oct 2016 01:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.899 X-Spam-Level: X-Spam-Status: No, score=0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.599, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APuPr45hSrut for ; Thu, 20 Oct 2016 01:15:59 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9DBD129540 for ; Thu, 20 Oct 2016 01:15:58 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id l131so67735648lfl.2 for ; Thu, 20 Oct 2016 01:15:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=Lg+s/1/9Maf+Vjpk+HCCkYN4heNC6nJ90fN7sgzxBVk=; b=Zs/4mbOL8mr1k14kyuv47cKvbKHjJf3dNhCty4IRo7nL+MNMIN0CoqB5jwGGksD23g 6pmfx8yGkKp/XnO5oxMSsCYzNDaWSxcShsWbvKce4Cu27Sdvzqz8rWJqk7YcXU3uzp7j rzJOu3JFonHmyVwXl2KXg0scOz3FCsGeat+oJRtpwdrOxe7boTu7TE14O3ug/gMrlKRk 7MxC6Kq0RCER1VKTk6uQIKVadtx9BPPIh2IL8T3rgt4uVbt7tslkal9LpGizMTJDnpq0 /nZuSyVeuTA5oOPlXAqzeCM4vD75zl3FOc5DI3lXIhy2mLwV5ljaCbgfZQJu9PhDj6WH 34ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=Lg+s/1/9Maf+Vjpk+HCCkYN4heNC6nJ90fN7sgzxBVk=; b=jya7xmUVpB/iWHjOogfGrYMrKhe+QSQi01jeyMKwA1hezUbCI6XQ5qdAU1kO9hiCn1 yr6U7ZRHfNnpViQrp+00kivRu+frSe/ZkjW+sZCHBZGeS21ZUURbG1OPmMgt9VCJCyA/ AAPTB9YxWOpfyIIMwbqlF1WUtbnHi17pf/+MjffeQo4hso5RleIEK9guUBtD3qV9E6sN /iQzUz2QWUPjzSlJ3AUVyN0WkliwBF/mvbhWZlxar1t0GERmrVN0pS/csCGbPO33zSzq dAF3q0N0TxHqLe0ghDqlrpHBW2yuRhV8UNAyjztzOfkV4saAp6l/PRSU6Ad4dRSnJj+3 yurQ== X-Gm-Message-State: AA6/9RmdWPI18FFG796H6ZezL53YjNVnzh0iTPY5RsPz5vYeOH/iBvVumh5SxPXqZs3PQA== X-Received: by 10.25.39.15 with SMTP id n15mr9418768lfn.91.1476951354739; Thu, 20 Oct 2016 01:15:54 -0700 (PDT) Received: from svanPC ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id o77sm492483lff.21.2016.10.20.01.15.53 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 20 Oct 2016 01:15:54 -0700 (PDT) From: "Valery Smyslov" To: "'Tobias Guggemos'" , "'Daniel Migault'" , "'IPsecME WG'" References: <147594692832.28921.7850239516371972090.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C117F98570@eusaamb107.ericsson.se> <001e01d22aa5$d3ebc4a0$7bc34de0$@mnm-team.org> In-Reply-To: <001e01d22aa5$d3ebc4a0$7bc34de0$@mnm-team.org> Date: Thu, 20 Oct 2016 11:15:32 +0300 Message-ID: <00e001d22aaa$20e01910$62a04b30$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMujZjKyFM1eyZtntAB2Ojf4WSB5wH0L881Ak+afe0CSBmo+J3D1syw Content-Language: ru Archived-At: Subject: Re: [IPsec] FW: New Version Notification fordraft-mglt-ipsecme-implicit-iv-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 08:16:01 -0000 Hi Tobias, > Hey Valery, > Thanks for the clarification, we'll add this statement in the draft! Thank you. > Just because I'm interested: For me, this seems to be a general = problem for implementing counter ciphers > in multicast scenarios, regardless of implicit-iv or not. > Do you know how the IV is usually chosen in multicast-implementations? The Group Controller assigns each sender a unique counter prefix. See = Section 3.5 of RFC 6407. Regards, Valery. > Maybe we could add a recommendation in the draft. >=20 > Thanks > Tobias >=20 >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: IPsec [mailto:ipsec-bounces@ietf.org] Im Auftrag von Valery = Smyslov > Gesendet: Montag, 10. Oktober 2016 09:06 > An: Daniel Migault ; IPsecME WG = > Betreff: Re: [IPsec] FW: New Version Notification = fordraft-mglt-ipsecme-implicit-iv-01.txt >=20 > Hi Daniel, >=20 > I think you should add a text in the Security Considerations that = these transforms MUST NOT be used in > situations where there is a chance that Sequence Numbers repeat. The = most prominent example where it > can happen - multicast ESP SA with multiple senders. >=20 > Regards, > Valery. >=20 >=20 > > Hi, > > > > Based on the feed backs and the discussions from the previous IETF, > > see the updated version of our draft. We believe the document is in > > good > shape to become a WG document. > > > > Feel free to support the draft and as usually, comments are welcome! > > > > BR, > > Daniel > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Saturday, October 08, 2016 7:15 PM > > To: Tobias Guggemos ; Yoav Nir > > ; Daniel Migault > > Subject: New Version Notification for > > draft-mglt-ipsecme-implicit-iv-01.txt > > > > > > A new version of I-D, draft-mglt-ipsecme-implicit-iv-01.txt > > has been successfully submitted by Daniel Migault and posted to the > > IETF > repository. > > > > Name: draft-mglt-ipsecme-implicit-iv > > Revision: 01 > > Title: Implicit IV for Counter-based Ciphers in IPsec Document date: > > 2016-10-08 > > Group: Individual Submission > > Pages: 6 > > URL: > = https://www.ietf.org/internet-drafts/draft-mglt-ipsecme-implicit-iv-01.tx= t > > Status: > https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ > > Htmlized: > https://tools.ietf.org/html/draft-mglt-ipsecme-implicit-iv-01 > > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-mglt-ipsecme-implicit-iv-01 > > > > Abstract: > > IPsec ESP sends an initialization vector (IV) or nonce in each > > packet, adding 8 or 16 octets. Some algorithms such as AES-GCM, = AES- > > CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do = not > > require an unpredictable nonce. When using such algorithms the > > packet counter value can be used to generate a nonce, saving 8 = octets > > per packet. This document describes how to do this. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > The IETF Secretariat > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Oct 20 01:18:31 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69CF129540; Thu, 20 Oct 2016 01:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=adobe.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g10qeixSSvZe; Thu, 20 Oct 2016 01:18:22 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0046.outbound.protection.outlook.com [104.47.36.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72AD11293F8; Thu, 20 Oct 2016 01:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adobe.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=69sN8xMJZa4DZG4UdYegRQzbD5+VqRpyXmStJS2cfoM=; b=VJQVpoS8goSec1ZmOIHFj+1nBoneI9dLek/Nrv6UusU52TfTYC5aPtnFOL0lousZa9OypCpdzbk8bBI0O/bf1nmywA7nCqH9sXJ303j2XV53Da6+KOzvlD35gy5Rt26sXoKGJf28tweFKtLeWmvvMrU2ID3uZo4wEOkTriRABIA= Received: from BY1PR0201MB1030.namprd02.prod.outlook.com (10.161.203.148) by BY1PR0201MB1032.namprd02.prod.outlook.com (10.161.203.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Thu, 20 Oct 2016 08:18:20 +0000 Received: from BY1PR0201MB1030.namprd02.prod.outlook.com ([10.161.203.148]) by BY1PR0201MB1030.namprd02.prod.outlook.com ([10.161.203.148]) with mapi id 15.01.0659.025; Thu, 20 Oct 2016 08:18:20 +0000 From: Antonio Sanso To: Peter Gutmann Thread-Topic: [saag] [IPsec] trapdoor'ed DH (and RFC-5114 again) Thread-Index: AQHSKduU/0Rej7lBOUG2WHjBaRnjnaCwee4AgACHZ4A= Date: Thu, 20 Oct 2016 08:18:19 +0000 Message-ID: References: <8C717FB2-DDC2-452E-AEC3-115B1E1397CF@gmail.com> <551e6c5c-0db7-62d5-da31-b99f26475010@bbn.com> , <1476922421060.41042@cs.auckland.ac.nz> In-Reply-To: <1476922421060.41042@cs.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=asanso@adobe.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [192.147.117.11] x-ms-office365-filtering-correlation-id: 2d3ae1db-f52a-46c8-543a-08d3f8c1a6e3 x-microsoft-exchange-diagnostics: 1; BY1PR0201MB1032; 7:yxAExWYBdOpewbOWilnZG8EBuofEDfEYVpw4y9xe0oEyigbjplt8jQ/B9z+ylP+fgao3zrjr81Qqbqqd1d8EqesR9kjug+QHKjE4csyGXjhaR1XEZP35ICqRPqYqnc05ubkWfwufKiVwv+ZGrBlMn7xHH4yLYn8g0JKfdjcr13yBi2RALbayjDOIBX36Cw/oOGkZImHOqKh7CyT2gTh0VkI3VWvh70aydq5DDVJpQnqMbsSRZHoJAsHLJwWWpFyimFIQXBu0v+Vl0kR9RGxHZcaH4MeyZ4sbUYvdglzMgCP8g+tnJn58LSvgV1meWufPZLWI60Hb7gC4Hzx0pga3/B9oR1mtHyQU0t9bJvKBDGM=; 20:n6hb/0sZMR6IJAVp9COONLCFx9/uy4lfH4WSu2Bc9rQmS9BV/+q1qjjLyyEYFKSVyWlMYwdKkECqYYtUwdfgn9e7Qdhh7vLCbkHKDWqDdR/d5U8OtD2MN/+UgBjmq1qUGL+GJRWhf6+PQCeV2HCM6JDpAeJ91W4RKX/54YK+mlI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB1032; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(278428928389397)(120809045254105)(192374486261705)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BY1PR0201MB1032; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0201MB1032; x-forefront-prvs: 01018CB5B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(377454003)(24454002)(199003)(586003)(101416001)(3846002)(8676002)(87936001)(10090500001)(5002640100001)(77096005)(15975445007)(7736002)(81156014)(7846002)(54356999)(33656002)(92566002)(6916009)(5660300001)(50986999)(305945005)(3660700001)(2950100002)(93886004)(122556002)(3280700002)(106116001)(105586002)(36756003)(76176999)(19580405001)(81166006)(83716003)(8936002)(106356001)(19580395003)(66066001)(6116002)(102836003)(97736004)(99286002)(189998001)(68736007)(4326007)(86362001)(2906002)(2900100001)(82746002)(10400500002)(110136003)(11100500001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0201MB1032; H:BY1PR0201MB1030.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-ID: <659BC7680B462945945A8A276F19C0A7@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2016 08:18:19.9492 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0201MB1032 Archived-At: Cc: "ipsec@ietf.org WG" , Paul Wouters , Security Area Advisory Group , Nikos Mavrogiannopoulos , John Mattsson Subject: Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 08:18:26 -0000 hi Peter, (one of the authors here) thanks a lot for you comments. As for the case with Nikos we take on board and well appreciate comments/fe= edbacks. Will pass the message. Thanks a lot and regards antonio On Oct 20, 2016, at 2:13 AM, Peter Gutmann wrot= e: > Nikos Mavrogiannopoulos writes: >=20 >> I am not sure that the recommendations of this paper should be blindly >> trusted. There are some inaccurate facts about a library I work on [0], = but a >> part of the abstract is also concerning: "We examine over 20 open-source >> cryptographic libraries and applications and observe that until January = 2016, >> not a single one validated subgroup orders by default." >=20 > I've got some comments on it as well, are any of the authors on this list= ? > There are no email addresses given in the paper and I'm not sure that I s= hould > be spamming them all, or at least the ones I know... in any case the comm= ents > may be of interest to others, so I've posted them here. >=20 > Using shorter private exponents yields faster exponentiation times, and = is a > commonly implemented optimization. The justification for matching the or= der > of the subgroup q to the exponent size rather than making subgroup order= as > large as possible is not documented anywhere in the standards documents. >=20 > It's not in any standards doc, but it's in HAC AFAIK, and originally came= from > a paper by van Oorschot and Wiener. My code uses a curve-fitting mechani= sm to > choose the appropriate-size exponent for a given prime (implementation > provided by Colin Plumb many years ago). Calling it a quadratic curve > calculation is probably over-selling it a bit, it's just a way of matchin= g the > exponent size to the prime size without having to include a large lookup > table. >=20 > For protocols like TLS and SSH that allow a server to unilaterally speci= fy > the group to use, this validation step is not possible for clients to > perform for non-safe primes: there is no way for the server to communica= te > to the client the intended order of the group >=20 > Actually it is for TLS, anything implementing the TLS-LTS draft [1] will > communicate the group order and the client can then verify it. >=20 > We observe that no implementation that we examined validated group order= for > subgroups of order larger than two >=20 > That's kind of a tautology there, both TLS and SSH make this impossible t= o do. > At the moment there's at least one implementation that does this, and pos= sibly > more (there are some proprietary vendor stacks doing -LTS, but since they= 're > for embedded devices and tend to be as minimalistic as possible - the mos= t > popular ASN.1 library there is memcpy() - I wouldn't be surprised if they > skipped this particular check). So there's a minimum of one, and a maxim= um of > n. >=20 > In addition, we observed that nearly every implementation uses short > exponents by default, >=20 > Yep, because they're the most efficient. This is what killed RFC 5114, > they're the most inefficient (random) DH domain parameters ever published= . > Which, in the long run, was probably a good thing since it strongly > discouraged their use. >=20 > They have been widely implemented in IPsec and TLS >=20 > Not in TLS they ain't, for the reason given above. I realise there are > oddball implementations out there that use or enable their use, but I wou= ldn't > say that counts as "widely used". >=20 > This means a client has no feasible way to validate that the group sent = by > the server has the desired level of security or that a server=92s key ex= change > value is in the correct group for a non-safe prime. >=20 > See the previous note, TLS-LTS provides this capability. If you're using= the > RFC 3526 DH params then you can also pretty easily recreate q from them, = so > it's a simple change to apply this fix. >=20 > (TLS-LTS also fixes a number of other issues in TLS 1.2 and earlier, it's= not > only the DH fix that's in there). >=20 > TABLE II: TLS Library Behavior >=20 > I assume this was the item that Nikos was grumbling about :-). The two i= ssues > are that the "Reuses exponent" entries are rather unclear and "Validates > Subgroup" is somewhat tautological since standard TLS (without -LTS) does= n't > allow you to do this, so the anwer is always "No". I assume for "Reuses > exponent" the entry "Application dependent" means "it's not very clear fr= om > the code", because my code certainly never reuses DH exponents. However,= to > see that you need to know that although each DH instance uses an { x, y }= pair > that's fixed at the time of creation, no DH instance is ever reused in a = TLS > or SSH session, >=20 > (Nikos, if you want to do the subgroup checking with GnuTLS and interop-t= est > an implementation that provides subgroup info and does the required check= ing, > let me know and I'll put up a server. Same for anyone else, e.g. the Ope= nSSL > guys). >=20 > implementations should follow the guidelines outlined in RFC 7919 for > selecting finite field Diffie-Hellman primes >=20 > Uh, no. 7919 is a my-way-or-the-highway spec, or more accurately my-way-= or- > no-way. You can't say "I'd like to do DH-2048" as with SSH, you can only= use > the one value that 7919 specifies and if either side chooses some other > DH-2048 value you're required to fall back to RSA. When this was discuss= ed on > the TLS list, the general response, from those who commented, was that th= ey > weren't going to use it because of this and other problems it had. Some = of > these issues were brought up long ago (e.g. [2]), but ignored. So 7919 i= s > pretty much a non-starter. >=20 > implementations should prefer =93safe=94 primes of documented provenance= of at > least 2048 bit >=20 > This is unfortunately easier to recommend than to do. For example my cod= e > (and some other implementations I know of) recognise and fastpath known-g= ood > values like the RFC 3526 ones, but you can't restrict yourself to only us= ing > known-good values because too many sites use who-knows-what sort of value= s, > and you'd lose the ability to connect to a significant chunk of the net i= f you > get too exclusive. >=20 > The real solution, and obviously I'm a bit biased here because I'm the au= thor > (but then it was also an obvious problem that needed fixing), is to use -= LTS, > which provides what you need to validate the DH parameters. >=20 > Peter. >=20 > [0] Not my footnote. > [1] https://datatracker.ietf.org/doc/draft-gutmann-tls-lts. > [2] https://www.ietf.org/mail-archive/web/tls/current/msg18697.html. >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Thu Oct 20 11:41:07 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D734A1295B1; Thu, 20 Oct 2016 11:41:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147698886187.18123.8815573364247477008.idtracker@ietfa.amsl.com> Date: Thu, 20 Oct 2016 11:41:01 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-15.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 18:41:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : Algorithm Implementation Requirements and Usage Guidance for IKEv2 Authors : Yoav Nir Tero Kivinen Paul Wouters Daniel Migault Filename : draft-ietf-ipsecme-rfc4307bis-15.txt Pages : 18 Date : 2016-10-20 Abstract: The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document updates RFC 7296 and obsoletes RFC 4307 in defining the current algorithm implementation requirements and usage guidance for IKEv2, and does minor cleaning up of the IKEv2 IANA registry. This document does not update the algorithms used for packet encryption using IPsec Encapsulated Security Payload (ESP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 20 11:43:52 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554951295B1 for ; Thu, 20 Oct 2016 11:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 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.431] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJwLZML069Dl for ; Thu, 20 Oct 2016 11:43:49 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1230F129584 for ; Thu, 20 Oct 2016 11:43:49 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3t0Hl66pjTz39k for ; Thu, 20 Oct 2016 20:43:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1476989026; bh=IphfMc0tIPXCKQSCGTPA8I0DfYlFT5637cirB98CpV8=; h=Date:From:To:Subject:In-Reply-To:References; b=OSzKl9rrWbM4KP9pW0YdRj29XCSF5cY14WoVUC8Jcn3zhYMJzUzoWfKyOYppn9r+c kCtfh54c/Ur8J4SiI4IpzCyw/RauMCYmpsTlzOTWI03VT947fMoxUXqq89MqqbT9nw T4xXKefq8zoA+lGHZjdDlOF0L8wKwBCQFcSWzqhA= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id g8k8L1b9lZjx for ; Thu, 20 Oct 2016 20:43:44 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Thu, 20 Oct 2016 20:43:44 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id F35864CA652; Thu, 20 Oct 2016 14:43:41 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca F35864CA652 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DA78040DAA3D for ; Thu, 20 Oct 2016 14:43:41 -0400 (EDT) Date: Thu, 20 Oct 2016 14:43:41 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: <147698886187.18123.8815573364247477008.idtracker@ietfa.amsl.com> Message-ID: References: <147698886187.18123.8815573364247477008.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-15.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 18:43:50 -0000 On Thu, 20 Oct 2016, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Security Maintenance and Extensions of the IETF. > > Title : Algorithm Implementation Requirements and Usage Guidance for IKEv2 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-15 The only change in this version is based on discussion on saag and ipsecme, where there was consensus to change DH Group 22 from SHOULD NOT to MUST NOT. DH 23 and 24 remain at SHOULD NOT and retain their warning they will move to MUST NOT in the near future. Paul From nobody Thu Oct 20 14:43:15 2016 Return-Path: X-Original-To: expand-draft-ietf-ipsecme-safecurves.all@virtual.ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 41644129484; Thu, 20 Oct 2016 14:43:14 -0700 (PDT) X-Original-To: xfilter-draft-ietf-ipsecme-safecurves.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-ipsecme-safecurves.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143751295A3 for ; Thu, 20 Oct 2016 14:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.63 X-Spam-Level: X-Spam-Status: No, score=-3.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvk0iech0q1P for ; Thu, 20 Oct 2016 14:43:12 -0700 (PDT) Received: from smtp01.icann.org (smtp01.icann.org [192.0.46.81]) (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 BAE7F129484 for ; Thu, 20 Oct 2016 14:43:12 -0700 (PDT) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (Postfix) with ESMTP id 082CDE173C for ; Thu, 20 Oct 2016 21:43:12 +0000 (UTC) Received: by request3.lax.icann.org (Postfix, from userid 48) id BBBA1C20266; Thu, 20 Oct 2016 21:43:11 +0000 (UTC) RT-Owner: amanda.baber From: "Amanda Baber via RT" In-Reply-To: <147672722073.4523.16815334159940258739.idtracker@ietfa.amsl.com> References: <147672722073.4523.16815334159940258739.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #932374 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Thu, 20 Oct 2016 21:43:11 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Resent-From: Resent-To: ynir.ietf@gmail.com, simon@josefsson.org, david.waltermire@nist.gov, kivinen@iki.fi, Kathleen.Moriarty.ietf@gmail.com, stephen.farrell@cs.tcd.ie, "Tero Kivinen" , ipsec@ietf.org Resent-Message-Id: <20161020214314.41644129484@ietfa.amsl.com> Resent-Date: Thu, 20 Oct 2016 14:43:14 -0700 (PDT) Archived-At: Cc: draft-ietf-ipsecme-safecurves.all@ietf.org Subject: [IPsec] [IANA #932374] Protocol Action: 'Curve25519 and Curve448 for IKEv2 Key Agreement' to Proposed Standard (draft-ietf-ipsecme-safecurves-05.txt) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Reply-To: drafts-approval@iana.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 21:43:14 -0000 Dear Authors: ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED We've completed the registry actions for the following RFC-to-be: draft-ietf-ipsecme-safecurves-05 We've added the following entries to the Transform Type 4 - Diffie-Hellman Group Transform ID registry: Number Name Recipient Tests Reference 31 Curve25519 [RFC-ietf-ipsecme-safecurves-05], Sec. 3.2 [RFC-ietf-ipsecme-safecurves-05] 32 Curve448 [RFC-ietf-ipsecme-safecurves-05], Sec. 3.2 [RFC-ietf-ipsecme-safecurves-05] Please see http://www.iana.org/assignments/ikev2-parameters Please let us know whether the above registry actions have been completed correctly. As soon as we receive your confirmation, we'll notify the RFC Editor that this document's actions are complete. If the document has a team of authors, one reply on behalf of everyone will suffice. We'll update any references to this document in the registries when the RFC Editor notifies us that they've assigned an RFC number. Best regards, Amanda Baber Lead IANA Services Specialist PTI From nobody Thu Oct 20 14:50:03 2016 Return-Path: X-Original-To: expand-draft-ietf-ipsecme-safecurves.all@virtual.ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 8496C129489; Thu, 20 Oct 2016 14:50:01 -0700 (PDT) X-Original-To: xfilter-draft-ietf-ipsecme-safecurves.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-ipsecme-safecurves.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5267E1294F9 for ; Thu, 20 Oct 2016 14:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0o_4MlBGahs9 for ; Thu, 20 Oct 2016 14:49:59 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33AB1129489 for ; Thu, 20 Oct 2016 14:49:59 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id b75so104315793lfg.3 for ; Thu, 20 Oct 2016 14:49:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vTDO7HLVTRD7pPDN3/tuzf4m2yejhRzZpTZPRE2dWgo=; b=vh29/HkCV6xlhBqXB/YAP3VYaK9FzzzIQ1KCB3xTN+cwLtGlpAE3a1cyg0dUEeheP/ KeR1+FkFj7mCB4lrA2P+c4t4/7ILzdi0MmS25Yle3H5Yg/kxXXv2Uz0WG+geOwoUZVDA 7UT41RchJ12n2AvcSr12so7P5zi8+sSv68r4VMu+GivyFy+kW/TyCl0NzqIS0972YSQz p2o4R/wcWquyIEUXqAyfuTrAkhoTqngbwiOC8K9shW9K0cYdavdcFO2SZDNeApPFJ4yY ZRtUwIJxBcNC/8ShborepCopAzMhf+G9xG/CzGvmY/Z4ovV0MzKAUTNPRri0iY8gJC0c sbZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vTDO7HLVTRD7pPDN3/tuzf4m2yejhRzZpTZPRE2dWgo=; b=lYkjolYnh8G+ycb5J5Q3GDVciSFzWxxZ3KnpUR2DD1N/LnluZPXdDAwU4Wr6e6DtkZ Ey9+hi4wAlK+4PtiuJN8XiaaX3H8XOP3UhmVre6wM+mVNjbNDjj4cb73mGbErKGcX3Rl cY41QnKLSaq80Ggs22vhGfSsvKcruj9nKCKxBJF6bX2WgzJHeUvVmi5db/64hUzOe/k2 odGnw84mpKvEuxjkopQS4VwhYXruv6kfJibDsqghHGNcIJsuZBjoi/DvLwysiGDk9JVk /iehxTM0L4sRFq4IHs6yqMNJWeuuWAERKUsRgDkbxVljftlzrXjw7qCbsg+69bN0wyh9 QJfA== X-Gm-Message-State: ABUngveMx7I2NF3cAxAvl1qSz0k2EiLZgHA3q00htOjPnnnRWXzAAwiGX1XDeCz8NK7KDA== X-Received: by 10.194.200.39 with SMTP id jp7mr1617760wjc.64.1477000197249; Thu, 20 Oct 2016 14:49:57 -0700 (PDT) Received: from [10.99.22.49] ([5.148.94.149]) by smtp.gmail.com with ESMTPSA id 135sm704206wmq.8.2016.10.20.14.49.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Oct 2016 14:49:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Yoav Nir In-Reply-To: Date: Thu, 20 Oct 2016 22:49:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147672722073.4523.16815334159940258739.idtracker@ietfa.amsl.com> To: drafts-approval@iana.org X-Mailer: Apple Mail (2.3226) Resent-From: Resent-To: ynir.ietf@gmail.com, simon@josefsson.org, david.waltermire@nist.gov, kivinen@iki.fi, Kathleen.Moriarty.ietf@gmail.com, stephen.farrell@cs.tcd.ie, "Tero Kivinen" , ipsec@ietf.org Resent-Message-Id: <20161020215001.8496C129489@ietfa.amsl.com> Resent-Date: Thu, 20 Oct 2016 14:50:01 -0700 (PDT) Archived-At: Cc: draft-ietf-ipsecme-safecurves.all@ietf.org Subject: Re: [IPsec] [IANA #932374] Protocol Action: 'Curve25519 and Curve448 for IKEv2 Key Agreement' to Proposed Standard (draft-ietf-ipsecme-safecurves-05.txt) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 21:50:01 -0000 Hi, Amanda This seems correct. Thanks. Yoav > On 20 Oct 2016, at 22:43, Amanda Baber via RT = wrote: >=20 > Dear Authors: >=20 > ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED=20 >=20 > We've completed the registry actions for the following RFC-to-be: >=20 > draft-ietf-ipsecme-safecurves-05 >=20 > We've added the following entries to the Transform Type 4 - = Diffie-Hellman Group Transform ID registry: >=20 > Number Name Recipient Tests Reference=20 > 31 Curve25519 [RFC-ietf-ipsecme-safecurves-05], Sec. 3.2 = [RFC-ietf-ipsecme-safecurves-05] > 32 Curve448 [RFC-ietf-ipsecme-safecurves-05], Sec. 3.2 = [RFC-ietf-ipsecme-safecurves-05] >=20 > Please see > http://www.iana.org/assignments/ikev2-parameters >=20 > Please let us know whether the above registry actions have been = completed correctly. As soon as we receive your confirmation, we'll = notify the RFC Editor that this document's actions are complete. If the = document has a team of authors, one reply on behalf of everyone will = suffice. >=20 > We'll update any references to this document in the registries when = the RFC Editor notifies us that they've assigned an RFC number. >=20 > Best regards, >=20 > Amanda Baber > Lead IANA Services Specialist > PTI >=20 From nobody Thu Oct 20 15:05:08 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F151D1294E6; Thu, 20 Oct 2016 15:05:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , "Tero Kivinen" X-Test-IDTracker: no X-IETF-IDTracker: 6.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147700110498.6763.1088682372810613305.idtracker@ietfa.amsl.com> Date: Thu, 20 Oct 2016 15:05:04 -0700 From: IETF Secretariat Archived-At: Subject: [IPsec] ID Tracker State Update Notice: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 22:05:05 -0000 IANA action state changed to Waiting on Authors ID Tracker URL: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-safecurves/ From nobody Thu Oct 20 16:05:07 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 192F312940F; Thu, 20 Oct 2016 16:05:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , "Tero Kivinen" X-Test-IDTracker: no X-IETF-IDTracker: 6.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147700470607.8980.10410310169368243065.idtracker@ietfa.amsl.com> Date: Thu, 20 Oct 2016 16:05:06 -0700 From: IETF Secretariat Archived-At: Subject: [IPsec] ID Tracker State Update Notice: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 23:05:06 -0000 IANA action state changed to Waiting on RFC Editor ID Tracker URL: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-safecurves/ From nobody Thu Oct 20 17:05:06 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8F4127735; Thu, 20 Oct 2016 17:05:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , "Tero Kivinen" X-Test-IDTracker: no X-IETF-IDTracker: 6.35.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147700830562.11774.17791700290559240427.idtracker@ietfa.amsl.com> Date: Thu, 20 Oct 2016 17:05:05 -0700 From: IETF Secretariat Archived-At: Subject: [IPsec] ID Tracker State Update Notice: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 00:05:05 -0000 IANA action state changed to RFC-Ed-Ack ID Tracker URL: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-safecurves/ From nobody Fri Oct 21 16:24:59 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFB31298A1; Fri, 21 Oct 2016 16:21:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147709207358.28214.7887633677834306574.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2016 16:21:13 -0700 Archived-At: Cc: ipsec@ietf.org, Kathleen.Moriarty.ietf@gmail.com Subject: [IPsec] ipsecme - Requested session has been scheduled for IETF 97 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2016 23:21:13 -0000 Dear Tero Kivinen, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ipsecme Session 1 (1:30:00) Tuesday, Afternoon Session I 1330-1530 Room Name: Studio 2 size: 80 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: Tero Kivinen Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 30 Conflicts to Avoid: First Priority: cfrg saag tls curdle tcpinc mile sacm Second Priority: 6tisch lwig ace httpauth Third Priority: uta 6lo dane tcpm netmod Special Requests: --------------------------------------------------------- From nobody Sun Oct 23 04:33:12 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24B0128B44; Sun, 23 Oct 2016 04:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.631 X-Spam-Level: X-Spam-Status: No, score=-4.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.431] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1Zq4lMGjhxY; Sun, 23 Oct 2016 04:33:02 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D46AE129514; Sun, 23 Oct 2016 04:33:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1477222381; x=1508758381; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=RFzAzDOaa6r8i4fxreuHfuosL3oi+Qm0dSE/DjkxY50=; b=h8M4/hDgPTKf0sTmaM0eefQ91eezt6EznLS0GcjGcXiA5UcRcJVircHA mvVttM4RoVnhGw/EgdgZafA3hHKFDMyvKQ/rh+l86qiBXRhz0Hrpu5TnA ANfnYonL2v6bIzDqCgYCyzoMcQK2b4d2TApsjUp8SS1jMqjHwer0H/wvR 6yH01oPOUIlMPCbnBF89cITt3wO8UBysV0WQ6JoSfbAoAW+aU+bsYeDFG i0Xv8QPsXWaudNE3p1ZOPalw7WhmzozADQK1laCn1zdmg1pkNRSWIkJzj 4FRK9P9WT2gsNRY16jvzZvlRd41yXFa42FtX98+FkjUnFLS/rwSfZCxO8 A==; X-IronPort-AV: E=Sophos;i="5.31,388,1473076800"; d="scan'208";a="111623691" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.3 - Outgoing - Outgoing Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-tdc-b.UoA.auckland.ac.nz) ([10.6.3.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 24 Oct 2016 00:32:57 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-b.UoA.auckland.ac.nz (10.6.3.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 24 Oct 2016 00:32:57 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Mon, 24 Oct 2016 00:32:57 +1300 From: Peter Gutmann To: Paul Wouters , "ipsec@ietf.org WG" , Security Area Advisory Group Thread-Topic: [saag] Yet another RFC-5114 attack Thread-Index: AQHSKUf706LEkw7PNk+MbYj2YFBVsaC17m90 Date: Sun, 23 Oct 2016 11:32:56 +0000 Message-ID: <1477222363928.11089@cs.auckland.ac.nz> References: In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] [saag] Yet another RFC-5114 attack X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2016 11:33:08 -0000 And another one:=0A= =0A= http://eprint.iacr.org/2016/999.pdf=0A= =0A= Indiscreet Logs: Persistent Diffie-Hellman Backdoors in TLS=0A= =0A= Software implementations of discrete logarithm based cryptosystems over= =0A= finite fields typically make the assumption that any domain parameters th= ey=0A= are presented with are trustworthy, i.e., the parameters implement cyclic= =0A= groups where the discrete logarithm problem is assumed to be hard. An=0A= informal and widespread justification for this seemingly exists that says= =0A= validating parameters at run time is too computationally expensive relati= ve=0A= to the perceived risk of a server sabotaging the privacy of its own=0A= connection. In this paper we explore this trust assumption and examine=0A= situations where it may not always be justified.=0A= =0A= We conducted an investigation of discrete logarithm domain parameters in = use=0A= across the Internet and discovered evidence of a multitude of potentially= =0A= backdoored moduli of unknown order in TLS and STARTTLS spanning numerous= =0A= countries, organizations, and protocols. Although our disclosures resulte= d=0A= in a number of organizations taking down suspicious parameters, we argue = the=0A= potential for TLS backdoors is systematic and will persist until either= =0A= until better parameter hygiene is taken up by the community, or finite fi= eld=0A= based cryptography is eliminated altogether.=0A= =0A= This problem at least:=0A= =0A= No mechanism is provided in TLS to communicate group order=0A= =0A= is already fixed:=0A= =0A= https://datatracker.ietf.org/doc/draft-gutmann-tls-lts/=0A= =0A= Peter.= From nobody Mon Oct 24 02:44:41 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD8012967B for ; Mon, 24 Oct 2016 02:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYllMtbhbHUu for ; Mon, 24 Oct 2016 02:44:39 -0700 (PDT) Received: from mail.strongswan.org (sitav-80046.hsr.ch [152.96.80.46]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3151E129510 for ; Mon, 24 Oct 2016 02:44:38 -0700 (PDT) Received: from [152.96.214.79] (unknown [152.96.214.79]) by mail.strongswan.org (Postfix) with ESMTPSA id B43DB40178; Mon, 24 Oct 2016 11:44:37 +0200 (CEST) To: "IPsecme WG (ipsec@ietf.org)" From: Andreas Steffen Message-ID: <580DD800.5040608@strongswan.org> Date: Mon, 24 Oct 2016 11:44:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090109050903030807050605" Archived-At: Subject: [IPsec] NewHope Post-Quantum Key Exchange for IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2016 09:44:41 -0000 This is a cryptographically signed message in MIME format. --------------ms090109050903030807050605 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, we'd like to inform the IPsecme mailing list that version 5.5.1 of the strongSwan open source IKE daemon https://www.strongswan.org/ implements the lattice-based NewHope key exchange algorithm proposed by Erdem Alkim, L=C3=A9o Ducas, Thomas P=C3=B6ppelmann and Peter Schwabe = in their 2015 paper "Post-quantum key exchange =E2=80=93 a new hope" https://eprint.iacr.org/2015/1092.pdf NewHope is already being used by Google's experimental Canary Chrome browser in combination with a Curve25519 ECDH key exchange. strongSwan implements an experimental NewHope key exchange only and has assigned the DH group 1040 from the private-use range to the algorithm. The following all-out quantum-resistant IKEv2 example scenario uses AES encryption with a 256 bit symmetric key, a NewHope key exchange and a BLISS signature, both with a post-quantum cryptographic strength of 128 bits: https://www.strongswan.org/testing/testresults/swanctl/rw-newhope-bliss/ The NewHope key exchange is a direct replacement for a traditional Diffie-Hellman exchange, the only drawback being that the IKE_SA_INIT request/response messages will have a size of about 2000-2500 bytes and thus with a typical MTU of 1500 bytes will get fragmented as the following IKEv2 daemon log shows https://www.strongswan.org/testing/testresults/swanctl/rw-newhope-bliss/c= arol.daemon.log Lattice-based BLISS signatures and certificates are even larger, leading to IKE_AUTH request/response messages with a size between 3200-4000 bytes but with IKEv2 fragmentation in place they do not pose any problems. Best regards Andreas Steffen BTW - As soon as the Safecurves RFC number will be known, a strongSwan version with Curve25519 support will be released. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Andreas Steffen andreas.steffen@strongswan.org strongSwan - the Open Source VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D[ITA-HSR]=3D=3D --------------ms090109050903030807050605 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CwUwggUbMIIEA6ADAgECAhBuUxLd3zNyJYxWKYW719FJMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwOTA5MTkyNzQxWhcNMTcwOTA5MTkyNzQxWjBYMScwJQYDVQQDDB5hbmRy ZWFzLnN0ZWZmZW5Ac3Ryb25nc3dhbi5vcmcxLTArBgkqhkiG9w0BCQEWHmFuZHJlYXMuc3Rl ZmZlbkBzdHJvbmdzd2FuLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKHS uZp+jtu8bNOw/9/xh4LKs/ZWzxMF12nZSKWYm/2+jokenFQ3i2VaAtvqD1zdVRfsNWvUDu/e 6VN0PPTyzSbZW/2a8WMa9WSmi9WBTGv8uI7LOMq2kRdRrlhjW5FVwVramtBd0mT9/4Y2qOYh HtlEA5Lj3djfTnWKtF8gc3Uc6ZPNMbtVhA5+9CW1aqZx2tuukC1uYZdLgYOQoCRySMFa7lVD OoMk5fOZePKsM/RfN45Pn1drY7jsfWNdnuo9AZtSf75Vs6E8ffELt6aU1jp7CRCXc1KgHeZC gdFZVhO3Kzbi1lCr0T+o80+IoEJH2hMh12V+ndfhErjCLc5wtKsCAwEAAaOCAcIwggG+MA4G A1UdDwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwCQYDVR0TBAIw ADAdBgNVHQ4EFgQUG99dVPmyPEV8VjDhmwI8by/ngYswHwYDVR0jBBgwFoAUJIFsOWG+SQ+P txtGK8kotSdIbWgwbwYIKwYBBQUHAQEEYzBhMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5z dGFydHNzbC5jb20wOQYIKwYBBQUHMAKGLWh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRz L3NjYS5jbGllbnQxLmNydDA4BgNVHR8EMTAvMC2gK6AphidodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9zY2EtY2xpZW50MS5jcmwwKQYDVR0RBCIwIIEeYW5kcmVhcy5zdGVmZmVuQHN0cm9u Z3N3YW4ub3JnMCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBHBgNVHSAE QDA+MDwGCysGAQQBgbU3AQIFMC0wKwYIKwYBBQUHAgEWH2h0dHBzOi8vd3d3LnN0YXJ0c3Ns LmNvbS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggEBAKE27itDRB20DgVxymhhr0XDgjXgOGuu W8Y04kWMDhUjzzP2wKcZM4lwmmU1tAe9afnpbXO6CuBnW2F0qIVCmk4698Oi7K18SiQu6RoB L+1IbFHxoz4AQvRHTkuB09xJOlJl5w4rS1KOd1qtd0qsiGiXzjEGB+ggwPSloQ5+c9x4XwDE eI4jbHIh589UskSBuTtKxfaPxs/20AX2QN4ZdyLcWqf4Cg2gMn8oQwgC2dBCXSPRHjTua9q2 PNZThVkd5fml5N3PC/iCPbQ5jLp1CaR9pJHq7mQDkV7eEJ3a53V8ii+TF9NrCSb8v/KeoR39 5PDNwk1m8obnE7lQay4Fa/MwggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqG SIb3DQEBCwUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFy dENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYw MTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQL EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20g Q2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC9fdr3 w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwObhajcVmnKVxhrUwkZPXR AwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0qn4TPgnr3X2vPVS51 M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsSslxLce0CGWRs T8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrOAyDPFJVU vKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAOBgNV HQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2Zz Y2EuY3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRz c2wuY29tMDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5j cnQwHQYDVR0OBBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFul F2mHMMo0aEPQQa7yMD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8B Aluc4SMnIwS9NPBwAm5SH9uh2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs 0p7NZWcIe7Bvem2AWaXBsxsaRTYw5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp 4AiFXgvxprJrW7izsyetOrRHPbkW4Y07v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW /ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Yklue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2 D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQyCkC2aNNsK5cWOojBar5c7HplX9aHYUCZ ouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVDo/ebn9c6PaM/XtDYCCaM/7XX6wc3 s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2B2NLatidKE/m7G+rB9m+FlVg IiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6jbAV+WL+LDeGfVcq8DHS 3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0peVLadVHhqf9nXqKa xnr358VgfrxzUIrvOaOjMYIDzDCCA8gCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9y aXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQblMS3d8zciWMVimF u9fRSTANBglghkgBZQMEAgEFAKCCAhMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTYxMDI0MDk0NDMyWjAvBgkqhkiG9w0BCQQxIgQgkR8bsW9AP7pBEOSZ QC/cvUN2YnmA+N1vOS26Q8JuWPwwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJ YIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBmgYJKwYBBAGCNxAEMYGMMIGJMHUxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EC EG5TEt3fM3IljFYphbvX0UkwgZwGCyqGSIb3DQEJEAILMYGMoIGJMHUxCzAJBgNVBAYTAklM MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0ECEG5T Et3fM3IljFYphbvX0UkwDQYJKoZIhvcNAQEBBQAEggEAhx0DV4zbTvuiYVtMr03qI7Xxf8/U lAoD6v7lX3nu/DV33B3N8xFfOAcGy1WQGe4etTUYSUuCXEMvEVzUDcuQpbLenTZPf7KvGg6w ARiapG7ER70n5SyhgwPj19EqQIudaTCKFEW/EnSjsOE1sNiGxdiSqrmyfL3kGHMYJ/o6qzo5 pRzlEtI77VsVjsEk37DkLvzb5JZGuORJgkHfujZhjBWVCAexHheUoxJjkHYW7H75t9Iu2q8W nC3u/ubFc45pCAJYWK/5amUb/3ZyGlCT9Nxdm1ji94S+A1XCCid5ncpb1uJDk3STpUfR7fR5 dwe58+xR8QSWUJpOhOrZfjXh9QAAAAAAAA== --------------ms090109050903030807050605-- From nobody Thu Oct 27 08:25:46 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A134912996A; Thu, 27 Oct 2016 08:25:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147758194465.24715.3557251338401543807.idtracker@ietfa.amsl.com> Date: Thu, 27 Oct 2016 08:25:44 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc7321bis-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 15:25:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) Authors : Daniel Migault John Mattsson Paul Wouters Yoav Nir Tero Kivinen Filename : draft-ietf-ipsecme-rfc7321bis-00.txt Pages : 13 Date : 2016-10-06 Abstract: This document updates the Cryptographic Algorithm Implementation Requirements for ESP and AH. The goal of these document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable. This document obsoletes RFC 7321 on the cryptographic recommendations only. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc7321bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-rfc7321bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 27 11:49:07 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C2712966D for ; Thu, 27 Oct 2016 11:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ro0Opevujrc for ; Thu, 27 Oct 2016 11:49:03 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0108.outbound.protection.outlook.com [23.103.201.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1EA1295E9 for ; Thu, 27 Oct 2016 11:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qbd3ZxMTHSmH82VUAEiLHS0aSj5s5qP+xwancHprZMI=; b=jwVcj6/AxhHzCIWZIcZ7LYITXsTAq9Giptqu7FEv9rfveqd06rCfQAm6slprPUgVJX+bWa4WxpEUTqAOVtM/m6WATzSqTzo+9IFPICOAX5t2FTjG927I9tHE681N6haj279rNt8TXPryC+WkfW4WuksO873kAN9fiUxEOEHPQRs= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1437.namprd09.prod.outlook.com (10.173.50.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.12; Thu, 27 Oct 2016 18:49:02 +0000 Received: from MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) by MWHPR09MB1440.namprd09.prod.outlook.com ([10.173.50.14]) with mapi id 15.01.0679.015; Thu, 27 Oct 2016 18:49:02 +0000 From: "Waltermire, David A. (Fed)" To: IPsecME WG Thread-Topic: WGLC on draft-ietf-ipsecme-rfc4307bis-11 Thread-Index: AdIFjEsiiAZg58SjSQuP1+89T+2nUgq9Z5ew Date: Thu, 27 Oct 2016 18:49:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-office365-filtering-correlation-id: 7a3ee7b0-e33d-48f5-068a-08d3fe99eb78 x-microsoft-exchange-diagnostics: 1; MWHPR09MB1437; 7:2JQ7aL3tSP56e40ubec5mfjQl+tWe9OAMg705hJBrvNccPVNUwplWnmCZ5hSU90RYIY8JeH+CtbkJ5O59la2tLiTZfGJofHK8UCLYYng0nIMKKc9HWzvD8hORLBB4hO7cO/AiqDWCXqIQgAm/uevlx+54AkNKn2D9aHu9Hjf4qo2O+fraKvre0KJ0Y7T4SYNiwBZz10GJ5U1ACm+tZx15ygtqSdlGQFIck/j6C5iLnMMKtf7qvLFeVMnupXfZX/31dfO+Cgjsc/H7h52ZLBMYM7BlGVm1yL/JuOjIbgonAMZllNQlHEQUOcpWdkUL3dNFLNPEKY6YRNWN9R5jKBat4I4s+CjYhqEKefyswT7TV4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:MWHPR09MB1437; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:MWHPR09MB1437; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1437; x-forefront-prvs: 0108A997B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(377454003)(199003)(13464003)(110136003)(86362001)(5660300001)(7696004)(77096005)(2900100001)(15975445007)(19580405001)(19580395003)(74316002)(2906002)(8676002)(3900700001)(87936001)(76576001)(81156014)(6916009)(122556002)(3660700001)(8936002)(9686002)(3280700002)(81166006)(92566002)(189998001)(6116002)(3846002)(101416001)(10400500002)(54356999)(105586002)(50986999)(230783001)(102836003)(106356001)(107886002)(305945005)(7736002)(7846002)(5002640100001)(66066001)(68736007)(11100500001)(450100001)(33656002)(586003)(99286002)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1437; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2016 18:49:02.1603 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1437 Archived-At: Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-rfc4307bis-11 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2016 18:49:06 -0000 The latest revision of draft-ietf-ipsecme-rfc4307bis -15 was published a we= ek ago. I haven't seen any additional discussion of the draft since then. = I'd like to conclude the WGLC on this draft and progress it to the IESG. Be= fore I do so, are there any unresolved remaining concerns with the draft? Thanks, Dave > -----Original Message----- > From: Waltermire, David A. (Fed) > Sent: Friday, September 02, 2016 10:41 PM > To: IPsecME WG > Subject: WGLC on draft-ietf-ipsecme-rfc4307bis-11 >=20 > All, >=20 > This message starts a Working Group Last Call (WGLC) for draft-ietf-ipsec= me- > rfc4307bis-11. >=20 > The version to be reviewed is https://www.ietf.org/id/draft-ietf-ipsecme- > rfc4307bis-11.txt. >=20 > Please send your comments, questions, and edit proposals to the WG mail > list until September 19th, 2016. If you believe that the document is rea= dy to > be submitted to the IESG for consideration as a Standards Track RFC pleas= e > send a short message stating this. >=20 > Best Regards, > Dave and Tero From nobody Fri Oct 28 06:52:43 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E64129AD2 for ; Fri, 28 Oct 2016 06:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tfc6BuOQAXLm for ; Fri, 28 Oct 2016 06:52:40 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5242E129ACC for ; Fri, 28 Oct 2016 06:52:40 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u9SDqb9D009203 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 28 Oct 2016 16:52:37 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u9SDqbKg012656; Fri, 28 Oct 2016 16:52:37 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22547.22565.329808.194716@fireball.acr.fi> Date: Fri, 28 Oct 2016 16:52:37 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 2 min Archived-At: Cc: Kathleen Moriarty Subject: [IPsec] IPsecME status update 2016-10-28 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 13:52:41 -0000 Agenda of IETF 97, Seoul posted: Tuesday, November 15, 2016 13:30-15:30 Tuesday Afternoon session I - Agenda bashing, adminstrivia - Chairs (5 min) - Status of ready WG drafts - Chairs (5 min) (ddos-protection, safecurves, rfc4307bis, rfc7321bis) - Status of other WG items - Chairs / Authors (30 min) tcp-encaps and split-dns - Pauly eddsa and implicit-iv - Nir - PSS vs PKCS1 v1.5 interop issues - Valery Smyslov (15 min) - QR discussion (30 min) Document Status: - draft-ietf-ipsecme-ddos-protection (David) In RFC Editor Queue. - draft-ietf-ipsecme-safecurves (Tero) Approved in the 2016-10-13 IESG telecat. Now in RFC Editor Queue. - draft-ietf-ipsecme-rfc4307bis (David) WGLC period done, resulted some changes, should be ready to go forward. - draft-ietf-ipsecme-rfc7321bis (David) Adopted as WG document, should be ready for WG LC. - draft-ietf-ipsecme-eddsa (Tero) I think this is still waiting for the curdle to decide for OID. No comments during WG adoptation call, adopted as WG document. - draft-ietf-ipsecme-tcp-encaps (Tero) This should also be ready for WGLC, waiting for Tero to review. New work: - Quantum Resistance (David) Discussion has started on the mailing list about the requirements and when we have those decided on the list, we should start working on document. - draft-pauly-ipsecme-split-dns (David) This was accepted as charter item, but need few more reviews before taking it as WG draft. - draft-mglt-ipsecme-implicit-iv (Tero) This was also accepted as charter item, but would like to see few more reviews before taking it as WG draft. -- kivinen@iki.fi From nobody Fri Oct 28 07:01:01 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2FE71293E0; Fri, 28 Oct 2016 07:01:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147766326079.24940.11205450689083622188.idtracker@ietfa.amsl.com> Date: Fri, 28 Oct 2016 07:01:00 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 14:01:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : Postquantum Preshared Keys for IKEv2 Authors : Scott Fluhrer David McGrew Panos Kampanakis Filename : draft-fluhrer-qr-ikev2-03.txt Pages : 9 Date : 2016-10-28 Abstract: This document describes an extension of IKEv2 to allow it to be resistant to a Quantum Computer, by using preshared keys The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-fluhrer-qr-ikev2/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-fluhrer-qr-ikev2-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-fluhrer-qr-ikev2-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 28 07:25:54 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D793129B0B for ; Fri, 28 Oct 2016 07:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.952 X-Spam-Level: X-Spam-Status: No, score=-14.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7ymC_ZTnnkI for ; Fri, 28 Oct 2016 07:25:51 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC9BF129B02 for ; Fri, 28 Oct 2016 07:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5096; q=dns/txt; s=iport; t=1477664749; x=1478874349; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=gzMBOhEHzQ29BOeDl+mSRZB8NajIwOgw2oeRwZJAIkA=; b=PYgCvy2X+N8dwVCPN4hhuqvTkG6gscs0Yh//2wIKZLDuzxmSZygY/RgM Rs5x9FS1bbgRKj0uanX0J0MLeCUeeeLOZy9p9uwtDBjm73YoFDXuZ38SN rhVeGDd4IbKldPwi+FDREYCuLRpGZVWg3phGGpBfdT27vDS1xqmhLaUR3 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DXBABfXxNY/51dJa1SCRwBAQQBAQoBA?= =?us-ascii?q?YMqAQEBAQEfgVy6dIgeQhEBAgEBAQEBAQFiKIRjBoELAQgQaBsBBgQBBBsTiDm?= =?us-ascii?q?hUpxjAQEIAgEkhj2EVYQghgYFjweLEQGQH4F1jhaHHolxATQgX4MbHIFTh1yBC?= =?us-ascii?q?QEBAQ?= X-IronPort-AV: E=Sophos;i="5.31,410,1473120000"; d="scan'208";a="167100306" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Oct 2016 14:25:47 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u9SEPkpj002136 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 28 Oct 2016 14:25:46 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 28 Oct 2016 10:25:45 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Fri, 28 Oct 2016 10:25:45 -0400 From: "Scott Fluhrer (sfluhrer)" To: "IPsecme WG (ipsec@ietf.org)" Thread-Topic: Quantum Resistance Requirements Thread-Index: AdH0G8ijQKeg6MaXRiG9vXmtSf0/rwUZFu7ACMepu6AAD1cOEAFR877A Date: Fri, 28 Oct 2016 14:25:45 +0000 Message-ID: <6c1585204f6a4598b6e40b05912ba4c4@XCH-RTP-006.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.52] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [IPsec] FW: Quantum Resistance Requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 14:25:53 -0000 Here is an update on the voting for the list of potential requirements for = a short term Quantum Resistance solution; and a summary of the recent updat= e to our draft (which reflects the stated requirements) The votes so far (omitting the "no opinion" votes); I've listed the voters = chiefly so that if I mischaracterized their votes, they can correct me. - Simplicity; how large of a change to IKE (and IKE implementations) are we= willing to contemplate? Scott Fluhrer: very important Michael Richardson: very important Tommy Pauly: very important Valery Smyslov: not as important as other issues Oscar Garcia-Morchon: very important. - Preserving existing IKE security properties? Scott Fluhrer: very important Michael Richardson: very important Tommy Pauly: very important Valery Smyslov: important Oscar Garcia-Morchon: very important.=20 - What do we feel needs to protected from someone with a Quantum Computer? = =A0Do we feel =A0the need to protect only the IPsec traffic, or do we need = to protect the IKE traffic as well. Tommy Pauly: not clear if IKE traffic needs to be protected. Valery Smylsov: important Oscar Garcia-Morchon: IPsec traffic must be protected, IKE traffic would be= a nice-to-have.=20 - What level of identity protection do we need to provide?=A0 If two differ= ent IKE negotiations use the same shared secret, do we mind if someone can = deduce that? Scott Fluhrer: not important Michael Richardson: very important Tommy Pauly: not important Valery Smylsov: this is a nice to have, but not critical Oscar Garcia-Morchon: this is less important Russ Houseley: this is a nice to have, but only if it is cheap - =A0PPK management; how much support do we provide for automatically manag= ing the secrets? Scott Fluhrer: not important Tommy Pauly: not important Oscar Garcia-Morchon: not important - How much support do we provide for nonstatic secrets, for example, by QKD= , or via something like HIMMO (a key distribution mechanism that appears to= be post quantum)? Scott Fluhrer: not important Michael Richardson: not important Tommy Pauly: not important Oscar Garcia-Morchon: not important now, but will become important in the f= uture - Authentication; if someone with a Quantum Computer can break the DH in re= al time, do we care if he can act as a man-in-the-middle? Scott Fluhrer: not important Michael Richardson: important, provided that we don't run into the same iss= ues that IKEv1 PSKs ran into Tommy Pauly: not important Valery Smylsov: this would be nice to have Oscar Garcia-Morchon: this would be nice to have - Algorithm agility; how important is it that we negotiate any cryptoprimit= ives involved? Scott Fluhrer: not important Tommy Pauly: not important Valery Smylsov: important Oscar Garcia-Morchon: less important. My tentative summary of the votes: - Simplicity and preserving existing security properties are the most impor= tant - Protecting IKE traffic was considered less important. We have updated our draft to reflect these requirements; it is much simpler= than the previous draft, but does not provide anonymity. It is based on a= suggestion by Tero (which was to do the initial IKE SA establishment as no= rmal, and then stir in the PPK into the IPsec KEYMAT generation process); t= his makes it much simpler than trying to exchange identities before doing t= he initial key derivation. We did add a modification to how the child SA S= KEYSEED was computed (by stirring in the PPK there as well); the advantage = of this is that this means that any child IKE SAs were also quantum resista= nt. This implies that an implementation that did insist on protecting the = IKE traffic could immediately generate a child SA after negotiation, and th= en use that child SA to do all the real negotiation. We thought that this = flexibility justified the extra complication of modifying the SKEYSEED comp= utation. Such an implementation would leak the identities to a Quantum adv= ersary, but everything else would be protected. Here is how the draft scores against the given criteria: - Simplicity; it is fairly simple - Preserving existing IKE security properties? It preserves all IKE securi= ty properties against an adversary with a conventional computer=20 - What is protected from someone with a Quantum Computer? It protects the = IPsec traffic; it also allows an implementation (with more exchanges) to pr= otect the IKE traffic (apart from the identities) - What level of identity protection do we need to provide? This doesn't pr= ovide any identity protection against someone with a Quantum Computer - PPK management; not addressed - How much support do we provide for nonstatic secrets? Not addressed, how= ever it would not be difficult to add in the future. - Authentication; can an attacker with Quantum Computer act as a man-in-the= -middle? No, not if both sides have PPK mandatory - Algorithm agility; yes, the only algorithms used are the ones negotiated From nobody Fri Oct 28 09:15:53 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995FC1295A0 for ; Fri, 28 Oct 2016 09:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCUea5D2f76b for ; Fri, 28 Oct 2016 09:15:51 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 019DE129552 for ; Fri, 28 Oct 2016 09:15:51 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 895A12009E; Fri, 28 Oct 2016 12:30:59 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C07EE63B05; Fri, 28 Oct 2016 12:15:49 -0400 (EDT) From: Michael Richardson To: "Scott Fluhrer \(sfluhrer\)" In-Reply-To: <6c1585204f6a4598b6e40b05912ba4c4@XCH-RTP-006.cisco.com> References: <6c1585204f6a4598b6e40b05912ba4c4@XCH-RTP-006.cisco.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: "IPsecme WG \(ipsec@ietf.org\)" Subject: Re: [IPsec] FW: Quantum Resistance Requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 16:15:52 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Scott Fluhrer (sfluhrer) wrote: > - What level of identity protection do we need to provide?=C2=A0 If t= wo > different IKE negotiations use the same shared secret, do we mind if > someone can deduce that? I think that this depends greatly upon the deployment scenario. > - Authentication; if someone with a Quantum Computer can break the DH > in real time, do we care if he can act as a man-in-the-middle? Scott > Fluhrer: not important Michael Richardson: important, provided that we > don't run into the same issues that IKEv1 PSKs ran into Tommy Pauly: > not important Valery Smylsov: this would be nice to have Oscar > Garcia-Morchon: this would be nice to have I'm very concerned that we don't wind up with insecure Group PSKs as we had with IKEv1. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWBN5soCLcPvd0N1lAQIifQgAjJPkaP3bVhanIOQDOym1zt1sSCNfl3Gr qFogn+YJwEBWgGxSJCtFAssmGf1ACZloCdYiPvgf/cTLB2zhAqMZbyCmRxDY9dKy VRGGjZ9bZ39qwRTmPi6rs/d6aSUyrJZYfq+wrnKGEZLHIRMuk1OPO2UA/sjl6cXY KKhCRO2B0k5Go+Fm/06+gjhfBFOjHA0gGXH+p/q2jBivaBxAt1raVZFVrXo6LSl/ TfT66Tt9gWBf7yPFjaQa8DZSQPuHBeta6TY2obXVz+qjy76OjtRYQHJlmYKVW5W/ EXZv1b28L7ESwC7Umr6LyFoU8kQvFnUYYeQ7pRSDveqPxCKQxcSccA== =oTjI -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Oct 28 12:54:06 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50810129505; Fri, 28 Oct 2016 12:54:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147768444132.24987.10305392703895531882.idtracker@ietfa.amsl.com> Date: Fri, 28 Oct 2016 12:54:01 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-eddsa-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2016 19:54:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : Using Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange (IKEv2) Author : Yoav Nir Filename : draft-ietf-ipsecme-eddsa-00.txt Pages : 5 Date : 2016-10-28 Abstract: This document describes the use of the Edwards-curve digital signature algorithm in the IKEv2 protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-eddsa/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-eddsa-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Oct 29 08:19:45 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E15B129538; Sat, 29 Oct 2016 08:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNTIIFPc2H-r; Sat, 29 Oct 2016 08:19:41 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 751CA126B6D; Sat, 29 Oct 2016 08:19:41 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id n67so160408630wme.1; Sat, 29 Oct 2016 08:19:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=+V2+c9z3WlhuNFmbQiilOBp6nr0qqnzx87e/KDgYKWA=; b=wtyJlrhupybqsWsMphRooupWyVrzLboWcn6Yqljf48KwdTP/LSNE6BFzAJiN4nr5Aq YoYf6tY/2eQQsshLkPW5E0RiwPvRDLjE+s3CsjjyrLe6CBp1hgY3lKiGpoSKbdA/ix1J n1ALNrkiDxFmrOnnVrxLq9Qav4kO1MWrg1gKzPMRdmQzBayFrTCtIRimfN38quRBOMtv zQBsY3pmxb1JG6LOgjQwhfqaqMiIYpsSjJ0m/B4wNpAjf0xTVfZIxBv3c4N+p3TQjSMu x+Ub3OK3zX6VtkZc2tsNYsSCj/kUcbz0vizF684WnlZ/a0zsL8Fc445lTj8ZUQmfm9ul a2Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=+V2+c9z3WlhuNFmbQiilOBp6nr0qqnzx87e/KDgYKWA=; b=cur+vZbz2JZjo4qfYTGIzEEO+EQvk07XP5dCo0WXxdOiRkDZQjWEYpuIN0gWkXCYqZ +p1APCE8RhUehMebq93YMVcF5UJf5lL1pNFC29URjaKyvoQZzm4ApG11CG9CKXMKQfkE FlGOuYB/gtQRnfCDAk9w1Qfrv5X0IuXclPKu6vKdr8YMSI3355SpTzKBP0yvm7yLyZyQ 4BZS+N9kCU6rYm85RFJVdd7Ov6/0SmgDlWCjOjA1GmDhFQuC7V/iS663HrvXTbSaHuJr 3UvmsLfw6WCngd5O8iclv/PyMFTrZUZjGS/hafMHwTLCLtgFLO4AlaYVHHQz7Ayj8J3i CbGw== X-Gm-Message-State: ABUngvf6EOYLVJPt32Il/vObsycatEJy8K7V0f+dMUIlJ22D8bNHVQnHnYEEyXFVTjF5Gg== X-Received: by 10.28.148.22 with SMTP id w22mr3801872wmd.42.1477754379493; Sat, 29 Oct 2016 08:19:39 -0700 (PDT) Received: from [192.168.1.13] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id jt8sm19885072wjc.33.2016.10.29.08.19.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Oct 2016 08:19:38 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_05E80549-FEF4-4402-95B1-E2108B665C9C" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Sat, 29 Oct 2016 18:19:36 +0300 In-Reply-To: <147768444132.24987.10305392703895531882.idtracker@ietfa.amsl.com> To: internet-drafts@ietf.org References: <147768444132.24987.10305392703895531882.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: ipsec@ietf.org, i-d-announce@ietf.org Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-eddsa-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2016 15:19:43 -0000 --Apple-Mail=_05E80549-FEF4-4402-95B1-E2108B665C9C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This version is similar to draft-nir-ipsecme-eddsa-01, with the = following changes: Updated references Removed the title of the Curdle draft from the text because it had = become unwieldy [1] Updated the OIDs in appendix A and added a binary representation as in = RFC 7427 Added some text in IANA considerations The XML source is now in = https://github.com/ietf-ipsecme/drafts/blob/master/draft-ietf-ipsecme-edds= a.xml = Yoav [1] Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 = and X448 for use in the Internet X.509 Public Key Infrastructure > On 28 Oct 2016, at 22:54, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IP Security Maintenance and = Extensions of the IETF. >=20 > Title : Using Edwards-curve Digital Signature = Algorithm (EdDSA) in the Internet Key Exchange (IKEv2) > Author : Yoav Nir > Filename : draft-ietf-ipsecme-eddsa-00.txt > Pages : 5 > Date : 2016-10-28 >=20 > Abstract: > This document describes the use of the Edwards-curve digital > signature algorithm in the IKEv2 protocol. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-eddsa/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-eddsa-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_05E80549-FEF4-4402-95B1-E2108B665C9C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This version is similar to draft-nir-ipsecme-eddsa-01, with = the following changes:
  1. Updated references
  2. Removed the title of = the Curdle draft from the text because it had become unwieldy = [1]
  3. Updated the OIDs in appendix A and added a binary = representation as in RFC 7427
  4. Added some text in IANA = considerations

The XML source is now in https://github.com/ietf-ipsecme/drafts/blob/master/draft-ietf-i= psecme-eddsa.xml

Yoav

[1] Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, = Ed448ph, X25519 and X448 for use in the Internet X.509 Public Key = Infrastructure

On 28 Oct 2016, at 22:54, internet-drafts@ietf.org wrote:


A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of = the IP Security Maintenance and Extensions of the IETF.

       Title =           : Using = Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key = Exchange (IKEv2)
=        Author =          : Yoav Nir
= Filename        : = draft-ietf-ipsecme-eddsa-00.txt
Pages =           : 5
= Date =            : = 2016-10-28

Abstract:
=   This document describes the use of the Edwards-curve = digital
  signature algorithm in the IKEv2 = protocol.


The IETF = datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-eddsa/<= br class=3D"">
There's also a htmlized version available = at:
https://tools.ietf.org/html/draft-ietf-ipsecme-eddsa-00


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

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

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Apple-Mail=_05E80549-FEF4-4402-95B1-E2108B665C9C-- From nobody Mon Oct 31 08:20:43 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC5B129473 for ; Mon, 31 Oct 2016 08:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BitlRUZ5BcG8 for ; Mon, 31 Oct 2016 08:20:40 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3534A1293F3 for ; Mon, 31 Oct 2016 08:20:40 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u9VFKUau011257 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 31 Oct 2016 17:20:30 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u9VFKUqg000705; Mon, 31 Oct 2016 17:20:30 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22551.24894.457412.805177@fireball.acr.fi> Date: Mon, 31 Oct 2016 17:20:30 +0200 From: Tero Kivinen To: Michael Richardson In-Reply-To: <29931.1477671349@obiwan.sandelman.ca> References: <6c1585204f6a4598b6e40b05912ba4c4@XCH-RTP-006.cisco.com> <29931.1477671349@obiwan.sandelman.ca> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 7 min Archived-At: Cc: "IPsecme WG \(ipsec@ietf.org\)" , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] FW: Quantum Resistance Requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 15:20:42 -0000 Michael Richardson writes: > > - Authentication; if someone with a Quantum Computer can break the DH > > in real time, do we care if he can act as a man-in-the-middle? Scott > > Fluhrer: not important Michael Richardson: important, provided that we > > don't run into the same issues that IKEv1 PSKs ran into Tommy Pauly: > > not important Valery Smylsov: this would be nice to have Oscar > > Garcia-Morchon: this would be nice to have > > I'm very concerned that we don't wind up with insecure Group PSKs as we had > with IKEv1. As this document is written (or how I think it is written, as I have not yet had time to read the latest version), the PPK used to provide to quantum resistance is not used in the authentication, there is still normal IKEv2 authentication step using normal IKEv2 shared secret, or certificates. So even if the people would be using group PPK, that would not allow similar issues than what happend with IKEv1. Of course everybody sharing the same PPK will be able to attack other users of the same group by just breaking the Diffie-Hellman :-) On the other hand even if you know the PPK, you cannot do anything without breaking the Diffie-Hellman, as it does not allow you do to man-in-the-middle without breaking the normal authentication. So, yes, there is some dangerous things that can happen, but I do not think it will be reducing IKEv2 security even if such insecure practices are used (except than it will reduce the quantum resistance provided by PPK, if everybody knows PPK). -- kivinen@iki.fi From nobody Mon Oct 31 08:56:22 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E83EC1296D7; Mon, 31 Oct 2016 08:56:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.36.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147792938094.32373.833800643936554773.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2016 08:56:20 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 15:56:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : TCP Encapsulation of IKE and IPsec Packets Authors : Tommy Pauly Samy Touati Ravi Mantha Filename : draft-ietf-ipsecme-tcp-encaps-03.txt Pages : 20 Date : 2016-10-31 Abstract: This document describes a method to transport IKE and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as TCP encapsulation, involves sending both IKE packets for tunnel establishment as well as tunneled packets using ESP over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 31 09:00:43 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A50129857 for ; Mon, 31 Oct 2016 09:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dTFicxDRXa3 for ; Mon, 31 Oct 2016 09:00:40 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (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 D50B212985D for ; Mon, 31 Oct 2016 09:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1477929638; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=BXIwOJihbgBGe8yaPUNXAXQchx+SZx/R8rZ+2wzklVg=; b=GBymJfU9l5vkiVDcc/CHgzvE+NzxCaTCsjyDJWrNwBomvRHMG7YgJa9WHgVR6BTC ZIaZgI09L9i6cZPfo9vDVri+1G6a/kcxYARb6tWiNPkAbGj8cqpZLLHg9WHDE/aF TRFlMU/KllCHhJrxw+2X7RGFIntxNMIL4LlyLQyDN8xNY9013X/bxmhK99q11/xL Atp4N60hjCvH4af3Old6yv0dB+AtoNMGdvpwxtakZ5qSiBD9Q2BVXjiYhGj84r0E fi6tgvu4MIdDWq/RypNRbTSLGch2QgkjvbjNZf+QVTjSix0OjA9QofEgjie7i61D TKK7qkjZAUeo1m+keJ1Qiw==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id CC.04.28372.6AA67185; Mon, 31 Oct 2016 09:00:38 -0700 (PDT) X-AuditID: 11973e11-f85fb70000006ed4-bd-58176aa6e9f8 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by relay4.apple.com (Apple SCV relay) with SMTP id 3D.4A.20305.5AA67185; Mon, 31 Oct 2016 09:00:38 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.234.34.78] (unknown [17.234.34.78]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OFX00J8W5T04230@nwk-mmpp-sz10.apple.com> for ipsec@ietf.org; Mon, 31 Oct 2016 09:00:37 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Content-transfer-encoding: quoted-printable Date: Mon, 31 Oct 2016 09:00:49 -0700 References: <147792938094.32373.833800643936554773.idtracker@ietfa.amsl.com> To: IPsecME WG In-reply-to: <147792938094.32373.833800643936554773.idtracker@ietfa.amsl.com> Message-id: <61A7C96D-66A0-4BA7-82BE-277CBE13ED45@apple.com> X-Mailer: Apple Mail (2.3252) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUi2FAYrrssSzzC4Nd1fYv9W16wOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4/Pa9cwFF0Uq3h1extzAOFGgi5GTQ0LARKLv6Uq2LkYuDiGB vYwS05/9Z4dJPH54mQUicYhRYuqr70wgCV4BQYkfk+8BJTg4mAXUJaZMyYWomc0k8f1cDxNI XFhAQmLznkSQcjYBFYnj3zYwg9jMAtoST95dYAWxhQUcJe72LAHbxSKgKvHn3VawGiEBH4kf v9qYQcaICMhLzLyRCWJyCvhKPLmhDnGAjcTimZuZIa6UlVj5dCMryAUSAjPYJM7dXc0+gVFo FpJDZyEcOgvJEQsYmVcxCuUmZuboZuYZ6SUWFOSk6iXn525iBAXqdDvBHYzHV1kdYhTgYFTi 4d3gKR4hxJpYVlyZe4hRmoNFSZx3fipQSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2P2vO/h VZlRRXFiPau9XS21Ln/QfrfrS/OSq3eZ17x5z7D4W5vRRL4vwiEhx1X+c/YbTmUtYw29umgG 35f4BbJ+Owp2PgzZknW0yrDA9MCMSO+VWz+fXhp1bptH54rN9XeZq+2jeuZyME0+vuSquMIH JbYups2Lb5YtrnUqNjte962e5ebzL11KLMUZiYZazEXFiQCUmE9ZNQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUi2FBcpbssSzzCYHcXm8X+LS/YHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8XnteuaCiyIV7w4vY25gnCjQxcjJISFgIvH44WUWCFtM4sK9 9WxdjFwcQgKHGCWmvvrOBJLgFRCU+DH5HlARBwezgLrElCm5EDWzmSS+n+thAokLC0hIbN6T CFLOJqAicfzbBmYQm1lAW+LJuwusILawgKPE3Z4l7CA2i4CqxJ93W8FqhAR8JH78amMGGSMi IC8x80YmiMkp4Cvx5IY6xAE2EotnbmaGuFJWYuXTjawTGAVmIbltFsJts5DsXcDIvIpRoCg1 J7HSRC+xoCAnVS85P3cTIzjgCsN3MP5bZnWIUYCDUYmHd4OneIQQa2JZcWUu0PMczEoivN8z gEK8KYmVValF+fFFpTmpxYcYk4Gun8gsJZqcD4yGvJJ4QxMTAxNjYzNjY3MTc9KElcR5D4QK RAgJpCeWpGanphakFsFsYeLglGpgzOhcMWMDk+mh71tfLGZY1/XkuLF3yuwcNXUn7lnHM+28 ZwlP3qkTVm08K9l/zcv8/jUiCxueSW2r3K8gwX/EKo7H/9XCLQarvF+ukLKy8W+4Wt4a12G5 /HTu+Z66yg1GGtEuQZ83sV/bNulmbsrzNN/30h/sVTlXntZfFJ0sqHn+/B/3RBdPJZbijERD Leai4kQA+t7ZGXwCAAA= Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 16:00:41 -0000 Hello, I=E2=80=99ve posted a new version of the TCP encapsulation draft with = the following changes: 1. Added a section to explicitly discuss how to fallback from UDP to TCP = (retransmissions, etc) based on feedback from the charter discussion 2. Explained that this method of encapsulation can be used for any = stream protocol, and is not TCP specific, based on feedback from the = charter discussion 3. Clarified the use of multiple TCP connections for Child SAs, based on = Jun Hu=E2=80=99s questions Also, I=E2=80=99m happy to say that we=E2=80=99ve been doing = interoperability testing between Apple clients and Cisco server for TCP = encapsulation. If anyone else has an implementation they=E2=80=99d like = to try out, please let us know! Best, Tommy > On Oct 31, 2016, at 8:56 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IP Security Maintenance and = Extensions of the IETF. >=20 > Title : TCP Encapsulation of IKE and IPsec Packets > Authors : Tommy Pauly > Samy Touati > Ravi Mantha > Filename : draft-ietf-ipsecme-tcp-encaps-03.txt > Pages : 20 > Date : 2016-10-31 >=20 > Abstract: > This document describes a method to transport IKE and IPsec packets > over a TCP connection for traversing network middleboxes that may > block IKE negotiation over UDP. This method, referred to as TCP > encapsulation, involves sending both IKE packets for tunnel > establishment as well as tunneled packets using ESP over a TCP > connection. This method is intended to be used as a fallback option > when IKE cannot be negotiated over UDP. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-tcp-encaps-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Oct 31 09:50:47 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F0C12986C for ; Mon, 31 Oct 2016 09:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.018 X-Spam-Level: X-Spam-Status: No, score=-16.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjxMG-oHF-ws for ; Mon, 31 Oct 2016 09:50:44 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A97261298BB for ; Mon, 31 Oct 2016 09:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1653; q=dns/txt; s=iport; t=1477932644; x=1479142244; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vv/aVMj1yA4oS66rCZbuY4sRuFpiqczg1AXOUW3sf6w=; b=OF2VQxY1cF6E3ZERgyFm+RMqzWvNmQAs2glbqA2fjaiFT5hoezLGSsq2 bn5i27xs3IhQl7SDQz8p7Kt+le8heww1aJrkbozVdLC2eFRIQc3wb+xbK /BCzDb00jVMYLc4XMY2bQwl7mIlWhyhunVU39hoYfIbUr11JijW9dazpa Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B3AQBCdRdY/5tdJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgyoBAQEBAR+BVQeNL5Z+lD6CB4YjAoIQPxQBAgEBAQEBAQFiKIRiAQE?= =?us-ascii?q?BBDo/DAQCAQgQAQQBAR8JBzIUCAEIAgQBDQUIiEy9LAEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBARyGPYRViicFmhgBkCiBdYgnhW+NEYQBAR42YIUScocAgQkBAQE?= X-IronPort-AV: E=Sophos;i="5.31,575,1473120000"; d="scan'208";a="340581201" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Oct 2016 16:50:44 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u9VGohOj006920 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 31 Oct 2016 16:50:44 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 31 Oct 2016 12:50:43 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Mon, 31 Oct 2016 12:50:43 -0400 From: "Scott Fluhrer (sfluhrer)" To: Tero Kivinen , Michael Richardson Thread-Topic: [IPsec] FW: Quantum Resistance Requirements Thread-Index: AdH0G8ijQKeg6MaXRiG9vXmtSf0/rwUZFu7ACMepu6AAD1cOEAFR877AAA0HF4AAlPE+AAAFarAQ Date: Mon, 31 Oct 2016 16:50:43 +0000 Message-ID: <2bfa4b2cc5ce429b8ca75db997572210@XCH-RTP-006.cisco.com> References: <6c1585204f6a4598b6e40b05912ba4c4@XCH-RTP-006.cisco.com> <29931.1477671349@obiwan.sandelman.ca> <22551.24894.457412.805177@fireball.acr.fi> In-Reply-To: <22551.24894.457412.805177@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "IPsecme WG \(ipsec@ietf.org\)" Subject: Re: [IPsec] FW: Quantum Resistance Requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 16:50:46 -0000 > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Monday, October 31, 2016 11:20 AM > To: Michael Richardson > Cc: Scott Fluhrer (sfluhrer); IPsecme WG (ipsec@ietf.org) > Subject: Re: [IPsec] FW: Quantum Resistance Requirements >=20 > Michael Richardson writes: > > > - Authentication; if someone with a Quantum Computer can break th= e > DH > > > in real time, do we care if he can act as a man-in-the-middle? S= cott > > > Fluhrer: not important Michael Richardson: important, provided th= at > we > > > don't run into the same issues that IKEv1 PSKs ran into Tommy Pau= ly: > > > not important Valery Smylsov: this would be nice to have Oscar > > > Garcia-Morchon: this would be nice to have > > > > I'm very concerned that we don't wind up with insecure Group PSKs as > > we had with IKEv1. >=20 > As this document is written (or how I think it is written, as I have not = yet had > time to read the latest version), the PPK used to provide to quantum > resistance is not used in the authentication, there is still normal IKEv2 > authentication step using normal IKEv2 shared secret, or certificates. So= even > if the people would be using group PPK, that would not allow similar issu= es > than what happend with IKEv1. That is correct; we do not replace the existing privacy and authentication = features; instead, we supplement them by adding the PPK; this PPK is design= ed to add Quantum Resistance; however at the worse (e.g. you use the 'MakeM= eTastyGoat' PPK), you still have the privacy/authentication security found = that IKE provides. From nobody Mon Oct 31 11:24:40 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C6B1299B7 for ; Mon, 31 Oct 2016 11:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHE6uo-0ZGAb for ; Mon, 31 Oct 2016 11:24:35 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD9E21299AD for ; Mon, 31 Oct 2016 11:24:34 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0E7C42009E; Mon, 31 Oct 2016 14:39:54 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B4A84637A6; Mon, 31 Oct 2016 14:24:33 -0400 (EDT) From: Michael Richardson To: "Scott Fluhrer (sfluhrer)" In-Reply-To: <2bfa4b2cc5ce429b8ca75db997572210@XCH-RTP-006.cisco.com> References: <6c1585204f6a4598b6e40b05912ba4c4@XCH-RTP-006.cisco.com> <29931.1477671349@obiwan.sandelman.ca> <22551.24894.457412.805177@fireball.acr.fi> <2bfa4b2cc5ce429b8ca75db997572210@XCH-RTP-006.cisco.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Oct 2016 14:24:33 -0400 Message-ID: <26996.1477938273@obiwan.sandelman.ca> Archived-At: Cc: "IPsecme WG \(ipsec@ietf.org\)" , Tero Kivinen Subject: Re: [IPsec] FW: Quantum Resistance Requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 18:24:37 -0000 Scott Fluhrer (sfluhrer) wrote: >> Michael Richardson writes: > > - Authentication; if someone with a >> Quantum Computer can break the DH > > in real time, do we care if h= e >> can act as a man-in-the-middle? Scott > > Fluhrer: not important >> Michael Richardson: important, provided that we > > don't run into = the >> same issues that IKEv1 PSKs ran into Tommy Pauly: > > not important >> Valery Smylsov: this would be nice to have Oscar > > Garcia-Morchon= : >> this would be nice to have >> > >> > I'm very concerned that we don't wind up with insecure Group PSKs= as >> > we had with IKEv1. >> = >> As this document is written (or how I think it is written, as I hav= e >> not yet had time to read the latest version), the PPK used to provi= de >> to quantum resistance is not used in the authentication, there is >> still normal IKEv2 authentication step using normal IKEv2 shared >> secret, or certificates. So even if the people would be using group >> PPK, that would not allow similar issues than what happend with IKE= v1. > That is correct; we do not replace the existing privacy and > authentication features; instead, we supplement them by adding the P= PK; > this PPK is designed to add Quantum Resistance; however at the worse > (e.g. you use the 'MakeMeTastyGoat' PPK), you still have the > privacy/authentication security found that IKE provides. Thank you for this clarification. -- = ] Never tell me the odds! | ipv6 mesh networ= ks [ = ] Michael Richardson, Sandelman Software Works | network architec= t [ = ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ = = From nobody Mon Oct 31 18:29:09 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A91331293DA for ; Mon, 31 Oct 2016 18:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=philips.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEjEN25gNwTh for ; Mon, 31 Oct 2016 18:29:05 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0787.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::787]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E671912945E for ; Mon, 31 Oct 2016 18:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Philips.onmicrosoft.com; s=selector1-philips-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RYC1oADYyN2gq+wPRJ4oLVUIHNeQk1Ch9ZZ8Gvk6XRU=; b=TZQG2yyfYVFNgnUV0+8C7doH/Aa00hkc/y5hEfwAXe4uEPsSkHUfdqdzF4mKNwfblBSrl0MMppsBVtVgp6sU/MuL8bM9wHCGb4NYMQRb0tq73hs25lWNyv6+X/YFukVSYi2Re+LBKO/hN/VL9m6IerK8/2O/hm8rU57RNP55OlA= Received: from VI1P122CA0001.EURP122.PROD.OUTLOOK.COM (129.75.100.79) by DB5P122MB0021.EURP122.PROD.OUTLOOK.COM (129.75.100.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.12; Tue, 1 Nov 2016 01:28:48 +0000 Received: from DB3FFO11FD056.protection.gbl (213.199.154.83) by VI1P122CA0001.outlook.office365.com (129.75.100.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.12 via Frontend Transport; Tue, 1 Nov 2016 01:28:48 +0000 Authentication-Results: spf=none (sender IP is 40.103.22.100) smtp.mailfrom=philips.com; iki.fi; dkim=none (message not signed) header.d=none;iki.fi; dmarc=none action=none header.from=philips.com; Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts) Received: from 011-smtp-out.Philips.com (40.103.22.100) by DB3FFO11FD056.mail.protection.outlook.com (10.47.217.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.6 via Frontend Transport; Tue, 1 Nov 2016 01:28:47 +0000 Received: from HE1PR9003MB0234.MGDPHG.emi.philips.com (129.75.99.147) by HE1PR9003MB0235.MGDPHG.emi.philips.com (129.75.99.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.12; Tue, 1 Nov 2016 01:28:46 +0000 Received: from HE1PR9003MB0234.MGDPHG.emi.philips.com ([129.75.99.147]) by HE1PR9003MB0234.MGDPHG.emi.philips.com ([129.75.99.147]) with mapi id 15.01.0693.009; Tue, 1 Nov 2016 01:28:46 +0000 From: "Garcia Morchon O, Oscar" To: Tero Kivinen , Michael Richardson Thread-Topic: [IPsec] FW: Quantum Resistance Requirements Thread-Index: AdH0G8ijQKeg6MaXRiG9vXmtSf0/rwUZFu7ACMepu6AAD1cOEAFR877AAASlU4AAlPE9AAAUR9ng Date: Tue, 1 Nov 2016 01:28:46 +0000 Message-ID: <70be9d19b5d349599e783152f0a1cad5@HE1PR9003MB0234.MGDPHG.emi.philips.com> References: <6c1585204f6a4598b6e40b05912ba4c4@XCH-RTP-006.cisco.com> <29931.1477671349@obiwan.sandelman.ca> <22551.24894.457412.805177@fireball.acr.fi> In-Reply-To: <22551.24894.457412.805177@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [209.6.209.22] X-MS-Office365-Filtering-Correlation-Id: 2ea5310c-26fd-48dc-e3d4-08d401f66dbf Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: HE1PR9003MB0235.MGDPHG.emi.philips.com X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:40.103.22.100; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(2980300002)(428002)(85714005)(199003)(189002)(55904004)(377454003)(374574003)(13464003)(189998001)(97736004)(19580405001)(54356999)(50986999)(106466001)(5001770100001)(92566002)(50466002)(105586002)(21840400001)(68736007)(76176999)(8676002)(356003)(81166006)(11100500001)(19580395003)(101416001)(15975445007)(81156014)(97756001)(86362001)(7846002)(46406003)(2950100002)(8746002)(8936002)(7736002)(10400500002)(33646002)(305945005)(626004)(69596002)(87936001)(66066001)(108616004)(6116002)(2900100001)(5660300001)(2906002)(4326007)(47776003)(24736003)(7696004)(586003)(23726003)(102836003)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5P122MB0021; H:011-smtp-out.Philips.com; FPR:; SPF:None; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DB3FFO11FD056; 1:yJXsfwbaOYrmExgUclef7SbEmDlVaPFvd3qgM4cayuSV+8/0nQhB853/4YpXOmBSIXRqPpABIiCMBGXqvGtIFNYaxlPqzGEEqfvfuleuHU8OJ6KN1RS+fEJMBbTgnTRxDjCoGomka8BocC4E9Rb3ebiy9Vz3MHVHc4xGKSdcEEx1Xso/rQ9CfxebaD0tDeL9EGNgg+uenDPoahxiSTc6swAAEvkcgquwZuNekSVnOyFEtxXCcfStSfJiqvUbFAiLcFru2SIaBaXMNGnXpnBZaAQ1Ra3fIYYATq+8D89nydeZempHyohcBOsZ7U3qPDl/aXbxT4ac/vpW8S7WbNuzKlAHeMY4CtdXbhkVVJgAL1ytH2HF+kebV0w+ymoqp9Ep6qSlZesQNS7/vK4xI3cAOsAW5ejQj2NYmVvfrQySt/AZYUGLfyK+naO0QLEIU3ERfhXVGxtHQf4Z5SVkhOzOdhAgOzvdEMYfSGxJ1vKm+9xZ98Mhl8DG5J2b2bngwd3FQR8qBy+IVVWtoWJ3SEw2Jw== X-CrossPremisesHeadersFiltered: DB3FFO11FD056.protection.gbl X-Microsoft-Exchange-Diagnostics: 1; DB5P122MB0021; 2:O6iHY2TvEBVpCDSxkdv9qMd6G1a4U/qsUiMm8O4kXz+6+Opdk5U7Y+MKudpvBl+Mny+MRclEqHEjqBkBr/ukPfXaNwHuHSpqKacK2PjXNKcF1JGdSaJRgegLR+960+IF74KDYoZ048I3OijF/o6YEaiYRok8ebl1wSKODWRCcjR1AkiwKSTm/9iGbMx3VPsHlGROB2gDmXuic0uezXmfdw==; 3:MNpJRiUB5tPxNZTd/jjg+Ho1UZXSWI3mVPxSjvsFk/a2t+K5uajejbbMPuTlWUM2nwXcB0mv7jEXLycojCGgzJdtwiy3uSQuWDphxeyLBlWwczJJPkKKS19RyTrsPPK3YsgMC7iw37kTXSjl9J5/ItLuJNGH5zYsdGZbdh8vCoMMtaR8ExfTHrjIxZGq+hdF20NmQg8B5/ACeDW4oWPO2/maukMYkerkCMbl+25gidCB7tiSSaFr99pQh9bdxoX7; 25:zU2OO0wOefvOoWElh7t2oREr1f8FbAPCsIxeLk0Tc0sxG2Q+600xSs46qnoztNodgMKKtbKabmCjkmV9y7cUNe/mhPjWXsKRulACknBKEsSGZbgf1blgcouwM7bZTBPZ+vaMHyA36dM/93SxA0GBXsNjr/Dxo/FGEVkB1NFbs+l9i+ZNF31Ci72OSFtvJV4SOcMzfTl31hHzXBGFjn7uAM+giPj6Lq06oNWiBbl6AM1Hti0+pyH/JG+4HNhvPmn9seW712lYEpRZB1lAM/n//XYKEFQnJlF4sW6IiQ//Kg2dqrrDY9kHzszhIUD6buvCKMOgFr8KXxsbYqrPrxzgzyIpBCbm2BN/9VjuSTrBBsXa4jGXGcmzmj3aGndP+0aZibohbdCS7PUagdKWweTdtDaOfWedgoGTNZ8/KxXVR2a0T7uYlLTABpyfLQq6+wGe X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5P122MB0021; X-Microsoft-Exchange-Diagnostics: 1; DB5P122MB0021; 31:dadgo17Sh6P+1jZqAPS8MZQ80bITMZghip8vgcliB4NvifS6ptDAXdRW3UH3iPFDf5OmsrmKTRU3Tz5QU+vBp6iYEmgWH+99o0hw/rM6UJPIMPlhITpiKPFL6hgXv8DESQXaEr24vBAN6lWOoAsbVxYcWLADKAyG0RDrJ05nDGf+XGIlrtJJYQbOCrwLgTEAvqrorXbrlQK0ZNAQPOAfyHq9HxSsXihU5hhVmdp5cnBiaBEqEkM1pSov9iUZFEHy; 20:lSjA6N0XETRxDtRuWeUvlZPCku7atDFRtgSGlsE8v8JWpBH9apkIRL2TIDJV+N+up7C7/eWr6lDwPS8o0fuwefmx1kl5TPVytp2xObCGaHdcOZhS88rd4zk4p5krBdHDNSksoqpFyOZCAC8knYeCR9IIFfMZRzMRKpUCB4s+EG6WNZQEy/jc3oG3SwwBDNnZz6WG4QlQ2zkD2Bcynh+5/BbjO8rc+sypMwhP/GxH28E4aMGd0QOO2zCoEYqtjp0LW2yW3/bn26+axHAGmpG7dbaT81PI2GJC+KjfOs23+LlOmdtTAeS+85XxdHaQITYxnmAV2FzipWM+h6GHP/KodCf+bxjFLqXfjC/Zw9uOdkyR2LAhH/XpG7wWEslQYNm23Wq3GRn1Ba7d5asPlE0ITSijdnXnF305NW0vjby20/jgFQvQker3TkxLiANNvgXXi6H+KMoQxf3boGosnJT+KpgLlePvwWXLNOlotxikBuSeZlNaprGiW1Nw8CYKD85M X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(2401047)(8121501046)(13018025)(5005006)(13016025)(3002001)(10201501046)(6055026); SRVR:DB5P122MB0021; BCL:0; PCL:0; RULEID:; SRVR:DB5P122MB0021; X-Microsoft-Exchange-Diagnostics: 1; DB5P122MB0021; 4:aRDWFKJ0OlvE6pOI4L75ajjPgEQCwP63xtEwcgD2npiz9xoLVKImI1wERYzgONKbqANnLYqX6GAWjkhYYChrICkLZx0eGCGPHOEaPbiU+u3+odZ0hN3SzwY3+c/W/VAAlsDOjwlS30VtFUNo/3L91hn1x7IK1XiDLnVg5Ro7T00YqR+P4ucWvwbQ8fgq7+JnvPNO/rrdSvix6QDUgYKQ7CZXl0SCOpgYPqkzLopngwbtRJUFt/0jekWaVSwIYXqXyHaaXYCeyxnbuFul2FT+5rabGM8Atmy5q0m0PNreSr/Epurhf9wXzAVyxdetuG9dpamLA/HvHyPebLpBvWLXsUmnv5WQez7N6GGiG5SKNhEWGwC8JEKOXWZ4OBlkLpIbNmGU1Ff4FvjrfQtD9/IAAYZfzFYC2iCdE4+k3P8Ne6x692QetNJGyXzMg1w+9Xg7yZ+TcOweZjOfGNvE58wCYuagCWtn5t3lLhETaDaG6Ps= X-Forefront-PRVS: 01136D2D90 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DB5P122MB0021; 23:z4QQHFQNLwIJTaArtoFHY/feyIUQB9K5/kehcVgGj?= =?us-ascii?Q?6KG0YZjKjKBROvn+XiiAH6VQd0YEkjSAzZuLWtdInMu3VrDDvBsEflTy129Y?= =?us-ascii?Q?Zr85TrtqnVtUp4df20sllnTni07xleBioofdfPmujk2qZrP1BxhsSJnsSW1l?= =?us-ascii?Q?lGXq4KvCGd8OqqMsnSWp5BIL+IsneDP7yYsAXaC+boAvqmWZg7Ybuq28RDrx?= =?us-ascii?Q?IzciVVZ3ppAAKxCrzDGvp4m6fSFVbBP1isTmAei1/ybnE4mdKQRgBN2zoPCc?= =?us-ascii?Q?rsi137XLLoUvPbUbl8vjq2FwZQDdNLpnNDqWzUaqSzS/laFCr7ry1hp6Xd8f?= =?us-ascii?Q?SeKU7UVdJ+F46YlATgpmq7nD1Lf3Mi+90eGN2p9FIafwH/06mf0WX1W6mv72?= =?us-ascii?Q?x/gjmDc6wo05sm4wKDpCaE9BUnpqB9KESYZPl7noiLQ16ob27SdGxn3mkSSq?= =?us-ascii?Q?KT6YB2Rtv7ktEUAz6oidEJF8PIqeB15SOyOJn2026vVrQPd4qbiq/Qq7dfTW?= =?us-ascii?Q?XA3Etv0uL257l7xH7QPx5gSaks/3ie5XTLPXPKeEN8bPrVOrU+xGa39Nm3jv?= =?us-ascii?Q?SCoK6Q9EjV9h3flDMh66sxPIrrT5oQrPDX3m74qmupDg3/cLa/fSnqAAxE7x?= =?us-ascii?Q?/7Kd2rYrmcU3sH4enugHB3VElFDrYos1xXFF6Yq7EjZ2Opvp0WUVidFu17V1?= =?us-ascii?Q?qoOEQ5GERAW1rXFQ7M6e2Rd+zxU1kxxscYgy0lKcz1fl5talUOFT8bAvE/Z8?= =?us-ascii?Q?/7zL09AqJGjCCGnCEqFdFhd6enKV2+DIQ/NaTRfZ9tYzd3sZBhQtAZqEcl7K?= =?us-ascii?Q?K7xag88EPejnRRnyE2QpQvwBwghwMnTS1BgU6ixNsnstSXJwUjDzyHgLBHDr?= =?us-ascii?Q?RRNqAgqONmPnW/AiNyEDsCARIi1S4xyX7UTsszd/L5shcZb4VuXDrj36IeQV?= =?us-ascii?Q?5JXWYrWmm+n9YnrH2WBamzsRvPHk7XCIl9y0xv+RIo3d3WfqDczfCyD/h4Pz?= =?us-ascii?Q?1HkJx8Xd27sFzMIMSVf+MsZAgon+l7gyO6OxYDtiqAHjnw4HyOdN+R0mif7E?= =?us-ascii?Q?z/evb5iB50VI4zBUpMlSbRUI5bzGg+18cfny8llFxXEPCSnZtHXl+EYKaB3x?= =?us-ascii?Q?6Z5smnOIVsMj841zKrSczJiZhqZkbW1vIeVPlYYLdkdw5vogQMbj/1vLDEox?= =?us-ascii?Q?3G3ClIDG0pMzMx8jimUkP/Vz4ygf27u/VcsQ4mxLYtqJqeduPpAvR6ZDuOPJ?= =?us-ascii?Q?s92LfZQQPz3qZbdWUGWaCGNOoYDo/d+/TMasG8rJqwTy2PXiH7jGnpc7bH/B?= =?us-ascii?Q?jK1IYcR+WqZKOYsQn/rfxOzyZusuuqtoBeT+D5Qi3oPbM3aJsgHPk2Fb31Wc?= =?us-ascii?Q?SBIlpIg2XV3eooAJmcfzNqZLIAnrZ8VRexnzHzIM92lkq0JWgj7ljyPevUxY?= =?us-ascii?Q?1SN4pbl3arpG59iWSzBQGN57fm2pAhk2XgF9YenjcrZ96OUB1kF?= X-Microsoft-Exchange-Diagnostics: 1; DB5P122MB0021; 6:qyzEcgZMPaO1q4QDjFsNSp6ZD1FJc82Qk36HRS47+n9IisFXnZ0f8IjViC69VOgfAa3eGwAODgYikkJ2ziJBtNVc/vekos+qRe3lrJk5ut5v2EWrwrd/t794sp958NiUJ1cwXFGADmdZBqUj//Fdfl146odjarSbCGg7J/LlV2BXIgf28ezV4rLa7Sk20DMN5DT/ibuqVN6cs6lU8ByTY3xl7JaqJ6NFeF21s+GROXBXmKQj+fq33cVy4nZLMs6/wM7Kv+zlkn6SCEQd8suBnu7iP//p5kfFgvf48wvzgh8d97ItEwVen8cJI6puiWf9IOXFxyX72tImLYppUSy2sMcJzqy9AuHCBWgTJfnOw5Y=; 5:1r6s3WgNcf4Ir18YUR8ZRj8lCzsGhTW7fSVRTZI5w628sV8NVebHSk9bGJkNPheFAFhlwjcOHO7JA/7rdg5Sg04y6sG6UWzdxmaLGAjudeDbJMpaA7ZEOK1wv44XVVka9thysJQIAq8Iib8Jb2aCiw==; 24:1g81AfP2CzAO5s7qhfDqSS9cEiFEy6ZfmGemHI4ZowaovyssN/57aZ/HR6aqG7FaW1MrgyTjf/C3i9D1QMS6PTDOwDVtiKVzNK3daDr0/XA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB5P122MB0021; 7:SwXJ2ruhBFUsXV+3C7uSjre1zol8kg4lNYyZtdaXIkEjl1f9xs8mC+VaS4L+trg+mJf4XKGeolNgGtcdNTbhrNsnQFJHeLqnI1GzgcwYEcVJrMpDYoMcliodk8qzeHztKqfwiYNEMr+uNLt92Q3dZm3U5NUpaqJjl6Hfn74eecgMHRJhrLRLjiMcm+InJwn8Hut3a/L1RjPmxhiMjj0yCPGwoBW/jgX8iapiWW6/OxBcvsZuOrPK19HZa6/KlRkAq6S8Z8pSXcOmeJW/tV6LOV/0ZtCNAdvlLVK+gP0ZAU/IuLQVrsIMDWoz+ArQJQPRRO1tjCSNDrXyKD8lT57gbW/mENg4UwQkhP8cTK2QUJM= X-OriginatorOrg: philips.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Nov 2016 01:28:47.9865 (UTC) X-MS-Exchange-CrossTenant-Id: 1a407a2d-7675-4d17-8692-b3ac285306e4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=1a407a2d-7675-4d17-8692-b3ac285306e4; Ip=[40.103.22.100]; Helo=[011-smtp-out.Philips.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5P122MB0021 X-MS-Exchange-CrossPremises-OriginalClientIPAddress: 40.103.22.100 X-MS-Exchange-CrossPremises-AuthSource: DB3FFO11FD056.protection.gbl X-MS-Exchange-CrossPremises-AuthAs: Anonymous X-MS-Exchange-CrossPremises-AVStamp-Service: 1.0 X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-Antispam-ScanContext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-Processed-By-Journaling: Journal Agent X-OrganizationHeadersPreserved: DB5P122MB0021.EURP122.PROD.OUTLOOK.COM Archived-At: Cc: "IPsecme WG \(ipsec@ietf.org\)" , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] FW: Quantum Resistance Requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 01:29:07 -0000 > I'm very concerned that we don't wind up with insecure Group PSKs as > we had with IKEv1. This description does not reduce IKEv2 security - the PPK is used next to I= KEv2 security. Furthermore, the description can also support pairwise keys. I had a look at the description, and a later addition of a scheme such as H= IMMO is straightforward and such scheme can generate all those pairwise key= s very easily. Instead of exchanging a PPK identity, you exchange the HIMMO identity that = is used to generate the pairwise PPKs. Since the generated keys depend on the exchanged identities, the scheme cou= ld also provide authentication. The communication overhead is very small (a few tens of bytes). -----Original Message----- From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen Sent: Monday, October 31, 2016 11:21 AM To: Michael Richardson Cc: IPsecme WG (ipsec@ietf.org); Scott Fluhrer (sfluhrer) Subject: Re: [IPsec] FW: Quantum Resistance Requirements Michael Richardson writes: > > - Authentication; if someone with a Quantum Computer can break the = DH > > in real time, do we care if he can act as a man-in-the-middle? Sco= tt > > Fluhrer: not important Michael Richardson: important, provided that= we > > don't run into the same issues that IKEv1 PSKs ran into Tommy Pauly= : > > not important Valery Smylsov: this would be nice to have Oscar > > Garcia-Morchon: this would be nice to have > > I'm very concerned that we don't wind up with insecure Group PSKs as > we had with IKEv1. As this document is written (or how I think it is written, as I have not ye= t had time to read the latest version), the PPK used to provide to quantum = resistance is not used in the authentication, there is still normal IKEv2 a= uthentication step using normal IKEv2 shared secret, or certificates. So ev= en if the people would be using group PPK, that would not allow similar iss= ues than what happend with IKEv1. Of course everybody sharing the same PPK will be able to attack other users= of the same group by just breaking the Diffie-Hellman :-) On the other hand even if you know the PPK, you cannot do anything without = breaking the Diffie-Hellman, as it does not allow you do to man-in-the-midd= le without breaking the normal authentication. So, yes, there is some dangerous things that can happen, but I do not think= it will be reducing IKEv2 security even if such insecure practices are use= d (except than it will reduce the quantum resistance provided by PPK, if ev= erybody knows PPK). -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From nobody Mon Oct 31 18:45:34 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A28212949D for ; Mon, 31 Oct 2016 18:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTys2T4jItwU for ; Mon, 31 Oct 2016 18:45:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ECD8129477 for ; Mon, 31 Oct 2016 18:45:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUH14801; Tue, 01 Nov 2016 01:45:29 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 1 Nov 2016 01:45:29 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Tue, 1 Nov 2016 09:45:23 +0800 From: Xuxiaohu To: "ipsec@ietf.org" Thread-Topic: New Version Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt Thread-Index: AQHSM2gb01BpbARQ5EG6ZJX9p7ME46DDW/lw Date: Tue, 1 Nov 2016 01:45:22 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BB272FF@NKGEML515-MBX.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.184.181] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.5817F3B9.0163, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 24802ab53e8814a906b474a7b5c9925e Archived-At: Subject: [IPsec] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g?= =?utf-8?q?for_draft-xu-ipsecme-esp-in-udp-lb-00=2Etxt?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 01:45:33 -0000 SGkgYWxsLA0KDQpBbnkgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLg0KDQpC ZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7 tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnXQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTblubQxMOaciDMx5pelIDE5OjE1DQo+IOaUtuS7 tuS6ujogWHV4aWFvaHU7IHpoYW5nZGFjaGVuZzsgWGlhbGlhbmcgKEZyYW5rKQ0KPiDkuLvpopg6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQteHUtaXBzZWNtZS1lc3AtaW4tdWRw LWxiLTAwLnR4dA0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC14dS1pcHNl Y21lLWVzcC1pbi11ZHAtbGItMDAudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0 ZWQgYnkgTGlhbmcgWGlhIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+ IE5hbWU6CQlkcmFmdC14dS1pcHNlY21lLWVzcC1pbi11ZHAtbGINCj4gUmV2aXNpb246CTAwDQo+ IFRpdGxlOgkJRW5jYXBzdWxhdGluZyBJUHNlYyBFU1AgaW4gVURQIGZvciBMb2FkLWJhbGFuY2lu Zw0KPiBEb2N1bWVudCBkYXRlOgkyMDE2LTEwLTMxDQo+IEdyb3VwOgkJSW5kaXZpZHVhbCBTdWJt aXNzaW9uDQo+IFBhZ2VzOgkJNw0KPiBVUkw6DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC14dS1pcHNlY21lLWVzcC1pbi11ZHAtbGItMDAudHh0DQo+IFN0YXR1 czoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQteHUtaXBzZWNtZS1l c3AtaW4tdWRwLWxiLw0KPiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXh1LWlwc2VjbWUtZXNwLWluLXVkcC1sYi0wMA0KPiANCj4gDQo+IEFic3RyYWN0 Og0KPiAgIElQc2VjIFZpcnR1YWwgUHJpdmF0ZSBOZXR3b3JrIChWUE4pIGlzIHdpZGVseSB1c2Vk IGJ5IGVudGVycHJpc2VzIHRvDQo+ICAgaW50ZXJjb25uZWN0IHRoZWlyIGdlb2dyYXBoaWNhbCBk aXNwZXJzZWQgYnJhbmNoIG9mZmljZSBsb2NhdGlvbnMNCj4gICBhY3Jvc3MgSVAgV2lkZSBBcmVh IE5ldHdvcmsgKFdBTikuIFRvIGZ1bGx5IHV0aWxpemUgdGhlIGJhbmR3aWR0aA0KPiAgIGF2YWls YWJsZSBpbiBJUCBXQU4sIGxvYWQgYmFsYW5jaW5nIG9mIHRyYWZmaWMgYmV0d2VlbiBkaWZmZXJl bnQNCj4gICBJUHNlYyBWUE4gc2l0ZXMgb3ZlciBFcXVhbCBDb3N0IE11bHRpLVBhdGggKEVDTVAp IGFuZC9vciBMaW5rDQo+ICAgQWdncmVnYXRpb24gR3JvdXAgKExBRykgd2l0aGluIElQIFdBTiBp cyBhdHRyYWN0aXZlIHRvIHRob3NlDQo+ICAgZW50ZXJwcmlzZXMgZGVwbG95aW5nIElQc2VjIFZQ TiBzb2x1dGlvbnMuIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhDQo+ICAgbWV0aG9kIHRvIGVuY2Fw c3VsYXRlIElQc2VjIEVuY2Fwc3VsYXRpbmcgU2VjdXJpdHkgUGF5bG9hZCAoRVNQKQ0KPiAgIHBh Y2tldHMgaW5zaWRlIFVEUCBwYWNrZXRzIGZvciBpbXByb3ZpbmcgbG9hZC1iYWxhbmNpbmcgb2Yg SVBzZWMNCj4gICB0dW5uZWxlZCB0cmFmZmljLiBJbiBhZGRpdGlvbiwgdGhpcyBlbmNhcHN1bGF0 aW9uIGlzIGFsc28gYXBwbGljYWJsZQ0KPiAgIHRvIHNvbWUgc3BlY2lhbCBtdWx0aS10ZW5hbnQg ZGF0YSBjZW50ZXIgbmV0d29yayBlbnZpcm9ubWVudCB3aGVyZQ0KPiAgIHRoZSBvdmVybGF5IHR1 bm5lbHMgbmVlZCB0byBiZSBzZWN1cmVkLg0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3Vi bWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxh YmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K