From nobody Wed Mar 1 07:45:29 2017 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 484C4129590; Wed, 1 Mar 2017 07:45:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <148838312325.6997.2801529466089088877.idtracker@ietfa.amsl.com> Date: Wed, 01 Mar 2017 07:45:23 -0800 Archived-At: Cc: draft-ietf-ipsecme-rfc7321bis@ietf.org, ipsec@ietf.org, ipsecme-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, david.waltermire@nist.gov Subject: [IPsec] Last Call: (Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 15:45:23 -0000 The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-03-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc7321bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc7321bis/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Mar 3 15:58:59 2017 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 BC93A12966D; Fri, 3 Mar 2017 15:55:27 -0800 (PST) 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.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858532776.15846.10187900663867336952.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:27 -0800 Archived-At: Cc: ipsec@ietf.org, Kathleen.Moriarty.ietf@gmail.com Subject: [IPsec] ipsecme - Requested session has been scheduled for IETF 98 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, 03 Mar 2017 23:55:29 -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) Friday, Afternoon Session I 1150-1320 Room Name: Zurich B size: 100 --------------------------------------------- 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 Third Priority: uta 6lo dane tcpm netmod People who must be present: Kathleen Moriarty Tero Kivinen David Waltermire Resources Requested: Meetecho support in room Special Requests: --------------------------------------------------------- From nobody Wed Mar 8 10:49:12 2017 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 BD3891294EA for ; Wed, 8 Mar 2017 10:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, 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 4NSkWIkheofr for ; Wed, 8 Mar 2017 10:49:09 -0800 (PST) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 325E312944E for ; Wed, 8 Mar 2017 10:49:09 -0800 (PST) Received: by mail-it0-x231.google.com with SMTP id m27so46589381iti.1 for ; Wed, 08 Mar 2017 10:49:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=3mrHhuURXCuESlA00yBwLlnvN75R8VDOXnVqsrWxx9Y=; b=EYTHYi+C8mrS25eu5owOEztthjxaoOASwVSKL8wxSprlBtONoMD5EzP6QPy/njxmmu btB+JKEXtuPhuBu7kt+46cAq7VkjAm2AbmkFdFvMHNNGBz9uZk3N0BC4alFPIJHotXjn Xj8vuxpImqCxLwSZFKbSj+9IK5lOhRrzZOkGYyi5F7h606jssuF+yyK1ILQp9s4WWLvb cuu/7BTAEYQusjhcs3XxdNgV7iNa/58IZn1kAxxXVUjN2gYdVcsspJ7q5CxkB99i1RyS p0FdMJ12V3PgpPLkt1N8XZs/pxUB7MMaYl9cVeV7GqdANLxFVgxEsJCb1eX3tIybDFcq /z4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=3mrHhuURXCuESlA00yBwLlnvN75R8VDOXnVqsrWxx9Y=; b=RGYfi+pOvvJae6AIKwo9BxwRMEVsIHoS/Z/wJwlysVGT2fkFmZjtawKLvRyNR4ZF/3 PQdGJvhSHTJm9DDuPu1iwBYr9TmEYgJKFIRaIAcrr03DuBsVpTGO0NxvBsNVwTCpLkAl un06RDU3YkDOnyw+zRJjvV4ih+JiF0505DAS6uTCzQYTmfa8BX3xjJ0TZ9r+23mNEJYD 6BOkcIb91sKxTAbxszexA8rWS+WrqOdExtgeJaGczgxMESc13NC8aeqnpscT2IlWcm5o 2kRQlmFFyiU1axC9lCifrIajB5winXJ7N3pzlzm2cWYNKHM4s90SbysmzvpwGzwWYdE0 aEUg== X-Gm-Message-State: AMke39nbOoEpiUjlvGykEqCSBGKFlCuiP61m8cmlxhgveM31j1iEoihVor0BGBCp0kiO1in2GOOirx6L1+fNNg== X-Received: by 10.107.168.21 with SMTP id r21mr7095903ioe.45.1488998948482; Wed, 08 Mar 2017 10:49:08 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.35.213 with HTTP; Wed, 8 Mar 2017 10:49:07 -0800 (PST) In-Reply-To: <22692.28549.958589.705943@fireball.acr.fi> References: <22683.8182.349840.103676@fireball.acr.fi> <22684.25414.470545.969594@fireball.acr.fi> <32d17f6f-3b55-a275-9fe5-960833899780@strongswan.org> <22692.28549.958589.705943@fireball.acr.fi> From: Daniel Migault Date: Wed, 8 Mar 2017 13:49:07 -0500 X-Google-Sender-Auth: 1sZ4-UWPb0U7iuQ-kyb15qVwUF4 Message-ID: To: Tero Kivinen Content-Type: multipart/alternative; boundary=001a114215e865422c054a3c95e9 Archived-At: Cc: "ipsec@ietf.org" , David Schinazi Subject: Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00 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, 08 Mar 2017 18:49:11 -0000 --001a114215e865422c054a3c95e9 Content-Type: text/plain; charset=UTF-8 Hi, Please find my comments regarding the draft. I believe the draft is ready to be moved forward. I do not have strong opinion on the value to assign. Yours, Daniel The Internet Key Exchange protocol [RFC7296] can use arbitrary signature algorithms as described in [RFC7427]. The latter RFC defines the SIGNATURE_HASH_ALGORITHMS notification where each side of the IKE negotiation lists its supported hash algorithms. This assumes that all signature schemes involve a hashing phase followed by a signature phase. This made sense because most signature algorithms either cannot sign messages bigger than their key or truncate messages bigger than their key. EdDSA ([I.D-eddsa]) defines signature methods that do not require pre-hashing of the message. Unlike other methods, these accept arbitrary-sized messages, so no pre-hashing is required. These methods are called Ed25519 and Ed448, which respectively use the Edwards 25519 and the Edwards 448 ("Goldilocks") curves. Although that document also defines pre-hashed versions of these algorithm, those versions are not recommended for protocols where the entire to- be-signed message is available at once. MGLT: I think that a pointer for the recommendation should be provided - section 10.5 of I.D-eddsa. The first sentence of the paragraph above confuses me. Although this si true, I prefer to say that EdDSA ([I.D-eddsa]) defines signatures methods that includes pre-hasing as well as signature methods that do not require prehashing. Following the recommendation of Section 10.5 I.D-eddsa, the pre-hash variant SHOULD NOT be used. Given the title, it would be more appropriated to have the first paragraph here. EdDSA defines the binary format of the signatures that should be used in the "Signature Value" field of the Authentication Data Format in section 3. The CURDLE PKIX document ([I.D-curdle-pkix]) defines the object identifiers (OIDs) for these signature methods. For convenience, these OIDs are repeated in Appendix A. MGLT: Note that the pkix document is still on discussion. -- Although IOD seems out of the scope of the discussion. In order to signal within IKE that no hashing needs to be done, we define a new value has in the SIGNATURE_HASH_ALGORITHMS notification, one that indicates that no hashing is performed. On Wed, Feb 15, 2017 at 10:11 AM, Tero Kivinen wrote: > Andreas Steffen writes: > > I personally think that 0 would have been legitimate for the "Identity" > > hash but the next unassigned value (5) is also ok for me. > > > > Could you please ask IANA for an early assignment of the code point? > > strongSwan 5.5.2 with Ed25519 support is ready to be deployed, > > thus we would be able to release the stable version as soon as > > the code point has been assigned. > > Before we can make code point allocation, we need to agree on whether > it is going to be zero or next number. As you can see from the emails > in this list there is not agreement on this yet, so even if authors > make IANA request to ask for assignment, when it comes to me (as for > expert review) few days later, I would wait for the comments on the > list to agree on which number we are going to allocate. > > Now it seems more people are supporting allocating something else than > zero... > > As for the process: > > > > As this is expert review registry there is no need to ask for early > > > allocation, the normal process is just to fill in the IANA general > > > request for assignments, which then goes to the IANA and they will > > > then send it to the expert (me) for verification. > > And then we will then come back to this list to finish this > discussion... > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --001a114215e865422c054a3c95e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please find my comments regarding t= he draft. I believe the draft is ready to be moved forward. I do not have s= trong opinion on the value to assign.

Yours,

Daniel

= =C2=A0=C2=A0 The Internet Key Exchange protocol [RFC7296] can use arbitrary=
=C2=A0=C2=A0 signature algorithms as described in [RFC7427].=C2=A0 The = latter RFC
=C2=A0=C2=A0 defines the SIGNATURE_HASH_ALGORITHMS notificati= on where each side of
=C2=A0=C2=A0 the IKE negotiation lists its support= ed hash algorithms.=C2=A0 This
=C2=A0=C2=A0 assumes that all signature s= chemes involve a hashing phase followed
=C2=A0=C2=A0 by a signature phas= e.=C2=A0 This made sense because most signature
=C2=A0=C2=A0 algorithms = either cannot sign messages bigger than their key or
=C2=A0=C2=A0 trunca= te messages bigger than their key.=C2=A0=C2=A0
=C2=A0=C2=A0
=C2=A0= =C2=A0 EdDSA ([I.D-eddsa]) defines signature methods that do not require=C2=A0=C2=A0 pre-hashing of the message.=C2=A0 Unlike other methods, these= accept
=C2=A0=C2=A0 arbitrary-sized messages, so no pre-hashing is requ= ired.=C2=A0 These
=C2=A0=C2=A0 methods are called Ed25519 and Ed448, whi= ch respectively use the
=C2=A0=C2=A0 Edwards 25519 and the Edwards 448 (= "Goldilocks") curves.=C2=A0 Although
=C2=A0=C2=A0 that documen= t also defines pre-hashed versions of these algorithm,
=C2=A0=C2=A0 thos= e versions are not recommended for protocols where the entire to-
=C2=A0= =C2=A0 be-signed message is available at once.

MGLT: I think that a = pointer for the recommendation should be provided - section 10.5 of I.D-edd= sa.

The first sentence of the paragraph above confuses me. Although= this si true, I prefer to say that=C2=A0 EdDSA ([I.D-eddsa]) defines signa= tures methods that includes pre-hasing as well as signature methods that do= not require prehashing. Following the recommendation of Section 10.5 I.D-e= ddsa, the pre-hash variant SHOULD NOT be used.

Given the title, it = would be more appropriated to have the first paragraph here.
=C2=A0=C2= =A0
=C2=A0=C2=A0 EdDSA defines the binary format of the signatures that= should be used
=C2=A0=C2=A0 in the "Signature Value" field of= the Authentication Data Format in
=C2=A0=C2=A0 section 3.=C2=A0 The CUR= DLE PKIX document ([I.D-curdle-pkix]) defines the
=C2=A0=C2=A0 object id= entifiers (OIDs) for these signature methods.=C2=A0 For
=C2=A0=C2=A0 con= venience, these OIDs are repeated in Appendix A.

MGLT: Note that the= pkix document is still on discussion. -- Although IOD seems out of the sco= pe of the discussion.
=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0 In order to s= ignal within IKE that no hashing needs to be done, we
=C2=A0=C2=A0 defin= e a new value has in the SIGNATURE_HASH_ALGORITHMS notification,
=C2=A0= =C2=A0 one that indicates that no hashing is performed.


On Wed, Feb 15, 2017 at= 10:11 AM, Tero Kivinen <kivinen@iki.fi> wrote:
Andreas Steffen writes:
> I personally think that 0 would have been legitimate for the "Ide= ntity"
> hash but the next unassigned value (5) is also ok for me.
>
> Could you please ask IANA for an early assignment of the code point? > strongSwan 5.5.2 with Ed25519 support is ready to be deployed,
> thus we would be able to release the stable version as soon as
> the code point has been assigned.

Before we can make code point allocation, we need to agree on whethe= r
it is going to be zero or next number. As you can see from the emails
in this list there is not agreement on this yet, so even if authors
make IANA request to ask for assignment, when it comes to me (as for
expert review) few days later, I would wait for the comments on the
list to agree on which number we are going to allocate.

Now it seems more people are supporting allocating something else than
zero...

As for the process:

> > As this is expert review registry there is no need to ask for ear= ly
> > allocation, the normal process is just to fill in the IANA genera= l
> > request for assignments, which then goes to the IANA and they wil= l
> > then send it to the expert (me) for verification.

And then we will then come back to this list to finish this
discussion...
--
kivinen@iki.fi

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

--001a114215e865422c054a3c95e9-- From nobody Thu Mar 9 09:39:17 2017 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 1E4491296DC for ; Thu, 9 Mar 2017 09:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mG2SrbDfaFQg for ; Thu, 9 Mar 2017 09:39:15 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::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 0BF7A1296D6 for ; Thu, 9 Mar 2017 09:39:15 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id w189so31274437pfb.0 for ; Thu, 09 Mar 2017 09:39:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=p4Wxud1FCpPszgWIiPky7MdES4AxlkBGrvIWJ2IpI4M=; b=DlGn0z5sjXP8AOpxUGdCMi4Wyc1vDmbcVKDeMdkgwQ/6d/BPlSWB++Mgez7+NGkeS8 SJ4Z4rTvSF4/24an5PutKfIRgZvvQaKZRgM8vbeQyHPfa6FXovfPp+FphriaB6cyvzHC QUPcDjbaqoEfNgFhYNBgRf0PRoJ81Yufl13H2qb0lRslF7Twcs6LUn9VdCa61WNtv96T b8rV65k8sQ3pfpHwOxgzg0ENL+UtxDWnwwZe7mQ1TJQv8z1Xftzb/rB71/IUQ2xsyVZV 2RjBYti1AfPel584HPUTGQx6Wbt5uQEHtTFEjTqOJPhEmAJvpVM6kfMvnOO2yye7NroE QGlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=p4Wxud1FCpPszgWIiPky7MdES4AxlkBGrvIWJ2IpI4M=; b=okZ22QNN4kyJaguvDZJ/C848lLvVOpWuX0DSn1mKAin6O1cQuXLYD7Epg3vyVv61sj yg9EuNVlLMp5li+sdGCCapVZNml/CgYJOepKBl09HF/FdtM6rtohPV8MINKC2zC7tW/2 B5Y/KVRy7KaJYWb5DYqdCez3BVmC8nMW/7AX59yiuwSqQNYjfR3dpc7kY6eBn1Cioc2o Pdauiwa4vYQhbRZ/qr5IbP4LL6MrQXKfYJRbNcw1uA1pubaEKpvEoS1TZ74hEmh+XQqC ShHNpzyFT23mQ34rSksU01x2esSOBppePrfx/w78ikYiYmEajS9N37zzo0KqK2SP4gY6 rJTg== X-Gm-Message-State: AMke39njrRaRtd6rj4UGhmLqkAfcfFSwmWHAPCsu3zu0PUusmJ6DasSdAb4V0I495En5cw/lrgKWO1/G390ahQ== X-Received: by 10.84.232.9 with SMTP id h9mr18767416plk.102.1489081154471; Thu, 09 Mar 2017 09:39:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.177.199 with HTTP; Thu, 9 Mar 2017 09:39:14 -0800 (PST) From: Kathleen Moriarty Date: Thu, 9 Mar 2017 12:39:14 -0500 Message-ID: To: "ipsec@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [IPsec] AD review of draft-ietf-ipsecme-tcp-encaps 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, 09 Mar 2017 17:39:16 -0000 Hello, Thank you for your work on draft-ietf-ipsecme-tcp-encaps. It's a well written draft and I just have one question. Section 7: Why is SHA-1 used? If this is a result of the protocol and prior RFCs, please include a reference. And an explanation on list would be helpful (pointer is fine if this was already discussed. -- Best regards, Kathleen From nobody Thu Mar 9 09:47:52 2017 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 1E57F1296C3 for ; Thu, 9 Mar 2017 09:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 tf24D7aIySqK for ; Thu, 9 Mar 2017 09:47:49 -0800 (PST) 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 D28B1129554 for ; Thu, 9 Mar 2017 09:47:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1489081669; 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=X1DHt8s64dkQUWJcqlT55gpH3fzVIAWAWG7opiH9E1U=; b=KfN9IjZ6n4cNFnVMwJxR8Yodkp6KbK26nOyH++dgjZvZmaYkIC+C4YQoMImXyFbf KjxeQ3F5dOajMXnz9yZRpcgJsu0jw7zTkTfpC3/nqIcaRAtKfpvx9uKsTs/5M0JB 5yE08sxyaWnJpmVOzFiHTa/AL6luYXjuvYV2LDnz6EsGgWOkazdxOI0attAnZmO7 9pXhgKwE3Eqj6wUpcXd9FOtBDGShQ9WiWuTgAZCVPjt3C/rs9HfhotHlukq1d5Wj /FpAC/jgxeY9eYQq5KbRv53KE89QswolS6CvK48gSaS59sHOtGRS3NLn+il0PbMi MNwPFZI/D4gjoG+u0qHE6w==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id C1.87.24168.54591C85; Thu, 9 Mar 2017 09:47:49 -0800 (PST) X-AuditID: 11973e12-62fd39a000005e68-51-58c195459012 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by relay2.apple.com (Apple SCV relay) with SMTP id C2.48.25530.54591C85; Thu, 9 Mar 2017 09:47:49 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.226.23.61] (unknown [17.226.23.61]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OMK00KKF6ROSE10@nwk-mmpp-sz10.apple.com>; Thu, 09 Mar 2017 09:47:49 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: Date: Thu, 09 Mar 2017 09:47:48 -0800 Message-id: <25B4F448-EB83-4CE6-8714-38AC0A98AA9A@apple.com> References: To: Kathleen Moriarty X-Mailer: Apple Mail (2.3263) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUi2FDorOs69WCEwY5zOhb7t7xgs2jYme/A 5LFz1l12jyVLfjIFMEVx2aSk5mSWpRbp2yVwZTzb/5+14ABHxds7W5gbGC+wdTFyckgImEj8 vdnK2sXIxSEksJdR4tG0L6wwiZ5Ts6EShxgl5vxbxQiS4BUQlPgx+R5LFyMHB7OAvMTB87Ig YWYBLYnvj1pZIOr7mSQmb9jNClIjLCAhsXlPIkiNsIC9xOK+u2Bj2ARUJI5/28AMYnMKBEus +v+RCcRmEVCVuDEd4gZmIHvWhNtMEGttJDpWnAPrFRIIkPixfg5Yr4iAhcSa5m9Qz8hKdC+c xgxhr2CT+DjbeQKj8CwkV89CuHoWkqsXMDKvYhTKTczM0c3MM9FLLCjISdVLzs/dxAgK6ul2 QjsYT62yOsQowMGoxMM7I/tghBBrYllxZe4hRmkOFiVx3qLZByKEBNITS1KzU1MLUovii0pz UosPMTJxcEo1MIYLfFpjtadlccxqk23Hb6psqDCzmtqU8WW9sWLWrfxvy39Z7RPN/KZ2Tf3Q qU9rzrUdnbjY1y/N3lZPSnEJ0++vkxdXf7nB93qGWXBUzkSHh07ee1Lu/T7tUpmYIHI6eYXS 9cnX/oYx+k1hDPhm+fav6JHoo/d3pvVbcJ121a6edOmE8dkUjWVKLMUZiYZazEXFiQAfTj7d SwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42IRbCiu0nWdejDC4NZJNYv9W16wWTTszHdg 8tg56y67x5IlP5kCmKK4bFJSczLLUov07RK4Mp7t/89acICj4u2dLcwNjBfYuhg5OSQETCR6 Ts1m7WLk4hASOMQoMeffKkaQBK+AoMSPyfdYuhg5OJgF5CUOnpcFCTMLaEl8f9TKAlHfzyQx ecNuVpAaYQEJic17EkFqhAXsJRb33QUbwyagInH82wZmEJtTIFhi1f+PTCA2i4CqxI3pX1gh ZqpKzJpwmwlirY1Ex4pzYL1CAgESP9bPAesVEbCQWNP8DepmWYnuhdOYJzAKzEJy6SyES2ch uXQBI/MqRoGi1JzESiO9xIKCnFS95PzcTYzgMCx03sF4bJnVIUYBDkYlHt4Z2QcjhFgTy4or c4FBwcGsJMJ7ug8oxJuSWFmVWpQfX1Sak1p8iLEK6P6JzFKiyfnAGMkriTc0MTEwMTY2MzY2 NzGnirCSOC/Tsr0RQgLpiSWp2ampBalFMMuZODilGhgF21/rHvzfufz23z3qcxd2zLXNbDPy mqL9jOPfcwmDqY19aduLnXYdF7WTOnzz8JND6oy67u+TNvDkyK/j2/R15tKoNe7Nd/a+Vrl5 /m1fU1TE499TZ0UwfBDlXHXx6Gt1fj33peekT1/w4ftwqdvUX2/NVydXvetx22UVF6SrHOXf LHDu81RjJZbijERDLeai4kQAyJsRD54CAAA= Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-tcp-encaps 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, 09 Mar 2017 17:47:51 -0000 Hi Kathleen, Yes, this is referring to how the existing NAT detection works in IKEv2: https://tools.ietf.org/html/rfc7296 Section 2.23. NAT Traversal o The data associated with the NAT_DETECTION_SOURCE_IP notification is a SHA-1 digest of the SPIs (in the order they appear in the header), IP address, and port from which this packet was sent. We can add a pointer to the section of the RFC. Thanks, Tommy > On Mar 9, 2017, at 9:39 AM, Kathleen Moriarty wrote: > > Hello, > > Thank you for your work on draft-ietf-ipsecme-tcp-encaps. It's a well > written draft and I just have one question. > > Section 7: Why is SHA-1 used? If this is a result of the protocol and > prior RFCs, please include a reference. And an explanation on list > would be helpful (pointer is fine if this was already discussed. > > > > -- > > Best regards, > Kathleen > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Mar 9 10:48:26 2017 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 364F3129705 for ; Thu, 9 Mar 2017 10:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gY9xvE2bm68b for ; Thu, 9 Mar 2017 10:48:23 -0800 (PST) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 AA0491294F0 for ; Thu, 9 Mar 2017 10:48:23 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id o126so31920775pfb.3 for ; Thu, 09 Mar 2017 10:48:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hbEgtvCpYMDHY458tRPfCI8CuJiwHg1zm4Igas9gbEk=; b=RHZfEtuz6zPRmGvx0Yweegrr4J/OzyKfXm0a3ILkPwA9gQCRTRrRB3KtDNjLzGz51J RBFT3wTWVhCz0zXOAYDa8nPjYq7M2m5xv/VYa890WsdC8HpRMSBM+2xWGpGPDjqyZd3v M0QbkNn4RU2fyUTTUiq59MrNKbMpAXmTSXS+TOgLXGxmBFfkKqTLFWx3qTRPb34AVirg d6ZMx0jP40oVoIus9tJpHavUHj2hJOp27mJC4/oI7cmbQylGauWN3gkxz/MuTVRNFB8v +LJX1nyI3YsgVaPCju887FSv+N4pIk1Cs3cRVAEeGffXncMR08S9GI7kIBqi9+CgGJZF kMkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hbEgtvCpYMDHY458tRPfCI8CuJiwHg1zm4Igas9gbEk=; b=Wjs/fWc/GbfzUh1gi/bmWVpSrekkOuM1KIe8zaqbYELJQnwTa1Xf6XxoUnrasEfboR +Y+A/1sT92alAX5+C0O+ApD6dCyAWYofbHWvIDTfCda1QGSEYwFGr4PvRZAvCAUR/EDI 99UipEsoseYyHnvG+Lr2R4ga9qyZcTT+/hZn8k1wSCVmUmNdBXuxqNCiBpde6sDqBGnB W+TyiPpprNr9aTzvzKUPvMcTvzweLjwDLNQNyXWpWE4gKvfGxIyrJe46YZxdrGSRAIeX CfYpT9Yu++DyzDg0aygfH6oTCOKnAc9rwsHogH+r2E7fcfumULj2LDigBlFyHxv3T71n PVqg== X-Gm-Message-State: AMke39ly/3aGmshuMtEEE9W5wifE9L6mpV0zIvCtIk0wtsfQEoCufdlH5CupfQ8vOytJWsO/0Do92nT/yGcTYQ== X-Received: by 10.98.32.24 with SMTP id g24mr15661794pfg.115.1489085303235; Thu, 09 Mar 2017 10:48:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.177.199 with HTTP; Thu, 9 Mar 2017 10:48:22 -0800 (PST) In-Reply-To: <25B4F448-EB83-4CE6-8714-38AC0A98AA9A@apple.com> References: <25B4F448-EB83-4CE6-8714-38AC0A98AA9A@apple.com> From: Kathleen Moriarty Date: Thu, 9 Mar 2017 13:48:22 -0500 Message-ID: To: Tommy Pauly Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-tcp-encaps 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, 09 Mar 2017 18:48:25 -0000 On Thu, Mar 9, 2017 at 12:47 PM, Tommy Pauly wrote: > Hi Kathleen, > > Yes, this is referring to how the existing NAT detection works in IKEv2: > > https://tools.ietf.org/html/rfc7296 > > Section 2.23. NAT Traversal > > o The data associated with the NAT_DETECTION_SOURCE_IP notification > is a SHA-1 digest of the SPIs (in the order they appear in the > header), IP address, and port from which this packet was sent. > > We can add a pointer to the section of the RFC. Great. Please let me know when that is done and I can start IETF last call. Does the WG want me to start that right away or to wait until after Chicago? I'm inclined to start it right away and have it on the first telechat after. Thanks, Kathleen > > Thanks, > Tommy > >> On Mar 9, 2017, at 9:39 AM, Kathleen Moriarty wrote: >> >> Hello, >> >> Thank you for your work on draft-ietf-ipsecme-tcp-encaps. It's a well >> written draft and I just have one question. >> >> Section 7: Why is SHA-1 used? If this is a result of the protocol and >> prior RFCs, please include a reference. And an explanation on list >> would be helpful (pointer is fine if this was already discussed. >> >> >> >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > -- Best regards, Kathleen From nobody Fri Mar 10 02:50:26 2017 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 4F7EA12987F for ; Fri, 10 Mar 2017 02:50:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148914302032.7524.13735929741615801705.idtracker@ietfa.amsl.com> Date: Fri, 10 Mar 2017 02:50:20 -0800 From: IETF Secretariat Archived-At: Subject: [IPsec] Milestones changed for ipsecme WG 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, 10 Mar 2017 10:50:20 -0000 Changed milestone "IETF Last Call on DDoS protection", resolved as "Done". Changed milestone "IETF Last Call on Curve25519 and Curve448 for IKEv2", resolved as "Done". Changed milestone "IETF Last Call on cryptographic algorithms for IKEv2", resolved as "Done". URL: https://datatracker.ietf.org/wg/ipsecme/about/ From nobody Fri Mar 10 18:21:36 2017 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 A8079129529; Fri, 10 Mar 2017 18:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.768 X-Spam-Level: **** X-Spam-Status: No, score=4.768 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_XBL=0.375, RDNS_NONE=0.793, SPF_FAIL=0.001, SPF_HELO_FAIL=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTOizY9hZEv1; Fri, 10 Mar 2017 18:21:16 -0800 (PST) Received: from vhba.mail.ru (unknown [27.76.241.99]) by ietfa.amsl.com (Postfix) with ESMTP id 9B50B12950E; Fri, 10 Mar 2017 18:21:06 -0800 (PST) From: "bensons" To: "ipr-announce-bounces" , "draft-hares-i2rs-fb-rib-data-model" , "ipsec" , "IETF 88 Attendees" <88attendees@ietf.org>, "91attendees" <91attendees@ietf.org>, "spfbis" , "architecture-discuss" Date: Sat, 11 Mar 2017 02:20:51 +0000 Message-ID: <1675083855.20170311052051@queuefull.net> Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_013EF139.3CB589B4" Content-Language: en-us MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] =?utf-8?q?How=27s_it_going?= 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, 11 Mar 2017 02:21:19 -0000 ------=_NextPart_000_0005_013EF139.3CB589B4 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sIA0KDQoNCkhvdyBhcmUgeW91ICBkb2luZz8gSSd2ZSBiZWVuIHRoaW5raW5nIG9mIHlv dSByZWNlbnRseSBhbmQgIEkgZ3Vlc3MgSSAgZm91bmQgc29tZXRoaW5nIHVzZWZ1bCBmb3IgeW91 LCAgcmVhZCBtb3JlIGhlcmUgIGh0dHA6Ly90aW1lLmpyaW9zbWFrZXVwLmNvbS8xYTFiDQoNCg0K YmVuc29ucw0KDQo= ------=_NextPart_000_0005_013EF139.3CB589B4 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hello,

 

 

H= ow are you doing? I've been thinking of you recently and I guess I = found something useful for you, read more here continue reading

 

 

bensons

------=_NextPart_000_0005_013EF139.3CB589B4-- From nobody Sun Mar 12 11:14:48 2017 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 72900129477 for ; Sun, 12 Mar 2017 11:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yP2Lvn5WMQpb for ; Sun, 12 Mar 2017 11:14:45 -0700 (PDT) Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4351112945C for ; Sun, 12 Mar 2017 11:14:45 -0700 (PDT) Received: by mail-wr0-x241.google.com with SMTP id u108so17569968wrb.2 for ; Sun, 12 Mar 2017 11:14:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=XIplgms4R+7drzDvHCMzHp4HsbfYATzaVOFLgXmlRFM=; b=Qen1egKzoxEcKajNVuDp1oKItp1+Hef3fejzdm6NPL35z9Cj71NPtq61lgZwLLkA+n rT+ZCjyaXg/Eez/KU03mpVJfPws/c22RwGQBPnbV1f5Wq+8nfvPJ26KPle8H4O/9dPIf tTyxUcAKJtdS8ucseoZLOJKYpDXCZrguj1RA1inRJovELZUCw0B5q4/KJXaZeo9Ad2km ZQVmF1EL7EFJSbtwNtl+RH5VnxmWqxATjnO9s3+pqt+qUTK5fHgWFNhb/D85izgwXDA5 qCmsHnQOeVP20uonDHV1RwomYsIhDKe05Wxs0IM365hNy2XGiQkinQbQ/AAqyS4i3yHT f9FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=XIplgms4R+7drzDvHCMzHp4HsbfYATzaVOFLgXmlRFM=; b=pH7duEWU9vWU8t39pBVa10eH+YCFUVZCF2tLFRS/5a4kGqsqKUDNQHWaadCur1yY11 VDoyPaePRxMp1+TbmVQs64YwqLR+SvQnoKx8dUZKiHIUQ/zHtQO1Ulf4SmJQEq5S1Fgk sEiEXGLrkVH+/A0OBrgL1SZ/Q4rambQuJ6owptEn5sZqS2sGVvrko2nNc6XY4a2P2h3z qCWUpr02bif8nYOjxVx/5wLItxrFGLjgEYL025C8182Uik23J/LPUJQhyjH2wbQyttwP qHVLvh2FQVUo7yxRQJBcXd5APNQ232XBsFOdQHQ6AjpJQvjkYBt6ZEsI9rHw8yjVwydn mTIg== X-Gm-Message-State: AMke39lp2Ztqwiut+B0y8iriMyu/tj5OxEy1R+yfTWt3OSMPt9xNqpaBNxKH1wfDs5en+Q== X-Received: by 10.223.178.205 with SMTP id g71mr23475786wrd.158.1489342483748; Sun, 12 Mar 2017 11:14:43 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id t103sm21989480wrc.43.2017.03.12.11.14.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Mar 2017 11:14:42 -0700 (PDT) From: Yoav Nir Message-Id: <1454D9C7-7E51-49AE-B0FC-26EDBA73552C@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_0F0D60A1-B089-4D75-BD75-F99585908854"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Sun, 12 Mar 2017 20:14:40 +0200 In-Reply-To: To: Daniel Migault References: <22683.8182.349840.103676@fireball.acr.fi> <22684.25414.470545.969594@fireball.acr.fi> <32d17f6f-3b55-a275-9fe5-960833899780@strongswan.org> <22692.28549.958589.705943@fireball.acr.fi> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "ipsec@ietf.org" , David Schinazi , Tero Kivinen Subject: Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00 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, 12 Mar 2017 18:14:47 -0000 --Apple-Mail=_0F0D60A1-B089-4D75-BD75-F99585908854 Content-Type: multipart/alternative; boundary="Apple-Mail=_FFC65ABA-77F0-4874-9245-9496784EE25B" --Apple-Mail=_FFC65ABA-77F0-4874-9245-9496784EE25B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Daniel. See my comments inline. Also see this pull request: = https://github.com/ietf-ipsecme/drafts/pull/25 = Unless I hear some push-back, I will submit this right before the = deadline. Yoav > On 8 Mar 2017, at 20:49, Daniel Migault = wrote: >=20 > Hi, >=20 > Please find my comments regarding the draft. I believe the draft is = ready to be moved forward. I do not have strong opinion on the value to = assign. >=20 > Yours, >=20 > Daniel >=20 > The Internet Key Exchange protocol [RFC7296] can use arbitrary > signature algorithms as described in [RFC7427]. The latter RFC > defines the SIGNATURE_HASH_ALGORITHMS notification where each side = of > the IKE negotiation lists its supported hash algorithms. This > assumes that all signature schemes involve a hashing phase followed > by a signature phase. This made sense because most signature > algorithms either cannot sign messages bigger than their key or > truncate messages bigger than their key. >=20 > EdDSA ([I.D-eddsa]) defines signature methods that do not require > pre-hashing of the message. Unlike other methods, these accept > arbitrary-sized messages, so no pre-hashing is required. These > methods are called Ed25519 and Ed448, which respectively use the > Edwards 25519 and the Edwards 448 ("Goldilocks") curves. Although > that document also defines pre-hashed versions of these algorithm, > those versions are not recommended for protocols where the entire = to- > be-signed message is available at once. >=20 > MGLT: I think that a pointer for the recommendation should be provided = - section 10.5 of I.D-eddsa. Added. Except that now it=E2=80=99s in section 8.5 of RFC 8032. > The first sentence of the paragraph above confuses me. Although this = si true, I prefer to say that EdDSA ([I.D-eddsa]) defines signatures = methods that includes pre-hasing as well as signature methods that do = not require prehashing. Yes, but the first paragraph is all about the assumption that all = signature methods have a pre-hash stage. The new thing about EdDSA is = that it introduces a method that does not have a pre-hash stage. The = fact that we are not even specifying the use of EdDSA with pre-hash is = all the more reason to push the mention of this to the end of the = paragraph. How about: EdDSA ([RFC8032]) defines signature methods that do not require pre- hashing of the message. Unlike other methods, these accept arbitrary-sized messages, so no pre-hashing is required. These methods are called Ed25519 and Ed448, which respectively use the Edwards 25519 and the Edwards 448 ("Goldilocks") curves. Although that document also defines pre-hashed versions of these algorithm, those versions are not recommended for protocols where the entire to- be-signed message is available at once. See section 8.5 or RFC 8032 for that recommendation. >=20 > EdDSA defines the binary format of the signatures that should be = used > in the "Signature Value" field of the Authentication Data Format in > section 3. The CURDLE PKIX document ([I.D-curdle-pkix]) defines = the > object identifiers (OIDs) for these signature methods. For > convenience, these OIDs are repeated in Appendix A. >=20 > MGLT: Note that the pkix document is still on discussion. -- Although = IOD seems out of the scope of the discussion. Since I=E2=80=99m referencing an I-D normatively, they become a cluster. = If Curdle decides to allocate other OIDs we=E2=80=99ll fix this = specification as well. Not that any of us expect that to happen. Yoav BTW: RFC 8032 is Informational, while this document and RFC4492bis and = the Curdle I-D are standards track. So I guess the shepherd=E2=80=99s = write-up should reflect that RFC 8032 should be added to the downref = registry. --Apple-Mail=_FFC65ABA-77F0-4874-9245-9496784EE25B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Daniel.

See my comments inline.

Also see this pull request:  https://github.com/ietf-ipsecme/drafts/pull/25

Unless I hear some = push-back, I will submit this right before the deadline.

Yoav

On 8 Mar 2017, at 20:49, Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi,

Please = find my comments regarding the draft. I believe the draft is ready to be = moved forward. I do not have strong opinion on the value to assign.

Yours,

Daniel

   The Internet Key Exchange = protocol [RFC7296] can use arbitrary
   = signature algorithms as described in [RFC7427].  The latter RFC
   defines the SIGNATURE_HASH_ALGORITHMS = notification where each side of
   the IKE = negotiation lists its supported hash algorithms.  This
   assumes that all signature schemes involve a = hashing phase followed
   by a signature = phase.  This made sense because most signature
   algorithms either cannot sign messages bigger = than their key or
   truncate messages bigger = than their key.  
  
   EdDSA ([I.D-eddsa]) defines signature methods = that do not require
   pre-hashing of the = message.  Unlike other methods, these accept
   arbitrary-sized messages, so no pre-hashing is = required.  These
   methods are called = Ed25519 and Ed448, which respectively use the
   = Edwards 25519 and the Edwards 448 ("Goldilocks") curves.  = Although
   that document also defines = pre-hashed versions of these algorithm,
   those = versions are not recommended for protocols where the entire to-
   be-signed message is available at once.

MGLT: I think that a pointer for the = recommendation should be provided - section 10.5 of I.D-eddsa.

Added. = Except that now it=E2=80=99s in section 8.5 of RFC 8032.

The first sentence of the paragraph above = confuses me. Although this si true, I prefer to say that  EdDSA = ([I.D-eddsa]) defines signatures methods that includes pre-hasing as = well as signature methods that do not require prehashing. =

Yes, but the = first paragraph is all about the assumption that all signature methods = have a pre-hash stage. The new thing about EdDSA is that it introduces a = method that does not have a pre-hash stage. The fact that we are not = even specifying the use of EdDSA with pre-hash is all the more reason to = push the mention of this to the end of the paragraph.

How about:

   EdDSA ([RFC8032]) defines = signature methods that do not require pre-
  =  hashing of the message.  Unlike other methods, these = accept
   arbitrary-sized messages, so no = pre-hashing is required.  These
   methods are = called Ed25519 and Ed448, which respectively use the
  =  Edwards 25519 and the Edwards 448 ("Goldilocks") curves. =  Although
   that document also defines = pre-hashed versions of these algorithm,
   those = versions are not recommended for protocols where the entire = to-
   be-signed message is available at once. =  See section 8.5 or RFC 8032
   for that = recommendation.

  
   EdDSA defines the = binary format of the signatures that should be used
   in the "Signature Value" field of the = Authentication Data Format in
   section = 3.  The CURDLE PKIX document ([I.D-curdle-pkix]) defines the
   object identifiers (OIDs) for these signature = methods.  For
   convenience, these OIDs = are repeated in Appendix A.

MGLT: Note that = the pkix document is still on discussion. -- Although IOD seems out of = the scope of the discussion.

Since I=E2=80=99m referencing an I-D normatively, = they become a cluster. If Curdle decides to allocate other OIDs we=E2=80=99= ll fix this specification as well. 

Not that any of us expect that to = happen.

Yoav

BTW: RFC 8032 is Informational, while this = document and RFC4492bis and the Curdle I-D are standards track. So I = guess the shepherd=E2=80=99s write-up should reflect that RFC 8032 = should be added to the downref registry.


= --Apple-Mail=_FFC65ABA-77F0-4874-9245-9496784EE25B-- --Apple-Mail=_0F0D60A1-B089-4D75-BD75-F99585908854 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYxZAQAAoJELhJCxUKWMyZAGQH/A/BpZCQjSlUdMvhwyQ5v2ol z6jEgiEWwpYsQ8SCJBUCkKTmhtu7YkJ2/ZBF8Of25CAUy8WBrKt6MNVwfa7hBOI0 6UAfg9xaZSy4Ngqf1V2XLwXYXgZzvL6uEpW18yo5ioUKNRs1elfnwG5mdr3cYMdn KEdfAaOZ8wzp7pxBHZ+uiBLmG3y7bJZ6xAjUIDO6AbNAyQ4+Wx38NCjRUFTM8PqT hCM4p98ezHJBPn3JUC3BiNf4vfbtBM81cuuVfeXCQ7uXnq6cdsiQKmRjDUG6x6AW OwfPLzKPZe4KERm8lA9dhRNXhM8+eWEe5dEJOjihi5rtJXYPs/boi6n0LrDeGxU= =RAXY -----END PGP SIGNATURE----- --Apple-Mail=_0F0D60A1-B089-4D75-BD75-F99585908854-- From nobody Sun Mar 12 12:10:01 2017 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 4D2DF129417; Sun, 12 Mar 2017 12:10: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.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148934580029.24757.8231400864351757794@ietfa.amsl.com> Date: Sun, 12 Mar 2017 12:10:00 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-09.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: Sun, 12 Mar 2017 19:10:00 -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-09.txt Pages : 22 Date : 2017-03-12 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 Security Association establishment and ESP packets 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-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-tcp-encaps-09 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 Sun Mar 12 12:11:55 2017 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 63CB6129484 for ; Sun, 12 Mar 2017 12:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, RP_MATCHES_RCVD=-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=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 fdngdxIBNAc3 for ; Sun, 12 Mar 2017 12:11:50 -0700 (PDT) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (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 72580128B38 for ; Sun, 12 Mar 2017 12:11:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1489345910; 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=0WHDnMjX6MZHdU2vWI737H69/ds7Tg9o+e75iU2h7mw=; b=qSg+G9Rgx/avJx+WQ2BgeGpp4mpsu8imoXmIA4PmIkBumS95Xiu7mhlsOiJZ6bU4 nZVAyuTVAUhSb4UIRnbYQmfENJUYABAW84jyKqHV6WmXZ3opnFDopF+YWDgsY30p 1rC7dMRIuPB1AbfKe/zIPOsbFLStyLbrl32tYtNz33Jc1vkvIbxvZ2l+w0fXZtDP gV9cR1hkHaAxCkhkgs5nZ4gzBmrdfEQWWDXHeDS915SySu5EFYKJQ6NaBvzilggr o6iMNPt6hW67I0iwPTfvXQUvMOuMzQnOjz82yhbAwUFqL7AiVsPjGqf5sozpPGFJ nHWy9e5YQA59uRcmMR3yUA==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id A1.FF.30614.47D95C85; Sun, 12 Mar 2017 12:11:49 -0700 (PDT) X-AuditID: 11973e15-d4ffb70000007796-73-58c59d74b019 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by relay6.apple.com (Apple SCV relay) with SMTP id 06.F4.18018.37D95C85; Sun, 12 Mar 2017 12:11:48 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_+uehfJY9T5JelvXNMUGG4g)" Received: from [17.153.24.72] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OMP00MIGUNNGL50@nwk-mmpp-sz10.apple.com>; Sun, 12 Mar 2017 12:11:47 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <20E77229-492A-478B-8B92-7B963EAFC685@apple.com> Date: Sun, 12 Mar 2017 12:11:46 -0700 In-reply-to: To: Kathleen Moriarty References: <25B4F448-EB83-4CE6-8714-38AC0A98AA9A@apple.com> X-Mailer: Apple Mail (2.3263) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUi2FAYpVs692iEwZqlNhb7t7xgs2jYme/A 5LFz1l12jyVLfjIFMEVx2aSk5mSWpRbp2yVwZdx48Z61oLWm4uKdvewNjIdzuhg5OSQETCQ+ 7F3MCmILCexllHj+WgQmvu39LWaI+CFGiXnv+UFsXgFBiR+T77GA2MwCYRL7Xh5i72LkAqr5 wigx69Vepi5GDg5hAQmJzXsSQWrYBFQkjn/bwAzRayMxddN+MFtYwF5icd9dRhCbRUBVou/6 G7CZnALBEj+3TWaFmK8qMWvCbSYQW0TAQmJN8zc2iF1nGCWuTzvPDnGorET3wmnMEPYRNond 540mMArNQnLrLCS3QthaEt8ftQLFOYBseYmD52UhwpoSz+59girRlnjy7gLrAka2VYxCuYmZ ObqZeWZ6iQUFOal6yfm5mxhBUTDdTnQH45lVVocYBTgYlXh4N8w6GiHEmlhWXJl7iFGag0VJ nHfRlMMRQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgjFqw99+YXk6VC+5v4jbOWvJfLzc04 tdCqSsnw9u5zVT9rgxnWnlhlLXPuO/9VUUU5yd9bb5zYXHDc5Me92euV3N5qH1o3T0Lgu7Fn 4Oq6ut1PQk/qek41WHp7i7nU+QKWwx2LfaRS56XVTC+88dZi35e1evt+5/N6hjhccmN8FOXz THLp9xXtSizFGYmGWsxFxYkAsJJsX2MCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUi2FBcpVsy92iEwd8lBhb7t7xgs2jYme/A 5LFz1l12jyVLfjIFMEVx2aSk5mSWpRbp2yVwZdx48Z61oLWm4uKdvewNjIdzuhg5OSQETCS2 vb/FDGILCRxilJj3nh/E5hUQlPgx+R4LiM0sECax7+Uh9i5GLqCaL4wSs17tZepi5OAQFpCQ 2LwnEaSGTUBF4vi3DcwQvTYSUzftB7OFBewlFvfdZQSxWQRUJfquvwGbySkQLPFz22RWiPmq ErMm3GYCsUUELCTWNH9jg9h1hlHi+rTz7BCHykp0L5zGPIGRfxaS+2YhuQ/C1pL4/qgVKM4B ZMtLHDwvCxHWlHh27xNUibbEk3cXWBcwsq1iFChKzUmsNNNLLCjISdVLzs/dxAgO3MKoHYwN y60OMQpwMCrx8G6YdTRCiDWxrLgyFxhGHMxKIrwuM4FCvCmJlVWpRfnxRaU5qcWHGCcyAn05 kVlKNDkfGFd5JfGGJiYGJsbGZsbG5ibmtBRWEufVmXU4QkggPbEkNTs1tSC1COYoJg5OqQZG xsK6hrb0Zf9vVImftvTNEpZbZzzpcgR/ovHh5TOmf9TZVJosZ1EguejmThO5d0Hlz9QDhTc8 i17xzdJ58pbnPAYS+Yz3/nV+uW+1wCJwvoPTye4imV1Me5/nKZ+I70liWtx17XbVwtnfN/iE vpsSX3Rs0eI9Wmxqzn3lRYt+VNfq8vFsbZZTYinOSDTUYi4qTgQAMBF+oc8CAAA= Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-tcp-encaps 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, 12 Mar 2017 19:11:52 -0000 --Boundary_(ID_+uehfJY9T5JelvXNMUGG4g) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi Kathleen, I've just posted a new version to fix some minor nits and add a reference for the SHA-1 digest used for NAT detection: https://www.ietf.org/id/draft-ietf-ipsecme-tcp-encaps-09.txt >From my perspective, I think starting a IETF last call now make sense. Thanks! Tommy > On Mar 9, 2017, at 10:48 AM, Kathleen Moriarty wrote: > > On Thu, Mar 9, 2017 at 12:47 PM, Tommy Pauly > wrote: >> Hi Kathleen, >> >> Yes, this is referring to how the existing NAT detection works in IKEv2: >> >> https://tools.ietf.org/html/rfc7296 >> >> Section 2.23. NAT Traversal >> >> o The data associated with the NAT_DETECTION_SOURCE_IP notification >> is a SHA-1 digest of the SPIs (in the order they appear in the >> header), IP address, and port from which this packet was sent. >> >> We can add a pointer to the section of the RFC. > > Great. Please let me know when that is done and I can start IETF last > call. Does the WG want me to start that right away or to wait until > after Chicago? I'm inclined to start it right away and have it on the > first telechat after. > > Thanks, > Kathleen > >> >> Thanks, >> Tommy >> >>> On Mar 9, 2017, at 9:39 AM, Kathleen Moriarty wrote: >>> >>> Hello, >>> >>> Thank you for your work on draft-ietf-ipsecme-tcp-encaps. It's a well >>> written draft and I just have one question. >>> >>> Section 7: Why is SHA-1 used? If this is a result of the protocol and >>> prior RFCs, please include a reference. And an explanation on list >>> would be helpful (pointer is fine if this was already discussed. >>> >>> >>> >>> -- >>> >>> Best regards, >>> Kathleen >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >> > > > > -- > > Best regards, > Kathleen --Boundary_(ID_+uehfJY9T5JelvXNMUGG4g) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
Hi Kathleen,

I've just posted a new version to fix = some minor nits and add a reference for the SHA-1 digest used for NAT = detection:
https://www.ietf.org/id/draft-ietf-ipsecme-tcp-encaps-09.txt

=46rom my = perspective, I think starting a IETF last call now make sense.

Thanks!
Tommy

On Mar 9, 2017, at 10:48 AM, Kathleen = Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

On Thu, Mar 9, 2017 at 12:47 PM, = Tommy Pauly <tpauly@apple.com> wrote:
Hi Kathleen,
Yes, this is referring to how the existing NAT detection = works in IKEv2:

https://tools.ietf.org/html/rfc7296

Section 2.23. NAT Traversal

  o  The data associated with the = NAT_DETECTION_SOURCE_IP notification
     is a SHA-1 digest of the SPIs = (in the order they appear in the
     header), IP address, and port = from which this packet was sent.

We can add = a pointer to the section of the RFC.

Great.  Please let me know when that is = done and I can start IETF last
call.  Does the WG want me = to start that right away or to wait until
after Chicago?  I'm = inclined to start it right away and have it on the
first telechat after.
Thanks,
Kathleen

Thanks,
Tommy

On Mar 9, 2017, at 9:39 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Hello,

Thank you = for your work on draft-ietf-ipsecme-tcp-encaps.  It's a well
written draft and I just have one question.

Section 7: Why is SHA-1 used?  If this is a result of = the protocol and
prior RFCs, please include a reference. = And an explanation on list
would be helpful (pointer is = fine if this was already discussed.



--

Best = regards,
Kathleen

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


-- 
Best regards,
Kathleen

= --Boundary_(ID_+uehfJY9T5JelvXNMUGG4g)-- From nobody Sun Mar 12 16:21:38 2017 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 EF46612949F for ; Sun, 12 Mar 2017 16:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, RP_MATCHES_RCVD=-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=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 kFQQ8D40PifR for ; Sun, 12 Mar 2017 16:21:35 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.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 F0D3D12949B for ; Sun, 12 Mar 2017 16:21:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1489360894; 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=Z946xoZ0QDjfuscaJUhxfdoNLHPoiSXMvmGZ/BBkgxE=; b=K4cbUi57xdBzhx7txvWaVCqS3uKnJSFexLaBRIDFI+2fdxDEgB8o9vVbkWSCBI6j zc2emSpfUf+Wl9kb15qJDMtktsfj3FJGKqFWTYyeMK4iul2HQsylLOjFHjfC16MN I96b5xRirP5jgeQ5NItg+YntCoDuTrOpS7iqsd0NuFLq0NJYegcRBRYZTLFGDBkW w0yq7tLLzzAxQrvR//6lrX+FzYtgv9cYjvIpSGm3CnkAQswIJ8t+KsP43zeF74Ws NVzR6dlJE9F6jGfo15x5hAcrn9jfBvCUNSAlsTSEfKry0n+eh4tuusllD0Gz08hV 9jg3fCg/P8dEkKKtUsM8oQ==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 5B.BC.20305.BF7D5C85; Sun, 12 Mar 2017 16:21:34 -0700 (PDT) X-AuditID: 11973e16-935ff70000004f51-bc-58c5d7fb64e1 Received: from kencur (kencur.apple.com [17.151.62.38]) by relay8.apple.com (Apple SCV relay) with SMTP id E9.A6.07296.AF7D5C85; Sun, 12 Mar 2017 16:21:31 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_vOajKaWsgz6lzGlbo779gQ)" Received: from [17.153.45.50] (unknown [17.153.45.50]) by kencur.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OMQ00J8O67TE580@kencur.apple.com>; Sun, 12 Mar 2017 16:21:30 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: <01846746-E380-4179-B8D6-8972AE6C20ED@apple.com> Date: Sun, 12 Mar 2017 16:21:28 -0700 In-reply-to: <1454D9C7-7E51-49AE-B0FC-26EDBA73552C@gmail.com> To: Yoav Nir References: <22683.8182.349840.103676@fireball.acr.fi> <22684.25414.470545.969594@fireball.acr.fi> <32d17f6f-3b55-a275-9fe5-960833899780@strongswan.org> <22692.28549.958589.705943@fireball.acr.fi> <1454D9C7-7E51-49AE-B0FC-26EDBA73552C@gmail.com> X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUi2FCYpvvv+tEIg/8fBSymTN/DZrF/yws2 i6Pnn7NZLD32gcmBxePX16tsHjtn3WX3WLLkJ5PH4a8LWQJYorhsUlJzMstSi/TtErgynm9q Zim4uIix4vj0JpYGxjfdjF2MnBwSAiYSHRt+MHcxcnEICexjlHj35CRTFyMHWOLkAiOI+ApG iW9dz5lBGngFBCV+TL7HAmIzC4RJTFl+gBGiqJFJ4v7xp0wgCWEBaYmuC3dZQQaxCWhJHFhj BNFrI9G8cB4jRIm/xOVlO8FsFgFVifMrjoDZnAK2Eu/f32WDmF8i0XSnB2yviICSxOErX6EO /c4ksfh0J9QHshKfnv9khzj6MZvEb8UJjEKzkJw6C8mps4CqmAXUJaZMyYUIa0s8eXeBFcJW k1j4exETsvgCRrZVjEK5iZk5upl55nqJBQU5qXrJ+bmbGEExM91ObAfjw1VWhxgFOBiVeHg3 zDoaIcSaWFZcmXuIUZqDRUmcd/GUwxFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGCfMTMgp zuTzDtn2T31zaPrG+72fop1mOdU8t3m+69vbaOPOgL0zZ3twnzv0L6U/bVfGjwl/WBZKTnU9 06S22XDrlastizKXlO5wX+O9uaX6895Vi3zsBP1d2lUnC8zVi9LufnWv+lz/rds/t70T9Ixs 65/c95FfueDV/t0f+4tc5tSdvBk9XVaJpTgj0VCLuag4EQBZAU+iegIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMIsWRmVeSWpSXmKPExsUiON1OTff39aMRBrd3cFtMmb6HzWL/lhds FkfPP2ezWHrsA5MDi8evr1fZPHbOusvusWTJTyaPw18XsgSwRHHZpKTmZJalFunbJXBlPN/U zFJwcRFjxfHpTSwNjG+6GbsYOTgkBEwkTi4w6mLk4hASWMEo8a3rOXMXIycHr4CgxI/J91hA bGaBMIkpyw8wQhQ1MkncP/6UCSQhLCAt0XXhLivIIDYBLYkDa4wgem0kmhfOY4Qo8Ze4vGwn mM0ioCpxfsURMJtTwFbi/fu7bBDzSySa7vSA7RURUJI4fOUrM8Su70wSi093gjVICMhKfHr+ k30CI/8sJPfNQnLfLKAzmAXUJaZMyYUIa0s8eXeBFcJWk1j4exETsvgCRrZVjAJFqTmJlRZ6 iQUFOal6yfm5mxhBYd5QmLaDsWm51SFGAQ5GJR7eDbOORgixJpYVV+YeYpTgYFYS4W28BhTi TUmsrEotyo8vKs1JLT7EOJER6MuJzFKiyfnAKMwriTc0MTEwMTY2MzY2NzGnpbCSOK/OrMMR QgLpiSWp2ampBalFMEcxcXBKNTC6fis8L8jWsHVm+/sJPSwhqv9nHun7dn7mvj/v/Z4mTPh9 8LS9hZ2qjYP1090+ovUX9nj92pLYe4/L53jjlPCy5PNXTKv/z39d9+GmffCJy3+yytnzu732 na6UY0gQdl45V2HhusxSkZdqnjInb5s2sFz7uvN2yErJNq+QHVKbbQuev3f5E9GixFKckWio xVxUnAgAVQkMwuYCAAA= Archived-At: Cc: "ipsec@ietf.org" , Daniel Migault , Tero Kivinen Subject: Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00 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, 12 Mar 2017 23:21:37 -0000 --Boundary_(ID_vOajKaWsgz6lzGlbo779gQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Yoav, The diff looks good to me. Based on the discussion in this thread, it looks like there is consensus to not use 0 as the value for Identity. Would it make sense to reflect that in the document? The "IANA Considerations" section currently states: IANA is requested to assign a new value from the "IKEv2 Hash Algorithms" registry with name "Identity" and this document as reference. Since the value zero was reserved by RFC 7427 and this "Identity" hash is no hash at all, assigning the value zero to Identity seems appropriate. Could we replace this with: IANA is requested to assign a new value from the "IKEv2 Hash Algorithms" registry with name "Identity" and this document as reference. Since several current implementation already use the value zero with a different meaning, assigning the next available value (currently 5) seems appropriate. Thanks, David > On Mar 12, 2017, at 11:14, Yoav Nir wrote: >=20 > Hi, Daniel. >=20 > See my comments inline. >=20 > Also see this pull request: = https://github.com/ietf-ipsecme/drafts/pull/25 = >=20 > Unless I hear some push-back, I will submit this right before the = deadline. >=20 > Yoav >=20 >> On 8 Mar 2017, at 20:49, Daniel Migault > wrote: >>=20 >> Hi,=20 >>=20 >> Please find my comments regarding the draft. I believe the draft is = ready to be moved forward. I do not have strong opinion on the value to = assign.=20 >>=20 >> Yours,=20 >>=20 >> Daniel >>=20 >> The Internet Key Exchange protocol [RFC7296] can use arbitrary >> signature algorithms as described in [RFC7427]. The latter RFC >> defines the SIGNATURE_HASH_ALGORITHMS notification where each side = of >> the IKE negotiation lists its supported hash algorithms. This >> assumes that all signature schemes involve a hashing phase = followed >> by a signature phase. This made sense because most signature >> algorithms either cannot sign messages bigger than their key or >> truncate messages bigger than their key. =20 >> =20 >> EdDSA ([I.D-eddsa]) defines signature methods that do not require >> pre-hashing of the message. Unlike other methods, these accept >> arbitrary-sized messages, so no pre-hashing is required. These >> methods are called Ed25519 and Ed448, which respectively use the >> Edwards 25519 and the Edwards 448 ("Goldilocks") curves. Although >> that document also defines pre-hashed versions of these algorithm, >> those versions are not recommended for protocols where the entire = to- >> be-signed message is available at once. >>=20 >> MGLT: I think that a pointer for the recommendation should be = provided - section 10.5 of I.D-eddsa.=20 >=20 > Added. Except that now it=E2=80=99s in section 8.5 of RFC 8032. >=20 >> The first sentence of the paragraph above confuses me. Although this = si true, I prefer to say that EdDSA ([I.D-eddsa]) defines signatures = methods that includes pre-hasing as well as signature methods that do = not require prehashing.=20 >=20 > Yes, but the first paragraph is all about the assumption that all = signature methods have a pre-hash stage. The new thing about EdDSA is = that it introduces a method that does not have a pre-hash stage. The = fact that we are not even specifying the use of EdDSA with pre-hash is = all the more reason to push the mention of this to the end of the = paragraph. >=20 > How about: >=20 > EdDSA ([RFC8032]) defines signature methods that do not require = pre- > hashing of the message. Unlike other methods, these accept > arbitrary-sized messages, so no pre-hashing is required. These > methods are called Ed25519 and Ed448, which respectively use the > Edwards 25519 and the Edwards 448 ("Goldilocks") curves. Although > that document also defines pre-hashed versions of these algorithm, > those versions are not recommended for protocols where the entire = to- > be-signed message is available at once. See section 8.5 or RFC = 8032 > for that recommendation. >=20 >> =20 >> EdDSA defines the binary format of the signatures that should be = used >> in the "Signature Value" field of the Authentication Data Format = in >> section 3. The CURDLE PKIX document ([I.D-curdle-pkix]) defines = the >> object identifiers (OIDs) for these signature methods. For >> convenience, these OIDs are repeated in Appendix A. >>=20 >> MGLT: Note that the pkix document is still on discussion. -- Although = IOD seems out of the scope of the discussion.=20 >=20 > Since I=E2=80=99m referencing an I-D normatively, they become a = cluster. If Curdle decides to allocate other OIDs we=E2=80=99ll fix this = specification as well.=20 >=20 > Not that any of us expect that to happen. >=20 > Yoav >=20 > BTW: RFC 8032 is Informational, while this document and RFC4492bis and = the Curdle I-D are standards track. So I guess the shepherd=E2=80=99s = write-up should reflect that RFC 8032 should be added to the downref = registry. >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = --Boundary_(ID_vOajKaWsgz6lzGlbo779gQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Yoav,

The = diff looks good to me.

Based on the discussion in this thread, it looks like there = is consensus
to not use 0 as the value for = Identity.
Would it make sense to reflect that in = the document?
The "IANA Considerations" section = currently states:

IANA is requested to assign a new value from = the "IKEv2 Hash
Algorithms" registry with name = "Identity" and this document as
reference. =  Since the value zero was reserved by RFC 7427 and this
"Identity" hash is no hash at all, assigning the value zero = to
Identity seems appropriate.

Could we replace this = with:

IANA is requested to assign a new value from the "IKEv2 = Hash
Algorithms" registry with name "Identity" and = this document as
reference. Since several current = implementation already use
the value zero = with a different meaning, assigning the next
available value (currently 5) seems appropriate.

Thanks,
David


On Mar 12, 2017, at 11:14, Yoav Nir <ynir.ietf@gmail.com>= wrote:

Hi, Daniel.

See my comments inline.

Also see this pull request:  https://github.com/ietf-ipsecme/drafts/pull/25

Unless I hear some push-back, I will = submit this right before the deadline.

Yoav

On 8 Mar = 2017, at 20:49, Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi, 

Please find my comments regarding the draft. I believe = the draft is ready to be moved forward. I do not have strong opinion on = the value to assign. 
Yours, 

Daniel

   The Internet = Key Exchange protocol [RFC7296] can use arbitrary
   signature algorithms as described in = [RFC7427].  The latter RFC
   defines the = SIGNATURE_HASH_ALGORITHMS notification where each side of
   the IKE negotiation lists its supported hash = algorithms.  This
   assumes that all = signature schemes involve a hashing phase followed
   by a signature phase.  This made sense = because most signature
   algorithms either = cannot sign messages bigger than their key or
   = truncate messages bigger than their key.   
   
   = EdDSA ([I.D-eddsa]) defines signature methods that do not require
   pre-hashing of the message.  Unlike other = methods, these accept
   arbitrary-sized = messages, so no pre-hashing is required.  These
   methods are called Ed25519 and Ed448, which = respectively use the
   Edwards 25519 and the = Edwards 448 ("Goldilocks") curves.  Although
   that document also defines pre-hashed versions = of these algorithm,
   those versions are not = recommended for protocols where the entire to-
   = be-signed message is available at once.

MGLT:= I think that a pointer for the recommendation should be provided - = section 10.5 of I.D-eddsa. 

Added. Except that now it=E2=80=99s in section 8.5 of = RFC 8032.

The first = sentence of the paragraph above confuses me. Although this si true, I = prefer to say that  EdDSA ([I.D-eddsa]) defines signatures methods = that includes pre-hasing as well as signature methods that do not = require prehashing. 

Yes, but the first = paragraph is all about the assumption that all signature methods have a = pre-hash stage. The new thing about EdDSA is that it introduces a method = that does not have a pre-hash stage. The fact that we are not even = specifying the use of EdDSA with pre-hash is all the more reason to push = the mention of this to the end of the paragraph.

How about:

   EdDSA = ([RFC8032]) defines signature methods that do not require pre-
   hashing of the message.  Unlike other = methods, these accept
   arbitrary-sized = messages, so no pre-hashing is required.  These
   methods are called Ed25519 and Ed448, which = respectively use the
   Edwards 25519 and = the Edwards 448 ("Goldilocks") curves.  Although
   that document also defines pre-hashed versions = of these algorithm,
   those versions are = not recommended for protocols where the entire to-
   be-signed message is available at once. =  See section 8.5 or RFC 8032
   for = that recommendation.

   
   = EdDSA defines the binary format of the signatures that should be used
   in the "Signature Value" field of the = Authentication Data Format in
   section = 3.  The CURDLE PKIX document ([I.D-curdle-pkix]) defines the
   object identifiers (OIDs) for these signature = methods.  For
   convenience, these OIDs = are repeated in Appendix A.

MGLT: Note that = the pkix document is still on discussion. -- Although IOD seems out of = the scope of the discussion. 

Since I=E2=80=99m = referencing an I-D normatively, they become a cluster. If Curdle decides = to allocate other OIDs we=E2=80=99ll fix this specification as = well. 

Not = that any of us expect that to happen.

Yoav

BTW: RFC 8032 is Informational, while this document and = RFC4492bis and the Curdle I-D are standards track. So I guess the = shepherd=E2=80=99s write-up should reflect that RFC 8032 should be added = to the downref registry.


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

= --Boundary_(ID_vOajKaWsgz6lzGlbo779gQ)-- From nobody Sun Mar 12 16:32:12 2017 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 18A4D129466 for ; Sun, 12 Mar 2017 16:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUIqeOy0_kcj for ; Sun, 12 Mar 2017 16:32:09 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::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 978C6129413 for ; Sun, 12 Mar 2017 16:32:08 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id u108so93731291wrb.3 for ; Sun, 12 Mar 2017 16:32:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=p/w5m0qzXcaUZpLPFkshO2PCUHhjmh+HXwMHU/VqhPQ=; b=PZELPmjzmKUn6rFIiPdJGUYycqqkByJgV2YsSqJ9jWJ9lUOO0J3QUwsbDmfFhNcLsz 6AxRk/TRR9fD7bGDXaWoB+QqkugoDislelVYlahK5YR7IYANMjs0UswzeGhowEafPsBH XdudUIbsUrs+WDg/RaPA+DG2165zwkVRwZkrWu1wCC9rNLCK89oQdQSOcEakPxWW0DzX mrE6Q/tU0X9KZkW7fCSZZ2iD+TmBN0HYeDc2GA+Mos1janZKfwi4FBNy7q4eDJbTy4OL KymCVt4HNSX8TJWELXrcMlcoyete5A6FqLgardJ/q6g1gA6yeUbA/wCpPgIKmu3dE9RJ hQsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=p/w5m0qzXcaUZpLPFkshO2PCUHhjmh+HXwMHU/VqhPQ=; b=Uk62aO4YAoEtBtbRHiWmwHNgiEJZtdUQxW9OQTDFs7UrBNyPp2PbI1HyYhm2Jwoekk nsfGDX+U95hkdF2D/scCU5b62CMjt+b5zaPIjeFD8KsW1rcErQkGUNsN5hsPpeUnUPPp lQVUkXgoIf5T9ZyPj1W9eSPMJPm9G1pOerJtV7grE8gYW3dt+1bue3lsRZ3qEVkYT0D6 9y2yW1Y8VrYuQioiUsR7CicQrYaozHDUkiS81zm+E93z1kHBxbP87rhykGyjtWCMHZBk C1VU6nRuILp4C9KgJV0mXSGcfD/VadR7LZp7MeyGgMmr1AEyuOlKuK5xGtbhOMh8NYUg MuZg== X-Gm-Message-State: AMke39kZezbAnLFjUWbWP0q52zGHZMmEKPqSqqK+3N3OqYr9zpyK4qae50G8jBTfPouxYA== X-Received: by 10.223.160.162 with SMTP id m31mr26316254wrm.54.1489361527083; Sun, 12 Mar 2017 16:32:07 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id u41sm22723459wrc.24.2017.03.12.16.32.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Mar 2017 16:32:06 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_C530EBA9-107C-4860-AD7D-F5DA3359EA88"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 13 Mar 2017 01:32:03 +0200 In-Reply-To: <01846746-E380-4179-B8D6-8972AE6C20ED@apple.com> To: David Schinazi References: <22683.8182.349840.103676@fireball.acr.fi> <22684.25414.470545.969594@fireball.acr.fi> <32d17f6f-3b55-a275-9fe5-960833899780@strongswan.org> <22692.28549.958589.705943@fireball.acr.fi> <1454D9C7-7E51-49AE-B0FC-26EDBA73552C@gmail.com> <01846746-E380-4179-B8D6-8972AE6C20ED@apple.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "ipsec@ietf.org" , Daniel Migault , Tero Kivinen Subject: Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00 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, 12 Mar 2017 23:32:11 -0000 --Apple-Mail=_C530EBA9-107C-4860-AD7D-F5DA3359EA88 Content-Type: multipart/alternative; boundary="Apple-Mail=_EA365496-5DE7-4C07-8993-3F72E49070EF" --Apple-Mail=_EA365496-5DE7-4C07-8993-3F72E49070EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks, I will change that (but not put in the part about 5) The RFC editor anyway changes this to =E2=80=9CIANA has assigned the = value 5 in the =E2=80=A6=E2=80=9D so it doesn=E2=80=99t matter much what = we write. Modified the PR Yoav > On 13 Mar 2017, at 1:21, David Schinazi wrote: >=20 > Yoav, >=20 > The diff looks good to me. >=20 > Based on the discussion in this thread, it looks like there is = consensus > to not use 0 as the value for Identity. > Would it make sense to reflect that in the document? > The "IANA Considerations" section currently states: >=20 > IANA is requested to assign a new value from the "IKEv2 Hash > Algorithms" registry with name "Identity" and this document as > reference. Since the value zero was reserved by RFC 7427 and this > "Identity" hash is no hash at all, assigning the value zero to > Identity seems appropriate. >=20 > Could we replace this with: >=20 > IANA is requested to assign a new value from the "IKEv2 Hash > Algorithms" registry with name "Identity" and this document as > reference. Since several current implementation already use > the value zero with a different meaning, assigning the next > available value (currently 5) seems appropriate. >=20 > Thanks, > David >=20 >=20 >> On Mar 12, 2017, at 11:14, Yoav Nir > wrote: >>=20 >> Hi, Daniel. >>=20 >> See my comments inline. >>=20 >> Also see this pull request: = https://github.com/ietf-ipsecme/drafts/pull/25 = >>=20 >> Unless I hear some push-back, I will submit this right before the = deadline. >>=20 >> Yoav >>=20 >>> On 8 Mar 2017, at 20:49, Daniel Migault > wrote: >>>=20 >>> Hi, >>>=20 >>> Please find my comments regarding the draft. I believe the draft is = ready to be moved forward. I do not have strong opinion on the value to = assign. >>>=20 >>> Yours, >>>=20 >>> Daniel >>>=20 >>> The Internet Key Exchange protocol [RFC7296] can use arbitrary >>> signature algorithms as described in [RFC7427]. The latter RFC >>> defines the SIGNATURE_HASH_ALGORITHMS notification where each = side of >>> the IKE negotiation lists its supported hash algorithms. This >>> assumes that all signature schemes involve a hashing phase = followed >>> by a signature phase. This made sense because most signature >>> algorithms either cannot sign messages bigger than their key or >>> truncate messages bigger than their key. >>>=20 >>> EdDSA ([I.D-eddsa]) defines signature methods that do not require >>> pre-hashing of the message. Unlike other methods, these accept >>> arbitrary-sized messages, so no pre-hashing is required. These >>> methods are called Ed25519 and Ed448, which respectively use the >>> Edwards 25519 and the Edwards 448 ("Goldilocks") curves. = Although >>> that document also defines pre-hashed versions of these = algorithm, >>> those versions are not recommended for protocols where the entire = to- >>> be-signed message is available at once. >>>=20 >>> MGLT: I think that a pointer for the recommendation should be = provided - section 10.5 of I.D-eddsa. >>=20 >> Added. Except that now it=E2=80=99s in section 8.5 of RFC 8032. >>=20 >>> The first sentence of the paragraph above confuses me. Although this = si true, I prefer to say that EdDSA ([I.D-eddsa]) defines signatures = methods that includes pre-hasing as well as signature methods that do = not require prehashing. >>=20 >> Yes, but the first paragraph is all about the assumption that all = signature methods have a pre-hash stage. The new thing about EdDSA is = that it introduces a method that does not have a pre-hash stage. The = fact that we are not even specifying the use of EdDSA with pre-hash is = all the more reason to push the mention of this to the end of the = paragraph. >>=20 >> How about: >>=20 >> EdDSA ([RFC8032]) defines signature methods that do not require = pre- >> hashing of the message. Unlike other methods, these accept >> arbitrary-sized messages, so no pre-hashing is required. These >> methods are called Ed25519 and Ed448, which respectively use the >> Edwards 25519 and the Edwards 448 ("Goldilocks") curves. Although >> that document also defines pre-hashed versions of these algorithm, >> those versions are not recommended for protocols where the entire = to- >> be-signed message is available at once. See section 8.5 or RFC = 8032 >> for that recommendation. >>=20 >>>=20 >>> EdDSA defines the binary format of the signatures that should be = used >>> in the "Signature Value" field of the Authentication Data Format = in >>> section 3. The CURDLE PKIX document ([I.D-curdle-pkix]) defines = the >>> object identifiers (OIDs) for these signature methods. For >>> convenience, these OIDs are repeated in Appendix A. >>>=20 >>> MGLT: Note that the pkix document is still on discussion. -- = Although IOD seems out of the scope of the discussion. >>=20 >> Since I=E2=80=99m referencing an I-D normatively, they become a = cluster. If Curdle decides to allocate other OIDs we=E2=80=99ll fix this = specification as well. >>=20 >> Not that any of us expect that to happen. >>=20 >> Yoav >>=20 >> BTW: RFC 8032 is Informational, while this document and RFC4492bis = and the Curdle I-D are standards track. So I guess the shepherd=E2=80=99s = write-up should reflect that RFC 8032 should be added to the downref = registry. >>=20 >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec = --Apple-Mail=_EA365496-5DE7-4C07-8993-3F72E49070EF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks, I will change that (but not put in the part about = 5)

The RFC editor = anyway changes this to =E2=80=9CIANA has assigned the value 5 in the = =E2=80=A6=E2=80=9D so it doesn=E2=80=99t matter much what we = write.

Modified = the PR

Yoav

On 13 Mar 2017, at 1:21, David = Schinazi <dschinazi@apple.com> wrote:

Yoav,

The diff looks good to = me.

Based on = the discussion in this thread, it looks like there is = consensus
to not use 0 as the value for = Identity.
Would it make sense to reflect that in = the document?
The "IANA Considerations" section = currently states:

IANA is requested to assign a new value from = the "IKEv2 Hash
Algorithms" registry with name = "Identity" and this document as
reference. =  Since the value zero was reserved by RFC 7427 and this
"Identity" hash is no hash at all, assigning the value zero = to
Identity seems appropriate.

Could we replace this = with:

IANA is requested to assign a new value from the "IKEv2 = Hash
Algorithms" registry with name "Identity" and = this document as
reference. Since several current = implementation already use
the value zero = with a different meaning, assigning the next
available value (currently 5) seems appropriate.

Thanks,
David


On Mar 12, 2017, at 11:14, Yoav Nir <ynir.ietf@gmail.com>= wrote:

Hi, Daniel.

See my comments inline.

Also see this pull request:  https://github.com/ietf-ipsecme/drafts/pull/25

Unless I hear some push-back, I will = submit this right before the deadline.

Yoav

On 8 Mar = 2017, at 20:49, Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi, 

Please find my comments regarding the draft. I believe = the draft is ready to be moved forward. I do not have strong opinion on = the value to assign. 
Yours, 

Daniel

   The Internet = Key Exchange protocol [RFC7296] can use arbitrary
   signature algorithms as described in = [RFC7427].  The latter RFC
   defines the = SIGNATURE_HASH_ALGORITHMS notification where each side of
   the IKE negotiation lists its supported hash = algorithms.  This
   assumes that all = signature schemes involve a hashing phase followed
   by a signature phase.  This made sense = because most signature
   algorithms either = cannot sign messages bigger than their key or
   = truncate messages bigger than their key.   
   
   = EdDSA ([I.D-eddsa]) defines signature methods that do not require
   pre-hashing of the message.  Unlike other = methods, these accept
   arbitrary-sized = messages, so no pre-hashing is required.  These
   methods are called Ed25519 and Ed448, which = respectively use the
   Edwards 25519 and the = Edwards 448 ("Goldilocks") curves.  Although
   that document also defines pre-hashed versions = of these algorithm,
   those versions are not = recommended for protocols where the entire to-
   = be-signed message is available at once.

MGLT:= I think that a pointer for the recommendation should be provided - = section 10.5 of I.D-eddsa. 

Added. Except that now it=E2=80=99s in section 8.5 of = RFC 8032.

The first = sentence of the paragraph above confuses me. Although this si true, I = prefer to say that  EdDSA ([I.D-eddsa]) defines signatures methods = that includes pre-hasing as well as signature methods that do not = require prehashing. 

Yes, but the first = paragraph is all about the assumption that all signature methods have a = pre-hash stage. The new thing about EdDSA is that it introduces a method = that does not have a pre-hash stage. The fact that we are not even = specifying the use of EdDSA with pre-hash is all the more reason to push = the mention of this to the end of the paragraph.

How about:

   EdDSA = ([RFC8032]) defines signature methods that do not require pre-
   hashing of the message.  Unlike other = methods, these accept
   arbitrary-sized = messages, so no pre-hashing is required.  These
   methods are called Ed25519 and Ed448, which = respectively use the
   Edwards 25519 and = the Edwards 448 ("Goldilocks") curves.  Although
   that document also defines pre-hashed versions = of these algorithm,
   those versions are = not recommended for protocols where the entire to-
   be-signed message is available at once. =  See section 8.5 or RFC 8032
   for = that recommendation.

   
   = EdDSA defines the binary format of the signatures that should be used
   in the "Signature Value" field of the = Authentication Data Format in
   section = 3.  The CURDLE PKIX document ([I.D-curdle-pkix]) defines the
   object identifiers (OIDs) for these signature = methods.  For
   convenience, these OIDs = are repeated in Appendix A.

MGLT: Note that = the pkix document is still on discussion. -- Although IOD seems out of = the scope of the discussion. 

Since I=E2=80=99m = referencing an I-D normatively, they become a cluster. If Curdle decides = to allocate other OIDs we=E2=80=99ll fix this specification as = well. 

Not = that any of us expect that to happen.

Yoav

BTW: RFC 8032 is Informational, while this document and = RFC4492bis and the Curdle I-D are standards track. So I guess the = shepherd=E2=80=99s write-up should reflect that RFC 8032 should be added = to the downref registry.


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


= --Apple-Mail=_EA365496-5DE7-4C07-8993-3F72E49070EF-- --Apple-Mail=_C530EBA9-107C-4860-AD7D-F5DA3359EA88 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYxdp0AAoJELhJCxUKWMyZvskH/08bxF2C4lEwmPasfUu5eTbo VJn2FDjXQR7ay7r7dkTGclzbj4mgwGcEZmrdFt0CIHDMiBTIQNos7J6rfBAajOuE SX14grROczIoK0gVww1jRWUz6wcYRy3B6ppsjS19S75ie/V4qBOhelitm+RrQD2y 8/Wa2gdPh+VvlMvWkWa5gfElZNNCGJuXc6B0jLwc+qUMv8y/EB1K/ZrUo3VQnHjL W19wJLWbpdCxzh+wN9nB89fNUhy74e/pPSzVj6KzrsseXXXaSX5RyrahtmwyiEXR KDar+ewVnnblujI+4oGY9EavPbuIwlBsWBpR1UCg5rncvKw4ory51k2lOVBoK2E= =BjoU -----END PGP SIGNATURE----- --Apple-Mail=_C530EBA9-107C-4860-AD7D-F5DA3359EA88-- From nobody Sun Mar 12 16:53:17 2017 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 8D47F129413 for ; Sun, 12 Mar 2017 16:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, 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 7PA8tCDSKg4o for ; Sun, 12 Mar 2017 16:53:14 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4761E129426 for ; Sun, 12 Mar 2017 16:53:14 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id l7so75109283ioe.3 for ; Sun, 12 Mar 2017 16:53:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=PlnIu/RZNKCOc0SZaZES+kSxQ2+FAu8zb/MDZ0okd4Y=; b=aR+n/t4C916BnxQxBTaFNdL55vn87KDCDhv4Ws3a7sW29Tt3Ol6qWrZE+RKP8ioqZX VCh083GXW6BQYL+kABIzj+3AAuppDu8/KuUz5LLUikBY+IR/t0mKBDA0ZferozzcMV9W y6jFXAZSFlvDJGnXtKMjj8Zg/flFuvY2xUlo/H8L9Uu0flnez7xg2vK+adMQrowbUNzj BNPhPGoJinK5XMWHgv5uNbBchFJVB2Pgk02gsmT+04Vk4Ai9xN3/1ufpR9mPWswAPwzY g7bgbVxzlbj3yb/4u8e5FkOSoGWrWw7bS2KU7NaCV0huJ1hB0u+m9R88QnpQ2CIfIrQR UiUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=PlnIu/RZNKCOc0SZaZES+kSxQ2+FAu8zb/MDZ0okd4Y=; b=HsKvn1GpAYDiJO1yr14XBwo/85CjE/dk0+HpSHs5wzc2YwwwsmWyiStvxIhYN4d5HS F99TKcEvUjRu/W8b80LcuOzoKy31B6B6SifSLYHmMPqdgeUoCSrsXymm8ak67FbRHimR e4FZ3LHUwGmcX8U7DQRFBKYDkxm9d1ZFSMS3/EGsRxLrjH5E77hY7u1UmyVS+yuqWWft 1LPSWDelVj1yY1JrzTTkr35sgzQ3Xf6arRnuc4m8cHqr6m3CD70+jHdYQNE+hvrNQa5X YBw/q7sPm5Q2Tsc4LMj7CDPNMNbwjpZfqnnZH77RkFeaXX94xgvXgpR2yAK4QCY3mvr1 lu3w== X-Gm-Message-State: AMke39l6WsrRAnebRLPqbs3UmaLQ8HYuf/LqrmuxOK6Obeb752iQk54ARGDymj2EvcCLJjNcBjS8zr9cZZgRNA== X-Received: by 10.107.168.21 with SMTP id r21mr23636643ioe.45.1489362793604; Sun, 12 Mar 2017 16:53:13 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.35.213 with HTTP; Sun, 12 Mar 2017 16:53:13 -0700 (PDT) In-Reply-To: <1454D9C7-7E51-49AE-B0FC-26EDBA73552C@gmail.com> References: <22683.8182.349840.103676@fireball.acr.fi> <22684.25414.470545.969594@fireball.acr.fi> <32d17f6f-3b55-a275-9fe5-960833899780@strongswan.org> <22692.28549.958589.705943@fireball.acr.fi> <1454D9C7-7E51-49AE-B0FC-26EDBA73552C@gmail.com> From: Daniel Migault Date: Sun, 12 Mar 2017 19:53:13 -0400 X-Google-Sender-Auth: hMaagIzsjjDIVkow__6SyOL2_U4 Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=001a114215e8412ef5054a914c95 Archived-At: Cc: "ipsec@ietf.org" , David Schinazi , Tero Kivinen Subject: Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00 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, 12 Mar 2017 23:53:16 -0000 --001a114215e8412ef5054a914c95 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, This looks good to me. Here is the text to justify the downref ;-) The Downref is justified by RFC3967 as it falls into the following case: o A standards track document may need to refer to a protocol or algorithm developed by an external body but modified, adapted, or profiled by an IETF informational RFC. Yours, Daniel On Sun, Mar 12, 2017 at 2:14 PM, Yoav Nir wrote: > Hi, Daniel. > > See my comments inline. > > Also see this pull request: https://github.com/ietf- > ipsecme/drafts/pull/25 > > Unless I hear some push-back, I will submit this right before the deadlin= e. > > Yoav > > On 8 Mar 2017, at 20:49, Daniel Migault > wrote: > > Hi, > > Please find my comments regarding the draft. I believe the draft is ready > to be moved forward. I do not have strong opinion on the value to assign. > > Yours, > > Daniel > > The Internet Key Exchange protocol [RFC7296] can use arbitrary > signature algorithms as described in [RFC7427]. The latter RFC > defines the SIGNATURE_HASH_ALGORITHMS notification where each side of > the IKE negotiation lists its supported hash algorithms. This > assumes that all signature schemes involve a hashing phase followed > by a signature phase. This made sense because most signature > algorithms either cannot sign messages bigger than their key or > truncate messages bigger than their key. > > EdDSA ([I.D-eddsa]) defines signature methods that do not require > pre-hashing of the message. Unlike other methods, these accept > arbitrary-sized messages, so no pre-hashing is required. These > methods are called Ed25519 and Ed448, which respectively use the > Edwards 25519 and the Edwards 448 ("Goldilocks") curves. Although > that document also defines pre-hashed versions of these algorithm, > those versions are not recommended for protocols where the entire to- > be-signed message is available at once. > > MGLT: I think that a pointer for the recommendation should be provided - > section 10.5 of I.D-eddsa. > > > Added. Except that now it=E2=80=99s in section 8.5 of RFC 8032. > > The first sentence of the paragraph above confuses me. Although this si > true, I prefer to say that EdDSA ([I.D-eddsa]) defines signatures method= s > that includes pre-hasing as well as signature methods that do not require > prehashing. > > > Yes, but the first paragraph is all about the assumption that all > signature methods have a pre-hash stage. The new thing about EdDSA is tha= t > it introduces a method that does not have a pre-hash stage. The fact that > we are not even specifying the use of EdDSA with pre-hash is all the more > reason to push the mention of this to the end of the paragraph. > > How about: > > EdDSA ([RFC8032]) defines signature methods that do not require pre- > hashing of the message. Unlike other methods, these accept > arbitrary-sized messages, so no pre-hashing is required. These > methods are called Ed25519 and Ed448, which respectively use the > Edwards 25519 and the Edwards 448 ("Goldilocks") curves. Although > that document also defines pre-hashed versions of these algorithm, > those versions are not recommended for protocols where the entire to- > be-signed message is available at once. See section 8.5 or RFC 8032 > for that recommendation. > > > EdDSA defines the binary format of the signatures that should be used > in the "Signature Value" field of the Authentication Data Format in > section 3. The CURDLE PKIX document ([I.D-curdle-pkix]) defines the > object identifiers (OIDs) for these signature methods. For > convenience, these OIDs are repeated in Appendix A. > > MGLT: Note that the pkix document is still on discussion. -- Although IOD > seems out of the scope of the discussion. > > > Since I=E2=80=99m referencing an I-D normatively, they become a cluster. = If Curdle > decides to allocate other OIDs we=E2=80=99ll fix this specification as we= ll. > > Not that any of us expect that to happen. > > Yoav > > BTW: RFC 8032 is Informational, while this document and RFC4492bis and th= e > Curdle I-D are standards track. So I guess the shepherd=E2=80=99s write-u= p should > reflect that RFC 8032 should be added to the downref registry. > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --001a114215e8412ef5054a914c95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
Hi, 

This looks good to=
 me. 

Here is the text to justify the downref ;-)
The Downref is =
justified by RFC3967 as it falls into the following case:=20
   o  A standards track document may need to refer to a protocol or
      algorithm developed by an external body but modified, adapted, or
      profiled by an IETF informational RFC. 

Yours, 
Daniel

On Sun, Mar 1= 2, 2017 at 2:14 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:<= br>
Hi, D= aniel.

See my comments inline.

= Also see this pull request: =C2=A0https://github.com/ietf-ipsecme/dr= afts/pull/25

Unless I hear some push-back, I w= ill submit this right before the deadline.

Yoav

On 8 Mar 2= 017, at 20:49, Daniel Migault <daniel.migault@ericsson.com> wrote:
Hi,

Please find my comments regarding the draft. I = believe the draft is ready to be moved forward. I do not have strong opinio= n on the value to assign.

Yours,

Daniel

=C2=A0=C2=A0= The Internet Key Exchange protocol [RFC7296] can use arbitrary
=C2=A0= =C2=A0 signature algorithms as described in [RFC7427].=C2=A0 The latter RFC=
=C2=A0=C2=A0 defines the SIGNATURE_HASH_ALGORITHMS notification where e= ach side of
=C2=A0=C2=A0 the IKE negotiation lists its supported hash al= gorithms.=C2=A0 This
=C2=A0=C2=A0 assumes that all signature schemes inv= olve a hashing phase followed
=C2=A0=C2=A0 by a signature phase.=C2=A0 T= his made sense because most signature
=C2=A0=C2=A0 algorithms either can= not sign messages bigger than their key or
=C2=A0=C2=A0 truncate message= s bigger than their key.=C2=A0=C2=A0
=C2=A0=C2=A0
=C2=A0=C2=A0 EdDS= A ([I.D-eddsa]) defines signature methods that do not require
=C2=A0=C2= =A0 pre-hashing of the message.=C2=A0 Unlike other methods, these accept=C2=A0=C2=A0 arbitrary-sized messages, so no pre-hashing is required.=C2= =A0 These
=C2=A0=C2=A0 methods are called Ed25519 and Ed448, which respe= ctively use the
=C2=A0=C2=A0 Edwards 25519 and the Edwards 448 ("Go= ldilocks") curves.=C2=A0 Although
=C2=A0=C2=A0 that document also d= efines pre-hashed versions of these algorithm,
=C2=A0=C2=A0 those versio= ns are not recommended for protocols where the entire to-
=C2=A0=C2=A0 b= e-signed message is available at once.

MGLT: I think that a pointer = for the recommendation should be provided - section 10.5 of I.D-eddsa.
=

Added. Except that now it=E2= =80=99s in section 8.5 of RFC 8032.

The first sentence of the paragraph= above confuses me. Although this si true, I prefer to say that=C2=A0 EdDSA= ([I.D-eddsa]) defines signatures methods that includes pre-hasing as well = as signature methods that do not require prehashing.

Yes, but the first paragraph is all about the= assumption that all signature methods have a pre-hash stage. The new thing= about EdDSA is that it introduces a method that does not have a pre-hash s= tage. The fact that we are not even specifying the use of EdDSA with pre-ha= sh is all the more reason to push the mention of this to the end of the par= agraph.

How about:

= =C2=A0 =C2=A0EdDSA ([RFC8032]) defines signature methods that do not requir= e pre-
=C2=A0 =C2=A0hashing of the message.=C2= =A0 Unlike other methods, these accept
=C2=A0 =C2=A0arbitrary-siz= ed messages, so no pre-hashing is required.=C2=A0 These
=C2=A0 = =C2=A0methods are called Ed25519 and Ed448, which respectively use the
=C2=A0 =C2=A0Edwards 25519 and the Edwards 448 ("Goldilocks"= ;) curves.=C2=A0 Although
=C2=A0 =C2=A0that document also defines= pre-hashed versions of these algorithm,
=C2=A0 =C2=A0those versi= ons are not recommended for protocols where the entire to-
=C2=A0 =C2=A0be-signed message is available at once.=C2=A0 See section 8.5= or RFC 8032
=C2=A0 =C2=A0for that recommendation.

=
=C2=A0=C2=A0
=C2=A0=C2=A0 EdDSA defines the binary format of the sign= atures that should be used
=C2=A0=C2=A0 in the "Signature Value&quo= t; field of the Authentication Data Format in
=C2=A0=C2=A0 section 3.=C2= =A0 The CURDLE PKIX document ([I.D-curdle-pkix]) defines the
=C2=A0=C2= =A0 object identifiers (OIDs) for these signature methods.=C2=A0 For
=C2= =A0=C2=A0 convenience, these OIDs are repeated in Appendix A.

MGLT: = Note that the pkix document is still on discussion. -- Although IOD seems o= ut of the scope of the discussion.

=
Since I=E2=80=99m referencing an I-D normatively, they become a= cluster. If Curdle decides to allocate other OIDs we=E2=80=99ll fix this s= pecification as well.=C2=A0

Not that any of us exp= ect that to happen.

Yoav

BTW: = RFC 8032 is Informational, while this document and RFC4492bis and the Curdl= e I-D are standards track. So I guess the shepherd=E2=80=99s write-up shoul= d reflect that RFC 8032 should be added to the downref registry.
=


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


--001a114215e8412ef5054a914c95-- From nobody Sun Mar 12 23:16:58 2017 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 69D7F128B37; Sun, 12 Mar 2017 23:16:51 -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.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148938581141.24661.4691010752208511567@ietfa.amsl.com> Date: Sun, 12 Mar 2017 23:16:51 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-eddsa-01.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, 13 Mar 2017 06:16:51 -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-01.txt Pages : 5 Date : 2017-03-12 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-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-eddsa-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 13 05:57:09 2017 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 5B9ED1295D7 for ; Mon, 13 Mar 2017 05:57:08 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 5G1i91p1z_9b for ; Mon, 13 Mar 2017 05:57:05 -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 9B4C61295D4 for ; Mon, 13 Mar 2017 05:57:05 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vhdDZ4SFtz38s; Mon, 13 Mar 2017 13:57:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1489409822; bh=Ovzd9NNw/8y64zJkQDnts2whwfsHfQP6QaqiwhIYZZ0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=SBnFGOeoykFfHWCU4OATSAN3kdcZ0SV7OHFhvExUXFmUsguE7gE7CKrQcDdQDyf5D DE+zOOIdpSLEcoELc7MlmEeq0AWCljqkwb31NarWhTy+RzPhNoOYUqf1y9PJVPqATq 7oYRCvyHw+mpi5cciy8Pf4nsEyMaYfumAVK89V7o= 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 w73YBHh1aWz6; Mon, 13 Mar 2017 13:57:01 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 13 Mar 2017 13:57:00 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 3D9F631C858; Mon, 13 Mar 2017 08:56:59 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 3D9F631C858 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 29E6C4000880; Mon, 13 Mar 2017 08:56:59 -0400 (EDT) Date: Mon, 13 Mar 2017 08:56:58 -0400 (EDT) From: Paul Wouters To: Valery Smyslov In-Reply-To: <006501d26cb0$45483650$cfd8a2f0$@gmail.com> Message-ID: References: <22644.61072.705632.343770@fireball.acr.fi> <006501d26cb0$45483650$cfd8a2f0$@gmail.com> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org WG" , Tommy Pauly , 'Tero Kivinen' Subject: Re: [IPsec] Review of draft-pauly-ipsecme-split-dns-02 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, 13 Mar 2017 12:57:08 -0000 On Thu, 12 Jan 2017, Valery Smyslov wrote: >> This way if you have originally configured company1.com to the >> internal dns names, and then company decides to buy another company >> called company2.com, teh client can still request company1.com and >> server can return both company1.com and company2.com in its reply. >> Then it is up to the client whether it will belive the list or not. > > Why the client would ever not believe to the information from the authenticated server? > I'd go further and say that the initiator MUST use the received internal DNS servers > for all the requests within the received INTERNAL_DNS_DOMAIN (as you proposed before). Opportunistic IPsec means that we want to encrypt to those endpoints, but we have zero trust in them, and we don't allow them to set many of the IKE/IPsec features that we might allow when we are configured as a classic access vpn. >> In section 6: >> >> If a host connected to an authenticated IKE peer is connecting to >> another IKE peer that attempts to claim the same domain via the >> INTERNAL_DNS_DOMAIN attribute, the IKE connection should be >> terminated. >> >> Which of the IKE connection should be terminated? Perhaps the first >> connection has died and user tried to reconnect to the same server, >> which will of course give the same INTERNAL_DNS_DOMAIN. Tearing down >> that new connection and not allowing it to be formed until the first >> one is timed out is bit annoying. > > I think that tearing down a connection in this case is wrong and inconsistent with > Redirect Mechanism for IKEv2 (RFC5685). There could be several > VPN gateways protecting the internal network and the client > can be redirected from one to another (or even have a concurrent > IKE SAs in case of load sharing scenario). That's a good point. I have to think about how to write text that supports these trusted scenario's versus more untrusted scenarios. >> So I think the DNS configuration should be done immediately, >> regardless whether the Child SA to cover those IP address is there. >> In properly configured system the IP-address will then trigger the SA >> to be created when they are first time used. > > I completely agree here. As with internal IP address assignment > the failure to create IPsec SA is not a reason not to configure > internal DNS servers. Let me talk to Tommy about this. We'll bring these issues up for discussion in Chicago in two weeks. Paul From nobody Mon Mar 13 06:38:21 2017 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 6D3E8129621 for ; Mon, 13 Mar 2017 06:38:20 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 pAE-J0v_Qxn6 for ; Mon, 13 Mar 2017 06:38:16 -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 457AE12961D for ; Mon, 13 Mar 2017 06:38:16 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vhf843vkkz1HC; Mon, 13 Mar 2017 14:38:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1489412292; bh=EyJO+Nto7XTZjChEESQ/XcUXySPr1xHOvd6kaKDwOsw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=b1cTi+ZJgF9rTfdPStVWRNXiWZmg+NZV+cqq4l9O8m4Avy0clCKlncYgHADVLddFu YPC4Geo6FbpLfKxu1wmILx81ijHqlzRQYS8PqFyk0QdBRpFUPQrYK3PBeuZCKSvpx6 cOXTTKfqjbZB8dqpbC8nLP0JSgjVIhYAAEen4TL0= 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 zOk-ubzciG1X; Mon, 13 Mar 2017 14:38:09 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 13 Mar 2017 14:38:08 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id CF0A831C858; Mon, 13 Mar 2017 09:38:07 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca CF0A831C858 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id BA7344000880; Mon, 13 Mar 2017 09:38:07 -0400 (EDT) Date: Mon, 13 Mar 2017 09:38:07 -0400 (EDT) From: Paul Wouters To: Tero Kivinen In-Reply-To: <22644.61072.705632.343770@fireball.acr.fi> Message-ID: References: <22644.61072.705632.343770@fireball.acr.fi> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Review of draft-pauly-ipsecme-split-dns-02 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, 13 Mar 2017 13:38:20 -0000 On Tue, 10 Jan 2017, Tero Kivinen wrote: > > In the section 1 there is text: > > The client device > can use the internal DNS server(s) for any DNS queries within the > assigned domains, while routing other DNS queries to its regular > external DNS server. > > which would indicate that we can also use internal dns servers for > other DNS queries too. Clarified. > Then on section 5 there is text saying: > > All other domain > names MUST be resolved using some other external DNS resolver(s), > configured independently, and SHOULD NOT be sent to the internal DNS > resolver(s) listed in that CFG_REPLY message. > > This is bit confusing. First of all all other domain names MUST use > external DNS servers, but then the requirement for ont using internal > DNS is only SHOULD NOT. > What is what we want there. Do we want to have clear splitting of the > DNS servers, i.e. all request for internal names go to the internal > servers, and never external ones, and do we want all request to > external names go to the external servers, and never internal ones. > > I think the 1st point (I.e. all requests about internal names go to > the internal servers) is something that is important for security, so > it should perhaps be MUST. Ok, I agree with your point here. > On the other hand the 2nd point is not about security. Quite often > people can and want to use internal DNS server even for external DNS > requests. So I think that should be allowed in both ways, i.e., > external DNS names can be asked from either internal or external name > servers, or even both. Here I don't agree as much. I think it is a privacy issue if you run a split-net setup and start sending all your queries to your internal network. Also, you assume that the network is a trusted remote peer like a corporation. But these days we have many kinds of IPsec tunnels. Eg, if I watch netflix and use VPN, I really don't trust them with my DNS queries other then those needed to watch TV. I'll think about some text for this. >> From section 3.2 > > If the CFG_REQUEST included INTERNAL_DNS_DOMAIN attributes with non- > zero lengths, the CFG_REPLY MUST NOT assign any domains in its > INTERNAL_DNS_DOMAIN attributes that are not contained within the > requested domains. The initiator SHOULD ignore any domains beyond > its requested list. > > This whole thing about restricting the subdomains server can send by > sending the list from client is different than what we normally do. In > normal case the client sends list of suggestions for the configuration > values to the server. Here the client forces server to do something. > > I think it would be better to say that client can send list of dns > names it would like to be included, and server can then reply whatever > list it has in its configuration, and client is free to ignore as many > of the items from the list it likes. > > This way if you have originally configured company1.com to the > internal dns names, and then company decides to buy another company > called company2.com, teh client can still request company1.com and > server can return both company1.com and company2.com in its reply. > Then it is up to the client whether it will belive the list or not. I ran into this issue too when implementing. I realised that there is really no reason for the server to ever act on what the client sends. So I wondered if we should send it at all. It seems we might as well not send anything to the server, and when the server gives us a list, filter it based on what we will accept. This could be different based on the kind of ipsec tunnel (corporate vs free proxy) > In section 4.2 it would be useful to repeat the fact that the bytes > after the Length match the DNS wire format of a DS record as specified > in [RFC4034]. The bytes match, but we repeat the definition from the > RFC4034, so it would be good idea to also explictly say it here, and > not only in section 3.2. Okay, will add. > -- > > In section 5 the text: > > For each INTERNAL_DNS_DOMAIN entry in a CFG_REPLY payload, the client > SHOULD use the provided INTERNAL_IP4_DNS or INTERNAL_IP6_DNS DNS > servers as the only resolvers for the listed domains and its sub- > domains and it SHOULD NOT attempt to resolve the provided DNS domains > using its external DNS servers. > > Why is that only SHOULD. I mean if there is INTERNAL_DNS_DOMAIN > specified, shouldn't the client be following it? So why it is not > MUST? And in which cases the SHOULD can be broken? What are the > exceptions where internal domains can be resolved from the outside dns > servers (or actually failed to be resolved). Yes, same point you raised above. I agree. > If the initiator host is configured to block DNS answers containing > IP addresses from special IP address ranges such as those of > [RFC1918], the initiator SHOULD allow the DNS domains listed in the > INTERNAL_DNS_DOMAIN attributes to contain these IP addresses. > > I think this is wrong. I think we should say that it should not block > any addresses which are part of the configured INTERNAL_IP*_SUBNETS. > I.e., if the vpn is not configured to pass packets to 10.0.0.0/8 > network, then blocking those DNS answers is still fine. Agreed. Fixed. > If a CFG_REPLY contains one or more INTERNAL_DNS_DOMAIN attributes, > the client SHOULD configure its DNS resolver to resolve those domains > and all their subdomains using only the DNS resolver(s) listed in > that CFG_REPLY message. > > Again why only SHOULD? When should it ignore the instructions from the > server? Same but I need to think a little further on how to rewrite this. > If those resolvers fail, those names SHOULD > NOT be resolved using any other DNS resolvers. > > Should this also be MUST NOT? Yes, same issue. > All other domain > names MUST be resolved using some other external DNS resolver(s), > configured independently, and SHOULD NOT be sent to the internal DNS > resolver(s) listed in that CFG_REPLY message. > > This was already in my previous comment. Yup. > -- > > For example, if the > INTERNAL_DNS_DOMAIN attribute specifies "example.com", then > "example.com", "www.example.com" and "mail.eng.example.com" MUST be > resolved using the internal DNS resolver(s), but "anotherexample.com" > and "ample.com" MUST be resolved using the system's external DNS > resolver(s). > > But then in the example there is only MUSTs.... yup yup. > When an IPsec connection is terminated, the DNS forwarding must be > unconfigured. The DNS forwarding itself MUST be be deleted. All > cached data of the INTERNAL_DNS_DOMAIN provided DNS domainis MUST be > flushed. This includes negative cache entries. Obtained DNSSEC > trust anchors MUST be removed from the list of trust anchors. The > > This might cause security issues. I.e., if you have mail.example.com > resolved using internal dns server to have IP-address of 10.0.0.1, and > then someone manages to tear down the VPN connection, and suddenly all > these mappings go away, the next time your mail client tries to fetch > email, it does mail.example.com lookup using external DNS servers, and > will get IP-address of 1.1.1.1 from ns.evil.org, then then it will > connect to wrong mail server... If you are afraid of this attack, deploy DNSSEC on your domain. > Perhaps we should keep the mappings for some time, just in case the > connection comes back few seconds later when the vpn reconnects... I switch regularly from redhat.com to public, and that would really cause me problems. It is really important to wipe all the now unreachable cached DNS data. If you wish to stall for a few seconds, I'd recommend you would be dropping the DNS packets instead of lingering old state, and I would say that is a pure local implementation issue and shouldn't go into the RFC. > A domain that is served via INTERNAL_DNS_DOMAIN MUST NOT have > indirect references to DNS records that point to other Split DNS > domains that are not served via INTERNAL_DNS_DOMAIN attributes. > Indirect reference RRtypes include CNAME, DNAME, MX and SRV RR's. > > How this going to be done? > > I.e., how do you convince the system adminstrator of the company1.com > that adding mail.company2.com CNAME mail.company1.com is against RFC, > and must not be done until all clients are configured to ask > company1.com and company2.com internal dns domains? > > I think we can put that text in the security consideration section and > say that adminstrators should take care that the CNAMES etc used in > the internal domains, do not leak out to wrong domain names or > something. Sounds good. Will make the change. > In section 6: > > If a host connected to an authenticated IKE peer is connecting to > another IKE peer that attempts to claim the same domain via the > INTERNAL_DNS_DOMAIN attribute, the IKE connection should be > terminated. > > Which of the IKE connection should be terminated? Perhaps the first > connection has died and user tried to reconnect to the same server, > which will of course give the same INTERNAL_DNS_DOMAIN. Tearing down > that new connection and not allowing it to be formed until the first > one is timed out is bit annoying. I agree this problem needs some better consideration. I had only thought of the malicious case, but you are right we might hit some legitimate case. > If the IP address value of the received INTERNAL_IP4_DNS or > INTERNAL_IP6_DNS attribute is not covered by the proposed IPsec > connection, then the local DNS should not be reconfigured until a > CREATE_CHILD Exchange is received that covers these IP addresses. > > I think this is dangerous. I.e. if the server returns INTERNAL_IP4_DNS > of 10.0.0.1 and INTERNAL_DNS_DOMAIN of example.com, but initial Child > sa connection fails for some reason (out of resources). Next the email > client trying to resolve the mail.example.com goes out to the external > dns servers to find the name, instead of trying to use 10.0.0.1 dns > server. Note, that when it tries to send packet to 10.0.0.1, then the > IPsec will simply trigger for that packet, and will create the Child > SA needed... > > So I think the DNS configuration should be done immediately, > regardless whether the Child SA to cover those IP address is there. > In properly configured system the IP-address will then trigger the SA > to be created when they are first time used. Let's talk in Chicago about this. I see you point but I'm not yey persuaded this is the way to go. Paul From nobody Mon Mar 13 06:58:45 2017 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 193D112962A; Mon, 13 Mar 2017 06:58:44 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id de-IE_HXVX-F; Mon, 13 Mar 2017 06:58:43 -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 D53E5129644; Mon, 13 Mar 2017 06:58:42 -0700 (PDT) X-AuditID: c6180641-0291898000000a06-28-58c65f3bc93f Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by (Symantec Mail Security) with SMTP id 22.16.02566.B3F56C85; Mon, 13 Mar 2017 09:58:35 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0319.002; Mon, 13 Mar 2017 09:58:38 -0400 From: Daniel Migault To: "lwip@ietf.org" , IPsecME WG Thread-Topic: New Version Notification for draft-mglt-lwig-minimal-esp-04.txt Thread-Index: AQHSnAGh9Qszm36zMkeB70bOf3/LJ6GSy3OQ Date: Mon, 13 Mar 2017 13:58:38 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA46B2@eusaamb107.ericsson.se> References: <148941339246.17014.2244961993369060510.idtracker@ietfa.amsl.com> In-Reply-To: <148941339246.17014.2244961993369060510.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+NgFrrJLMWRmVeSWpSXmKPExsUyuXRPuK5N/LEIgw0cFvu3vGCzmLdP2IHJ Y8mSn0wBjFFcNimpOZllqUX6dglcGR1NVgWPRCqOnt7P0sA4R6SLkZNDQsBEYsqHLYxdjFwc QgLrGSVeXVgG5SxnlPg44SEjSBWbgJFE26F+dhBbRMBB4u3ZTqA4B4ewgI/E7Tt+EGFfiS3b 3jFB2EYS3TPfsoLYLAKqEpd65oKN4QWqaZq4khnEFgKy/x5YDxbnFPCT2LhjGguIzSggJvH9 1BqwOcwC4hK3nsxngjhUQGLJnvPMELaoxMvH/1ghbCWJj7/ns4OcwyygKbF+lz5Eq6LElO6H 7BBrBSVOznzCMoFRZBaSqbMQOmYh6ZiFpGMBI8sqRo7S4oKc3HQjw02MwAA/JsHmuINxb6/n IUYBDkYlHt6CpKMRQqyJZcWVuYcYJTiYlUR4pZYcixDiTUmsrEotyo8vKs1JLT7EKM3BoiTO ez3kfriQQHpiSWp2ampBahFMlomDU6qBsWLqnD1Gf3QSxO5H/A89Hbg3zSXdwl3Zm68uK03l sEVvkbv6k/xkxc4P4fzHLjL2tM3afP1C+PVu6/btFhOXnp22SW7W5Pex/q4Zh17re6/LtX07 d3nWLsb80wu4a/+v+/QjVHWmiU7hhOC/i7aG8JrbvRL+8mSdsVr4uisJcaFH78522uEQpsRS nJFoqMVcVJwIACLyiEpsAgAA Archived-At: Subject: [IPsec] FW: New Version Notification for draft-mglt-lwig-minimal-esp-04.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, 13 Mar 2017 13:58:44 -0000 SGksIA0KDQpQbGVhc2UgZmluZCBhbiB1cGRhdGUgb2YgYSBndWlkYW5jZSBmb3IgbGlnaHQgaW1w bGVtZW50YXRpb24gb2Ygc3RhbmRhcmQgRVNQLiBGZWVsIGZyZWUgdG8gY29tbWVudCENCg0KWW91 cnMsIA0KRGFuaWVsIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNl bnQ6IE1vbmRheSwgTWFyY2ggMTMsIDIwMTcgOTo1NyBBTQ0KVG86IFRvYmlhcyBHdWdnZW1vcyA8 Z3VnZ2Vtb3NAbW5tLXRlYW0ub3JnPjsgRGFuaWVsIE1pZ2F1bHQgPGRhbmllbC5taWdhdWx0QGVy aWNzc29uLmNvbT4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt bWdsdC1sd2lnLW1pbmltYWwtZXNwLTA0LnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC1tZ2x0LWx3aWctbWluaW1hbC1lc3AtMDQudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IERhbmllbCBNaWdhdWx0IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3Np dG9yeS4NCg0KTmFtZToJCWRyYWZ0LW1nbHQtbHdpZy1taW5pbWFsLWVzcA0KUmV2aXNpb246CTA0 DQpUaXRsZToJCU1pbmltYWwgRVNQDQpEb2N1bWVudCBkYXRlOgkyMDE3LTAzLTEzDQpHcm91cDoJ CUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxMA0KVVJMOiAgICAgICAgICAgIGh0dHBz Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tZ2x0LWx3aWctbWluaW1hbC1l c3AtMDQudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtbWdsdC1sd2lnLW1pbmltYWwtZXNwLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tZ2x0LWx3aWctbWluaW1hbC1lc3AtMDQNCkRpZmY6 ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbWdsdC1s d2lnLW1pbmltYWwtZXNwLTA0DQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmli ZXMgYSBtaW5pbWFsIHZlcnNpb24gb2YgdGhlIElQIEVuY2Fwc3VsYXRpb24NCiAgIFNlY3VyaXR5 IFBheWxvYWQgKEVTUCkgZGVzY3JpYmVkIGluIFJGQyA0MzAzIHdoaWNoIGlzIHBhcnQgb2YgdGhl DQogICBJUHNlYyBzdWl0ZS4NCg0KICAgRVNQIGlzIHVzZWQgdG8gcHJvdmlkZSBjb25maWRlbnRp YWxpdHksIGRhdGEgb3JpZ2luIGF1dGhlbnRpY2F0aW9uLA0KICAgY29ubmVjdGlvbmxlc3MgaW50 ZWdyaXR5LCBhbiBhbnRpLXJlcGxheSBzZXJ2aWNlIChhIGZvcm0gb2YgcGFydGlhbA0KICAgc2Vx dWVuY2UgaW50ZWdyaXR5KSwgYW5kIGxpbWl0ZWQgdHJhZmZpYyBmbG93IGNvbmZpZGVudGlhbGl0 eS4NCg0KICAgVGhpcyBkb2N1bWVudCBkb2VzIG5vdCB1cGRhdGUgb3IgbW9kaWZ5IFJGQyA0MzAz LCBidXQgcHJvdmlkZXMgYQ0KICAgY29tcGFjdCBkZXNjcmlwdGlvbiBvZiBob3cgdG8gaW1wbGVt ZW50IHRoZSBtaW5pbWFsIHZlcnNpb24gb2YgdGhlDQogICBwcm90b2NvbC4gIElmIHRoaXMgZG9j dW1lbnQgYW5kIFJGQyA0MzAzIGNvbmZsaWN0cyB0aGVuIFJGQyA0MzAzIGlzDQogICB0aGUgYXV0 aG9yaXRhdGl2ZSBkZXNjcmlwdGlvbi4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoN ClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQN Cg0K From nobody Mon Mar 13 12:57:26 2017 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 14094129AF5 for ; Mon, 13 Mar 2017 12:57:12 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 qbiBT7-T_mvw for ; Mon, 13 Mar 2017 12:57:10 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10128.outbound.protection.outlook.com [40.107.1.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 4E7D5129AF8 for ; Mon, 13 Mar 2017 12:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gzvr4xOZIAB1L5WdSm/35yUa9zxa0L/Hi91ajduz7AA=; b=LOKPZSWZI2LDRq/fXH/8a6ShTLRyjv2FuxlQwUZYGEBwAAb0Qq0V7P8bOgds8S7UTPVjoo60FXCBydrAZXLCeoFAW0yMJ+vj5dSmiUwRnCOl1BMLAoYyR6szlRE2J93lq22swFUOX34FkIhuoKH7gEceq9hHKi/OtJfm0JfgF0E= Received: from HE1PR07MB1417.eurprd07.prod.outlook.com (10.169.122.15) by HE1PR07MB1418.eurprd07.prod.outlook.com (10.169.122.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Mon, 13 Mar 2017 19:57:06 +0000 Received: from HE1PR07MB1417.eurprd07.prod.outlook.com ([10.169.122.15]) by HE1PR07MB1417.eurprd07.prod.outlook.com ([10.169.122.15]) with mapi id 15.01.0977.010; Mon, 13 Mar 2017 19:57:06 +0000 From: "Hu, Jun (Nokia - US)" To: Paul Wouters , Tero Kivinen Thread-Topic: [IPsec] Review of draft-pauly-ipsecme-split-dns-02 Thread-Index: AQHSm/8Me2az7x+ZuUeyc5ExdY/py6GTJflA Date: Mon, 13 Mar 2017 19:57:06 +0000 Message-ID: References: <22644.61072.705632.343770@fireball.acr.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nohats.ca; dkim=none (message not signed) header.d=none;nohats.ca; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.48.252] x-microsoft-exchange-diagnostics: 1; HE1PR07MB1418; 7:ujRRTGMQHVD5HqwMS5Z7rBG6M5Xwx4F1OzSXt1JPJB0EXBCPA8c0twGN1pi/i9y4Q/2Nm9tOwvL4zeC4/KQl8NvMBPyVkIxXjJs7S/zzSBeLuFuRu4UfaDHBU4+/JtB25WDUeC/Emrp9ogPtZ+U+lX9nsPUxu+CoKNT8uxIBK/q1kY8HTzHnJg7jLhMHh4m00JDaAsjK4GS7ep/dNyIyJszpynShG8qlgOahjoCwv3oMAIoEQ6DVimHpddQa0xuiturh5uT3htIune0SRXNdwYxB9dDThVF1vfTEpbeqREUqJMH+WyTO9BwrhcCwXA5skqvd6QVF7rEeM0ajSTnp9A== x-ms-office365-filtering-correlation-id: 477135b3-81df-4d1a-79fb-08d46a4b20ae x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:HE1PR07MB1418; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123558025)(20161123564025)(6072148); SRVR:HE1PR07MB1418; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1418; x-forefront-prvs: 0245702D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39410400002)(39860400002)(39450400003)(39840400002)(106116001)(81166006)(33656002)(6436002)(2900100001)(3660700001)(6506006)(77096006)(76176999)(25786008)(6246003)(86362001)(54356999)(50986999)(38730400002)(122556002)(189998001)(8676002)(305945005)(66066001)(5660300001)(8936002)(7736002)(74316002)(7696004)(4326008)(3280700002)(2950100002)(2906002)(3846002)(229853002)(99286003)(55016002)(230783001)(102836003)(6116002)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1418; H:HE1PR07MB1417.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2017 19:57:06.7760 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1418 Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Review of draft-pauly-ipsecme-split-dns-02 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, 13 Mar 2017 19:57:12 -0000 > >> From section 3.2 > > > > If the CFG_REQUEST included INTERNAL_DNS_DOMAIN attributes with non- > > zero lengths, the CFG_REPLY MUST NOT assign any domains in its > > INTERNAL_DNS_DOMAIN attributes that are not contained within the > > requested domains. The initiator SHOULD ignore any domains beyond > > its requested list. > > > > This whole thing about restricting the subdomains server can send by > > sending the list from client is different than what we normally do. In > > normal case the client sends list of suggestions for the configuration > > values to the server. Here the client forces server to do something. > > > > I think it would be better to say that client can send list of dns > > names it would like to be included, and server can then reply whatever > > list it has in its configuration, and client is free to ignore as many > > of the items from the list it likes. > > > > This way if you have originally configured company1.com to the > > internal dns names, and then company decides to buy another company > > called company2.com, teh client can still request company1.com and > > server can return both company1.com and company2.com in its reply. > > Then it is up to the client whether it will belive the list or not. >=20 > I ran into this issue too when implementing. I realised that there is rea= lly no > reason for the server to ever act on what the client sends. > So I wondered if we should send it at all. It seems we might as well not = send > anything to the server, and when the server gives us a list, filter it ba= sed on > what we will accept. This could be different based on the kind of ipsec t= unnel > (corporate vs free proxy) [HJ] I think it is most flexible to still allow client to send what it want= in CFG_REQUEST, but it is up to gateway's local policy to decide if it sho= uld consider or ignore them;=20 For example, the INTERNAL_DNS_DOMAIN could be used by gateway as additional= hints for which DNS server address to return in case a gateway is serving = multiple types of clients, each has its own internal domains to be resolved= via its own DNS sever; Same applies to CFG_REPLY, it is up to client's local policy to decide whet= her to accept or ignore.=20 In section 3.2, "If the CFG_REQUEST did not contain an INTERNAL_DNS_DOMAIN attribute, the responder MUST NOT include an INTERNAL_DNS_DOMAIN attribute in the CFG_REPLY." If it is agreed that it is essential local policy for what gateway send or = accept, then gateway should be allowed to send INTERNAL_DNS_DOMAIN even whe= n client doesn't include it in the CFG_REQUEST; According to section 2.19 of RFC7296, "the IRAS MAY also send other attribu= tes that were not included in CP(CFG_REQUEST)", I think it is a general ru= le for all configuration attributes=20 From nobody Mon Mar 13 13:41:40 2017 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 BA33A1294C7 for ; Mon, 13 Mar 2017 13:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] 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 wysCOc27r_a5 for ; Mon, 13 Mar 2017 13:41:37 -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 C37741294A5 for ; Mon, 13 Mar 2017 13:41:36 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vhqXX1Jvyz3Tj; Mon, 13 Mar 2017 21:41:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1489437692; bh=qGz5lP+C/nclDk0lx9TxR9Xdq+7vyplKIW2KdMualsA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=gCoA7YhpGmLxusftEnKtRFbF4jv4u1Q8Dso9dEIE7Z8pOt4n6G5wRpaY2OH18O25x z2MoyphCe7oeEUYglumLY6FH9ZmcokvQyUXrxHjbkE0lW7PYXMUZCVLBwysLj5xvt/ OvFYI1qGzP3qTVMan/AOnW24yRoe/GFBEtJnrwTI= 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 DiBjH6qVYEty; Mon, 13 Mar 2017 21:41:30 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 13 Mar 2017 21:41:29 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 061C131C858; Mon, 13 Mar 2017 16:41:28 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 061C131C858 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id F3506407E851; Mon, 13 Mar 2017 16:41:28 -0400 (EDT) Date: Mon, 13 Mar 2017 16:41:28 -0400 (EDT) From: Paul Wouters To: "Hu, Jun (Nokia - US)" In-Reply-To: Message-ID: References: <22644.61072.705632.343770@fireball.acr.fi> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org" , Tero Kivinen Subject: Re: [IPsec] Review of draft-pauly-ipsecme-split-dns-02 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, 13 Mar 2017 20:41:39 -0000 On Mon, 13 Mar 2017, Hu, Jun (Nokia - US) wrote: >> I ran into this issue too when implementing. I realised that there is really no >> reason for the server to ever act on what the client sends. >> So I wondered if we should send it at all. It seems we might as well not send >> anything to the server, and when the server gives us a list, filter it based on >> what we will accept. This could be different based on the kind of ipsec tunnel >> (corporate vs free proxy) > > > [HJ] I think it is most flexible to still allow client to send what it want in CFG_REQUEST, but it is up to gateway's local policy to decide if it should consider or ignore them; > For example, the INTERNAL_DNS_DOMAIN could be used by gateway as additional hints for which DNS server address to return in case a gateway is serving multiple types of clients, each has its own internal domains to be resolved via its own DNS sever; > Same applies to CFG_REPLY, it is up to client's local policy to decide whether to accept or ignore. I think though, that the server should return those attributes even if the client did not ask for them. I cannot think of a good example where the client provided values would cause the server to return something different (as the server should not trust the client to begin with) > In section 3.2, "If the CFG_REQUEST did not contain an > INTERNAL_DNS_DOMAIN attribute, the responder MUST NOT include an > INTERNAL_DNS_DOMAIN attribute in the CFG_REPLY." > > If it is agreed that it is essential local policy for what gateway send or accept, then gateway should be allowed to send INTERNAL_DNS_DOMAIN even when client doesn't include it in the CFG_REQUEST; But the assumption is, if the client does not support it, there is no point in the server sending it. I guess in the old IKEv1/ModeCfg we were more strict. You could not reply with anything not requested. IKEv2 has relaxed this to say either side can send anything and the other end just has to ignore what it does not understand. > According to section 2.19 of RFC7296, "the IRAS MAY also send other attributes that were not included in CP(CFG_REQUEST)", I think it is a general rule for all configuration attributes I guess I'm fine with either approach. Since the base IKEv2 RFC states any side can send/ignore anything, perhaps it is best to copy that approach in this document as well? Paul From nobody Mon Mar 13 14:02:03 2017 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 175E312942F; Mon, 13 Mar 2017 14:02:02 -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.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148943892208.20401.17970719539700282400@ietfa.amsl.com> Date: Mon, 13 Mar 2017 14:02:02 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-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: Mon, 13 Mar 2017 21:02:02 -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 : Split DNS Configuration for IKEv2 Authors : Tommy Pauly Paul Wouters Filename : draft-ietf-ipsecme-split-dns-00.txt Pages : 11 Date : 2017-03-13 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". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-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 Mon Mar 13 14:34:57 2017 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 22092129BB8 for ; Mon, 13 Mar 2017 14:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=nokia.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 gpi2Dko9zfVd for ; Mon, 13 Mar 2017 14:34:54 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0109.outbound.protection.outlook.com [104.47.1.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 388E8129BB5 for ; Mon, 13 Mar 2017 14:34:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=q/EY6l5ZyYMtfQeta+hniSefBMWZwIUCk46RztWFL/M=; b=qvIFaJ8UWt1ZK1YNCeKpe0uKZs4l9W3y+QAgmBZ418BB1aSNG/3dgK+naLpMNxHy0g+qbHss2Qs0QeK+7c3NCKuS+ymrxEngjIhxq/KJ25m97RjFCdf1k3N7Mpopvc3ggv/l/3i/mGEr+xE9Ga8yu7jYGzCofmimeoQmp946pyU= Received: from HE1PR07MB1417.eurprd07.prod.outlook.com (10.169.122.15) by HE1PR07MB1420.eurprd07.prod.outlook.com (10.169.122.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.977.5; Mon, 13 Mar 2017 21:34:51 +0000 Received: from HE1PR07MB1417.eurprd07.prod.outlook.com ([10.169.122.15]) by HE1PR07MB1417.eurprd07.prod.outlook.com ([10.169.122.15]) with mapi id 15.01.0977.010; Mon, 13 Mar 2017 21:34:51 +0000 From: "Hu, Jun (Nokia - US)" To: Paul Wouters Thread-Topic: [IPsec] Review of draft-pauly-ipsecme-split-dns-02 Thread-Index: AQHSm/8Me2az7x+ZuUeyc5ExdY/py6GTJflAgAAWaQCAAAuLwA== Date: Mon, 13 Mar 2017 21:34:50 +0000 Message-ID: References: <22644.61072.705632.343770@fireball.acr.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nohats.ca; dkim=none (message not signed) header.d=none;nohats.ca; dmarc=none action=none header.from=nokia.com; x-originating-ip: [135.245.48.252] x-microsoft-exchange-diagnostics: 1; HE1PR07MB1420; 7:6n4+O7754CUp5okIwhfs3/vspqO+Yh/CH71HGVT59HW7xzEiQbYTpL9dAq1wgYRBpXKzPIKdc611GlNN/Vb8e+/K2VkEiqmlE9HzfOpHtjMMtw7atMmOdSIcjIIyJB6KW8Af72Y5xzBEQNmWS+Fcs84j7J7SMDbjbI8rx//cINVFoBeEE15EhOykpdF7ohdoE5GnTa4shcIeTtPLae+1JcLg9TSz/NIuW55ElXyIqGU9xVfO9TxGM1mk11HsCtD5RZNP5eSg3xAveFoSP+SYQUIK+st/56Om7NDV5FmroqOJ2aND91FRolcVnMDiLXIum58E15pFtM/PZ+V5gvEqlQ== x-ms-office365-filtering-correlation-id: 3aeeb371-edd2-484e-e193-08d46a58c7ef x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:HE1PR07MB1420; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123558025)(20161123562025)(20161123560025)(20161123564025)(6072148); SRVR:HE1PR07MB1420; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1420; x-forefront-prvs: 0245702D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39840400002)(39450400003)(39860400002)(39410400002)(13464003)(25786008)(122556002)(54906002)(81166006)(110136004)(230783001)(6436002)(8676002)(5660300001)(99286003)(55016002)(2906002)(74316002)(6246003)(53936002)(4326008)(102836003)(305945005)(7736002)(6116002)(3846002)(38730400002)(8936002)(50986999)(54356999)(86362001)(76176999)(2900100001)(106116001)(33656002)(93886004)(3280700002)(7696004)(3660700001)(229853002)(66066001)(6916009)(2950100002)(77096006)(6506006)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1420; H:HE1PR07MB1417.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2017 21:34:50.8260 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1420 Archived-At: Cc: "ipsec@ietf.org" , Tero Kivinen Subject: Re: [IPsec] Review of draft-pauly-ipsecme-split-dns-02 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, 13 Mar 2017 21:34:56 -0000 > -----Original Message----- > From: Paul Wouters [mailto:paul@nohats.ca] > >> I ran into this issue too when implementing. I realised that there is > >> really no reason for the server to ever act on what the client sends. > >> So I wondered if we should send it at all. It seems we might as well > >> not send anything to the server, and when the server gives us a list, > >> filter it based on what we will accept. This could be different based > >> on the kind of ipsec tunnel (corporate vs free proxy) > > > > > > [HJ] I think it is most flexible to still allow client to send what it > > want in CFG_REQUEST, but it is up to gateway's local policy to decide > > if it should consider or ignore them; For example, the > INTERNAL_DNS_DOMAIN could be used by gateway as additional hints for whic= h > DNS server address to return in case a gateway is serving multiple types = of > clients, each has its own internal domains to be resolved via its own DNS= sever; > Same applies to CFG_REPLY, it is up to client's local policy to decide wh= ether to > accept or ignore. >=20 > I think though, that the server should return those attributes even if th= e client > did not ask for them. I cannot think of a good example where the client > provided values would cause the server to return something different (as = the > server should not trust the client to begin with) [HJ] I think Tero's example (company1 bought company2) make sense to me; th= ere could be even case where the company1 wants to change the all domain na= mes to company2, if we allow gateway to return different value, it will mak= e such transition much easier; Just like today a client could send INTERNAL_IP4_ADDRESS in CFG_REQUEST to = indicate its preference to get that address, but it doesn't mean gateway ha= s to honor it; >=20 > > In section 3.2, "If the CFG_REQUEST did not contain an > > INTERNAL_DNS_DOMAIN attribute, the responder MUST NOT include an > > INTERNAL_DNS_DOMAIN attribute in the CFG_REPLY." > > > > If it is agreed that it is essential local policy for what gateway > > send or accept, then gateway should be allowed to send > > INTERNAL_DNS_DOMAIN even when client doesn't include it in the > > CFG_REQUEST; >=20 > But the assumption is, if the client does not support it, there is no poi= nt in the > server sending it. >=20 > I guess in the old IKEv1/ModeCfg we were more strict. You could not reply= with > anything not requested. IKEv2 has relaxed this to say either side can sen= d > anything and the other end just has to ignore what it does not understand= . >=20 [HJ] if client's doesn't support split DNS, of course it will not send thes= e new CFG attributes, but I don't think we should always assume client does= n't support split DNS if it doesn't include these attributes in CFG_REQUEST > > According to section 2.19 of RFC7296, "the IRAS MAY also send other > > attributes that were not included in CP(CFG_REQUEST)", I think it is > > a general rule for all configuration attributes >=20 > I guess I'm fine with either approach. Since the base IKEv2 RFC states an= y side > can send/ignore anything, perhaps it is best to copy that approach in thi= s > document as well? [HJ] I think we should just follow RFC7296=20 From nobody Mon Mar 13 14:43:07 2017 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 7A129129B9D for ; Mon, 13 Mar 2017 14:43:06 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 j5tOy9vx9JgN for ; Mon, 13 Mar 2017 14:43:04 -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 7512B129BA7 for ; Mon, 13 Mar 2017 14:43:01 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vhrvP5sB3z3Wd for ; Mon, 13 Mar 2017 22:42:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1489441377; bh=ql4pkc48+HlmZJ7JCwmPS5aVYGkwb4xsxikt8BHmBU4=; h=Date:From:To:Subject:In-Reply-To:References; b=iYbg8ejbTcQTjzpMaOx5JjKJ53dbFOQxWNWavcEd4mIfvx90R5lT1DMTypFXQSIZL 3TyIwJRQjF7JGo2eiHKyOPVjD5VfWmQoDn4+kl12qzAPXiGiC3pSXFAM/iJE6BsNYr 3cpzMlnBBrNLRXSVb0W+czjxdOJOfmj27kgB/46M= 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 9-wXdjcFYdLZ for ; Mon, 13 Mar 2017 22:42:55 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Mon, 13 Mar 2017 22:42:54 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id C77B331C858; Mon, 13 Mar 2017 17:42:53 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca C77B331C858 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B2BDD407E851 for ; Mon, 13 Mar 2017 17:42:53 -0400 (EDT) Date: Mon, 13 Mar 2017 17:42:53 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: <148943892208.20401.17970719539700282400@ietfa.amsl.com> Message-ID: References: <148943892208.20401.17970719539700282400@ietfa.amsl.com> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-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: Mon, 13 Mar 2017 21:43:06 -0000 On Mon, 13 Mar 2017, internet-drafts@ietf.org wrote: > https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-00 Sadly no diff is available against draft-pauly-ipsecme-split-dns on the announcement page or the datatracker despite our xml tag of obsoleting it (Tero: bug for ietf tools team :) You can see the diff here: http://tools.ietf.org//rfcdiff?url2=https://tools.ietf.org/id/draft-ietf-ipsecme-split-dns-00.txt&url1=https://tools.ietf.org/id/draft-pauly-ipsecme-split-dns-02.txt I'll send a list of items to the list that seem to not yet have concensus, that we can also use as a base for discussion in Chicago. Paul From nobody Tue Mar 14 17:56:10 2017 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 D7626131777; Tue, 14 Mar 2017 17:56:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-ipsecme-rfc4307bis@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, david.waltermire@nist.gov, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148953936879.24311.6108233027392233073.idtracker@ietfa.amsl.com> Date: Tue, 14 Mar 2017 17:56:08 -0700 Archived-At: Subject: [IPsec] Ben Campbell's No Objection on draft-ietf-ipsecme-rfc4307bis-17: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 00:56:09 -0000 Ben Campbell has entered the following ballot position for draft-ietf-ipsecme-rfc4307bis-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 2.1, 2nd to last paragraph says that ENCR_3DES has been downgraded to SHOULD NOT. But both the table in this section, and the change table later in the draft say MAY. From nobody Tue Mar 14 18:32:31 2017 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 7AFFE1296AA; Tue, 14 Mar 2017 18:32:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stephen Farrell To: "The IESG" Cc: draft-ietf-ipsecme-rfc7321bis@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, david.waltermire@nist.gov, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148954154141.24303.17110055626587941944.idtracker@ietfa.amsl.com> Date: Tue, 14 Mar 2017 18:32:21 -0700 Archived-At: Subject: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-rfc7321bis-05 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 01:32:24 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-ipsecme-rfc7321bis-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-rfc7321bis/ There are no remarks associated with this position. From nobody Tue Mar 14 18:33:19 2017 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 888E6129631; Tue, 14 Mar 2017 18:33:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stephen Farrell To: "The IESG" Cc: draft-ietf-ipsecme-rfc7321bis@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, david.waltermire@nist.gov, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148954159755.24347.12366542904819082480.idtracker@ietfa.amsl.com> Date: Tue, 14 Mar 2017 18:33:17 -0700 Archived-At: Subject: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 01:33:17 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-ipsecme-rfc7321bis-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-rfc7321bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - I agree with Christian's secdir review [1] that this doesn't seem justified (at least on it's face): " If manual keying is used anyway, ENCR_AES_CBC MUST be used, and ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT be used as these algorithms require IKE. " Can you explain the reasoning that lead the WG to say that? - ENCR_NULL IMO ought be MUST NOT - did the WG discuss that explicitly? If so, can you provide a pointer to the archive? If not, does it still have to be a MUST? I do wonder who wants to use AH via NAT but cannot, which seems to be the justification. [1] https://www.ietf.org/mail-archive/web/secdir/current/msg07262.html From nobody Tue Mar 14 23:58:23 2017 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 29E5612967A; Tue, 14 Mar 2017 23:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDeZPSbFPVuw; Tue, 14 Mar 2017 23:58:13 -0700 (PDT) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 882DE129677; Tue, 14 Mar 2017 23:58:13 -0700 (PDT) Received: by mail-wm0-x242.google.com with SMTP id z63so3077207wmg.2; Tue, 14 Mar 2017 23:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=UMywmhBTzPWMgCskKyjqzZFTil9pJek9nBJo7BxgSdo=; b=oa1sW4nHEQl/uf6J1XHPk3fhSdMt9JdbHZg8fIB4Ala5RHovfCbSGZwsBWJ0TvqJmU 402SqnZ6+voBJNct7m72Tv86+w0+PYFTI6xzJrvv7UjszkYoDd/u4qJ8BGbB9XGrGluW XUqmEnJdA/hM7qiRDnk9kcA0SXGyYf1i4PJ11vS27UkagcevUvciNKRNZSqaFmjwOM++ 9fEMEX7K+YV1V2jaL09uCsSfS1NrmhBapLtnUZvNiQiviTvKj6ukTXcVUV+lqJZ+Wf56 yGjZo/E3Tgmi+jI/+h2J1JlVEZfIKYaJl0u3SCtw8ykBht4a5XRBb6d2KPTn1tfSqy2c 4B+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=UMywmhBTzPWMgCskKyjqzZFTil9pJek9nBJo7BxgSdo=; b=nVicSxVDXMXHAZMVFXM5nq9IFnQiajyRWOjuD1fPEIFb4Bq76SRE0zlawbg7QbK4UB usT+46JLdHyZR7rG1RfAlHk9zfoE59ABJRtBKXn0Eh7yjkRrSfiUoxC1SBftZhMEuKJP P9+yHSxy8IeFOklbuE6g0I9LAeaUReJy3tNxfhjsgfJfQceG93ZOiFIpLhzPaC3LFta/ CgrTtXzZBsWbJ3EP4KhPr9TjJDz+T7DA+L20U8D3tsGRasdAC/oVvEDp1+a3KfVlQZrj eYqRzox5HAV1+rAEiCARq6/usCYkR4Re6YfTlhtDRnBvQ0T+3Zu+16zLw+jOdF/iKf87 lYkg== X-Gm-Message-State: AFeK/H2Xb74KFY7s5HDTiac4VM45U986JD7aw51hopNYtSeH+6DoQlhkKqsy4uP705r9hw== X-Received: by 10.28.7.20 with SMTP id 20mr2731603wmh.115.1489561092088; Tue, 14 Mar 2017 23:58:12 -0700 (PDT) Received: from [192.168.137.86] ([109.253.147.134]) by smtp.gmail.com with ESMTPSA id m83sm18149735wmc.33.2017.03.14.23.58.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Mar 2017 23:58:11 -0700 (PDT) From: Yoav Nir Message-Id: <459BC926-6E26-4B5E-B3CA-B1DAF3D58DCF@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_AF173E2E-44B4-40E8-9C3F-9AC50DF023B5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 15 Mar 2017 08:58:08 +0200 In-Reply-To: <148954159755.24347.12366542904819082480.idtracker@ietfa.amsl.com> Cc: The IESG , draft-ietf-ipsecme-rfc7321bis@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, ipsec@ietf.org To: Stephen Farrell References: <148954159755.24347.12366542904819082480.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 06:58:15 -0000 --Apple-Mail=_AF173E2E-44B4-40E8-9C3F-9AC50DF023B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi. I=E2=80=99d like to address the second comment. > On 15 Mar 2017, at 3:33, Stephen Farrell = wrote: > - ENCR_NULL IMO ought be MUST NOT - did the WG discuss > that explicitly? If so, can you provide a pointer to the > archive? If not, does it still have to be a MUST? I do > wonder who wants to use AH via NAT but cannot, which seems > to be the justification. This was raised at some meeting, and it was claimed that people are = using it. This includes other standards bodies like IEEE 1588. Although I don=E2=80=99t think IEEE 1588 is ever used over NAT, we need = ENCR_NULL if we are to pull AH out of implementations (and = implementations have been removing AH for years. It=E2=80=99s = practically deprecated) Yoav --Apple-Mail=_AF173E2E-44B4-40E8-9C3F-9AC50DF023B5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYyOYAAAoJELhJCxUKWMyZgDkIAMEIOfGH4VyzQgx4LKYLi44B BCuP7EzymTECukwfZ6BTfUQ8lD76jrhglldMt2QZE3GlOxaXxRh/ynTBQEEpl84T G4iCxNIW4g+30rz7v1/NDL8u+OunP+WN13b2ebd9aIJ+q61lLRLaWbqGefHvAt1t gfhjoinzu6PGuZ95sIPOqg04qNYIW9U0SffpJyDrxerMCFTVxDJwWYJ5gZJRL6AP 0p6l2zc4EoW5kP/Ut/0zgcbHqcuyZjZ1im3/hBBMDca0rvPxq9G9IhS073/wxudH t+/8RJw+KAZjvtq/wcTZJqXk8fip5Ho4wM5db8WF5G1vWH2jYXZbAiHgRKwUoCs= =gfFq -----END PGP SIGNATURE----- --Apple-Mail=_AF173E2E-44B4-40E8-9C3F-9AC50DF023B5-- From nobody Wed Mar 15 02:57:15 2017 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 80206129A95; Wed, 15 Mar 2017 02:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VywYaInJ0Oqx; Wed, 15 Mar 2017 02:57:06 -0700 (PDT) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (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 21E53129A91; Wed, 15 Mar 2017 02:57:06 -0700 (PDT) Received: by mail-it0-x244.google.com with SMTP id g138so2568964itb.0; Wed, 15 Mar 2017 02:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jqf7iIPA+FtQ1MmurkAUtYBLkBwYG+oU9B/In0VsKwE=; b=RxroFudxIPmSL1J+57g6yYZYd1CwffDwPeoEba3lOg0rAN7W/0XdO4o34mxrsy+Hi6 3eVnjcUSIK3n7ynCQ5P1WimnTiLg7mE4ThoAAx49QwcMqH0g+/xjL0usk5H74knXDAKP 9d3Cd0AZaV8jxl6GBshBo+luZ1ukGu2mXbSUBqX77GqD9j8nUN/P15pxPkP2KvEmM8m8 4OIcTRIoQgbPwv1D/iQPPAztUPds67YrMSWaQoiiggVfUSqGzfUylTazCzre1VhzwFEv huflKvQgpLL6O02X/xvJ/EByuWxrkthoG/+ZqAZEHlsQV/TQnyOCUXCp/a5qcj2rr6RQ PxrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jqf7iIPA+FtQ1MmurkAUtYBLkBwYG+oU9B/In0VsKwE=; b=XA4osVNDYIwz/9FHnJoyKYoDX2b349Z/2mIBJ5SqvBG9yYYppVlO39YHoc7FJrjHPk 0LXgwuEOE0G7fNvVFN35i7uOYnM3uW1Iem+bcWyxrOJr8dROMPRK/FcOH7jAa7eWn3Yd 6fLqJhhkLYsy0vyjETTmPEX0IH+Kutr+DRHeFpbftFGoCMOMb23wJRRNzOXvM5RZHZES NBq23IpG91QbwFPPE9U/Gtd0Nwr2THoRWtcQEj0rn2oiXHF8oKG07QA92mHzwTl8x+W7 +h359UI/l0+zHf3H/wyWK1NlEv0rsenMBEs7Pe1P8IYEN2mpx+3IAy8wqY44uygrjYNS /BQQ== X-Gm-Message-State: AFeK/H2NopY01WUnKWVlut1YCfzA1Lc32FZTa21W8uUtgN8EDjVbjFb7wKJ238QQA1TiPYmcbVrKMKC1ixLkMA== X-Received: by 10.36.206.6 with SMTP id v6mr4155334itg.48.1489571825447; Wed, 15 Mar 2017 02:57:05 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.35.213 with HTTP; Wed, 15 Mar 2017 02:57:04 -0700 (PDT) In-Reply-To: <148954159755.24347.12366542904819082480.idtracker@ietfa.amsl.com> References: <148954159755.24347.12366542904819082480.idtracker@ietfa.amsl.com> From: Daniel Migault Date: Wed, 15 Mar 2017 05:57:04 -0400 X-Google-Sender-Auth: pnOVMgabM3Fx80sOpsBR8fxNjT8 Message-ID: To: Stephen Farrell Cc: The IESG , draft-ietf-ipsecme-rfc7321bis@ietf.org, "ipsec@ietf.org" , ipsecme-chairs@ietf.org, "Waltermire, David A. (Fed)" Content-Type: multipart/alternative; boundary=94eb2c0b0c5886001f054ac1f714 Archived-At: Subject: Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 09:57:08 -0000 --94eb2c0b0c5886001f054ac1f714 Content-Type: text/plain; charset=UTF-8 Regarding the first item manual key is prevented by AES-GCM RFC4306. We do not not such "MUST NOT" level for AES-CCM and Chacha20_poly1305. Maybe we could relax that a little bit and be more accurate saying: OLD: " If manual keying is used anyway, ENCR_AES_CBC MUST be used, and ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT be used as these algorithms require IKE. " NEW: " If manual keying is used anyway, ENCR_AES_GCM MUST NOT be used and ENCR_AES_CBC SHOULD be used." NEWbis: " If manual keying is used anyway, ENCR_AES_CBC SHOULD be used." Yours, Daniel AES-GCM (RFC4306 section 2): """ Because reusing an nonce/key combination destroys the security guarantees of AES-GCM mode, it can be difficult to use this mode securely when using statically configured keys. For safety's sake, implementations MUST use an automated key management system, such as the Internet Key Exchange (IKE) [RFC2409 ], to ensure that this requirement is met. """ AES-CCM (RFC4309) """ To be safe, implementations MUST use fresh keys with AES CCM. The Internet Key Exchange (IKE) [IKE ] protocol or IKEv2 [IKEv2 ] can be used to establish fresh keys. """ Chacha20_poly1305 (RFC7539) """ To generate such a key pair (r,s), we will use the ChaCha20 block function described in Section 2.3 . This assumes that we have a 256-bit session key for the Message Authentication Code (MAC) function, such as SK_ai and SK_ar in Internet Key Exchange Protocol version 2 (IKEv2) ([RFC7296 ]), the integrity key in the Encapsulating Security Payload (ESP) and Authentication Header (AH), or the client_write_MAC_key and server_write_MAC_key in TLS. Any document that specifies the use of Poly1305 as a MAC algorithm for some protocol must specify that 256 bits are allocated for the integrity key. """ On Tue, Mar 14, 2017 at 9:33 PM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-ipsecme-rfc7321bis-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-rfc7321bis/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - I agree with Christian's secdir review [1] that this > doesn't seem justified (at least on it's face): " If > manual keying is used anyway, ENCR_AES_CBC MUST be used, > and ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 > MUST NOT be used as these algorithms require IKE. " Can > you explain the reasoning that lead the WG to say that? > > - ENCR_NULL IMO ought be MUST NOT - did the WG discuss > that explicitly? If so, can you provide a pointer to the > archive? If not, does it still have to be a MUST? I do > wonder who wants to use AH via NAT but cannot, which seems > to be the justification. > > [1] https://www.ietf.org/mail-archive/web/secdir/current/msg07262.html > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --94eb2c0b0c5886001f054ac1f714 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Regarding the first item manual key is prevented by A= ES-GCM RFC4306. We do not not such "MUST NOT" level for AES-CCM a= nd Chacha20_poly1305. Maybe we could relax that a little bit and be more ac= curate saying:

OLD:
" If manual keying is used an= yway, ENCR_AES_CBC MUST be used,
and ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305
MUST NOT be used as these algorithms require IKE.=C2=A0 "

NEW:
" If manual keying is used anyway, ENCR_AES_GCM MUST NOT= be used and ENCR_AES_CBC SHOULD be used."
=C2=A0
NEWbis:
&qu= ot; If manual keying is used anyway, ENCR_AES_CBC SHOULD be used."
=
Yours,
Daniel

AES-GCM= (RFC4306 section 2):
"""
   Because reusing an nonce/key combination destroys the security
   guarantees of AES-GCM mode, it can be difficult to use this mode
   securely when using statically configured keys.  For safety's sake,
   implementations MUST use an automated key management system, such as
   the Internet Key Exchange (IKE) [RFC2409]=
, to ensure that this
   requirement is met.
""" 

AES-CCM (RFC4309)

"""
   To be safe, =
implementations MUST use fresh keys with
   AES CCM.  The Internet Key Exchange (IKE) [IKE] protocol or IKEv2
   [IKEv2] can be used to e=
stablish fresh keys.
"""

Chacha20_poly1305 (RFC7539)
"""
To generate such a key pair (r,s), we will use the C=
haCha20 block
   function described in Section 2.3.  This assumes that we have a
   256-bit session key for the Message Authentication Code (MAC)
   function, such as SK_ai and SK_ar in Internet Key Exchange Protocol
   version 2 (IKEv2) ([RFC7296<=
/a>]), the integrity key in the Encapsulating
   Security Payload (ESP) and Authentication Header (AH), or the
   client_write_MAC_key and server_write_MAC_key in TLS.  Any document
   that specifies the use of Poly1305 as a MAC algorithm for some
   protocol must specify that 256 bits are allocated for the integrity
   key.
"""
On Tue, Mar 14, 2017 at 9:33 PM, Stephen Farrel= l <stephen.farrell@cs.tcd.ie> wrote:
Stephen Farrell has entered the following ballot positio= n for
draft-ietf-ipsecme-rfc7321bis-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/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc= /draft-ietf-ipsecme-rfc7321bis/



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


- I agree with Christian's secdir review [1] that this
doesn't seem justified (at least on it's face): " If
manual keying is used anyway, ENCR_AES_CBC MUST be used,
and ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305
MUST NOT be used as these algorithms require IKE.=C2=A0 " Can
you explain the reasoning that lead the WG to say that?

- ENCR_NULL IMO ought be MUST NOT - did the WG discuss
that explicitly?=C2=A0 If so, can you provide a pointer to the
archive?=C2=A0 If not, does it still have to be a MUST?=C2=A0 I do
wonder who wants to use AH via NAT but cannot, which seems
to be the justification.

[1] https://www.ietf.org/mail-archive/web/secdir/current/msg07262.html


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

--94eb2c0b0c5886001f054ac1f714-- From nobody Wed Mar 15 04:43:37 2017 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 29F35129BF6; Wed, 15 Mar 2017 04:43:30 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 UvJMGJ7BqiyN; Wed, 15 Mar 2017 04:43:28 -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 F1CB6129BF5; Wed, 15 Mar 2017 04:43:27 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vjqVj1YRszD26; Wed, 15 Mar 2017 12:43:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1489578205; bh=EzMPtgtiT6lxzkTSOFp+rOzSwoqG2uRVggNYWIIQMQs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Lo7J2dN/8zAiiaF9hiFKTjs84HvPTJD2bsd77xm0EbSp+MzWjZFPLqFIelYgwb+LM NaTBFF1r9+bxTw+o3/0MplJREvnQYeNMTR/jLL2ogsSc5zJuqa2O54Wog9FwIAoSua d7KkPL1v3obAJLd+wuBjxHFSxlQazPQfBdMNiZbM= 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 1dKqr_bgcPD6; Wed, 15 Mar 2017 12:43:21 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 15 Mar 2017 12:43:20 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id E8E5C2DEFC7; Wed, 15 Mar 2017 07:43:18 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca E8E5C2DEFC7 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D079140D80EE; Wed, 15 Mar 2017 07:43:18 -0400 (EDT) Date: Wed, 15 Mar 2017 07:43:18 -0400 (EDT) From: Paul Wouters To: Daniel Migault cc: Stephen Farrell , draft-ietf-ipsecme-rfc7321bis@ietf.org, "ipsec@ietf.org" , ipsecme-chairs@ietf.org, The IESG , "Waltermire, David A. (Fed)" In-Reply-To: Message-ID: References: <148954159755.24347.12366542904819082480.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 11:43:30 -0000 On Wed, 15 Mar 2017, Daniel Migault wrote: > Regarding the first item manual key is prevented by AES-GCM RFC4306. We do not not such "MUST > NOT" level for AES-CCM and Chacha20_poly1305. Maybe we could relax that a little bit and be more > accurate saying: > > OLD: > " If manual keying is used anyway, ENCR_AES_CBC MUST be used, > and ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 > MUST NOT be used as these algorithms require IKE.  " > > NEW: > " If manual keying is used anyway, ENCR_AES_GCM MUST NOT be used and ENCR_AES_CBC SHOULD be > used." >   > NEWbis: > " If manual keying is used anyway, ENCR_AES_CBC SHOULD be used." I don't think that we should relax it. Those ciphers MUST NOT be used with manual keying due to cryptographic reasons. On top of that, people SHOULD NOT use manual keying because it prevents Perfect Forward Secrecy (PFS). We can clarify that, but I don't think we should change the MUST NOT. Paul > > AES-GCM (RFC4306 section 2): > """ > > Because reusing an nonce/key combination destroys the security > guarantees of AES-GCM mode, it can be difficult to use this mode > securely when using statically configured keys. For safety's sake, > implementations MUST use an automated key management system, such as > the Internet Key Exchange (IKE) [RFC2409], to ensure that this > requirement is met. > """ > > AES-CCM (RFC4309) > """ > To be safe, implementations MUST use fresh keys with > AES CCM. The Internet Key Exchange (IKE) [IKE] protocol or IKEv2 > [IKEv2] can be used to establish fresh keys. > """ > > Chacha20_poly1305 (RFC7539) > > """ > To generate such a key pair (r,s), we will use the ChaCha20 block > function described in Section 2.3. This assumes that we have a > 256-bit session key for the Message Authentication Code (MAC) > function, such as SK_ai and SK_ar in Internet Key Exchange Protocol > version 2 (IKEv2) ([RFC7296]), the integrity key in the Encapsulating > Security Payload (ESP) and Authentication Header (AH), or the > client_write_MAC_key and server_write_MAC_key in TLS. Any document > that specifies the use of Poly1305 as a MAC algorithm for some > protocol must specify that 256 bits are allocated for the integrity > key. > """ > > On Tue, Mar 14, 2017 at 9:33 PM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-ipsecme-rfc7321bis-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-rfc7321bis/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - I agree with Christian's secdir review [1] that this > doesn't seem justified (at least on it's face): " If > manual keying is used anyway, ENCR_AES_CBC MUST be used, > and ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 > MUST NOT be used as these algorithms require IKE.  " Can > you explain the reasoning that lead the WG to say that? > > - ENCR_NULL IMO ought be MUST NOT - did the WG discuss > that explicitly?  If so, can you provide a pointer to the > archive?  If not, does it still have to be a MUST?  I do > wonder who wants to use AH via NAT but cannot, which seems > to be the justification. > > [1] https://www.ietf.org/mail-archive/web/secdir/current/msg07262.html > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > From nobody Wed Mar 15 05:23:56 2017 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 86E6213010C; Wed, 15 Mar 2017 05:23:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-ipsecme-rfc7321bis@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, david.waltermire@nist.gov, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148958062948.24307.17742891713464962830.idtracker@ietfa.amsl.com> Date: Wed, 15 Mar 2017 05:23:49 -0700 Archived-At: Subject: [IPsec] Alissa Cooper's No Objection on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 12:23:50 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-ipsecme-rfc7321bis-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc7321bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- "Interoperability with IoT" doesn't parse when I read it -- maybe you mean "for IoT devices to interoperate" or something like that? From nobody Wed Mar 15 06:19:01 2017 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 C1A9F129C00; Wed, 15 Mar 2017 06:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7s13hlFFDoI; Wed, 15 Mar 2017 06:18:54 -0700 (PDT) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (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 1D499129A9C; Wed, 15 Mar 2017 06:18:54 -0700 (PDT) Received: by mail-it0-x244.google.com with SMTP id g138so3034363itb.0; Wed, 15 Mar 2017 06:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=aDEBMxcKWOhlnTPpoOEK/StUzYz4/Vbl4MF271O4OLI=; b=ZdQu8WBE3SCfjn3yXz1idr1oSv1Lqce75ziqaKpqUylLm9+sA5YsT/QWAk9jngRtk3 yQpyXZmHAfBhGhZ57cfrjpOID1MHKiOHC7Ea2DRFV6LXUnRguB65LwHF1irulRNsJjlt T8nfOp+CwNNzJLn2vqsRW8jidiuETBWE1e2bIUCES+0wiFpIpq6lTmqdDJnctEO+y2R9 iXdHReooP6530VIdfbAaGhuYjQO7RSK6A7Bwj9Dknif9iWDgBna8tRysqZkNWRK+CPTm lhXixyDQ14LYZNUbOdoHjWuNQdB1lbNzN18Q2MRU+Kg43JTdaH7v1ucO11KtV64J+i53 x9/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=aDEBMxcKWOhlnTPpoOEK/StUzYz4/Vbl4MF271O4OLI=; b=kVd9A0vNHCfVhYPsdWNKAJ8cM3NFNPjDxpUXAm3DYwA8xdjHcSowR748vBY1rBTzp4 x8iDjTUs3fbtkjTFOoMg3c7iKSSqrWdm9RvrSJ9ZBAK4Akar/XT/pT5nqH2qiJjm8IQB RBh3vWowi1Yj9/nvElJi8US2etGJZAevRL0W2EZZlJ5YSc6ohdjSg1fZLX7Y2UOQuri8 2Pd8zckBgdsQ65vEnbgS1J7AmwinGqJDdHyGevCMjaE74NLD/o8nRVxHoN2FUY4avf8d vpLKNwbAZarvS93TCV8zRmEX1eZTc4abKkujktt3q2V8dR+rrvxtI4lANkMgqWJYPFNw 8APQ== X-Gm-Message-State: AFeK/H33zxOR44QOWElg6x31S792CzE8OiA/O6zky0eU35UygohokZngORf5z5rSSmYmhAZlDCLUO1pggcdHZg== X-Received: by 10.36.184.129 with SMTP id m123mr4971376ite.120.1489583933488; Wed, 15 Mar 2017 06:18:53 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.35.213 with HTTP; Wed, 15 Mar 2017 06:18:53 -0700 (PDT) In-Reply-To: <148958062948.24307.17742891713464962830.idtracker@ietfa.amsl.com> References: <148958062948.24307.17742891713464962830.idtracker@ietfa.amsl.com> From: Daniel Migault Date: Wed, 15 Mar 2017 09:18:53 -0400 X-Google-Sender-Auth: XUXd7xu8EUfUyuOcxTKKEMldaIY Message-ID: To: Alissa Cooper Cc: The IESG , draft-ietf-ipsecme-rfc7321bis@ietf.org, "ipsec@ietf.org" , ipsecme-chairs@ietf.org, "Waltermire, David A. (Fed)" Content-Type: multipart/alternative; boundary=94eb2c114576380e1c054ac4c95f Archived-At: Subject: Re: [IPsec] Alissa Cooper's No Objection on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 13:18:56 -0000 --94eb2c114576380e1c054ac4c95f Content-Type: text/plain; charset=UTF-8 Hi Alissa, Thanks you for the review and the comments. The recommendation is mostly here for implementation that needs to consider interoperability with IoT devices. This includes the IoT devices themselves. So I have replaced "IoT interoperability" with "to interoperate with IoT devices". Happy to change it if there is a better wording. Yours, Daniel On Wed, Mar 15, 2017 at 8:23 AM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-ipsecme-rfc7321bis-05: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc7321bis/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > "Interoperability with IoT" doesn't parse when I read it -- maybe you > mean "for IoT devices to interoperate" or something like that? > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --94eb2c114576380e1c054ac4c95f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alissa,

Thanks you for the= review and the comments.=C2=A0 The recommendation is mostly here for imple= mentation that needs to consider interoperability with IoT devices. This in= cludes the IoT devices themselves. So I have replaced "IoT interoperab= ility" with "to interoperate with IoT devices". Happy to cha= nge it if there is a better wording.

Yours,
Daniel

On Wed, M= ar 15, 2017 at 8:23 AM, Alissa Cooper <alissa@cooperw.in> wr= ote:
Alissa Cooper has entered the follow= ing ballot position for
draft-ietf-ipsecme-rfc7321bis-05: No Objection

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


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


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc= /draft-ietf-ipsecme-rfc7321bis/



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

"Interoperability with IoT" doesn't parse when I read it -- m= aybe you
mean "for IoT devices to interoperate" or something like that?

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

--94eb2c114576380e1c054ac4c95f-- From nobody Wed Mar 15 06:20:56 2017 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 CC091131498; Wed, 15 Mar 2017 06:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 BpB33XQ1OKkN; Wed, 15 Mar 2017 06:20:52 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 620D5131496; Wed, 15 Mar 2017 06:20:52 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E08CB2BC7FD; Wed, 15 Mar 2017 13:12:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E08CB2BC7FD Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=pwouters@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com E08CB2BC7FD Received: from thinkpad.nohats.ca (vpn-235-251.phx2.redhat.com [10.3.235.251]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v2FDCMFs017460; Wed, 15 Mar 2017 09:12:23 -0400 To: Christian Huitema , The IESG , secdir@ietf.org, draft-ietf-ipsecme-rfc7321bis.all@ietf.org, ipsec@ietf.org References: <2927d78d-7293-ba53-4aa3-0351e0a6e7b2@huitema.net> From: Paul Wouters Message-ID: Date: Wed, 15 Mar 2017 09:12:21 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 15 Mar 2017 13:12:25 +0000 (UTC) Archived-At: Subject: Re: [IPsec] secdir review of draft-ietf-ipsecme-rfc7321bis-05 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 13:20:54 -0000 On 03/14/2017 09:08 PM, Christian Huitema wrote: Thanks for your review Christian! > Adding Paul explicitly, since the forwarding through the draft.all alias > does not pass through the gates of redhat. Thanks, sorry for DMARC'ing issues. I did report it to our IT, but I doubt things will change :( >> This document is ready for publication as a Proposed Standard, with some nits. >> >> My first set of nits concerns the keywords "SHOULD+", "SHOULD-" and "MUST-" that the >> draft is defining. These keywords would make an interesting update to RFC 6919. I >> understand that "SHOULD+" and "MUST-" are already defined and used in RFC 7321, and >> that you have at places to say "RFC 7321 said SHOULD+, but we change that to MUST". >> So maybe you should just note that "RFC 7321 defines these additional keywords". >> Also, you never use SHOULD- in the text, so there is no need to define it. You >> only MUST- once, to downgrade "AUTH_HMAC_SHA1_96" from MUST to MUST-. You could save >> space in the document by just adding a footnote for the SHA1 entry in the table, >> stating that "this MUST means REALLY SHOULD NOT." Or maybe you really want to >> update RFC 6919. We really tried to keep the bis documents 4307bis and 7321bis close to the original so that updates read easily. So even if we do not use one of the keywords now, we might in a new version, so I think it is good for this set of documents to try and keep the same keyword list. >> The second set of nits contains manual keying. According to the draft, anyone using >> manual keying is punished for doing so, and will only be able to use ENCR_AES_CBC. I >> assume that there is WG consensus on that, but the justification that other algorithms >> really require IKEv2 is a bit weak. If there is an API to configure encryption with the >> results of an IKEv2 negotiation, it could just as well be used with the results of a >> manual configuration. Not sure that the definition of algorithms is the best place to >> deprecate manual configuration, even if there are some pretty good reasons to do that. I answered this in the list already, but the short version is that any algorithm that requires IVs to never repeat can never use manual keying because then there is no mechanism to prevent re-using IVs, as most IV's are implemented as counters, which at some point will overflow back to 0 and then the attacker can gain the private key knowledge. Additionally, thre is no PFS when using manual keying, so any compromise could decrypt all previous traffic. With IKE we are talking about 1-8 hours of session key lifetimes, which are just beyond manual keying that stays in place with the same key for months, years or worse. I'm willing to explain the text a bit on this to clarify. >> My last set of nits concerns the relation between this draft and the IANA registry of >> Internet Key Exchange Version 2 (IKEv2) Parameters. I understand that we have five states >> of specification or recommendation: >> * MUST implement and MAY use algorithms such as ENCR_AES_GCM_16; >> * SHOULD implement and MAY use algorithms such as ENCR_CHACHA20_POLY1305; >> * SHOULD implement and MAY use but only for IoT devices, e.g. ENCR_AES_CCM_8; >> * SHOULD NOT implement and MUST NOT use, e.g. ENCR_DES; Presumably, the code >> has to be yanked from existing implementations. >> * and then MAY implement and MAY use, e.g. ENCR_CAMELLIA_CBC. >> But the fifth category is only specified by default, as "those algorithms that >> are listed in the IANA registry but not referenced in the draft." I wonder whether there >> is a way to express that clearly in the draft. Since the tables are pretty big, that's a bit hard to do, and it would distract from the very few prime algorithms we would like them to focus on. Implementers I guess should have the IANA IKEv2 page open along with the RFC for the full picture. I do want to say that for ipsec, the algorithms that are only in MAY are either pretty new and have no deployment yet (curve25519, chacha20-poly1305) or are kind of obsolete but no known attack against them has been successful (cast, serpent, twofish) Paul From nobody Wed Mar 15 07:37:55 2017 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 2A5121315A7; Wed, 15 Mar 2017 07:37:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Pete Resnick To: Cc: ipsec@ietf.org, draft-ietf-ipsecme-rfc4307bis.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148958867307.4072.14018084445475450669@ietfa.amsl.com> Date: Wed, 15 Mar 2017 07:37:53 -0700 Archived-At: Subject: [IPsec] Review of draft-ietf-ipsecme-rfc4307bis-17 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 14:37:53 -0000 Reviewer: Pete Resnick Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-ipsecme-rfc4307bis-17 Reviewer: Pete Resnick Review Date: 2017-03-15 IETF LC End Date: 2017-01-31 IESG Telechat date: 2017-03-16 Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: While using MUST, SHOULD, and MAY as nouns and adjectives causes me a twitch, this document is just fine. There's a typo in the first paragraph of 1.2. From nobody Wed Mar 15 16:55:26 2017 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 337EB12EA6A; Wed, 15 Mar 2017 16:55:25 -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, RP_MATCHES_RCVD=-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 LFGbgX-DjcTl; Wed, 15 Mar 2017 16:55:24 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id BF1C112E852; Wed, 15 Mar 2017 16:55:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 092AE2CCC1; Thu, 16 Mar 2017 01:55:23 +0200 (EET) (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 xO_ALTBJjcC4; Thu, 16 Mar 2017 01:55:22 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id EF8662CC5E; Thu, 16 Mar 2017 01:55:20 +0200 (EET) (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=_7453E6B7-61A1-4712-8520-14D8C39CC027"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: <148958867307.4072.14018084445475450669@ietfa.amsl.com> Date: Thu, 16 Mar 2017 08:55:18 +0900 Cc: General Area Review Team , ipsec@ietf.org, draft-ietf-ipsecme-rfc4307bis.all@ietf.org Message-Id: <1553C4D7-A087-47A2-BEDF-B5DABFF88C5C@piuha.net> References: <148958867307.4072.14018084445475450669@ietfa.amsl.com> To: Pete Resnick X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [IPsec] Review of draft-ietf-ipsecme-rfc4307bis-17 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 23:55:25 -0000 --Apple-Mail=_7453E6B7-61A1-4712-8520-14D8C39CC027 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks for your review, Pete. I have posted a no-objection position for = today=92s IESG telechat. Jari --Apple-Mail=_7453E6B7-61A1-4712-8520-14D8C39CC027 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 iQIcBAEBCgAGBQJYydRmAAoJEM80gCTQU46qo3IP/1mlfX7q40Hqo5uPhoUzNy9i cboo2pMPTZmuW6kOWuWPh6N0/lLqu4g38o0noJcq/npa/p9a/eQu6hTmBCFXCSwW lq1N55tZK4a9ELrM9BPMDt7jnstT0JABJ2mH6JDKdcPj3bfgfOaAN5y4kVsyUQOd bkSKsMg09BNFDW3bKl0eGi51LB4jTCSsvRG3FDKYTR2tBC82MwFHgc6GGd9tbKHf h8UIYDYxgubU13yZ/ps7LTZ9etgFu7B+dyOBkjyhDGUiAh3lL84x7NLyD7S39r2V uX6gGdigvZgYwmZJa91lT1rForaKqIwzu4f4AkCXzpDZZnsgd4jaka3yewKm3t57 HZGn+YTNVQUDozB0Pw7CbTGUJ01Rer1MYvzt6Dd36q2dsCY6i3xANcfIK34bto14 76tLblM30tFU/re4Goi5J+wrrwZFv+cMGhu6w9BJCIJcHZnWkGv+znZQcvP6LTXa 20QMsGAjrk47Mch4Gctkj1a/mGEj2O71IWBUgkCNXAe9ogZDyvTW35AIdx1na4Uz bD7eVX9uzYNtNAD9yzWWI+W7lZlqWczbxaiNNJDO8Joxggzi0MdgqqHuKXi3nTJx 8zD2Hm+G9PY8peKuGzLKb7cd3d8g7rX8O5CXy7MIIe3eTHa67eFEGAc9b4ZBwjGb V87rcqHsYHuoL5gB243f =I9Ye -----END PGP SIGNATURE----- --Apple-Mail=_7453E6B7-61A1-4712-8520-14D8C39CC027-- From nobody Wed Mar 15 18:48:20 2017 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 D9ED312F24E; Wed, 15 Mar 2017 18:48:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-ipsecme-rfc7321bis@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, david.waltermire@nist.gov, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148962889979.14189.965850110922865986.idtracker@ietfa.amsl.com> Date: Wed, 15 Mar 2017 18:48:19 -0700 Archived-At: Subject: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 01:48:20 -0000 Ben Campbell has entered the following ballot position for draft-ietf-ipsecme-rfc7321bis-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-rfc7321bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm balloting "Yes", but I have a few minor comments/questions: - Abtstract: "This document obsoletes RFC 7321 on the cryptographic recommendations only." I'm not sure what that means. Does the reader of this still need to read 7321? If so, is "obsoletes" the correct relation? -3: I wonder why "... is not to be used..." is not "... MUST NOT be used...". But the section goes on to say if you do it anyway, you MUST NOT use certain cryptosuites. So, does "... is not to be used..." mean "SHOULD NOT"? Or is this one of those "MUST NOT BUT WE KNOW YOU WILL" sort of requirements? - Table in section 6: I'm boggled by the first entry being labeled "MUST/MUST NOT". I don't see anything in the text to explain the "MUST" part--did I miss something? From nobody Wed Mar 15 18:49:43 2017 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 D0D6212F24E; Wed, 15 Mar 2017 18:49:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-ipsecme-rfc4307bis@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, david.waltermire@nist.gov, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148962898085.14169.1591384545915810858.idtracker@ietfa.amsl.com> Date: Wed, 15 Mar 2017 18:49:40 -0700 Archived-At: Subject: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc4307bis-17: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 01:49:41 -0000 Ben Campbell has entered the following ballot position for draft-ietf-ipsecme-rfc4307bis-17: 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-rfc4307bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (oops, meant to ballot "yes". Fixed now.) Section 2.1, 2nd to last paragraph says that ENCR_3DES has been downgraded to SHOULD NOT. But both the table in this section, and the change table later in the draft say MAY. From nobody Thu Mar 16 01:26:46 2017 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 3C51B1250B8; Thu, 16 Mar 2017 01:26:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: draft-ietf-ipsecme-rfc7321bis@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, david.waltermire@nist.gov, ipsec@ietf.org, jiangsheng@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148965279915.14221.1905194181077675780.idtracker@ietfa.amsl.com> Date: Thu, 16 Mar 2017 01:26:39 -0700 Archived-At: Subject: [IPsec] Benoit Claise's No Objection on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 08:26:39 -0000 Benoit Claise has entered the following ballot position for draft-ietf-ipsecme-rfc7321bis-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc7321bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- As discussed based on the OPS DIR review: Hi Paul, To avoid any future questions, are your 3 justifications below mentioned in the draft? Regards, Benoit > On 03/13/2017 07:17 AM, Sheng Jiang wrote: > > Hello Sheng, > > thanks for your review! > >> Comparing with RFC 7321, this document uses different names for algorithms. Although it looks consistent, it may reduce readability a little. The below items, I would like to double check for consistent. >> >> >> >> 3DES ?= TripleDES-CBC (old) >> >> DES ?= DES-CBC (old) >> >> AES_XCBC_96 ?= AES-XCBC-MAC-96 (old) > e actually changed all names to match the actual IANA IKEv2 entries at http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml > >> There are a few new algorithms mentioned, without any description or analysis. Additional explanation should be needed. >> >> >> DES_IV64 >> >> DES_IV32 >> >> 3IDEA > Those are old reserved entries that have no implementation and therefor actually have no RFC we can point to. Which is also why we made > it very clear these are MUST NOT. > >> I actually have more concerns regarding to the below algorithm that is mentioned in RFC7321, but not in this document. Does it create a new hole? >> >> >> AES-CTR [RFC3686] > It was mentioned in 7321 because it went from SHOULD to MAY. > > It is not mentioned in 7321bis because it is still at MAY, and we do not list any algorithms in MAY. > > I hope this clarifies your questions, > > Paul From nobody Thu Mar 16 09:59:37 2017 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 7BABF1273E2; Thu, 16 Mar 2017 09:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] 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 66c1hJSvWZTh; Thu, 16 Mar 2017 09:59:33 -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 8C0AC1296BA; Thu, 16 Mar 2017 09:59:33 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vkZSw4V4bz7bp; Thu, 16 Mar 2017 17:59:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1489683568; bh=3FjogsThbHkKuhCyYQ7ShJIb002FmOasOlwEPIWWrNI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=VsIJcn1Vqx/k4gdD0WQK+9Eblg0nF8kwU+l4fNMfmJteZ6+3OQlbN8F0k14Vuvxb0 uiqsz5New6HG48bF9ClsJYKJTMlJKGjWI/jOWrzgDw53A4lro4DQPjY6owNmREeFAr +DPucvQk6iXri9ou3dm494ZfRiqs3nBcw9mlRvtc= 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 4IMZz8ycL2vb; Thu, 16 Mar 2017 17:59:27 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 16 Mar 2017 17:59:27 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 863E239D3A6; Thu, 16 Mar 2017 12:59:26 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 863E239D3A6 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6E2A740ACF3C; Thu, 16 Mar 2017 12:59:26 -0400 (EDT) Date: Thu, 16 Mar 2017 12:59:26 -0400 (EDT) From: Paul Wouters To: Ben Campbell cc: The IESG , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-rfc4307bis@ietf.org, david.waltermire@nist.gov In-Reply-To: <148962898085.14169.1591384545915810858.idtracker@ietfa.amsl.com> Message-ID: References: <148962898085.14169.1591384545915810858.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc4307bis-17: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 16:59:36 -0000 On Wed, 15 Mar 2017, Ben Campbell wrote: > Section 2.1, 2nd to last paragraph says that ENCR_3DES has been > downgraded to SHOULD NOT. But both the table in this section, and the > change table later in the draft say MAY. Oops, that's a big bug this late in the game!! We will have to do another update with the table fixed. I do believe the text is correct and 3DES is classified as SHOULD NOT. Paul From nobody Thu Mar 16 10:07:46 2017 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 837071296BE; Thu, 16 Mar 2017 10:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] 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 VCsOW849WFf2; Thu, 16 Mar 2017 10:07:37 -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 BC81D127011; Thu, 16 Mar 2017 10:07:37 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vkZfH2psTzD2K; Thu, 16 Mar 2017 18:07:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1489684055; bh=BNBpG2ubBfYzz8dhv1LhKeKTAGDA4dvhdmTEX22g1hM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Wz2sNr6pv05XFF2z/jREYVY1Kou+zsXVYqByM1ZOPUIT/cHnx1RP97prEYbpqqxDw b3PyQT1auU92lZ16GtNPmOSWnhEsCKjrj94rTWRXpGnJhD/94UPrcYELtAzWxdTgRW +FQSkK5H6Qbk9ZVAq7SCGRZCg2XavCa/kGjnNzZk= 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 X76uCQJ1u8Zt; Thu, 16 Mar 2017 18:07:34 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 16 Mar 2017 18:07:33 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id BAA5239D3A6; Thu, 16 Mar 2017 13:07:32 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca BAA5239D3A6 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A7D5C40ACF3C; Thu, 16 Mar 2017 13:07:32 -0400 (EDT) Date: Thu, 16 Mar 2017 13:07:32 -0400 (EDT) From: Paul Wouters To: Ben Campbell cc: The IESG , draft-ietf-ipsecme-rfc7321bis@ietf.org, ipsec@ietf.org, ipsecme-chairs@ietf.org, david.waltermire@nist.gov In-Reply-To: <148962889979.14189.965850110922865986.idtracker@ietfa.amsl.com> Message-ID: References: <148962889979.14189.965850110922865986.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 17:07:39 -0000 On Wed, 15 Mar 2017, Ben Campbell wrote: > - Abtstract: "This document obsoletes RFC 7321 on the cryptographic > recommendations only." > > I'm not sure what that means. Does the reader of this still need to read > 7321? If so, is "obsoletes" the correct relation? Skimming over 7321 I cannot actually tell what we meant to not obsolete? I think we can remove the "on the cryptographic recommendations only." > -3: I wonder why "... is not to be used..." is not "... MUST NOT be > used...". But the section goes on to say if you do it anyway, you MUST > NOT use certain cryptosuites. So, does "... is not to be used..." mean > "SHOULD NOT"? Or is this one of those "MUST NOT BUT WE KNOW YOU WILL" > sort of requirements? It is indeed. I think a SHOULD NOT would actually be appropriate ? > - Table in section 6: > I'm boggled by the first entry being labeled "MUST/MUST NOT". I don't see > anything in the text to explain the "MUST" part--did I miss something? First paragraph under the table: AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT. The only reason NULL is acceptable is when authenticated encryption algorithms are selected from Section 5. In all other cases, NULL MUST NOT be selected. Paul From nobody Thu Mar 16 10:14:40 2017 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 20FEF1296BC; Thu, 16 Mar 2017 10:14:39 -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 hwQ_pDO1stEb; Thu, 16 Mar 2017 10:14:35 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0136.outbound.protection.outlook.com [23.103.201.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 C67FE12948B; Thu, 16 Mar 2017 10:14:34 -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=dLGcxXZzKXFyOrUfcSy/qJEIfWQfioYNXLB6+3imSvY=; b=atD/Kf5/L43eYrUmouvyktnGKA/UoS+jKvO4EtMXyoGPCHilr+lqyqDOZPRUKiLHQShYApHWHBozmj/CA9ap7wawIKkl5Zyvot4lkJo0mkfIY6nfrhY6HcHg8kRf7PF6dCG05btP71Nm7ugIZNObo/SgEe5DRAscyjyf+NRZCl4= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1439.namprd09.prod.outlook.com (10.173.50.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17; Thu, 16 Mar 2017 17:14:33 +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.0961.022; Thu, 16 Mar 2017 17:14:33 +0000 From: "Waltermire, David A. (Fed)" To: "ipsec@ietf.org" CC: "paul@nohats.ca" , Ben Campbell , "The IESG" , "ipsecme-chairs@ietf.org" , "draft-ietf-ipsecme-rfc7321bis@ietf.org" Thread-Topic: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT) Thread-Index: AQHSnfdl40+jpMEtEk+V4UbJ3240ZKGXs6oAgAAAe/A= Date: Thu, 16 Mar 2017 17:14:33 +0000 Message-ID: References: <148962889979.14189.965850110922865986.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.220.16] x-microsoft-exchange-diagnostics: 1; MWHPR09MB1439; 7:3F3jSu1O88sK57UuCp6jd9f2OmtJoSK13PXo6ND6jr2IlhkdsaOCkNeZ9YRvK1016w6O5VWVJPYdufR7PSt4SP10c9msbJ1vNAOuqNaamlBBiOvC1FBhRcUFWz6c05hC6U+AwfrgqB4EUXoE7gHIRvpM8bpYHV83eO/nQDmWF5er5xGzZ6YeYP93lvLsZCWekafP3y6j470KXhWUvFk33vTJ2PkBRcaD5gTYuzGC+rUr5uGLFe3kokQnY/waxu9eGBdv1TT1QR1sQxTUIdkeCnbrmrZXGLwpVKIQMsjcJ4AHXF3snj2QWYCi/mKHti1VYZ53HO58myOf9F2WussEjA== x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-ms-office365-filtering-correlation-id: 2ec31b9b-d5e2-4899-b36f-08d46c8fea6f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:MWHPR09MB1439; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123558025)(20161123564025)(20161123562025)(20161123560025)(6072148); SRVR:MWHPR09MB1439; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1439; x-forefront-prvs: 024847EE92 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39410400002)(39860400002)(39840400002)(39450400003)(13464003)(377454003)(24454002)(66066001)(7696004)(53546007)(2351001)(189998001)(4326008)(6916009)(81166006)(2950100002)(1730700003)(8676002)(5660300001)(86362001)(54906002)(8936002)(74316002)(230783001)(305945005)(2501003)(5640700003)(6436002)(2906002)(25786008)(76176999)(50986999)(122556002)(54356999)(2900100001)(3280700002)(3660700001)(53936002)(6116002)(33656002)(55016002)(3846002)(99286003)(6246003)(229853002)(102836003)(9686003)(77096006)(110136004)(38730400002)(6506006); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1439; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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: 16 Mar 2017 17:14:33.2041 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1439 Archived-At: Subject: Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 17:14:39 -0000 Comments below. > -----Original Message----- > From: Paul Wouters [mailto:paul@nohats.ca] > Sent: Thursday, March 16, 2017 1:08 PM > To: Ben Campbell > Cc: The IESG ; draft-ietf-ipsecme-rfc7321bis@ietf.org; > ipsec@ietf.org; ipsecme-chairs@ietf.org; Waltermire, David A. (Fed) > > Subject: Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-= 05: > (with COMMENT) >=20 > On Wed, 15 Mar 2017, Ben Campbell wrote: >=20 > > -3: I wonder why "... is not to be used..." is not "... MUST NOT be > > used...". But the section goes on to say if you do it anyway, you MUST > > NOT use certain cryptosuites. So, does "... is not to be used..." mean > > "SHOULD NOT"? Or is this one of those "MUST NOT BUT WE KNOW YOU > WILL" > > sort of requirements? >=20 > It is indeed. I think a SHOULD NOT would actually be appropriate ? Anyone in the WG have an opinion about making this change to SHOULD NOT? Pl= ease comment soon if you do. Thanks, Dave From nobody Thu Mar 16 10:55:37 2017 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 3F394129584; Thu, 16 Mar 2017 10:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44m0Cty-3F9z; Thu, 16 Mar 2017 10:55:33 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B22FB129704; Thu, 16 Mar 2017 10:55:33 -0700 (PDT) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v2GHtWcN074842 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 16 Mar 2017 12:55:32 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Paul Wouters" Cc: "The IESG" , draft-ietf-ipsecme-rfc7321bis@ietf.org, ipsec@ietf.org, ipsecme-chairs@ietf.org, david.waltermire@nist.gov Date: Thu, 16 Mar 2017 12:55:31 -0500 Message-ID: In-Reply-To: References: <148962889979.14189.965850110922865986.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 17:55:35 -0000 Thansk for the response. This resolves all but one of my comments, where I still have a question: On 16 Mar 2017, at 12:07, Paul Wouters wrote: > On Wed, 15 Mar 2017, Ben Campbell wrote: [...] > > > First paragraph under the table: > > AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT. The > only reason NULL is acceptable is when authenticated encryption > algorithms are selected from Section 5. In all other cases, NULL > MUST NOT be selected. So does the authenticated encryption case make AUTH_NONE a MUST? If so, it would help to add something along the lines of "..., in which case AUTH_NONE MUST be selected." to the 2nd sentence. > > Paul From nobody Thu Mar 16 11:58:54 2017 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 7BA051298B7; Thu, 16 Mar 2017 11:58: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 G5Hm7I4ZHSm7; Thu, 16 Mar 2017 11:58:47 -0700 (PDT) Received: from mail-qt0-x241.google.com (mail-qt0-x241.google.com [IPv6:2607:f8b0:400d:c0d::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B7E012975C; Thu, 16 Mar 2017 11:58:47 -0700 (PDT) Received: by mail-qt0-x241.google.com with SMTP id n37so6898281qtb.3; Thu, 16 Mar 2017 11:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=X6/3k86Fxw60ZZq17kFSMs5MVsYHwiKmn7rauppyf8U=; b=rzrTiFUMrKJV2ab0UfB79jIxSEk3Fyu8qVkSfs7cYVdPYcuWa8Al4V8Z0CoEsMAkiH qsDV6LmT1RFgMNcZf/7U3Ldg9GJjeHxsQ/Q6g7+k5+uU3eb2ukiisW2245DxdwskchXx T6rwvd6npCcn7BCCsl5kzl6QFofboNFsFUyNVirj8r8fwmT4xz+ioNyOoSPoqTDg6c9B VrwElReh4GQFEIrNbfSYvPQARptuUokrPJGwWrT4edynCotC3dG+PqAM1lxuSY5SgK6F BzON7rdgAnUUFme3q/JxUUBNoPY+WCYvZwtxzSa7wUrVkxn4whvR/FW7JRAdu7gLiSsy IKFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=X6/3k86Fxw60ZZq17kFSMs5MVsYHwiKmn7rauppyf8U=; b=htmC610Cjc7LUpG2BrdL/UMeX5u/DrUUJhpixSkX2mqeFruLVWX5ZB2Ra71QIo/GnP uiFcplX9FxMGGdjZrbKdMqOsrX96fEtfLQCrN/zpx76XMgTu+l/KI3tO0jnmua+zDHwt GmB49T1OSAtjNWlpOyLHTvE4nJ5QlS9m2YjX5lKyBCXucE/yFm4YxnncGzQ9v4GZcLRM r9Ch4T/olCrZ5KDGsM6Y1x/yibgctf5y/6He6BbvsNiwVfmnaKWEQiW0JJz65K5Sbq59 LyNbDbRpUFNn7kzcKb3NMEvzKOUU4aoBnjv69NNsyjVw5GYFxFvZL4wU6pi2uAxTTL6+ EJ0A== X-Gm-Message-State: AFeK/H0J9QyVG/bpKaiMknUEjE/D8DlCo5r8kpPGo9l753J1tmVx9c/3SDworpqS90Dr8g== X-Received: by 10.237.50.97 with SMTP id y88mr10920084qtd.104.1489690726370; Thu, 16 Mar 2017 11:58:46 -0700 (PDT) Received: from [10.132.111.189] (mobile-166-172-062-104.mycingular.net. [166.172.62.104]) by smtp.gmail.com with ESMTPSA id q15sm4260426qtc.1.2017.03.16.11.58.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Mar 2017 11:58:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: kathleen.moriarty.ietf@gmail.com X-Mailer: iPhone Mail (14D27) In-Reply-To: Date: Thu, 16 Mar 2017 14:58:44 -0400 Cc: Ben Campbell , ipsec@ietf.org, ipsecme-chairs@ietf.org, david.waltermire@nist.gov, The IESG , draft-ietf-ipsecme-rfc4307bis@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4516FA2D-9494-41DA-8E7F-087A527C49AB@gmail.com> References: <148962898085.14169.1591384545915810858.idtracker@ietfa.amsl.com> To: Paul Wouters Archived-At: Subject: Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc4307bis-17: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 18:58:48 -0000 Please excuse typos, sent from handheld device=20 > On Mar 16, 2017, at 12:59 PM, Paul Wouters wrote: >=20 >> On Wed, 15 Mar 2017, Ben Campbell wrote: >>=20 >> Section 2.1, 2nd to last paragraph says that ENCR_3DES has been >> downgraded to SHOULD NOT. But both the table in this section, and the >> change table later in the draft say MAY. >=20 > Oops, that's a big bug this late in the game!! Right, but it's an inconsistency in the document. Which of the 3 were normat= ive? I'm just on a phone at the moment or I'd look. I'm just asking from a process standpoint. Thank you, Kathleen=20 >=20 > We will have to do another update with the table fixed. I do believe > the text is correct and 3DES is classified as SHOULD NOT. >=20 > Paul >=20 From nobody Thu Mar 16 13:13:53 2017 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 2A0BA129A44 for ; Thu, 16 Mar 2017 13:13:51 -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 dyZWsRE-aJkZ for ; Thu, 16 Mar 2017 13:13:48 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0138.outbound.protection.outlook.com [23.103.201.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36907120025 for ; Thu, 16 Mar 2017 13:13:48 -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=Hie4iulLK12QxIGSMXEN0NiSnB4tZU33ph8ycA13nmg=; b=onpH3DJCFP7mIOHFJy6yYRxTUCPecjCiCtsX/IhBoRK7vjh5L8Qsde6d5C3DhiRjKNB350OALUvKMo53pS9AX7CZEran9+qzhuHb+FLUALo8Bp/HzxTExu/Ik4HVfHQWOOB3Lh7bBSytjWRLZMohW+L311/8HPTeyb2grfydoGw= Received: from DM5PR09MB1339.namprd09.prod.outlook.com (10.172.37.139) by DM5PR09MB1434.namprd09.prod.outlook.com (10.173.171.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.961.17; Thu, 16 Mar 2017 20:13:47 +0000 Received: from DM5PR09MB1339.namprd09.prod.outlook.com ([10.172.37.139]) by DM5PR09MB1339.namprd09.prod.outlook.com ([10.172.37.139]) with mapi id 15.01.0977.010; Thu, 16 Mar 2017 20:13:46 +0000 From: "Frankel, Sheila E. (Fed)" To: "Waltermire, David A. (Fed)" , "ipsec@ietf.org" Thread-Topic: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT) Thread-Index: AQHSnfdtwGnzaqhrYUa0/UAwrK5Vm6GXs6oAgAAB9oCAADF1Eg== Date: Thu, 16 Mar 2017 20:13:46 +0000 Message-ID: References: <148962889979.14189.965850110922865986.idtracker@ietfa.amsl.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nist.gov; dkim=none (message not signed) header.d=none;nist.gov; dmarc=none action=none header.from=nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [132.163.219.22] x-microsoft-exchange-diagnostics: 1; DM5PR09MB1434; 7:voqRm2xdVuJNmF1uVdrC2orxoy06IZr5DfRI0DXguZMwY5fsfViNYbaATz7aaH44kZK4QKu414j9ojwsmM0kP0R8ncrKUJYkEbX8B9KNiPWpzqd1wQIUp2fo+bw9xcRa3GE6extUQtht/4ZWgGaAWPYTIJ9P0c3ly7mEdJdZdvoAGRphtjqkdT/42v+jecx7CG9V4KR7bgUaMAKICPnnW5j4yNr+QzFAKi6Cldt6NEI16lU2K8Wo2VSZYRFP3xsoJwnn8E/+qLWcGUt1VVzaiBZqc/Vpayx/5E66PSGRnzaKyZr6oJ4OaX0AU6ZGfYWBsk3XRhI3ajFq5lgxLeMJDw== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(39450400003)(39860400002)(39840400002)(13464003)(54094003)(377454003)(24454002)(6246003)(230783001)(7736002)(86362001)(74316002)(122556002)(33656002)(76176999)(189998001)(7906003)(54356999)(50986999)(6436002)(606005)(6506006)(25786008)(102836003)(66066001)(6116002)(236005)(5660300001)(53936002)(7696004)(53546007)(6306002)(54896002)(9686003)(2501003)(3280700002)(99286003)(55016002)(2950100002)(229853002)(2906002)(8936002)(8676002)(77096006)(38730400002)(81166006)(3660700001)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR09MB1434; H:DM5PR09MB1339.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 55201a07-9c59-4950-ead4-08d46ca8f3a5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254037)(48565401081); SRVR:DM5PR09MB1434; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(65766998875637)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(20161123558025)(6072148); SRVR:DM5PR09MB1434; BCL:0; PCL:0; RULEID:; SRVR:DM5PR09MB1434; x-forefront-prvs: 024847EE92 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR09MB1339A9DFAE3E6E09150BF627E7260DM5PR09MB1339namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2017 20:13:46.2393 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR09MB1434 Archived-At: Subject: Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 20:13:51 -0000 --_000_DM5PR09MB1339A9DFAE3E6E09150BF627E7260DM5PR09MB1339namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dave, I don't have any strong feelings about MUST NOT vs. SHOULD NOT, but I wonde= r if it would help to clarify the reasoning behind it. For these algorithms, RFC6071 (IPsec/IKE Roadmap) says: - Reuse of the IV with the same key compromises the data's security; thus, = AES-GCM should not be used with manual keying. - Reuse of the IV with the same key and nonce compromises the data's securi= ty; thus, AES-CTR should not be used with manual keying. - Reuse of the IV with the same key compromises the data's security; thus, = AES-CCM should not be used with manual keying. - Reuse of the salt value with the same key compromises the data's security= ; thus, AES-GMAC should not be used with manual keying. Instead of just saying "these algorithms require IKE", could we give a slig= htly more detailed explanation? something like: "These algorithms require t= he use of an automated key negotiation protocol (e.g. IKE) to avoid reuse o= f important parameters, whose reuse compromises the algorithm's security." = (Not the best wording, but you get the idea!) But if you don't add this, I wouldn't object to publication of the RFC. Sheila Frankel ________________________________ From: IPsec on behalf of Waltermire, David A. (Fed= ) Sent: Thursday, March 16, 2017 1:14:33 PM To: ipsec@ietf.org Cc: draft-ietf-ipsecme-rfc7321bis@ietf.org; Ben Campbell; ipsecme-chairs@ie= tf.org; paul@nohats.ca; The IESG Subject: Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05= : (with COMMENT) Comments below. > -----Original Message----- > From: Paul Wouters [mailto:paul@nohats.ca] > Sent: Thursday, March 16, 2017 1:08 PM > To: Ben Campbell > Cc: The IESG ; draft-ietf-ipsecme-rfc7321bis@ietf.org; > ipsec@ietf.org; ipsecme-chairs@ietf.org; Waltermire, David A. (Fed) > > Subject: Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-= 05: > (with COMMENT) > > On Wed, 15 Mar 2017, Ben Campbell wrote: > > > -3: I wonder why "... is not to be used..." is not "... MUST NOT be > > used...". But the section goes on to say if you do it anyway, you MUST > > NOT use certain cryptosuites. So, does "... is not to be used..." mean > > "SHOULD NOT"? Or is this one of those "MUST NOT BUT WE KNOW YOU > WILL" > > sort of requirements? > > It is indeed. I think a SHOULD NOT would actually be appropriate ? Anyone in the WG have an opinion about making this change to SHOULD NOT? Pl= ease comment soon if you do. Thanks, Dave _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_DM5PR09MB1339A9DFAE3E6E09150BF627E7260DM5PR09MB1339namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable


Hi Dave,

I don't have any strong feelings about MUST NOT vs. SHOULD NOT, but I wonde= r if it would help to clarify the reasoning behind it.

For these algorithms, RFC6071 (IPsec/IKE Roadmap) says:
- Reuse of the IV with the same key compromises the data's security; thus, = AES-GCM should not be used with manual keying.
- Reuse of the IV with the same key and nonce compromises the data's securi= ty; thus, AES-CTR should not be used with manual keying.
- Reuse of the IV with the same key compromises the data's security; thus, = AES-CCM should not be used with manual keying.
- Reuse of the salt value with the same key compromises the data's security= ; thus, AES-GMAC should not be used with manual keying.

Instead of just saying "these algorithms require IKE", could we g= ive a slightly more detailed explanation? something like: "These algor= ithms require the use of an automated key negotiation protocol (e.g. IKE) t= o avoid reuse of important parameters, whose reuse compromises the algorithm's security." (Not the best wording, but you= get the idea!)
But if you don't add this, I wouldn't object to publication of the RFC.

Sheila Frankel

From: IPsec <ipsec-bou= nces@ietf.org> on behalf of Waltermire, David A. (Fed) <david.walterm= ire@nist.gov>
Sent: Thursday, March 16, 2017 1:14:33 PM
To: ipsec@ietf.org
Cc: draft-ietf-ipsecme-rfc7321bis@ietf.org; Ben Campbell; ipsecme-ch= airs@ietf.org; paul@nohats.ca; The IESG
Subject: Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc732= 1bis-05: (with COMMENT)
 

Comments below.

> -----Original Message-----
> From: Paul Wouters [mailto:paul@noha= ts.ca]
> Sent: Thursday, March 16, 2017 1:08 PM
> To: Ben Campbell <ben@nostrum.com>
> Cc: The IESG <iesg@ietf.org>; draft-ietf-ipsecme-rfc7321bis@ietf= .org;
> ipsec@ietf.org; ipsecme-chairs@ietf.org; Waltermire, David A. (Fed) > <david.waltermire@nist.gov>
> Subject: Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321b= is-05:
> (with COMMENT)
>
> On Wed, 15 Mar 2017, Ben Campbell wrote:
>
> > -3: I wonder why "... is not to be used..." is not &quo= t;... MUST NOT be
> > used...". But the section goes on to say if you do it anyway= , you MUST
> > NOT use certain cryptosuites. So, does "... is not to be use= d..." mean
> > "SHOULD NOT"? Or is this one of those "MUST NOT BU= T WE KNOW YOU
> WILL"
> > sort of requirements?
>
> It is indeed. I think a SHOULD NOT would actually be appropriate ?

Anyone in the WG have an opinion about making this change to SHOULD NOT? Pl= ease comment soon if you do.

Thanks,
Dave

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.or= g/mailman/listinfo/ipsec
 --_000_DM5PR09MB1339A9DFAE3E6E09150BF627E7260DM5PR09MB1339namp_-- From nobody Thu Mar 16 13:19:49 2017 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 899A2129A4C for ; Thu, 16 Mar 2017 13:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.496 X-Spam-Level: X-Spam-Status: No, score=-5.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.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 6N_aqx5ZPFM1 for ; Thu, 16 Mar 2017 13:19:46 -0700 (PDT) Received: from esa3.dell-outbound.iphmx.com (esa3.dell-outbound.iphmx.com [68.232.153.94]) (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 3C8921296A2 for ; Thu, 16 Mar 2017 13:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1489695082; x=1521231082; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qOfdifl9luGqcYP3kQ74h7JEMYwCVdk6AhJdJrZbSc8=; b=IB6jKR9FlGRwT3nbiKGeCy74VLxZq53NsKh3v6zIIlmBm24rvoUxQfpZ s1maCyo0VaiEZtbEhMfdpP+yTgumyL+XQl2wUcFxW/TfWqRExumOl4IH3 a27ctnPEOgOwAuO72ZeU7o7E5lZHi8Ym8Nmaw119eVi7wayi2CC/JUXAm M=; Received: from esa5.dell-outbound2.iphmx.com ([68.232.153.203]) by esa3.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Mar 2017 15:11:21 -0500 From: Received: from ausxippc101.us.dell.com ([143.166.85.207]) by esa5.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Mar 2017 02:10:33 +0600 X-LoopCount0: from 10.175.216.249 X-IronPort-AV: E=Sophos;i="5.36,173,1486447200"; d="scan'208,217";a="922469200" To: CC: , Thread-Topic: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT) Thread-Index: AQHSnfd0XQvvES+uGkGEDF04hrQ/d6GYB3wAgAAB9oCAADISAIAAAcoA Date: Thu, 16 Mar 2017 20:19:40 +0000 Message-ID: <64AEC115-E33A-4E2C-9636-06AC33386F1E@dell.com> References: <148962889979.14189.965850110922865986.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.178.128.191] Content-Type: multipart/alternative; boundary="_000_64AEC115E33A4E2C963606AC33386F1Edellcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 20:19:47 -0000 --_000_64AEC115E33A4E2C963606AC33386F1Edellcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mar 16, 2017, at 4:13 PM, Frankel, Sheila E. (Fed) > wrote: Hi Dave, I don't have any strong feelings about MUST NOT vs. SHOULD NOT, but I wonde= r if it would help to clarify the reasoning behind it. For these algorithms, RFC6071 (IPsec/IKE Roadmap) says: - Reuse of the IV with the same key compromises the data's security; thus, = AES-GCM should not be used with manual keying. ... If "compromises" means that the security is slightly weakened, then this wo= rding seems ok. If it means that the cipher is readily broken if you do th= is bad thing, then the only valid text is "MUST NOT". paul --_000_64AEC115E33A4E2C963606AC33386F1Edellcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Mar 16, 2017, at 4:13 PM, Frankel, Sheila E. (Fed) <<= a href=3D"mailto:sheila.frankel@nist.gov" class=3D"">sheila.frankel@nist.go= v> wrote:


Hi Dave,

I don't have any strong feelings about MUST NOT vs. SHOULD NOT, but I wonde= r if it would help to clarify the reasoning behind it.

For these algorithms, RFC6071 (IPsec/IKE Roadmap) says:
- Reuse of the IV with the same key compromises the data's security; thus, = AES-GCM should not be used with manual keying.   ...

If "compromises" means that the security is slightly weakened, th= en this wording seems ok.  If it means that the cipher is readily brok= en if you do this bad thing, then the only valid text is "MUST NOT&quo= t;.

paul



--_000_64AEC115E33A4E2C963606AC33386F1Edellcom_-- From nobody Sat Mar 18 19:05:14 2017 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 6F7A412945A for ; Sat, 18 Mar 2017 19:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRHfTz7Q-qHf for ; Sat, 18 Mar 2017 19:05:10 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C366C124281 for ; Sat, 18 Mar 2017 19:05:10 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id o4so73063296ywd.3 for ; Sat, 18 Mar 2017 19:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=vSxBsLaC1+LdTq/4ywPd0EIKWEjy+BdIGQpzaNaWwQk=; b=TEZ1jK76x71MyH5kDw0jIPCfWFctEkwmC0ZgVFupM7vNC8XqvOC/DOqEDSsgDlFvVM D2w+y0U7wiPrLuKCD/lmfaIWKdlSIo6J2KRMIsnImDvwjuP0nvrb65SB7OudUHGZdxWl KM4dD3j+7IJkGFqH8AAC6YRpofR4WTioxP8/JveweOHkq9lFkbhN6yeKrrJVgFueWhiB +GAkXr1x8zIAz3IHhhnMH9teOcwx9wkGfMP+7pTXz7i4+k4hFzLLN/6SRuIX866IZrBv 9elGMUUsRtC3SnYXg9qOLvetj6v7kBVuc7xqVQlKFMyn6rSXV6xgzS+K4WSwEjQcWOdW AUkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vSxBsLaC1+LdTq/4ywPd0EIKWEjy+BdIGQpzaNaWwQk=; b=qpBmyiLAA2Gia9mheX64OPwyaZ5YyVmXGAYJU5Le+znxNIlc3GuApmpPkLtSZi3IvK pLRyFDE/17gw80DybGlFXngwagAfUhuAzOl0pWRMoVVF4oIE/s3Q+nUSEgZakegyVdPA LsuXGZBxoPPnguUW++9R2ANVE9OwZgWRa6Xm6iPXgb+iaFi5P1+d9dmvNnEBpTyDIBop EH0iCh7G8M12MogNm0Z4XE4We03RNWagF4dW0oE9zRUi9ZvaW5aA5hI98kKRNup21al4 rt5bgEqO+WI3JZwk23kxz7PCBjaMfnxh9gVu/5rHATaVqfLILayo30DXArjegwIWu69g o3Mg== X-Gm-Message-State: AFeK/H0sVowEddWyGYsdazFjEsGJvKu8XXv2uAafK3WRUkmRNFymsLrFDpWDgmWovZSE8u3XG8bsWWUb2JvZ/Q== X-Received: by 10.13.250.67 with SMTP id k64mr9153327ywf.125.1489889110126; Sat, 18 Mar 2017 19:05:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Sat, 18 Mar 2017 19:04:29 -0700 (PDT) From: Eric Rescorla Date: Sat, 18 Mar 2017 19:04:29 -0700 Message-ID: To: draft-ietf-ipsecme-tcp-encaps@ietf.org, ipsec@ietf.org Content-Type: multipart/alternative; boundary=94eb2c07f34a2a0ca5054b0bd7a3 Archived-At: Subject: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 02:05:12 -0000 --94eb2c07f34a2a0ca5054b0bd7a3 Content-Type: text/plain; charset=UTF-8 [Now with the right address] I just finished reading this document. Some comments below. - You have a uniform 16 bit length field followed by a 4 byte all-zeros sentinel value to indicate that a packet is IKE rather than ESP. Given that in S 3 graf 2 you have a SHOULD-level requirement to use typical UDP payload lengths, why not instead explicitly limit lengths to 15 bits and use the top bit to indicate IKE versus ESP. This would be slightly more efficient and seems simpler. I suppose that the counterargument is that IKE over UDP behaves differently, but in terms of implementation, that doesn't seem like much of an argument. - If you're going to have a framing disambiguator, why not choose one that has higher entropy. If there is a protocol with a random start, then you are going to get some collisions with 2^48 bits. - It seems like IKE associations can span TCP connections (S 6) so why not instead of doing UDP first then TCP, do happy eyeballs. " when TLS is used on the TCP connection, both the TCP Originator and TCP Responder SHOULD allow the NULL cipher to be selected for performance reasons." This seems like you are going to have some problems with TLS 1.3 - If you are going to use TLS, shouldn't you be using ALPN? Feel free to tell me that these ideas have been considered and rejected. :) -Ekr --94eb2c07f34a2a0ca5054b0bd7a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[Now with the right addre= ss]

I just finished reading this document. Some com= ments below.


=
- You have a uniform 16 bit length field followed by a 4 byte all-zero= s
=C2=A0 =C2=A0sentinel value to indicate that a packet is IKE ra= ther than ESP.
=C2=A0 =C2=A0Given that in S 3 graf 2 you have a S= HOULD-level requirement
=C2=A0 =C2=A0to use typical UDP payload l= engths, why not instead explicitly
=C2=A0 =C2=A0limit lengths to = 15 bits and use the top bit to indicate IKE versus
=C2=A0 =C2=A0E= SP. This would be slightly more efficient and seems simpler.
=C2= =A0 =C2=A0I suppose that the counterargument is that IKE over UDP behaves
=C2=A0 =C2=A0differently, but in terms of implementation, that doe= sn't seem like
=C2=A0 much of an argument.

- If you're going to have a framing disambiguator, why not choos= e
=C2=A0 one that has higher entropy. If there is a protocol with= a random
=C2=A0 start, then you are going to get some collisions= with 2^48 bits.

- It seems like IKE associations = can span TCP connections (S 6)
=C2=A0 so why not instead of d= oing UDP first then TCP, do happy eyeballs.

"= when TLS is used on the TCP connection, both the TCP Originator and TCP Re= sponder SHOULD allow the NULL cipher to be selected for performance reasons= ."

This seems like you are going to have some= problems with TLS 1.3

- If you are going to use T= LS, shouldn't you be using ALPN?

Feel free to = tell me that these ideas have been considered and rejected. :)
-Ekr
--94eb2c07f34a2a0ca5054b0bd7a3-- From nobody Sat Mar 18 23:29:35 2017 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 ED06E127071; Sat, 18 Mar 2017 23:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fy5Lzkc-zbgn; Sat, 18 Mar 2017 23:29:31 -0700 (PDT) Received: from mail-wr0-x243.google.com (mail-wr0-x243.google.com [IPv6:2a00:1450:400c:c0c::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74D1A1242EA; Sat, 18 Mar 2017 23:29:31 -0700 (PDT) Received: by mail-wr0-x243.google.com with SMTP id g10so14162853wrg.0; Sat, 18 Mar 2017 23:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Cwf6dHdzBsbHs75ScAtL6QYiwbVkpeqwE1CDa4euPGQ=; b=DbiWhTW5FMYfiN6Wm7lqbYSUg/8y6epGwKOa5pXce68MpXR8mHQquhIx14DjJKH4yV wjVgX7o0UXkdLij+dOzrnGjX4RSF8dQNmRffy/6lgWc0NzISLbv1z1r3VDXsn1ln3RXw n/lSYoUte6cXTKRhnPteA/ARZQ+P80GIMmpadFi5UXmGSmvOsFoQ9IaLf80pcUa1GxdM xAbmD1IEQl/rQFRSaMXbAlKAog6zma7kVSc8mHHNmEKkrSlG0EowIY1vBzx/ZqPaEd9P t8XqgzxbDtYfjU/QRrJ2dM+b8nPfBrzmnElkNxBgs/oCHH5bZnWoMqQRD6/3uM1fiSW8 BQTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Cwf6dHdzBsbHs75ScAtL6QYiwbVkpeqwE1CDa4euPGQ=; b=E0sj5lPtve7BMDLtKmcPGqt15//uS4xrX1Io0iQYT7ifb0ZKPhd4ijGaPaTPC+484Z w1vlo7qNPZICAPaK/3cc2952mX1+2LA0gNdVqW5srPm21T1WIxdZoPomvxz9G+GdFzhv IcJ/WfGHVyHg/Sz0q6XMYsjmD35WtYi/7lETRJrnA3tDREOp6zfQ8I/DDBiQzBSpYOz+ ihvMs847D6GlQbgY1F6sbQ86kHp/OgkPVWxnQmLzSBzj2jtuwitklepE+ZERAkcfyK3Z sOAo62eXBcw5vv/kYOWr+FSZkJMWktWKoEnQER77py4LTewz6tIS6zATtXwu29a7xr+g hf1w== X-Gm-Message-State: AFeK/H3fRdcX0FdrCAmVFDZBa6hM9mRZRAk7XPiFn/MGeyfYIdRnf2dy9ARbWZK+X82bdg== X-Received: by 10.223.138.134 with SMTP id y6mr19700714wry.118.1489904969935; Sat, 18 Mar 2017 23:29:29 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id o26sm4413228wmi.18.2017.03.18.23.29.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Mar 2017 23:29:29 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_6ABBBF37-6F52-46B9-A709-EC1822FE28A4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Sun, 19 Mar 2017 08:29:25 +0200 In-Reply-To: Cc: draft-ietf-ipsecme-tcp-encaps@ietf.org, ipsec@ietf.org To: Eric Rescorla References: X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 06:29:34 -0000 --Apple-Mail=_6ABBBF37-6F52-46B9-A709-EC1822FE28A4 Content-Type: multipart/alternative; boundary="Apple-Mail=_2353C618-E647-4CEC-B974-95FEE66417D1" --Apple-Mail=_2353C618-E647-4CEC-B974-95FEE66417D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Eric. > On 19 Mar 2017, at 4:04, Eric Rescorla wrote: >=20 > [Now with the right address] >=20 > I just finished reading this document. Some comments below. >=20 >=20 > - You have a uniform 16 bit length field followed by a 4 byte = all-zeros > sentinel value to indicate that a packet is IKE rather than ESP. > Given that in S 3 graf 2 you have a SHOULD-level requirement > to use typical UDP payload lengths, why not instead explicitly > limit lengths to 15 bits and use the top bit to indicate IKE versus > ESP. This would be slightly more efficient and seems simpler. > I suppose that the counterargument is that IKE over UDP behaves > differently, but in terms of implementation, that doesn't seem like > much of an argument. Another counter-argument is that we sometimes need the entire = theoretical length of a UDP packet. The IKE_AUTH messages typically = carry a certificate chain and sometimes even a CRL. And there is no way = to split a certificate chain over several messages. With remote access = VPN you also get a CFG payload with configuration information that can = also encode an unbounded amount of data. So I would not want to = constrain the certificate chains that we are able to send any more than = the IP packet length already does. Early on there was a proposal to increase the length field to 4 bytes to = do away with these IKE limitations, but that was rejected. > - If you're going to have a framing disambiguator, why not choose > one that has higher entropy. If there is a protocol with a random > start, then you are going to get some collisions with 2^48 bits. I don=E2=80=99t think anyone plans to implement this on any port other = than 443. And on that port we=E2=80=99re worrying about exactly one = protocol and it doesn=E2=80=99t start with =E2=80=9CIKETCP" > - It seems like IKE associations can span TCP connections (S 6) > so why not instead of doing UDP first then TCP, do happy eyeballs. I don=E2=80=99t think it=E2=80=99s necessary to prescribe for or against = this, but that is what we do, and I think that is what Apple intends to = do. > " when TLS is used on the TCP connection, both the TCP Originator and = TCP Responder SHOULD allow the NULL cipher to be selected for = performance reasons." >=20 > This seems like you are going to have some problems with TLS 1.3 >=20 > - If you are going to use TLS, shouldn't you be using ALPN? The idea of using TLS (rather than just IKE on port 443) is to get past = firewalls and IDP that examine the TCP traffic to determine that it = =E2=80=9Creally looks like HTTPS=E2=80=9D. There was some discussion = about whether this was a good idea or whether we should in such a case = either give up or standardize some kind of SSL-VPN. There was no = consensus to go with SSL-VPN in either this group or any other (there = was a bar bof a few IETFs ago) Yoav --Apple-Mail=_2353C618-E647-4CEC-B974-95FEE66417D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Eric.

On 19 Mar 2017, at 4:04, Eric = Rescorla <ekr@rtfm.com> wrote:

[Now with the = right address]

I just finished reading this = document. Some comments below.


- You have a uniform 16 bit length = field followed by a 4 byte all-zeros
  =  sentinel value to indicate that a packet is IKE rather than = ESP.
   Given that in S 3 graf 2 you have = a SHOULD-level requirement
   to use = typical UDP payload lengths, why not instead explicitly
   limit lengths to 15 bits and use the top bit to = indicate IKE versus
   ESP. This would be = slightly more efficient and seems simpler.
  =  I suppose that the counterargument is that IKE over UDP = behaves
   differently, but in terms of = implementation, that doesn't seem like
  much = of an argument.

Another counter-argument is that we sometimes need = the entire theoretical length of a UDP packet. The IKE_AUTH messages = typically carry a certificate chain and sometimes even a CRL. And there = is no way to split a certificate chain over several messages. With = remote access VPN you also get a CFG payload with configuration = information that can also encode an unbounded amount of data. So I would = not want to constrain the certificate chains that we are able to send = any more than the IP packet length already does.

Early on there was a proposal to increase the length = field to 4 bytes to do away with these IKE limitations, but that was = rejected.

- If you're going to have a framing disambiguator, why not = choose
  one that has higher entropy. If there = is a protocol with a random
  start, then you = are going to get some collisions with 2^48 = bits.

I don=E2=80=99t think anyone plans to implement = this on any port other than 443. And on that port we=E2=80=99re worrying = about exactly one protocol and it doesn=E2=80=99t start with = =E2=80=9CIKETCP"

- It seems like IKE associations can span TCP connections (S = 6)
  so why not instead of = doing UDP first then TCP, do happy = eyeballs.

I don=E2=80=99t think it=E2=80=99s necessary to = prescribe for or against this, but that is what we do, and I think that = is what Apple intends to do.

" when TLS is used on the TCP connection, both the TCP = Originator and TCP Responder SHOULD allow the NULL cipher to be selected = for performance reasons."

This seems like you are going to have some problems with TLS = 1.3

- If you = are going to use TLS, shouldn't you be using = ALPN?

The idea of using TLS (rather than just IKE on port = 443) is to get past firewalls and IDP that examine the TCP traffic to = determine that it =E2=80=9Creally looks like HTTPS=E2=80=9D. There was = some discussion about whether this was a good idea or whether we should = in such a case either give up or standardize some kind of SSL-VPN. There = was no consensus to go with SSL-VPN in either this group or any other = (there was a bar bof a few IETFs ago)

Yoav
= --Apple-Mail=_2353C618-E647-4CEC-B974-95FEE66417D1-- --Apple-Mail=_6ABBBF37-6F52-46B9-A709-EC1822FE28A4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYziVGAAoJELhJCxUKWMyZ1joIAM7oui43QYSYQnn3s/2/BeAQ cz03r3LQAZhnyekT7dS4JnmTwrlD/662WJxektyr2e6iXjRqmNWnGJrN0OTGVrJZ Kii5hKtlB2vmVchZo5va0+4mNVoqbWT/zkH8Dsne9SqnmEZE+slQHpbuDAOoxulH SbBNwAMlUTgFTc7M3610f38jE7hbb0U8YXT4f0Xn/FWshOlt7RtU+h3Cc/RPuDN+ Tv5LlvisOM/SyBuNT8ce8yBxSXX9zot4Iskyl3UZunnhgYFpOs0uzjx4xpy8FZtS eooZfMn4jDcnBZAJEpWFL95iV3UViw7rDMPSELpqFBhXmUIeoGR53uoDf0gjopg= =7F/U -----END PGP SIGNATURE----- --Apple-Mail=_6ABBBF37-6F52-46B9-A709-EC1822FE28A4-- From nobody Sun Mar 19 02:24:32 2017 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 EDE6A12441E; Sun, 19 Mar 2017 02:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCED77BLmseL; Sun, 19 Mar 2017 02:24:29 -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 0B6E8124217; Sun, 19 Mar 2017 02:24:29 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id z15so46074660lfd.1; Sun, 19 Mar 2017 02:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:from:to:references:in-reply-to:subject:date:mime-version :content-transfer-encoding:importance; bh=pKgeN57TIt3nCX2FQuoT7cwPSLQrXrXdgeVMRju8dOU=; b=XR2nLFw9aYglkKNOsMIDJLI4Ex6AojOSN+eoAHuD5rP1Jsi6d3PDE7j/aDBbsq+50z xHT3l/fivKoLOxQ66fxUsJIFsMR0j3lfr0U3mYcTK93/R1sv6HL6fiwLdtSmqj0QKpx2 +yZpaDNn8pRet44tElXjKOzp4N3ziL8sbALVROdQz1YuLNzFPMkZE+D87T0ZdF991ayV aeEia4CcXeHprQ/OngsbV/VB17rhaH72398zNQnXpADM8i4C7cHF+t9cB1MU6V9QT+jq lTQ14GHW72kmEZLYTiVU+2qtNcVhyLTNu/dm+A4RzKtTZYPgo0nqLzwvOzOW+w5QEN+W Igcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:to:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=pKgeN57TIt3nCX2FQuoT7cwPSLQrXrXdgeVMRju8dOU=; b=klwySa0OO83Z1rfqCm7xqY5lCXD0a/T0myejTZq9j8kkHFaqbVY5gQpVeOS9BZHL+z c1SCFuNWkMgbger8N9sgmk/1OHV3IWLJNlWxTDvfuE0HoeJP9h5SnZq17tW3K1Vf6Els sLMtiAudP/Su/S7NrfAZEJXn9TPPB+jLMxNAUO9fVE/LrTzkdckoTXvrscm26GG23n+l Tw+gok5CupSxc2FZCRFgGR6gJ94wZ4kTpVcb81zdu9YqmPZjjEGNPDrqUhg30RktSQzX SVUCSTZdP2GRokAYHTlnTj6XMx8Yp2ffFY2mat5TqqlmI9A7QcuhFjvawvfXmCJ54iJb Z+fA== X-Gm-Message-State: AFeK/H1NpC4oYT6OTqqdUF96a01qN43ea7hh6D0ByPhBqazQ6nNtkHyLDIutW3QmnTQHSA== X-Received: by 10.25.219.213 with SMTP id t82mr6140029lfi.75.1489915467214; Sun, 19 Mar 2017 02:24:27 -0700 (PDT) Received: from chichi (ppp83-237-175-1.pppoe.mtu-net.ru. [83.237.175.1]) by smtp.gmail.com with ESMTPSA id h7sm679783lji.10.2017.03.19.02.24.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 19 Mar 2017 02:24:26 -0700 (PDT) Message-ID: <621CA73A71744D9AAA226100AE915285@chichi> From: "Valery Smyslov" To: "Eric Rescorla" , , References: In-Reply-To: Date: Sun, 19 Mar 2017 12:24:25 +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 Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 09:24:31 -0000 Hi Eric, > I just finished reading this document. Some comments below. > > - You have a uniform 16 bit length field followed by a 4 byte all-zeros > sentinel value to indicate that a packet is IKE rather than ESP. > Given that in S 3 graf 2 you have a SHOULD-level requirement > to use typical UDP payload lengths, why not instead explicitly > limit lengths to 15 bits and use the top bit to indicate IKE versus > ESP. This would be slightly more efficient and seems simpler. > I suppose that the counterargument is that IKE over UDP behaves > differently, but in terms of implementation, that doesn't seem like > much of an argument. That won't work. An application protocol running over UDP is free to send messages up to 64Kbytes. While in tunnel mode we can first fragment these messages and then apply ESP (so that each ESP packet is rather small) , in transport mode it's impossible, and the ESP datagram can reach 64Kbytes in size. I agree that in wild there are few protocols that send such long UDP messages, but it is not prohibited. > - It seems like IKE associations can span TCP connections (S 6) > so why not instead of doing UDP first then TCP, do happy eyeballs. I don't think it's a good idea. The TCP encapsulation has a lot of drawbacks in terms of performance (see Section 12), so it is considered as a last resort if UDP doesn't work. In general UDP (or no encapsulation) is a preferred transport. If we start trying TCP and UDP in parallel, then in some cases TCP will win even if UDP works, resulting in non-efficient connection, even when UDP could be used. > -Ekr Regards, Valery Smyslov. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Sun Mar 19 03:14:10 2017 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 393051243FE; Sun, 19 Mar 2017 03:14:09 -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 2mHHLm6G1fJh; Sun, 19 Mar 2017 03:14:07 -0700 (PDT) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E5581201FA; Sun, 19 Mar 2017 03:14:06 -0700 (PDT) Received: by mail-wm0-x243.google.com with SMTP id n11so9765748wma.0; Sun, 19 Mar 2017 03:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=RcoQljSoithy3raDZdbe7hH2a5HATd8ezo6R2t5SmZc=; b=Y1L+vCzuiEzJmCpldql2qqw90NuJTq0nJFh6bKUg+NVxADpJw09r7AYIMJtNCEXYuw aBPJYJSdUJt70bHIIz01pvscLjFz1dYpYIQxTtEkerg8ZdW/6yvGuWpzrK68BJhj8A+S e15V4pgX6wmJMMUARFubtcJVsClhDVMvV9UQIqh5jAGt9B5TEC/lErvTHuLfquVO/Zpc JLxRg/q385qyuO5YToDwdLhlYEvhqT3L9h/+ppNR9BHb47AQvMb37SmdCagdeldKvib0 VEOplNXg/FaajUGXRkn8qetZU18ADjWMmMJbXbr+3+Do9/h5lFsl6YjAmJ+218/oRvK6 pDdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=RcoQljSoithy3raDZdbe7hH2a5HATd8ezo6R2t5SmZc=; b=QMfwIxLqnWcfQGgp2t77nW7DZTscBd4o9AM91pvUz4e37uabeA4kjcLJwCA/uXhQR8 FGDjEBLOYMr6oJOvp9oxYjMu1ZXCXOgKOgn7LL+Zbp8bCvE2CpUAkl3ePyv/2grGs2AL zTNP5LDQxhzsQpa3ri1THCU5dZbPFSk6gi50Da0tXRkh2HNNGMR63Ug3JrqPC80G5lxP 50Y9/zaQ93wb0RYYlKwhApW8cfb7UbqAHvjxCJRq0RsiBH//bwCqRcb88RXADKrcgVK0 y24qEDQksHyEAqdgjvQ9RnraD28KfG1NZl/9nAZ2Oa0xgAthZ36b+a/DvrKsM2eBtUwy tQ8w== X-Gm-Message-State: AFeK/H2vtkXQnnrHDrpywfw/KEZA48VTtjRWy9y0f+S/Fgxy0PqB9QfloZ+q8PlSBoUUjQ== X-Received: by 10.28.92.65 with SMTP id q62mr949458wmb.139.1489918445456; Sun, 19 Mar 2017 03:14:05 -0700 (PDT) Received: from [172.24.249.245] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id g43sm11240253wrg.35.2017.03.19.03.14.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Mar 2017 03:14:04 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_E83594FA-F9D8-40CB-970A-FA5C1B0149B6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Yoav Nir X-Priority: 3 In-Reply-To: <621CA73A71744D9AAA226100AE915285@chichi> Date: Sun, 19 Mar 2017 12:14:01 +0200 Cc: Eric Rescorla , draft-ietf-ipsecme-tcp-encaps@ietf.org, ipsec@ietf.org Message-Id: <2D2EA57F-EAF0-4C8C-87D7-FB1938C3CD22@gmail.com> References: <621CA73A71744D9AAA226100AE915285@chichi> To: Valery Smyslov X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 10:14:09 -0000 --Apple-Mail=_E83594FA-F9D8-40CB-970A-FA5C1B0149B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Valery. > On 19 Mar 2017, at 11:24, Valery Smyslov wrote: >=20 > Hi Eric, >=20 >> - It seems like IKE associations can span TCP connections (S 6) >> so why not instead of doing UDP first then TCP, do happy eyeballs. >=20 > I don't think it's a good idea. The TCP encapsulation has a lot of = drawbacks in terms of performance (see Section 12), so it is considered > as a last resort if UDP doesn't work. In general UDP (or no = encapsulation) is a preferred transport. If we start trying TCP and UDP = in parallel, then > in some cases TCP will win even if UDP works, resulting in = non-efficient connection, even when UDP could be used. So as I said before, we do it, although IIRC (I=E2=80=99m not on the = client team) the client gives TCP a one-second head start. The reason is = that in many places where a UDP packet can go, a fragmented UDP packet = gets dropped, so the first packets will work fine but the packets with = the certificates (either IKE_AUTH or Main Mode #5) will get dropped. In by the end of IKE we have determined that UDP also works, we move to = that for IPsec. And if TCP is blocked, we will try the IKE negotiation = on UDP. Note that we do all that only for remote access VPN. Site-to-site VPN is = ESP or UDP only. There=E2=80=99s just a lot of crappy routers out = there. Yoav --Apple-Mail=_E83594FA-F9D8-40CB-970A-FA5C1B0149B6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYzlnqAAoJELhJCxUKWMyZw38IAMiJGpIhAMtUrhNgyEaMrC2r hyrxpAe5/WR2O7Fo5GBeDVGN6/XwDo6O4FAY+UQZIR44mpoJjFbRpU20zCi3y44v JAxr7gk/20+PcKp2ZFrmVRBFySqJAHzGvB3Nn+uKaLFp7kcCQrjIaaX+vRs6qLOt qlLBAl/VGuFFAkFIoM/zedA9eUWQkhz41PXMOQ8KNos7/fXm0VF8J/e7L5NRgwc3 bPdw2xonNY7WbmgmtUsveas0bnqvOPk8NrCm1UYBkjy+lfscoVv8b+YpINSfOJlu T+khPIxtBF703DBjmdE7xpt3FfSKp7Jg81jD/V+3PElgu78c+h6HW6ZnPBJhI9M= =kwsy -----END PGP SIGNATURE----- --Apple-Mail=_E83594FA-F9D8-40CB-970A-FA5C1B0149B6-- From nobody Sun Mar 19 04:21:04 2017 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 4A04D126BF0; Sun, 19 Mar 2017 04:21:03 -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 01HhlYRaYQDH; Sun, 19 Mar 2017 04:21:02 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 560EF126B71; Sun, 19 Mar 2017 04:21:01 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id y193so46371143lfd.3; Sun, 19 Mar 2017 04:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-transfer-encoding:importance; bh=uZcvCIzw3qpu94Du5Wv131JNAed+40SClrCrpxH/458=; b=HSCHK9KbckYJlQdPzNlJej9jPsLtPBBq+NV81o8qi935ChLpZHKKV7VuiSd/l60X/9 PzQk4cU49R+wA+Srb9g8CXSvtGk+ttETdo/KqDIX9fEKT9zjtPq0pPX4aaoX+EMRvRd1 KM26JCLCqYcf1Pqzr2JkFrBENn2Y53hVRE8pj2/2jI6zm5fwanY8Bg16zTD8wgRnNyp5 aQVrPYk6wTdb/jjtJtIMa/yt0BNfBTa+eyd5eV/Bq6VOmOy0BiXlL/TvbK4SIhaHuZH7 R1EPU7GwSwBOy1Cufnj2PkByFAGrV2gDxWHbhMB7+XMbXOanthjtAqVc2RzYBAZ0261x 0PFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=uZcvCIzw3qpu94Du5Wv131JNAed+40SClrCrpxH/458=; b=teO5v/o3eXCnED05mTsW+bcPQUGCkPM6T2woyhXLnfhicdtpmm8JVE59cV+WfqT1Ge WuHSs9xrpmxVJGulCsaXKv9P3xkVOeDN9V59UWP1sebh0C/j9Gyh4ybTNW1BJpR5D61F XwbU8QH7Pgd/ERfOH8V/RL95IrpMGux68LPTV2Elke+yPKdMK3/u1WNScJ/ipEg4MX7/ Dvf+TMuOEHmFw2gcZPwOIzKRZ8b5ISkvVVvvhU6Zqwv8iwN6HUqWt6EJ1o7WV64yU0pR NuqonGZPP+BXrAB0KgD0sopNnN8v5EdWC0GAmmyFFNEVULluOvJCLMGIio0jCwwHvCji LzKw== X-Gm-Message-State: AFeK/H2q1+Mh1L3pqtnVVkp6mCtxDfHnuqy/aY15gh+FsIhVQRbucFqH+5IRvM0LITq84w== X-Received: by 10.25.77.2 with SMTP id a2mr6753224lfb.143.1489922459646; Sun, 19 Mar 2017 04:20:59 -0700 (PDT) Received: from chichi (ppp83-237-175-1.pppoe.mtu-net.ru. [83.237.175.1]) by smtp.gmail.com with ESMTPSA id h10sm1897245ljh.59.2017.03.19.04.20.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 19 Mar 2017 04:20:58 -0700 (PDT) Message-ID: <706148CB241E49EEBE79559DF5EBFD7D@chichi> From: "Valery Smyslov" To: "Yoav Nir" Cc: "Eric Rescorla" , , References: <621CA73A71744D9AAA226100AE915285@chichi> <2D2EA57F-EAF0-4C8C-87D7-FB1938C3CD22@gmail.com> In-Reply-To: <2D2EA57F-EAF0-4C8C-87D7-FB1938C3CD22@gmail.com> Date: Sun, 19 Mar 2017 14:20:58 +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: Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 11:21:03 -0000 Hi Yoav, > > I don't think it's a good idea. The TCP encapsulation has a lot of drawbacks in terms of performance (see Section > > 12), so it is considered > > as a last resort if UDP doesn't work. In general UDP (or no encapsulation) is a preferred transport. If we start > > trying TCP and UDP in parallel, then > > in some cases TCP will win even if UDP works, resulting in non-efficient connection, even when UDP could be used. > > So as I said before, we do it, although IIRC (I’m not on the client team) the client gives TCP a one-second head > start. > The reason is that in many places where a UDP packet can go, a fragmented UDP packet gets dropped, > so the first packets will work fine but the packets with the certificates (either IKE_AUTH or Main Mode #5) will get > dropped. With IKE Fragmentation that's not a problem anymore. > In by the end of IKE we have determined that UDP also works, we move to that for IPsec. And if TCP is blocked, we will > try the IKE negotiation on UDP. Your TCP encapsulation protocol seems to be more flexible than what is described in the draft. The current draft doesn't allow moving existing SA from TCP to UDP unless MOBIKE is negotiated (see Section 5). So, if you start with TCP first (or do happy eyeballs and TCP wins), you never switch back to UDP, even if it appears that UDP works for that path too, unless both sides support MOBIKE. And even with MOBIKE it's not clear if switching is alowed unless interface address changes. That's why UDP is given a preference. > Yoav Regards, Valery. From nobody Sun Mar 19 04:45:32 2017 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 1D6CC126CC7; Sun, 19 Mar 2017 04:45:31 -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 i47yEgIiOm9V; Sun, 19 Mar 2017 04:45:29 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c: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 3A81D120727; Sun, 19 Mar 2017 04:45:29 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id n11so44603566wma.1; Sun, 19 Mar 2017 04:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=8aeAzXjr6HbE+zLLL5X2jirq8g3A5Xu+gCeEv+V80S8=; b=YJdXibAiyKO/CstgRZV9LGOs5CzalDnWs9oSZfehR0GSNC9vxO8IqkmaYk/ss8NgUt ov41uAiIjQMvr4t8OUJIOd6v1c5G2g5PHjq7T1wDczdaJfB9lt82CviS7psM6m5vkeBm J34s3QLRQsLNW4N4TbQi96a0AzgrJw3VjvBz/yE3o/1QTzxEvk9keFbIB9WJQ7x6p/qg sW4ZMN6qpGDzgDqU6J1W/UcH3a1118n1dJNKkopsHMlkonGq7lKwPtQLbhVVhMTp25bX UKGPs+BuIUS4D6Mi8SFJoi8cYfPgtEhH8CEjsX5GTZ/RV/4RWEsgdSVUh12iOcw/mwJO aSbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=8aeAzXjr6HbE+zLLL5X2jirq8g3A5Xu+gCeEv+V80S8=; b=CgazMXslYzHQN7OghQSyusPkfLaChqqxLPXXKqdJZegJDVZ941O8hr2oFk8my8+7yv Ict7ILwpwxvVmh3HILYBNb8rektcnNOLWQwKxSETiylJ4Mi6NZ89iKp6gj84jIWsgXgn qFlNpcy6t4BTLtJXEUdT0lgpqRRBJjA2YwE2zBBNSnEDXWjUUkAXy2lXF1tiNPtshOYx O6Qozs0c1wV9ZYofVlPaL+nB1vMo/OuP2gnmivtFQ1qB1tA+hbVEaBx1M8xn/q78hncg PPwbLEyImlSPMwaoU7Nd8li4FX5oNHe9X36TBxBWmw/TqueBgpAXArJDO1ujYjAA3Gyr pxWw== X-Gm-Message-State: AFeK/H2uN8Y5VHEJ+CsYI3FIn10BsnEBb3AIUG1u5foCNElOXPPed/6HMMT2+m6lXYEIsA== X-Received: by 10.28.48.78 with SMTP id w75mr6193849wmw.55.1489923927764; Sun, 19 Mar 2017 04:45:27 -0700 (PDT) Received: from [172.24.249.245] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id v14sm9489730wmv.24.2017.03.19.04.45.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Mar 2017 04:45:26 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_A863991C-414E-4D4D-9AB5-8511F7BB8624"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Yoav Nir X-Priority: 3 In-Reply-To: <706148CB241E49EEBE79559DF5EBFD7D@chichi> Date: Sun, 19 Mar 2017 13:45:23 +0200 Cc: Eric Rescorla , draft-ietf-ipsecme-tcp-encaps@ietf.org, ipsec@ietf.org Message-Id: References: <621CA73A71744D9AAA226100AE915285@chichi> <2D2EA57F-EAF0-4C8C-87D7-FB1938C3CD22@gmail.com> <706148CB241E49EEBE79559DF5EBFD7D@chichi> To: Valery Smyslov X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 11:45:31 -0000 --Apple-Mail=_A863991C-414E-4D4D-9AB5-8511F7BB8624 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 19 Mar 2017, at 13:20, Valery Smyslov wrote: >=20 > Hi Yoav, >=20 >> > I don't think it's a good idea. The TCP encapsulation has a lot of = drawbacks in terms of performance (see Section > 12), so it is = considered >> > as a last resort if UDP doesn't work. In general UDP (or no = encapsulation) is a preferred transport. If we start > trying TCP and = UDP in parallel, then >> > in some cases TCP will win even if UDP works, resulting in = non-efficient connection, even when UDP could be used. >>=20 >> So as I said before, we do it, although IIRC (I=E2=80=99m not on the = client team) the client gives TCP a one-second head start. >> The reason is that in many places where a UDP packet can go, a = fragmented UDP packet gets dropped, >> so the first packets will work fine but the packets with the = certificates (either IKE_AUTH or Main Mode #5) will get dropped. >=20 > With IKE Fragmentation that's not a problem anymore. IKE over TCP solves the same problem (and a few others). >> In by the end of IKE we have determined that UDP also works, we move = to that for IPsec. And if TCP is blocked, we will try the IKE = negotiation on UDP. >=20 > Your TCP encapsulation protocol seems to be more flexible than what is = described in the draft. Yes, and we (the working group) decided to simplify things by not = incorporating this flexibility. > The current draft doesn't allow moving existing SA from TCP to UDP = unless MOBIKE is negotiated (see Section 5). > So, if you start with TCP first (or do happy eyeballs and TCP wins), = you never switch back to UDP, even if it appears > that UDP works for that path too, unless both sides support MOBIKE. = And even with MOBIKE it's not clear if switching > is alowed unless interface address changes. That's why UDP is given a = preference. Yes, and that=E2=80=99s why the cost of using this as an alternative to = IKE fragmentation is too high. Yoav --Apple-Mail=_A863991C-414E-4D4D-9AB5-8511F7BB8624 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYzm9TAAoJELhJCxUKWMyZMqQH/jAdZOgXvUOEaGyScujEUhiz UlqJ0La/hNVWZiVy4hwc6oVnTQmfz46soyRHX0gCvsz0u4mkNo0D0S+4H+xwZfS5 f4sz/ENKFPTK9v6v41xVtmigfI8WIBIGL3vauWkkWReE1OQ43+vs1Rt22pQu13ul 2pgczeOw80yi3UtU8p1f6uyXrClk3mOKFi4mPaC+qz7AxaBJh5uNAeIA0oFPj6c4 eDyyi6vDK0M9MBLdYSVqt0BK3NvdjMGj8SQQfOAWur5nBG7X6D01wkNiU1l0fdIJ HRT0wXjphi90bmjjfcDJGcf2ydlTl6r/00wQ/6o3mkW0HJ5/VmTCgcQ5Hd3SjyI= =hlko -----END PGP SIGNATURE----- --Apple-Mail=_A863991C-414E-4D4D-9AB5-8511F7BB8624-- From nobody Sun Mar 19 06:48:27 2017 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 755611294B3 for ; Sun, 19 Mar 2017 06:48:26 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSeVZsYjgTRn for ; Sun, 19 Mar 2017 06:48:24 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::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 1BEBC1294AF for ; Sun, 19 Mar 2017 06:48:24 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id v76so76599978ywg.0 for ; Sun, 19 Mar 2017 06:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Fm0SmIEzV4/sTF8mDGob1ihemVNwvSrrx7eQC8Shw3U=; b=dca13TGcy+EyIwDEw8el6MhE8mLD0dNnG4+2BHcFfCWZVjQHRAwZZC1KRHhiEJN8Cw M+t09MUXr4skVnaoaX21p+yLu2pWHwui6PRMvAKFUd7CCyeToQkSzrOHDVlz3N7jyUgU 9EAdN0YBafhA3KdsQwosW4xmo3iIpGc07chGYxu5RHfiRnCUTPfpCh6HUwiHIF1KCZge xaYadxYJqS9Za2+6H3s+9wKW8dpM9umbNzxbuX7OUK/82e6PEnquj0RGVoMVB2vQ42ei ztNKv8ousKlDiE8xTTpAASql1G7w92ai7aGYOljqSUyCEORENnklNng26h0OHr8OL4In 7b6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Fm0SmIEzV4/sTF8mDGob1ihemVNwvSrrx7eQC8Shw3U=; b=jDUO76aHgFLf1ajYoLW8RYcSN5NHeKj60+v4cTl0euLYoawkJRyqKsgHurCHV172ts qXhAZRZ5ml6ilEGh3rV/FgfKM+AbgD5MWRv6FIgggHqMbGAAm2d2oEhUAcTuEkMO1gqS 8Hq7Wh/pe+Trf+NqpS53KZUel7G0CMxRDV+MEFLqTAtm2Yl7n63P4uAjZzPmM6So3l7y GPTg4vpX3f0tinVfF5JoRUpOM9LlP+T3fxg78dCPI5C5BAv24HKbVc1ABuDWHEU4xohd oGIm0ivw3mLbFbKZeB1mxtVFdk+OJHbkLWHxkNHoUDl6BpHQ3q6iqqqfMpcCfDAJXnyg Nuhw== X-Gm-Message-State: AFeK/H27UfgpZhlV09pr8KwzHTPr7JK9Xex6tnLb65SkyuahRmqf8EfVHvtUDnyLodlHXuiIxrODB3Odh20eyw== X-Received: by 10.37.113.135 with SMTP id m129mr14711805ybc.65.1489931303374; Sun, 19 Mar 2017 06:48:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Sun, 19 Mar 2017 06:47:42 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sun, 19 Mar 2017 06:47:42 -0700 Message-ID: To: Yoav Nir Cc: draft-ietf-ipsecme-tcp-encaps@ietf.org, ipsec@ietf.org Content-Type: multipart/alternative; boundary=001a1148a84813e560054b15aad7 Archived-At: Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 13:48:26 -0000 --001a1148a84813e560054b15aad7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Mar 18, 2017 at 11:29 PM, Yoav Nir wrote: > Hi, Eric. > > On 19 Mar 2017, at 4:04, Eric Rescorla wrote: > > [Now with the right address] > > I just finished reading this document. Some comments below. > > > - You have a uniform 16 bit length field followed by a 4 byte all-zeros > sentinel value to indicate that a packet is IKE rather than ESP. > Given that in S 3 graf 2 you have a SHOULD-level requirement > to use typical UDP payload lengths, why not instead explicitly > limit lengths to 15 bits and use the top bit to indicate IKE versus > ESP. This would be slightly more efficient and seems simpler. > I suppose that the counterargument is that IKE over UDP behaves > differently, but in terms of implementation, that doesn't seem like > much of an argument. > > > Another counter-argument is that we sometimes need the entire theoretical > length of a UDP packet. The IKE_AUTH messages typically carry a certifica= te > chain and sometimes even a CRL. And there is no way to split a certificat= e > chain over several messages. With remote access VPN you also get a CFG > payload with configuration information that can also encode an unbounded > amount of data. So I would not want to constrain the certificate chains > that we are able to send any more than the IP packet length already does. > OK. Early on there was a proposal to increase the length field to 4 bytes to do > away with these IKE limitations, but that was rejected. > > - If you're going to have a framing disambiguator, why not choose > one that has higher entropy. If there is a protocol with a random > start, then you are going to get some collisions with 2^48 bits. > > > I don=E2=80=99t think anyone plans to implement this on any port other th= an 443. > And on that port we=E2=80=99re worrying about exactly one protocol and it= doesn=E2=80=99t > start with =E2=80=9CIKETCP" > Fair enough. > - It seems like IKE associations can span TCP connections (S 6) > so why not instead of doing UDP first then TCP, do happy eyeballs. > > > I don=E2=80=99t think it=E2=80=99s necessary to prescribe for or against = this, but that is > what we do, and I think that is what Apple intends to do. > Right, but the text here actively discourages this. https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-09#section-5.1 " to reduce connection setup delays. It is recommended that theinitial message over UDP is retransmitted at least once before falling back to TCP, unless the Initiator knows beforehand that the network is likely to block UDP." " when TLS is used on the TCP connection, both the TCP Originator and TCP > Responder SHOULD allow the NULL cipher to be selected for performance > reasons." > > This seems like you are going to have some problems with TLS 1.3 > > - If you are going to use TLS, shouldn't you be using ALPN? > > > The idea of using TLS (rather than just IKE on port 443) is to get past > firewalls and IDP that examine the TCP traffic to determine that it =E2= =80=9Creally > looks like HTTPS=E2=80=9D. There was some discussion about whether this w= as a good > idea or whether we should in such a case either give up or standardize so= me > kind of SSL-VPN. There was no consensus to go with SSL-VPN in either this > group or any other (there was a bar bof a few IETFs ago) > OK. You're still going to have a problem with 1.3... -Ekr --001a1148a84813e560054b15aad7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Mar 18, 2017 at 11:29 PM, Yoav Nir <ynir.ietf@gmail.com&= gt; wrote:
Hi, Eric.

On 19 Mar 2017, at 4:04, Eric Rescorla &l= t;ekr@rtfm.com> wr= ote:

[Now with the rig= ht address]

I just finished reading this document. = Some comments below.

- You have a uniform 16 bit length field followed by a 4 byte = all-zeros
=C2=A0 =C2=A0sentinel value to indicate that a packet i= s IKE rather than ESP.
=C2=A0 =C2=A0Given that in S 3 graf 2 you = have a SHOULD-level requirement
=C2=A0 =C2=A0to use typical UDP p= ayload lengths, why not instead explicitly
=C2=A0 =C2=A0limit len= gths to 15 bits and use the top bit to indicate IKE versus
=C2=A0= =C2=A0ESP. This would be slightly more efficient and seems simpler.
<= div>=C2=A0 =C2=A0I suppose that the counterargument is that IKE over UDP be= haves
=C2=A0 =C2=A0differently, but in terms of implementation, t= hat doesn't seem like
=C2=A0 much of an argument.
=

Another cou= nter-argument is that we sometimes need the entire theoretical length of a = UDP packet. The IKE_AUTH messages typically carry a certificate chain and s= ometimes even a CRL. And there is no way to split a certificate chain over = several messages. With remote access VPN you also get a CFG payload with co= nfiguration information that can also encode an unbounded amount of data. S= o I would not want to constrain the certificate chains that we are able to = send any more than the IP packet length already does.

OK.


<= div>
Early on there was a proposal to increa= se the length field to 4 bytes to do away with these IKE limitations, but t= hat was rejected.

= - If you're going to have a framing disambiguator, why not choose
=
=C2=A0 one that has higher entropy. If there is a protocol with a rand= om
=C2=A0 start, then you are going to get some collisions with 2= ^48 bits.

I don=E2=80=99t think anyone plans to implement this on any port = other than 443. And on that port we=E2=80=99re worrying about exactly one p= rotocol and it doesn=E2=80=99t start with =E2=80=9CIKETCP"
=

Fair enough.
=C2=A0<= /div>
=
- It s= eems like IKE associations can span TCP connections (S 6)
=C2= =A0 so why not instead of doing UDP first then TCP, do happy eyeballs.

I don=E2= =80=99t think it=E2=80=99s necessary to prescribe for or against this, but = that is what we do, and I think that is what Apple intends to do.

Right, but the text here actively = discourages this.

&quo= t; =C2=A0 to reduce connection setup delays. It is recommended that theini= tial message over UDP is retransmitted at least once before falling back to= TCP, unless the Initiator knows beforehand that the =C2=A0 network is like= ly to block UDP."

" when TLS is = used on the TCP connection, both the TCP Originator and TCP Responder SHOUL= D allow the NULL cipher to be selected for performance reasons."
=

This seems like you are going to have some problems wit= h TLS 1.3

- If you are going to use TLS, shouldn&#= 39;t you be using ALPN?

The idea of using TLS (rather than just IKE on port 443)= is to get past firewalls and IDP that examine the TCP traffic to determine= that it =E2=80=9Creally looks like HTTPS=E2=80=9D. There was some discussi= on about whether this was a good idea or whether we should in such a case e= ither give up or standardize some kind of SSL-VPN. There was no consensus t= o go with SSL-VPN in either this group or any other (there was a bar bof a = few IETFs ago)

OK. You= 9;re still going to have a problem with 1.3...

-Ek= r
--001a1148a84813e560054b15aad7-- From nobody Sun Mar 19 07:56:15 2017 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 C9F1B1294CF for ; Sun, 19 Mar 2017 07:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRR471dl6cJm for ; Sun, 19 Mar 2017 07:56:11 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002: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 55B25127B52 for ; Sun, 19 Mar 2017 07:56:11 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id v198so76874468ywc.2 for ; Sun, 19 Mar 2017 07:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=PZ+GC4JpBIptlsC4byverLUYjdH3HTeQ2GcIyvt8E/U=; b=cAiPdGquegjWKNMebWww3dWFWXKu+h5P+yHYNl8TQqFJYDnI+7nARESDTA0HsB1QzM /qCCKLoscNqMSza65IXupzdtS8SNEaOxWNX2fGR6nd0QC4zAyxR82gE3Bf8i2s9JReuR 7PfwnYO+KrfPOZMI8zbIWR1+XOX/6bxa3goNWxTBEmf1q7ox6sY7FOysINhjlLXlfBRd w2rIArvkyZLA1q9s0hnb7n4qRSANFnGk0I+3YfDAtRCtSyRhTBRB7j4pPaBJHHiH+4cL tJ1HDuFEJt64LFfn9TOq8RSXeSS6kdTerQVM47WA3uBJmNmUY5i4mfbpDxCf5ceWEpEX qB2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=PZ+GC4JpBIptlsC4byverLUYjdH3HTeQ2GcIyvt8E/U=; b=VpTqDNAL3NptaLF2TUmaErIsYElOuRft+WS32HSXXaE3Sb8oKFfdWQ4O/2uZrzWxmn IWV6JVJ0RQrzPnxEr7Dmb/S6U4muybMGbCArP8oXXoeoPpaCjvzuZ72i8FBl5UTKrhoJ 93bHymoOZa30ID/McMF8EWuURi0kl4H1pbAhgBacHhgXBl8Oj0conAS1ZYU8mZm1y7eR md/hbAEHJjUtMBu3KuIA62hwjop8GMmgpmUFTfijEM5yavIxcVeg2FxpeV7N7pl5M1zt USA/AWhzGt65Ek4IWdyYLzjSk8X7+tz1Y0XAVAgZAEX2bp8iYlDhDX6oIXziHExAnKou j+iQ== X-Gm-Message-State: AFeK/H1mkRuE4shx/cQE2QY0RHg+I/6zVOSjzCK3/axbPbnMs902CsgmvlrOyrBszSIWIhFXW+JPcUJDq+zQow== X-Received: by 10.129.152.22 with SMTP id p22mr11787895ywg.276.1489935370536; Sun, 19 Mar 2017 07:56:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Sun, 19 Mar 2017 07:55:30 -0700 (PDT) From: Eric Rescorla Date: Sun, 19 Mar 2017 07:55:30 -0700 Message-ID: To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0b8fb47fdfe2054b169c2c Archived-At: Subject: [IPsec] Comments on draft-mglt-ipsecme-implicit-iv-02.tx X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 14:56:14 -0000 --94eb2c0b8fb47fdfe2054b169c2c Content-Type: text/plain; charset=UTF-8 Overall: I notice that you are using a construction different from that used in TLS 1.3, which doesn't directly repeat nonces across associations. S 2. This document does not consider AES-CBC ([RFC3602])as AES-CBC requires the IV to be unpredictable. Deriving it directly from the packet counter as described below is insecure. Can you provide a cite for this? In any case, note that there are straightforward algorithms for deriving a CBC IV from a counter (e.g., run AES in counter mode with a different key). That structure would actually be suitable for GCM as well (and would address my point above). S 3. o IV: Initialization Vector. Although security requirements vary, the common usage of this term implies that the value is unpredictable. I don't think that this is true at all. I've frequently heard of a zero IV. It's also odd in that your IV is in fact predictable. S 5. I'm a bit surprised that you are deciding to have duplicate code points for every algorithm rather than some sort of IKE negotiation payload. I see that the WG is currently defining other extensions where you take that approach. -Ekr --94eb2c0b8fb47fdfe2054b169c2c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Overall:
I notice that you are using a = construction different from that used
in TLS 1.3, which doesn'= ;t directly repeat nonces across associations.

S 2= .
=C2=A0 =C2=A0This document does not consider AES-CBC ([RFC3602]= )as AES-CBC
=C2=A0 =C2=A0requires the IV to be unpredictable.=C2= =A0 Deriving it directly from the
=C2=A0 =C2=A0packet counter as = described below is insecure.

Can you provide a cit= e for this? In any case, note that there are
straightforward algo= rithms for deriving a CBC IV from a counter
(e.g., run AES in cou= nter mode with a different key). That structure
would actually be= suitable for GCM as well (and would address
my point above).


S 3.
=C2=A0 =C2=A0o =C2=A0IV= : Initialization Vector.=C2=A0 Although security requirements vary,
=C2=A0 =C2=A0 =C2=A0 the common usage of this term implies that the valu= e is
=C2=A0 =C2=A0 =C2=A0 unpredictable.

I don't think that this is true at all. I've frequently heard of a=
zero IV. It's also odd in that your IV is in fact predictabl= e.


S 5.
I'm a bit sur= prised that you are deciding to have duplicate
code points for ev= ery algorithm rather than some sort of IKE
negotiation payload. I= see that the WG is currently defining
other extensions where you= take that approach.


-Ekr




--94eb2c0b8fb47fdfe2054b169c2c-- From nobody Sun Mar 19 10:23:53 2017 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 0A498129505 for ; Sun, 19 Mar 2017 10:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcJVD9BaYSUM for ; Sun, 19 Mar 2017 10:23:50 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::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 BCB60129502 for ; Sun, 19 Mar 2017 10:23:49 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id g10so79162363wrg.2 for ; Sun, 19 Mar 2017 10:23:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=qId5pHuMsU45X8sa1v+XDRbPLWqIVccXKHoDNqV0F98=; b=vdQSgemJ+DXZwLIcMNKfBK3deDG0Uc3QdQX1SSb3PjCLSOXClfv4W44AWd2vkg/7Ex 45ZDqrzKjvIHHEgx3NNY3KVOVAnm9v9trhKDo9c18/QZNs3v+ZvpKwuAw4KbiEsqb81F 4AvEEYxMdVeidukXpVu0xx99gmWxXsHsS4YrWNFMe+rCa0wbkY77lFPie2ANq8vccezV dLwzC4U6UN1YFjOjApqAun+nzNKAaDE2lOylb0AofEEo6MCbghVQKI0x53pEn66HLFaI bTQgAa3DKeXMb+fR85M6ETkCjEJp8P/f5BLMAR/Frtg0e//HvrLuIaJN0HqHoVI759n4 X+CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=qId5pHuMsU45X8sa1v+XDRbPLWqIVccXKHoDNqV0F98=; b=b/uBiPQAMaEgZtZMZhPfmKfNkukyjtizCfxqzd8Ys/NS321vDV+WoHNdoNO/bWKSKv dXS+8ZEKOuTHkpSEig+jGuH+DNJgZL0i/rQ7IrB9Zc9AF1PBK5Urxe5sD6C/xDARhlCs 88T2E9Bct0Rq0y/47Djn/sOp5fiJJCwd976d7r3wwiN8QYMD7EvBd4oxZF5X0s4GR99H 3Dk+D0F2LD/yoaaw6sLS116yjlcAWXjBWKtGV70kbNN04TSy4Mfrt73BBMuAkSu1vDo3 WOwKafIXjCK7KjZUVHo/XMLWh0LBRsQP4K/fR6rvfpJIuCkW4MqZHMkMofDY7wtyKopH Fybg== X-Gm-Message-State: AFeK/H08NDWmaWDWvdJgRmwuqK0V2MQxwRhl4w8UIoCpRdXX8DcLji1KOw5RSnOLMF9OGA== X-Received: by 10.223.173.53 with SMTP id p50mr23498163wrc.112.1489944228288; Sun, 19 Mar 2017 10:23:48 -0700 (PDT) Received: from [192.168.137.86] ([109.253.156.201]) by smtp.gmail.com with ESMTPSA id v18sm17609609wrc.41.2017.03.19.10.23.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Mar 2017 10:23:47 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_69DFF076-0168-455A-8A45-4F0BFC61969C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Sun, 19 Mar 2017 19:23:12 +0200 In-Reply-To: Cc: ipsec@ietf.org To: Eric Rescorla References: X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [IPsec] Comments on draft-mglt-ipsecme-implicit-iv-02.tx X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 17:23:53 -0000 --Apple-Mail=_69DFF076-0168-455A-8A45-4F0BFC61969C Content-Type: multipart/alternative; boundary="Apple-Mail=_2537EAFF-69CF-4744-BA96-D03D480EA77C" --Apple-Mail=_2537EAFF-69CF-4744-BA96-D03D480EA77C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 19 Mar 2017, at 16:55, Eric Rescorla wrote: >=20 > Overall: > I notice that you are using a construction different from that used > in TLS 1.3, which doesn't directly repeat nonces across associations. >=20 > S 2. > This document does not consider AES-CBC ([RFC3602])as AES-CBC > requires the IV to be unpredictable. Deriving it directly from the > packet counter as described below is insecure. >=20 > Can you provide a cite for this? Even RFC 3602 requires that the IV be randomly generated (and for good = measure requires that it be unpredictable) > In any case, note that there are > straightforward algorithms for deriving a CBC IV from a counter > (e.g., run AES in counter mode with a different key). That structure > would actually be suitable for GCM as well (and would address > my point above). If each implementation generates a random key and uses this to generate = the IVs this is fine, but you still have to transmit the IV. If we = derive an =E2=80=9CIV key=E2=80=9D from the keying material, then we = don=E2=80=99t have to transmit the IV. We did bring this idea up at a WG meeting. This was not well-received = for three reasons: (1) it=E2=80=99s unnecessarily complicated. (2) The = world is going to AEAD. AES-CBC is the past, and (3) The perception was = that saving 8 bytes per packet was important mostly for IoT, and they = don=E2=80=99t care about CBC. > S 3. > o IV: Initialization Vector. Although security requirements vary, > the common usage of this term implies that the value is > unpredictable. >=20 > I don't think that this is true at all. I've frequently heard of a > zero IV. It's also odd in that your IV is in fact predictable. >=20 >=20 > S 5. > I'm a bit surprised that you are deciding to have duplicate > code points for every algorithm rather than some sort of IKE > negotiation payload. I see that the WG is currently defining > other extensions where you take that approach. See slide #7 of = https://www.ietf.org/proceedings/96/slides/slides-96-ipsecme-0.pdf = The problem is that IKEv2 has strict rules about unexpected attributes = in the substructures of the SA payload. The sense of the room was to go = with new identifiers. Yoav --Apple-Mail=_2537EAFF-69CF-4744-BA96-D03D480EA77C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 19 Mar 2017, at 16:55, Eric Rescorla <ekr@rtfm.com> = wrote:

Overall:
I notice that you are using a construction different from = that used
in TLS 1.3, which doesn't directly repeat = nonces across associations.

S 2.
   This document does = not consider AES-CBC ([RFC3602])as AES-CBC
  =  requires the IV to be unpredictable.  Deriving it directly = from the
   packet counter as described = below is insecure.

Can you provide a cite for = this?

Even RFC = 3602 requires that the IV be randomly generated (and for good measure = requires that it be unpredictable)

In any case, note that there are
straightforward algorithms for deriving a CBC IV from a = counter
(e.g., run AES in counter mode with a = different key). That structure
would actually be = suitable for GCM as well (and would address
my = point above).

If = each implementation generates a random key and uses this to generate the = IVs this is fine, but you still have to transmit the IV.  If we = derive an =E2=80=9CIV key=E2=80=9D from the keying material, then we = don=E2=80=99t have to transmit the IV. 

We did bring this idea up at a WG meeting. This = was not well-received for three reasons: (1) it=E2=80=99s unnecessarily = complicated. (2) The world is going to AEAD. AES-CBC is the past, and = (3) The perception was that saving 8 bytes per packet was important = mostly for IoT, and they don=E2=80=99t care about CBC.

S 3.
  =  o  IV: Initialization Vector.  Although security = requirements vary,
      the common = usage of this term implies that the value is
  =     unpredictable.

I don't think that this is true at all. = I've frequently heard of a
zero IV. It's also odd = in that your IV is in fact predictable.


S = 5.
I'm a bit surprised that you are deciding to = have duplicate
code points for every algorithm = rather than some sort of IKE
negotiation payload. I = see that the WG is currently defining
other = extensions where you take that = approach.

See slide #7 of https://www.ietf.org/proceedings/96/slides/slides-96-ipsecme-0.= pdf

The problem = is that IKEv2 has strict rules about unexpected attributes in the = substructures of the SA payload. The sense of the room was to go with = new identifiers.

Yoav

= --Apple-Mail=_2537EAFF-69CF-4744-BA96-D03D480EA77C-- --Apple-Mail=_69DFF076-0168-455A-8A45-4F0BFC61969C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYzr6AAAoJELhJCxUKWMyZlk0H/3K9/zm4PpouP2MxsBZyqv1p KgXfre5XzGtvQdEPwEXdFxq5fmtHw8VQzQDZpfyjc9C4f2RfOsObaRVvY6v4Obeu vgSSxnbWjpnNxGB1buwPbDmBHXoQMpuYZnUusI89dg4Au3dtoRh/uYuLH3ipf1Pa 6Uc26vzA6gkuMZ7GFYm3SlBP7RAeSfFoXdJkvYzil8NBvnIPyjkYuyM6L2RwLCxc kbLoNPncurfk8ZHDvS//96i6YR9XFLyoIel53lLMs1rxeQDYBfnhk7pCs/AkjqBz cpjI+PTK4+io8n189RlfxlQm5HVg4of2CBmyVJqID7sWyvW53Tf/AGz+EbKZaVE= =Ukv/ -----END PGP SIGNATURE----- --Apple-Mail=_69DFF076-0168-455A-8A45-4F0BFC61969C-- From nobody Sun Mar 19 10:31:01 2017 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 E1E53129506 for ; Sun, 19 Mar 2017 10:30:58 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsQR_h7FpscO for ; Sun, 19 Mar 2017 10:30:56 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::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 0A698129504 for ; Sun, 19 Mar 2017 10:30:56 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id o4so78209542ywd.3 for ; Sun, 19 Mar 2017 10:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YnJKheD9o8LzUjsYHcRYyzJZenLtur+piCgi8KBY1SM=; b=fO5N4RKU7EtWKlhhV7LZglk0pFeiKGFE4MCWCYv/FRE8qOnOUAkc5NJFMV+iX6+t4r nyQRDRi/CkWqbKX2GYqRM3Fe89Xz4b7Y6VEUU68AbEn/IWAyj5iJ+MKXx61KF+2thIzJ JaXEJrISeT1A9Y50EOsrebkBON0+9qs4eXZvnEuDEWPKZB2pmhglpdCwxL/AQJZ6fARv 3oeDzyLEDPtOnd9EDatfGk8JEBoIsuQJRQliNhGhWbPEcAcSWvYbwCk/2x/p7rEB8jl2 HIlmEw01qRh/hQmNHoSYjsgKKuxPJkjQmq++0KgM1D+J+cO+DrdRXiG0Sh67VIfdKjhG ITlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YnJKheD9o8LzUjsYHcRYyzJZenLtur+piCgi8KBY1SM=; b=V5iB87zMoQQJlXeFToX5hG6kKcvOiRF3X4wrCrIclcRt9AoZS8PJK7r+LzcxAFhoki klC3VS4YysgDiZ5CriFDY1A4+DdJgwcOUsxWsqAZvNtDkZyueMx+qGS3yGjWHAYgfTJS oBWZ75yvsElosQpgAJzjGhVGB2jn1/DQvlITw1Wwh1I0v/7CgHE9gAWi9DofAKWQ7GYc 6+DdHf6JqM8YJV/ALZBwtZ0ZHNkAHU4NADCAfVex3lVk6ys/E4hBB3Ul3Cun12rjprcv osZY4nN14H2vUzSz2fiGdIoQ/WeVt/GliagdCj/8bPWkxxjCDAg0oPIetJYqmNRWl4rr rfeA== X-Gm-Message-State: AFeK/H3zMIVitFwBk9cTjVUK8zTVECo7aFBTs++8XKYgDloHpRbpjkdWlu19yYsrvbQNlC7CwN5X37+szzxS7Q== X-Received: by 10.37.171.66 with SMTP id u60mr16056428ybi.64.1489944655285; Sun, 19 Mar 2017 10:30:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Sun, 19 Mar 2017 10:30:14 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sun, 19 Mar 2017 10:30:14 -0700 Message-ID: To: Yoav Nir Cc: ipsec@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0c30f0ea0212054b18c55d Archived-At: Subject: Re: [IPsec] Comments on draft-mglt-ipsecme-implicit-iv-02.tx X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 17:30:59 -0000 --94eb2c0c30f0ea0212054b18c55d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Mar 19, 2017 at 10:23 AM, Yoav Nir wrote: > > On 19 Mar 2017, at 16:55, Eric Rescorla wrote: > > Overall: > I notice that you are using a construction different from that used > in TLS 1.3, which doesn't directly repeat nonces across associations. > > I didn't see an answer to this. > > S 2. > This document does not consider AES-CBC ([RFC3602])as AES-CBC > requires the IV to be unpredictable. Deriving it directly from the > packet counter as described below is insecure. > > Can you provide a cite for this? > > > Even RFC 3602 requires that the IV be randomly generated (and for good > measure requires that it be unpredictable) > That's just a cite to a requirement, not to it being insecure. Do you have a citation to the relevant threat? > In any case, note that there are > straightforward algorithms for deriving a CBC IV from a counter > (e.g., run AES in counter mode with a different key). That structure > would actually be suitable for GCM as well (and would address > my point above). > > > If each implementation generates a random key and uses this to generate > the IVs this is fine, but you still have to transmit the IV. If we deriv= e > an =E2=80=9CIV key=E2=80=9D from the keying material, then we don=E2=80= =99t have to transmit the > IV. > You generate the IV from the sequence number, so you don't need to transmit the IV. That gives you an unpredictable IV without the per-packet overhead. We did bring this idea up at a WG meeting. This was not well-received for > three reasons: (1) it=E2=80=99s unnecessarily complicated. (2) The world = is going > to AEAD. AES-CBC is the past, and (3) The perception was that saving 8 > bytes per packet was important mostly for IoT, and they don=E2=80=99t car= e about > CBC. > Sure, that's reasonable. I'm merely observing that there are designs which work for CBC. S 3. > o IV: Initialization Vector. Although security requirements vary, > the common usage of this term implies that the value is > unpredictable. > > I don't think that this is true at all. I've frequently heard of a > zero IV. It's also odd in that your IV is in fact predictable. > > > S 5. > I'm a bit surprised that you are deciding to have duplicate > code points for every algorithm rather than some sort of IKE > negotiation payload. I see that the WG is currently defining > other extensions where you take that approach. > > > See slide #7 of https://www.ietf.org/proceedings/96/slides/slides- > 96-ipsecme-0.pdf > > The problem is that IKEv2 has strict rules about unexpected attributes in > the substructures of the SA payload. The sense of the room was to go with > new identifiers. > OK. Well, I agree it's ultimately a WG decision, but it doesn't seem very elegant. -Ekr > > Yoav > > --94eb2c0c30f0ea0212054b18c55d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 19, 2017 at 10:23 AM, Yoav Nir <ynir.ietf@gmail.com&= gt; wrote:

On 19= Mar 2017, at 16:55, Eric Rescorla <ekr@rtfm.com> wrote:

Overall:
I notice that you are using a construction different from that used=
in TLS 1.3, which doesn't directly repeat nonces across asso= ciations.
I didn't see an answer to this.
=C2=A0
<= blockquote type=3D"cite">

S 2.
=C2=A0 =C2=A0This document does not consider AES-CBC ([RFC3602])as A= ES-CBC
=C2=A0 =C2=A0requires the IV to be unpredictable.=C2=A0 De= riving it directly from the
=C2=A0 =C2=A0packet counter as descri= bed below is insecure.

Can you provide a cite for = this?

Even RFC 3602 req= uires that the IV be randomly generated (and for good measure requires that= it be unpredictable)

That'= s just a cite to a requirement, not to it being insecure. Do you have a cit= ation to the relevant threat?
=C2=A0
In any case, note that there ar= e
straightforward algorithms for deriving a CBC IV from a counter=
(e.g., run AES in counter mode with a different key). That struc= ture
would actually be suitable for GCM as well (and would addres= s
my point above).

<= /span>If each implementation generates a random key and uses this to genera= te the IVs this is fine, but you still have to transmit the IV.=C2=A0 If we= derive an =E2=80=9CIV key=E2=80=9D from the keying material, then we don= =E2=80=99t have to transmit the IV.=C2=A0

=
You generate the IV from the sequence number, so you don't n= eed to transmit the IV.
That gives you an unpredictable IV wi= thout the per-packet overhead.


We did bring= this idea up at a WG meeting. This was not well-received for three reasons= : (1) it=E2=80=99s unnecessarily complicated. (2) The world is going to AEA= D. AES-CBC is the past, and (3) The perception was that saving 8 bytes per = packet was important mostly for IoT, and they don=E2=80=99t care about CBC.=

Sure, that's reasonable. I= 'm merely observing that there are designs which work for CBC.


S 3.
=C2=A0 =C2=A0o =C2=A0IV: Initialization V= ector.=C2=A0 Although security requirements vary,
=C2=A0 =C2=A0 = =C2=A0 the common usage of this term implies that the value is
= =C2=A0 =C2=A0 =C2=A0 unpredictable.

I don't th= ink that this is true at all. I've frequently heard of a
zero= IV. It's also odd in that your IV is in fact predictable.

S 5.
I'm a bit surprised that you= are deciding to have duplicate
code points for every algorithm r= ather than some sort of IKE
negotiation payload. I see that the W= G is currently defining
other extensions where you take that appr= oach.

See slide #= 7 of=C2=A0https://www.ietf.org/proceedings/96/sl= ides/slides-96-ipsecme-0.pdf

The problem is tha= t IKEv2 has strict rules about unexpected attributes in the substructures o= f the SA payload. The sense of the room was to go with new identifiers.

OK. Well, I agree it's ultimat= ely a WG decision, but it doesn't seem very elegant.

-Ekr
=C2=A0
=

Yoav


--94eb2c0c30f0ea0212054b18c55d-- From nobody Sun Mar 19 11:25:58 2017 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 E8A7E1288B8 for ; Sun, 19 Mar 2017 11:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 imvTiF4mWFye for ; Sun, 19 Mar 2017 11:25:54 -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 B5F00126C23 for ; Sun, 19 Mar 2017 11:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1489947954; 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=gBqtYgakPsBRkFHqKQkwMdW5KqpeBk8DlNgGib0azbg=; b=c1n6fOVfcB08SMNOFfvBecSnECGtD4uzSzBjOKBEof9bP/WOoA5aDaIx6sHoMPWS uZV7OnI0tBAVwPBiDKIC4ehrzBWdmt7GFCJjkFnrp/xgYK8X36O/8GyMK+2AHg5j yrnZShy+NaDZrnCgdTmwWgHmdkNrQTmG/vZ/E82gf2Qqe1EqapP9wEvQULwrQFZn 9bLt290UqLYG/jLPM+rc13spjRbx+t1FyJqsS6UFse284u3qp2Yq0Bbs7MQ5dwG/ iJC8o+LBpS/WZa81CG7fRHsfrQ585XGbr5S1c5+ts03MKaWVomcUs451bbYzdGaS fsDN8laaiyUFGIyBIHhSIA==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id E6.61.30096.F2DCEC85; Sun, 19 Mar 2017 11:25:54 -0700 (PDT) X-AuditID: 11973e11-0d9ff70000007590-43-58cecd2f50ed Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by relay5.apple.com (Apple SCV relay) with SMTP id C5.5C.06491.E2DCEC85; Sun, 19 Mar 2017 11:25:51 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_vMjDpTLUHB3BTcK71R/v6Q)" Received: from [17.153.68.99] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ON2007J5R72BS60@nwk-mmpp-sz10.apple.com>; Sun, 19 Mar 2017 11:25:50 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <08CAB6F1-EA5C-4FA6-A9E9-1D7A87997470@apple.com> Date: Sun, 19 Mar 2017 11:25:51 -0700 In-reply-to: Cc: Yoav Nir , ipsec@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org To: Eric Rescorla References: X-Mailer: Apple Mail (2.3263) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUi2FAYoWt09lyEwbM2FYv3f84wWqx4fY7d Yv+WF2wWS499YHJg8dg56y67x5IlP5k8Jj9uYw5gjuKySUnNySxLLdK3S+DK2Pn4AXvB45KK SU+3MDYwzk7uYuTkkBAwkXj2+TFrFyMXh5DAXkaJL2fussAktvUdYYdIHGKUWD6nkRUkwSsg KPFj8j2wImaBMIlN11ZCFX1hlPi9fRqQw8EhLCAhsXlPIkgNm4CKxPFvG5hBwrwCNhLbbhSA hIUF7CSurtnJDGKzCKhKXJu/CqyTUyBY4uUMX4jpMRJ7Zt4B2yoioCDx688JFohNZxgltq16 wwxxp6xE98JpzCAJCYHrbBL/nx1knMAoNAvJqbOQnDoLaAezgLrElCm5EGFtiSfvLrBC2GoS C38vYkIWX8DItopRKDcxM0c3M89IL7GgICdVLzk/dxMjKE6m2wnuYDy+yuoQowAHoxIP74/y sxFCrIllxZW5hxilOViUxHmnTwEKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYBScv10kyOOV W9vvDOXb96rWSjY/2PSU75z6lVwvEe082dSImjqTM2Jn45oucj629jl7dFrLzpY5x1ia9xS9 vT4vb3pl8tLDsX1XC6QOZ91kr5HRTJh2ce/lGO3QbwqPNxmJl87WcNr6bZaKw3L7HfOWNvwx fFr+qHRX1gU5hZhNHCWiTPvknyixFGckGmoxFxUnAgDu9Qo1dAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNIsWRmVeSWpSXmKPExsUi2FBcpat/9lyEQe97DYv3f84wWqx4fY7d Yv+WF2wWS499YHJg8dg56y67x5IlP5k8Jj9uYw5gjuKySUnNySxLLdK3S+DK2Pn4AXvB45KK SU+3MDYwzk7uYuTkkBAwkdjWd4S9i5GLQ0jgEKPE8jmNrCAJXgFBiR+T77GA2MwCYRKbrq2E KvrCKPF7+zQgh4NDWEBCYvOeRJAaNgEViePfNjCDhHkFbCS23SgACQsL2ElcXbOTGcRmEVCV uDZ/FVgnp0CwxMsZvhDTYyT2zLwDtlVEQEHi158TLBCbzjBKbFv1hhniTlmJ7oXTmCcw8s9C ct0sJNfNAhrLLKAuMWVKLkRYW+LJuwusELaaxMLfi5iQxRcwsq1iFChKzUmsNNVLLCjISdVL zs/dxAgO68KIHYz/l1kdYhTgYFTi4Q2oOhshxJpYVlyZCwwiDmYlEV61U+cihHhTEiurUovy 44tKc1KLDzFOZAR6ciKzlGhyPjDq8kriDU1MDEyMjc2Mjc1NzGkprCTOO/EI0EUC6Yklqdmp qQWpRTBHMXFwSjUwOty7+2PKig13Ne/UFxk9eNPyb+utihub3nmLPlvgP/tNs9Tk+1qepuW3 p7KnLQpxefdd+cJbJrcty3flyD17u8Tt4bn2aWutnUwqG3VcmfvjfENE95UbxzgU9Cd0/2zY V63jHvZy8rHNqnvX33NcUil9QuRpzz+7nC1VvZdC2vwmzt+ekpQXo8RSnJFoqMVcVJwIAPfa 9YveAgAA Archived-At: Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 18:25:57 -0000 --Boundary_(ID_vMjDpTLUHB3BTcK71R/v6Q) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable > On Mar 19, 2017, at 6:47 AM, Eric Rescorla wrote: >=20 >=20 >=20 > On Sat, Mar 18, 2017 at 11:29 PM, Yoav Nir > wrote: > Hi, Eric. >=20 >> On 19 Mar 2017, at 4:04, Eric Rescorla > wrote: >>=20 >> [Now with the right address] >>=20 >> I just finished reading this document. Some comments below. >>=20 >>=20 >> - You have a uniform 16 bit length field followed by a 4 byte = all-zeros >> sentinel value to indicate that a packet is IKE rather than ESP. >> Given that in S 3 graf 2 you have a SHOULD-level requirement >> to use typical UDP payload lengths, why not instead explicitly >> limit lengths to 15 bits and use the top bit to indicate IKE = versus >> ESP. This would be slightly more efficient and seems simpler. >> I suppose that the counterargument is that IKE over UDP behaves >> differently, but in terms of implementation, that doesn't seem = like >> much of an argument. >=20 > Another counter-argument is that we sometimes need the entire = theoretical length of a UDP packet. The IKE_AUTH messages typically = carry a certificate chain and sometimes even a CRL. And there is no way = to split a certificate chain over several messages. With remote access = VPN you also get a CFG payload with configuration information that can = also encode an unbounded amount of data. So I would not want to = constrain the certificate chains that we are able to send any more than = the IP packet length already does. >=20 > OK. >=20 >=20 >=20 > Early on there was a proposal to increase the length field to 4 bytes = to do away with these IKE limitations, but that was rejected. >=20 >> - If you're going to have a framing disambiguator, why not choose >> one that has higher entropy. If there is a protocol with a random >> start, then you are going to get some collisions with 2^48 bits. >=20 > I don=E2=80=99t think anyone plans to implement this on any port other = than 443. And on that port we=E2=80=99re worrying about exactly one = protocol and it doesn=E2=80=99t start with =E2=80=9CIKETCP" >=20 > Fair enough. > =20 >> - It seems like IKE associations can span TCP connections (S 6) >> so why not instead of doing UDP first then TCP, do happy eyeballs. >=20 > I don=E2=80=99t think it=E2=80=99s necessary to prescribe for or = against this, but that is what we do, and I think that is what Apple = intends to do. >=20 > Right, but the text here actively discourages this. > = https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-09#section-5.1 = = =20 >=20 > " to reduce connection setup delays. It is recommended that = theinitial message over UDP is retransmitted at least once before = falling back to TCP, unless the Initiator knows beforehand that the = network is likely to block UDP." There's a tradeoff here between the Happy Eyeballs approach and the = long-term benefits of choosing one option. I'm definitely a big = proponent of Happy Eyeballs between address families, interfaces, and = protocol options in general. However, these IKE connections will often = be long-lived and tunnel a large amount of traffic used for many = different applications. Since we view tunneling over UDP as so much = preferable to tunneling over TCP, we want to weight the race more = heavily in UDP's favor. The draft does not specifically say that = attempts over UDP are ceased once the TCP attempt has begun, so there is = room to keep 'racing' at this point. The main point we wanted to get = across is that UDP should be given a fair shot, since it should be the = preference. Note that a Happy Eyeballs approach should always have one option be = attempted first anyhow, since simultaneous racing just adds extra load = to the network and servers. Thanks, Tommy >=20 >> " when TLS is used on the TCP connection, both the TCP Originator and = TCP Responder SHOULD allow the NULL cipher to be selected for = performance reasons." >>=20 >> This seems like you are going to have some problems with TLS 1.3 >>=20 >> - If you are going to use TLS, shouldn't you be using ALPN? >=20 > The idea of using TLS (rather than just IKE on port 443) is to get = past firewalls and IDP that examine the TCP traffic to determine that it = =E2=80=9Creally looks like HTTPS=E2=80=9D. There was some discussion = about whether this was a good idea or whether we should in such a case = either give up or standardize some kind of SSL-VPN. There was no = consensus to go with SSL-VPN in either this group or any other (there = was a bar bof a few IETFs ago) >=20 > OK. You're still going to have a problem with 1.3... >=20 > -Ekr > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Boundary_(ID_vMjDpTLUHB3BTcK71R/v6Q) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable
On Mar 19, 2017, at 6:47 AM, Eric Rescorla <ekr@rtfm.com> = wrote:



On Sat, Mar 18, 2017 at 11:29 PM, = Yoav Nir <ynir.ietf@gmail.com> wrote:
Hi, Eric.

On 19 Mar 2017, at 4:04, Eric = Rescorla <ekr@rtfm.com> wrote:

[Now with the right address]

I just finished = reading this document. Some comments below.


- You have a uniform 16 = bit length field followed by a 4 byte all-zeros
   sentinel value to indicate that a packet is IKE = rather than ESP.
   Given that in S 3 = graf 2 you have a SHOULD-level requirement
  =  to use typical UDP payload lengths, why not instead = explicitly
   limit lengths to 15 bits = and use the top bit to indicate IKE versus
  =  ESP. This would be slightly more efficient and seems = simpler.
   I suppose that the = counterargument is that IKE over UDP behaves
  =  differently, but in terms of implementation, that doesn't seem = like
  much of an = argument.

Another = counter-argument is that we sometimes need the entire theoretical length = of a UDP packet. The IKE_AUTH messages typically carry a certificate = chain and sometimes even a CRL. And there is no way to split a = certificate chain over several messages. With remote access VPN you also = get a CFG payload with configuration information that can also encode an = unbounded amount of data. So I would not want to constrain the = certificate chains that we are able to send any more than the IP packet = length already does.

OK.



Early on there was a proposal = to increase the length field to 4 bytes to do away with these IKE = limitations, but that was rejected.

- = If you're going to have a framing disambiguator, why not = choose
  one that has higher entropy. If there = is a protocol with a random
  start, then you = are going to get some collisions with 2^48 = bits.

I don=E2=80=99t think anyone = plans to implement this on any port other than 443. And on that port = we=E2=80=99re worrying about exactly one protocol and it doesn=E2=80=99t = start with =E2=80=9CIKETCP"

Fair enough.
 
- It seems like IKE = associations can span TCP connections (S 6)
  so why not instead of doing UDP first then TCP, do = happy eyeballs.

I don=E2=80=99t think it=E2=80=99s = necessary to prescribe for or against this, but that is what we do, and = I think that is what Apple intends to = do.

Right, but the text here actively = discourages this.
https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-09#se= ction-5.1 

"   to reduce connection setup delays. It is = recommended that theinitial message over UDP is retransmitted at least = once before falling back to TCP, unless the Initiator knows beforehand = that the   network is likely to block = UDP."

There's a tradeoff here between the Happy Eyeballs = approach and the long-term benefits of choosing one option. I'm = definitely a big proponent of Happy Eyeballs between address families, = interfaces, and protocol options in general. However, these IKE = connections will often be long-lived and tunnel a large amount of = traffic used for many different applications. Since we view tunneling = over UDP as so much preferable to tunneling over TCP, we want to weight = the race more heavily in UDP's favor. The draft does not specifically = say that attempts over UDP are ceased once the TCP attempt has begun, so = there is room to keep 'racing' at this point. The main point we wanted = to get across is that UDP should be given a fair shot, since it should = be the preference.

Note that a Happy = Eyeballs approach should always have one option be attempted first = anyhow, since simultaneous racing just adds extra load to the network = and servers.

Thanks,
Tommy

" when TLS is used on the TCP connection, both the TCP = Originator and TCP Responder SHOULD allow the NULL cipher to be selected = for performance reasons."

This seems like you are going to have some problems with TLS = 1.3

- If you = are going to use TLS, shouldn't you be using = ALPN?

The idea of using TLS (rather than just IKE on = port 443) is to get past firewalls and IDP that examine the TCP traffic = to determine that it =E2=80=9Creally looks like HTTPS=E2=80=9D. There = was some discussion about whether this was a good idea or whether we = should in such a case either give up or standardize some kind of = SSL-VPN. There was no consensus to go with SSL-VPN in either this group = or any other (there was a bar bof a few IETFs = ago)

OK. You're still going to have a = problem with 1.3...

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

= --Boundary_(ID_vMjDpTLUHB3BTcK71R/v6Q)-- From nobody Sun Mar 19 11:40:51 2017 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 7FDE1129516 for ; Sun, 19 Mar 2017 11:40:49 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HXCWJBKbEbU for ; Sun, 19 Mar 2017 11:40:46 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2085129511 for ; Sun, 19 Mar 2017 11:40:46 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id o4so78686932ywd.3 for ; Sun, 19 Mar 2017 11:40:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DjuYaKJkj3K55K//gMemqxBC7AjRsBSsfEsE3CoLoyA=; b=KfZIJO2i2hTz+8JGNq4I7PEOn9umjBMZa+3Gc1J5yFfMVfA4ARjsUZgA+3rgvybEDS 0BNsAR9rIfzaKHkgozFkFpEaJH3Z8tnywNnniOm62/+iZlkUxdNVy+aPjDrwH3viGJC3 XHIPU0CYJ1ndFd0z68Kc2/bM10rPy5y9HgPyjVtXtNkXaov92dPAOA8nwn7ZkoY5siLc bA0g/Gv5gGfT98TfLJ8j6J/SOwSV7NfAoK4Gph3Dh0sTL5y3A/h/rtsK32+KjhIboq3t zGi/CRR9aS8/zx3mxDQN/s9sC+eNjHbuBNqi/UedfQSdjDLRaiQbcJHxOXGwFmuJzjPQ fbkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DjuYaKJkj3K55K//gMemqxBC7AjRsBSsfEsE3CoLoyA=; b=B0jCZaUX+IPFgEU6h8EGegIykd2VNGX9NCc2Dk2mfCpm2o49G5u6+kQ5eIdCJCXDwt Q0dfnoR12yfIsWYXaf+a9G6IOGmfNo6iktZxMsaTf/AbWMOmpjbl3cuvEhBJjLo208iW /yvZxKYRWbAXC/6fzlZTONahvnNlPCiWhIB3UMh+38sEzbXULSSYF4ipPv2FxGSdFUnb VVk/Rv1Wr57wiuXFSoE+OSuik+vxcukF+xjjiLdZl79zm2T6A3hp5TrCokaiHQUZnrkI 8BaqFbKi4rq/18T1v9iaG0L6ePouohFQHtlxbElh2hiTS5TimfXmHJgkHb45TqRorrnq CxMA== X-Gm-Message-State: AFeK/H2Ht4Kkoa/qCVHJcYnbLgwPkqapiG8qaLLdYDsNEr7psy585VUM304P/wG/MD4zRrOzlHR4JSgPr/j1jg== X-Received: by 10.129.152.22 with SMTP id p22mr12471749ywg.276.1489948845893; Sun, 19 Mar 2017 11:40:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Sun, 19 Mar 2017 11:40:05 -0700 (PDT) In-Reply-To: <08CAB6F1-EA5C-4FA6-A9E9-1D7A87997470@apple.com> References: <08CAB6F1-EA5C-4FA6-A9E9-1D7A87997470@apple.com> From: Eric Rescorla Date: Sun, 19 Mar 2017 11:40:05 -0700 Message-ID: To: Tommy Pauly Cc: Yoav Nir , ipsec@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0b8fb4b17ee1054b19bf29 Archived-At: Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 18:40:49 -0000 --94eb2c0b8fb4b17ee1054b19bf29 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I haven't fully thought this through, but if yu can switch-hit between TCP and UDP, why can't you just race the setup between TCP and UDP and then if you start getting packets on UDP, cut over to that. Maybe I'm just too influenced by ICE :) -Ekr On Sun, Mar 19, 2017 at 11:25 AM, Tommy Pauly wrote: > > On Mar 19, 2017, at 6:47 AM, Eric Rescorla wrote: > > > > On Sat, Mar 18, 2017 at 11:29 PM, Yoav Nir wrote: > >> Hi, Eric. >> >> On 19 Mar 2017, at 4:04, Eric Rescorla wrote: >> >> [Now with the right address] >> >> I just finished reading this document. Some comments below. >> >> >> - You have a uniform 16 bit length field followed by a 4 byte all-zeros >> sentinel value to indicate that a packet is IKE rather than ESP. >> Given that in S 3 graf 2 you have a SHOULD-level requirement >> to use typical UDP payload lengths, why not instead explicitly >> limit lengths to 15 bits and use the top bit to indicate IKE versus >> ESP. This would be slightly more efficient and seems simpler. >> I suppose that the counterargument is that IKE over UDP behaves >> differently, but in terms of implementation, that doesn't seem like >> much of an argument. >> >> >> Another counter-argument is that we sometimes need the entire theoretica= l >> length of a UDP packet. The IKE_AUTH messages typically carry a certific= ate >> chain and sometimes even a CRL. And there is no way to split a certifica= te >> chain over several messages. With remote access VPN you also get a CFG >> payload with configuration information that can also encode an unbounded >> amount of data. So I would not want to constrain the certificate chains >> that we are able to send any more than the IP packet length already does= . >> > > OK. > > > > Early on there was a proposal to increase the length field to 4 bytes to >> do away with these IKE limitations, but that was rejected. >> >> - If you're going to have a framing disambiguator, why not choose >> one that has higher entropy. If there is a protocol with a random >> start, then you are going to get some collisions with 2^48 bits. >> >> >> I don=E2=80=99t think anyone plans to implement this on any port other t= han 443. >> And on that port we=E2=80=99re worrying about exactly one protocol and i= t doesn=E2=80=99t >> start with =E2=80=9CIKETCP" >> > > Fair enough. > > >> - It seems like IKE associations can span TCP connections (S 6) >> so why not instead of doing UDP first then TCP, do happy eyeballs. >> >> >> I don=E2=80=99t think it=E2=80=99s necessary to prescribe for or against= this, but that >> is what we do, and I think that is what Apple intends to do. >> > > Right, but the text here actively discourages this. > https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-09#section-5.1 > > " to reduce connection setup delays. It is recommended that theinitial > message over UDP is retransmitted at least once before falling back to TC= P, > unless the Initiator knows beforehand that the network is likely to blo= ck > UDP." > > > There's a tradeoff here between the Happy Eyeballs approach and the > long-term benefits of choosing one option. I'm definitely a big proponent > of Happy Eyeballs between address families, interfaces, and protocol > options in general. However, these IKE connections will often be long-liv= ed > and tunnel a large amount of traffic used for many different applications= . > Since we view tunneling over UDP as so much preferable to tunneling over > TCP, we want to weight the race more heavily in UDP's favor. The draft do= es > not specifically say that attempts over UDP are ceased once the TCP attem= pt > has begun, so there is room to keep 'racing' at this point. The main poin= t > we wanted to get across is that UDP should be given a fair shot, since it > should be the preference. > > Note that a Happy Eyeballs approach should always have one option be > attempted first anyhow, since simultaneous racing just adds extra load to > the network and servers. > > Thanks, > Tommy > > > " when TLS is used on the TCP connection, both the TCP Originator and TCP >> Responder SHOULD allow the NULL cipher to be selected for performance >> reasons." >> >> This seems like you are going to have some problems with TLS 1.3 >> >> - If you are going to use TLS, shouldn't you be using ALPN? >> >> >> The idea of using TLS (rather than just IKE on port 443) is to get past >> firewalls and IDP that examine the TCP traffic to determine that it =E2= =80=9Creally >> looks like HTTPS=E2=80=9D. There was some discussion about whether this = was a good >> idea or whether we should in such a case either give up or standardize s= ome >> kind of SSL-VPN. There was no consensus to go with SSL-VPN in either thi= s >> group or any other (there was a bar bof a few IETFs ago) >> > > OK. You're still going to have a problem with 1.3... > > -Ekr > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > --94eb2c0b8fb4b17ee1054b19bf29 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I haven't fully thought this through, but if yu can sw= itch-hit between TCP and UDP,
why can't you just race the setup bet= ween TCP and UDP and then if you start
getting packets on UDP, cu= t over to that.=C2=A0

Maybe I'm just too influ= enced by ICE :)

-Ekr


On Sun, Mar 19, 2017 at 11:25 AM= , Tommy Pauly <tpauly@apple.com> wrote:

On Mar 19, 2017, at 6:47 AM, Eric Re= scorla <ekr@rtfm.com> wrote:



On Sat, Mar 18, 2017 at 11:29 PM, Yoav Nir = <ynir.ietf@gmai= l.com> wrote:
Hi, Eric.

On 19 Mar = 2017, at 4:04, Eric Rescorla <ekr@rtfm.com> wrote:

[Now with the right address]
=
I just finished reading this document. Some comments below.


- You have= a uniform 16 bit length field followed by a 4 byte all-zeros
=C2= =A0 =C2=A0sentinel value to indicate that a packet is IKE rather than ESP.<= /div>
=C2=A0 =C2=A0Given that in S 3 graf 2 you have a SHOULD-level req= uirement
=C2=A0 =C2=A0to use typical UDP payload lengths, why not= instead explicitly
=C2=A0 =C2=A0limit lengths to 15 bits and use= the top bit to indicate IKE versus
=C2=A0 =C2=A0ESP. This would = be slightly more efficient and seems simpler.
=C2=A0 =C2=A0I supp= ose that the counterargument is that IKE over UDP behaves
=C2=A0 = =C2=A0differently, but in terms of implementation, that doesn't seem li= ke
=C2=A0 much of an argument.

Another counter-argument is that w= e sometimes need the entire theoretical length of a UDP packet. The IKE_AUT= H messages typically carry a certificate chain and sometimes even a CRL. An= d there is no way to split a certificate chain over several messages. With = remote access VPN you also get a CFG payload with configuration information= that can also encode an unbounded amount of data. So I would not want to c= onstrain the certificate chains that we are able to send any more than the = IP packet length already does.
OK.



Early on there was a proposal to increase the length field to 4= bytes to do away with these IKE limitations, but that was rejected.
<= div>
- I= f you're going to have a framing disambiguator, why not choose
=C2=A0 one that has higher entropy. If there is a protocol with a random<= /div>
=C2=A0 start, then you are going to get some collisions with 2^48= bits.

I don=E2=80=99t think anyone plans to implement this on any port oth= er than 443. And on that port we=E2=80=99re worrying about exactly one prot= ocol and it doesn=E2=80=99t start with =E2=80=9CIKETCP"

Fair enough.
=C2=A0
- It seems like IKE associations can span TCP connections (S 6)=
=C2=A0 so why not instead of doing UDP first then TCP, do ha= ppy eyeballs.

I don=E2=80=99t think it=E2=80=99s necessary to prescribe for or a= gainst this, but that is what we do, and I think that is what Apple intends= to do.

Right, but the te= xt here actively discourages this.

" =C2=A0 to reduce connection= setup delays. It is recommended that theinitial message over UDP is retra= nsmitted at least once before falling back to TCP, unless the Initiator kno= ws beforehand that the =C2=A0 network is likely to block UDP."

There= 9;s a tradeoff here between the Happy Eyeballs approach and the long-term b= enefits of choosing one option. I'm definitely a big proponent of Happy= Eyeballs between address families, interfaces, and protocol options in gen= eral. However, these IKE connections will often be long-lived and tunnel a = large amount of traffic used for many different applications. Since we view= tunneling over UDP as so much preferable to tunneling over TCP, we want to= weight the race more heavily in UDP's favor. The draft does not specif= ically say that attempts over UDP are ceased once the TCP attempt has begun= , so there is room to keep 'racing' at this point. The main point w= e wanted to get across is that UDP should be given a fair shot, since it sh= ould be the preference.

Note that a Happy Eyeballs= approach should always have one option be attempted first anyhow, since si= multaneous racing just adds extra load to the network and servers.

Thanks,
Tommy

" when TLS is used on the TCP connection, both the TCP Ori=
ginator and TCP Responder SHOULD allow the NULL cipher to be selected for p=
erformance reasons."

This seems like you are =
going to have some problems with TLS 1.3

- If you =
are going to use TLS, shouldn't you be using ALPN?

The idea of using TLS (ra=
ther than just IKE on port 443) is to get past firewalls and IDP that exami=
ne the TCP traffic to determine that it =E2=80=9Creally looks like HTTPS=E2=
=80=9D. There was some discussion about whether this was a good idea or whe=
ther we should in such a case either give up or standardize some kind of SS=
L-VPN. There was no consensus to go with SSL-VPN in either this group or an=
y other (there was a bar bof a few IETFs ago)

OK. You're still going to have a problem with 1.3.= ..

-Ekr
 _______________________________________________
IPsec mailing list<= br>IPsec@ietf.orghttps://www.ietf.org/mailman/listinfo/ipsec


--94eb2c0b8fb4b17ee1054b19bf29-- From nobody Sun Mar 19 11:45:57 2017 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 0B4021292FD for ; Sun, 19 Mar 2017 11:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 YSsrRRAhuonV for ; Sun, 19 Mar 2017 11:45:53 -0700 (PDT) Received: from mail-in24.apple.com (mail-out24.apple.com [17.171.2.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA48B126C0F for ; Sun, 19 Mar 2017 11:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1489949152; 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=kEC44DF/3HMs9QE4wybB/VxtX/ZCKWBjPyhpg6/wDQE=; b=TNbYcVtPoYvVbhRlXLReFIFvXWXm5mEk4lU7nLdFEaIna4mxL+gKrLL2OlS2p222 m/ply7EKPLk7J/amyjESUl67Gu/QsFvmmyGnrKINt8lIisWtIx4ZLX07Gc/tdz+H 3UulCDWpigTTKkGZw9+1Z2K+SCHsMoTd0AJLhnC3RUN1NE0hTMwcO/WNvQko/O7U 0D4xoGNYVAe8DJ/7SP5GlwjDXmDsio0IJIcqQIYUS8qaBiXw4rgZQmQiQbXss5Xn StRXcNKYdhj3OdVl+v5PBLMKZoBYzMok98v7Gn2t90iMeFHHt2M+ZKhYQudyaima Ar8lEPD9IdwcwD8mHexMIA==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in24.apple.com (Apple Secure Mail Relay) with SMTP id 8C.78.31801.0E1DEC85; Sun, 19 Mar 2017 11:45:52 -0700 (PDT) X-AuditID: 11ab0218-d930d9a000007c39-eb-58ced1e00d01 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by relay6.apple.com (Apple SCV relay) with SMTP id 33.7A.31597.FD1DEC85; Sun, 19 Mar 2017 11:45:52 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.68.99] by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ON200ASDS4FW430@nwk-mmpp-sz12.apple.com>; Sun, 19 Mar 2017 11:45:51 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: Date: Sun, 19 Mar 2017 11:45:52 -0700 Cc: Yoav Nir , ipsec@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org Message-id: References: <08CAB6F1-EA5C-4FA6-A9E9-1D7A87997470@apple.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3263) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUi2FAYpfvg4rkIgyVdOhbv/5xhtFjx+hy7 xf4tL9gslh77wOTA4rFz1l12jyVLfjJ5TH7cxhzAHMVlk5Kak1mWWqRvl8CVMXWyQ0G7WMWm 1UeYGxh3CXYxcnJICJhI/H14hqmLkYtDSGAfo8Ss6XdZYRK/+rrAbCGBQ4wSLx5Ugdi8AoIS PybfY+li5OBgFpCXOHheFiTMLKAl8f1RKwvEnC+MEms3/AOrERaQkNi8JxGkRljATuLqmp3M IDabgIrE8W8bwGxOgWCJZw+uMYLYLAKqElevNLJDzIyR2DPzDivIGF4BG4mOk9IQ448xSWxc fwesXkRAQeLXnxMsECfLSnQvnMYMUiQhMINN4ur7n2wTGIVnITl7FsLZs5CcvYCReRWjcG5i Zo5uZp6RiV5iQUFOql5yfu4mRlDQr2aS2MH45bXhIUYBDkYlHt4d285FCLEmlhVX5h5ilOZg URLnfT7lbISQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxu1PlA5PN3+/Kqrtsd7TG7bzBTbf DkpeFKNucHHL1AdzJ4a95dbKkV3JO33rzDOnZqbckFn2XW7F7ZOPf6z37p970TCd16ep+fL3 Xdej0gIm3jm+5YYm79ry0mWbspccmlLeKKNZ9tBzR/b0/jq/XRqKBqIdZ1+8WsH97yKPi/GO Av2zawX/PKhQYinOSDTUYi4qTgQA36ssXlsCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUi2FB8RvfBxXMRBvMesFq8/3OG0WLF63Ps Fvu3vGCzWHrsA5MDi8fOWXfZPZYs+cnkMflxG3MAcxSXTUpqTmZZapG+XQJXxtTJDgXtYhWb Vh9hbmDcJdjFyMkhIWAi8auvixXEFhI4xCjx4kEViM0rICjxY/I9li5GDg5mAXmJg+dlQcLM AloS3x+1AoW5gMq/MEqs3fAPrEZYQEJi855EkBphATuJq2t2MoPYbAIqEse/bQCzOQWCJZ49 uMYIYrMIqEpcvdLIDjEzRmLPzDusIGN4BWwkOk5KQ4w/xiSxcf0dsHoRAQWJX39OsECcLCvR vXAa8wRGgVlILp2FcOksJJcuYGRexShQlJqTWGmml1hQkJOql5yfu4kRHKKFUTsYG5ZbHWIU 4GBU4uENqDobIcSaWFZcmQsMCQ5mJRFetVPnIoR4UxIrq1KL8uOLSnNSiw8xSnOwKInz9h8B SgmkJ5akZqemFqQWwWSZODilGhjFhD8FSMcITpcVXCwUMTdcze/s0d0dE29ud+o9c+V4bMxH wSO5B3lVp8/deN9Or7JHRyA6/tKVBzfPLWfpMmh+/dn+M5PqKf33E5a+c/RefstVPDFHdsua q2df7V8ZWpn0327mz0dPtkx41t9s8mwi2+a3l/88zM+O4ZMtDFi77dRKg8N6t7+YKrEUZyQa ajEXFScCAA8MublNAgAA Archived-At: Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 18:45:56 -0000 Some servers may support that, but some may not. These sessions are often used for VPN access, and we've seen cases in which a particular user/certificate combination is only allowed to be connected once-at-a-time. That makes switching more complicated. Also, since the recommendation is to try sending the UDP first packet at least twice, the amount of time required for the user to wait before the fallback would kick in is only on the order of a few RTT. I think if these session were more likely to be used for user-interactive, short-lived connections, I'd see more value in a nuanced racing algorithm. However, we often see IKE brought up in the background and stay associated for a very long time, making the protocol that wins the race more important, and the time to wait to establish slightly less important. Thanks, Tommy > On Mar 19, 2017, at 11:40 AM, Eric Rescorla wrote: > > I haven't fully thought this through, but if yu can switch-hit between TCP > and UDP, > why can't you just race the setup between TCP and UDP and then if you start > getting packets on UDP, cut over to that. > > Maybe I'm just too influenced by ICE :) > > -Ekr > > > On Sun, Mar 19, 2017 at 11:25 AM, Tommy Pauly wrote: > >> >> On Mar 19, 2017, at 6:47 AM, Eric Rescorla wrote: >> >> >> >> On Sat, Mar 18, 2017 at 11:29 PM, Yoav Nir wrote: >> >>> Hi, Eric. >>> >>> On 19 Mar 2017, at 4:04, Eric Rescorla wrote: >>> >>> [Now with the right address] >>> >>> I just finished reading this document. Some comments below. >>> >>> >>> - You have a uniform 16 bit length field followed by a 4 byte all-zeros >>> sentinel value to indicate that a packet is IKE rather than ESP. >>> Given that in S 3 graf 2 you have a SHOULD-level requirement >>> to use typical UDP payload lengths, why not instead explicitly >>> limit lengths to 15 bits and use the top bit to indicate IKE versus >>> ESP. This would be slightly more efficient and seems simpler. >>> I suppose that the counterargument is that IKE over UDP behaves >>> differently, but in terms of implementation, that doesn't seem like >>> much of an argument. >>> >>> >>> Another counter-argument is that we sometimes need the entire theoretical >>> length of a UDP packet. The IKE_AUTH messages typically carry a certificate >>> chain and sometimes even a CRL. And there is no way to split a certificate >>> chain over several messages. With remote access VPN you also get a CFG >>> payload with configuration information that can also encode an unbounded >>> amount of data. So I would not want to constrain the certificate chains >>> that we are able to send any more than the IP packet length already does From nobody Sun Mar 19 11:47:11 2017 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 6BBE71292FD for ; Sun, 19 Mar 2017 11:47:10 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcSO7YmkKLfx for ; Sun, 19 Mar 2017 11:47:08 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3327E126C0F for ; Sun, 19 Mar 2017 11:47:08 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id o4so78727830ywd.3 for ; Sun, 19 Mar 2017 11:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2++ecyVBg4v7NjpcABJkheRtEU5ZuAVa8iZr06PGvzg=; b=GKMpG/WBJ0sAHNQQPFuwyO1Sh4Swi7iWj3HlmqU2NsCtvHFbpdRv444APOzZ3Fe9bD xzxN34Fz08/etrSiBwIcz3NfZfcoe1FJq7zwy7FQEjr78Q4h4qU8stvlAiBzVS2N4+TX l2pQUF9uNnZMS1OCXNdd3Rn1DwM1yJq9atOYLADt5rg1wmMQEJ4zdLAo7hPHEHB/EGQt f1xKPmh/7TQyPWMC6I+EJIZSC5YJ47rKbjNrk7ydZ59BumKGyZguAfWlv2RNYzW23h7S jtErbQdUP9ZKpiwE6L7a9XIXwmlVPdbDIhMiHjIXglAwfZ7Ihg266Hstg4XjRVvR22H+ NXIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2++ecyVBg4v7NjpcABJkheRtEU5ZuAVa8iZr06PGvzg=; b=S8BzZHXqv0WTCosn4H6CnGtHCSMa4sofgGa/mH7VgqacrOoAvjZfx60qn7cQNwAoKP Ee3w3fc4AQve4Jjuvdgqxcf/DEKlvxSE/PMPX0IrfwxtSTLLBjCB6Rca1mpre/XxP1ua Nc8p82g15MvqY/Wh+l77dbcmKJTb0XkleGPQnjkWBskoASoPo3FLAuJyarzEZDqHXWNi 92h0jFipeB73+IK+UzaVl3aLmQWK6l5OnA1XHz/tPKBKiY0PNreTxBBHr9tsjAnnDskZ XxkZV15Q1oFM9BIOonkEB9Uaff0gnPI/oSrZdpUG8HwrJadf54ocWxv/MQSOGDacnDSa 7XTw== X-Gm-Message-State: AFeK/H09jaeFJ/h9xzV5OmlGLayf73DPIrMPqbzb/5ll1KGZupd/Vu0nLeffcuuCJ/acvLgH9lx6kKzI9OdW2Q== X-Received: by 10.129.92.84 with SMTP id q81mr11971974ywb.87.1489949227554; Sun, 19 Mar 2017 11:47:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Sun, 19 Mar 2017 11:46:27 -0700 (PDT) In-Reply-To: References: <08CAB6F1-EA5C-4FA6-A9E9-1D7A87997470@apple.com> From: Eric Rescorla Date: Sun, 19 Mar 2017 11:46:27 -0700 Message-ID: To: Tommy Pauly Cc: Yoav Nir , ipsec@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org Content-Type: multipart/alternative; boundary=001a114d8570712fc9054b19d6a7 Archived-At: Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 18:47:10 -0000 --001a114d8570712fc9054b19d6a7 Content-Type: text/plain; charset=UTF-8 Thanks for the explanation... -Ekr On Sun, Mar 19, 2017 at 11:45 AM, Tommy Pauly wrote: > Some servers may support that, but some may not. These sessions are often > used for VPN access, and we've seen cases in which a particular > user/certificate combination is only allowed to be connected > once-at-a-time. That makes switching more complicated. Also, since the > recommendation is to try sending the UDP first packet at least twice, the > amount of time required for the user to wait before the fallback would kick > in is only on the order of a few RTT. > > I think if these session were more likely to be used for user-interactive, > short-lived connections, I'd see more value in a nuanced racing algorithm. > However, we often see IKE brought up in the background and stay associated > for a very long time, making the protocol that wins the race more > important, and the time to wait to establish slightly less important. > > Thanks, > Tommy > > > On Mar 19, 2017, at 11:40 AM, Eric Rescorla wrote: > > > > I haven't fully thought this through, but if yu can switch-hit between > TCP > > and UDP, > > why can't you just race the setup between TCP and UDP and then if you > start > > getting packets on UDP, cut over to that. > > > > Maybe I'm just too influenced by ICE :) > > > > -Ekr > > > > > > On Sun, Mar 19, 2017 at 11:25 AM, Tommy Pauly wrote: > > > >> > >> On Mar 19, 2017, at 6:47 AM, Eric Rescorla wrote: > >> > >> > >> > >> On Sat, Mar 18, 2017 at 11:29 PM, Yoav Nir wrote: > >> > >>> Hi, Eric. > >>> > >>> On 19 Mar 2017, at 4:04, Eric Rescorla wrote: > >>> > >>> [Now with the right address] > >>> > >>> I just finished reading this document. Some comments below. > >>> > >>> > >>> - You have a uniform 16 bit length field followed by a 4 byte all-zeros > >>> sentinel value to indicate that a packet is IKE rather than ESP. > >>> Given that in S 3 graf 2 you have a SHOULD-level requirement > >>> to use typical UDP payload lengths, why not instead explicitly > >>> limit lengths to 15 bits and use the top bit to indicate IKE versus > >>> ESP. This would be slightly more efficient and seems simpler. > >>> I suppose that the counterargument is that IKE over UDP behaves > >>> differently, but in terms of implementation, that doesn't seem like > >>> much of an argument. > >>> > >>> > >>> Another counter-argument is that we sometimes need the entire > theoretical > >>> length of a UDP packet. The IKE_AUTH messages typically carry a > certificate > >>> chain and sometimes even a CRL. And there is no way to split a > certificate > >>> chain over several messages. With remote access VPN you also get a CFG > >>> payload with configuration information that can also encode an > unbounded > >>> amount of data. So I would not want to constrain the certificate chains > >>> that we are able to send any more than the IP packet length already > does > > --001a114d8570712fc9054b19d6a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the explanation...

-Ekr


On Sun, Mar 19, 2017 at 11:45 AM, Tommy Pauly <tpauly@apple.com>= ; wrote:
Some servers may support = that, but some may not. These sessions are often used for VPN access, and w= e've seen cases in which a particular user/certificate combination is o= nly allowed to be connected once-at-a-time. That makes switching more compl= icated. Also, since the recommendation is to try sending the UDP first pack= et at least twice, the amount of time required for the user to wait before = the fallback would kick in is only on the order of a few RTT.

I think if these session were more likely to be used for user-interactive, = short-lived connections, I'd see more value in a nuanced racing algorit= hm. However, we often see IKE brought up in the background and stay associa= ted for a very long time, making the protocol that wins the race more impor= tant, and the time to wait to establish slightly less important.

Thanks,
Tommy

> On Mar 19, 2017, at 11:40 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> I haven't fully thought this through, but if yu can switch-hit bet= ween TCP
> and UDP,
> why can't you just race the setup between TCP and UDP and then if = you start
> getting packets on UDP, cut over to that.
>
> Maybe I'm just too influenced by ICE :)
>
> -Ekr
>
>
> On Sun, Mar 19, 2017 at 11:25 AM, Tommy Pauly <tpauly@apple.com> wrote:
>
>>
>> On Mar 19, 2017, at 6:47 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>>
>>
>> On Sat, Mar 18, 2017 at 11:29 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
>>
>>> Hi, Eric.
>>>
>>> On 19 Mar 2017, at 4:04, Eric Rescorla <ekr@rtfm.com> wrote:
>>>
>>> [Now with the right address]
>>>
>>> I just finished reading this document. Some comments below. >>>
>>>
>>> - You have a uniform 16 bit length field followed by a 4 byte = all-zeros
>>>=C2=A0 =C2=A0sentinel value to indicate that a packet is IKE ra= ther than ESP.
>>>=C2=A0 =C2=A0Given that in S 3 graf 2 you have a SHOULD-level r= equirement
>>>=C2=A0 =C2=A0to use typical UDP payload lengths, why not instea= d explicitly
>>>=C2=A0 =C2=A0limit lengths to 15 bits and use the top bit to in= dicate IKE versus
>>>=C2=A0 =C2=A0ESP. This would be slightly more efficient and see= ms simpler.
>>>=C2=A0 =C2=A0I suppose that the counterargument is that IKE ove= r UDP behaves
>>>=C2=A0 =C2=A0differently, but in terms of implementation, that = doesn't seem like
>>>=C2=A0 much of an argument.
>>>
>>>
>>> Another counter-argument is that we sometimes need the entire = theoretical
>>> length of a UDP packet. The IKE_AUTH messages typically carry = a certificate
>>> chain and sometimes even a CRL. And there is no way to split a= certificate
>>> chain over several messages. With remote access VPN you also g= et a CFG
>>> payload with configuration information that can also encode an= unbounded
>>> amount of data. So I would not want to constrain the certifica= te chains
>>> that we are able to send any more than the IP packet length al= ready does


--001a114d8570712fc9054b19d6a7-- From nobody Sun Mar 19 11:53:05 2017 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 A03F712896F for ; Sun, 19 Mar 2017 11:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8unIEVnPPPN for ; Sun, 19 Mar 2017 11:53:01 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 482C81292FC for ; Sun, 19 Mar 2017 11:53:00 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id u132so48828679wmg.0 for ; Sun, 19 Mar 2017 11:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=5ZjMu2EEoy08Rxroa1wFRJ7lFXcCVXpKaKv0WkTb0YI=; b=R2oqgmH2FAoy7a2vWRxB1Dkt33lN+QnTcKdGQMf0BJ+iXGjPQDhnRrI8f9OfLnixki pKTGHqtpuY1oKuuk+r+p276QMyOPyfFA+rL76eXaQZhdUhuAvaczC8ZMn7tpRSIBBtlM i7ylhmzC5bjKUh+mLphwUEYz/2kQDC6j6MQZsIVp1mNlaDvbQm+IFKTW9lJcHNDbIiTQ cbBDF7cJlzEW2rx7rrnes/iFUZ+Rwg/3mZYzCbeTIVxsrjvtZLN7oGvJ1z2DvCwAlszl AFNAFk018uD9YmM5hBWChVGyy2nYzUNSwa4VRVXM+HwBs6aEjLom/WJbj9QNggNp09NH H/Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=5ZjMu2EEoy08Rxroa1wFRJ7lFXcCVXpKaKv0WkTb0YI=; b=XGri39RuOGw2pilV22B+an1+xGFl/aK/2pVMzI7rv2IpjTkpnd3oJE0gTNHbCAD1D8 /Lp3gkx9s+W9igX7aEbwd2O6idkeU5vMtzTpn7ElrDyJGvOtS/zKvYEWDzJur4XKQ5ZZ uAs6eqelI1ZrTaq412b6+q5anFGNJfrzS5c+45zVvlW+8naljW2WtaFuhj8D22ASofF3 8RJK3cBYO4cYgxcvfN5m0j3rWOgQ9WBJ36VUEh/vSyIZBfG+Kxh6QRS16Qyy0U0+SU3G uNzzOOBI5246ljrUUelLNQ2xqARv7cw4IJp9bNtFR2nReG/syihfQWEV16uaShKMkyK+ /GNw== X-Gm-Message-State: AFeK/H1o3BdcQxYCdLg5Zq2dNuczU6dF1AoSl6qU5bH2m6WICgAbPBf1j3Nv+8LiDrEMZg== X-Received: by 10.28.21.15 with SMTP id 15mr6784417wmv.11.1489949578763; Sun, 19 Mar 2017 11:52:58 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id m186sm10639394wmd.21.2017.03.19.11.52.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Mar 2017 11:52:58 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A3303713-F582-4E8E-B2EC-A2926F04D2FF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Sun, 19 Mar 2017 20:52:55 +0200 In-Reply-To: Cc: ipsec@ietf.org To: Eric Rescorla References: X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [IPsec] Comments on draft-mglt-ipsecme-implicit-iv-02.tx X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 18:53:04 -0000 --Apple-Mail=_A3303713-F582-4E8E-B2EC-A2926F04D2FF Content-Type: multipart/alternative; boundary="Apple-Mail=_50C787C0-1426-4FF2-86C0-694713EA91B0" --Apple-Mail=_50C787C0-1426-4FF2-86C0-694713EA91B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 19 Mar 2017, at 19:30, Eric Rescorla wrote: >=20 >=20 >=20 > On Sun, Mar 19, 2017 at 10:23 AM, Yoav Nir > wrote: >=20 >> On 19 Mar 2017, at 16:55, Eric Rescorla > wrote: >>=20 >> Overall: >> I notice that you are using a construction different from that used >> in TLS 1.3, which doesn't directly repeat nonces across associations. >=20 > I didn't see an answer to this. Nonces are specified as 64-bit IV (usually counter and we are forcing it = to be a counter) plus 32-bit salt in RFC 4106. We saw no reason to = change that. >>=20 >> S 2. >> This document does not consider AES-CBC ([RFC3602])as AES-CBC >> requires the IV to be unpredictable. Deriving it directly from = the >> packet counter as described below is insecure. >>=20 >> Can you provide a cite for this? >=20 > Even RFC 3602 requires that the IV be randomly generated (and for good = measure requires that it be unpredictable) >=20 > That's just a cite to a requirement, not to it being insecure. Do you = have a citation to the relevant threat? We could cite BEAST. Of course BEAST depends on HTTPS, so it=E2=80=99s = not really applicable - it=E2=80=99s harder to manipulate the first 16 = bytes of the IP header - but these have been the recommendations for = using CBC in both RFCs and NIST documentations for years before BEAST. >=20 >> In any case, note that there are >> straightforward algorithms for deriving a CBC IV from a counter >> (e.g., run AES in counter mode with a different key). That structure >> would actually be suitable for GCM as well (and would address >> my point above). >=20 > If each implementation generates a random key and uses this to = generate the IVs this is fine, but you still have to transmit the IV. = If we derive an =E2=80=9CIV key=E2=80=9D from the keying material, then = we don=E2=80=99t have to transmit the IV. >=20 > You generate the IV from the sequence number, so you don't need to = transmit the IV. > That gives you an unpredictable IV without the per-packet overhead. >=20 >=20 > We did bring this idea up at a WG meeting. This was not well-received = for three reasons: (1) it=E2=80=99s unnecessarily complicated. (2) The = world is going to AEAD. AES-CBC is the past, and (3) The perception was = that saving 8 bytes per packet was important mostly for IoT, and they = don=E2=80=99t care about CBC. >=20 > Sure, that's reasonable. I'm merely observing that there are designs = which work for CBC. >=20 >=20 >> S 3. >> o IV: Initialization Vector. Although security requirements = vary, >> the common usage of this term implies that the value is >> unpredictable. >>=20 >> I don't think that this is true at all. I've frequently heard of a >> zero IV. It's also odd in that your IV is in fact predictable. >>=20 >>=20 >> S 5. >> I'm a bit surprised that you are deciding to have duplicate >> code points for every algorithm rather than some sort of IKE >> negotiation payload. I see that the WG is currently defining >> other extensions where you take that approach. >=20 > See slide #7 of = https://www.ietf.org/proceedings/96/slides/slides-96-ipsecme-0.pdf = >=20 > The problem is that IKEv2 has strict rules about unexpected attributes = in the substructures of the SA payload. The sense of the room was to go = with new identifiers. >=20 > OK. Well, I agree it's ultimately a WG decision, but it doesn't seem = very elegant. I was in the rough on this at first, but it was shown that every = alternate negotiation mechanism had unwanted consequences. Yoav --Apple-Mail=_50C787C0-1426-4FF2-86C0-694713EA91B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 19 Mar 2017, at 19:30, Eric Rescorla <ekr@rtfm.com> = wrote:



On = Sun, Mar 19, 2017 at 10:23 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:

On 19 Mar 2017, at 16:55, Eric Rescorla <ekr@rtfm.com> wrote:

Overall:
I notice that you are using a = construction different from that used
in TLS 1.3, = which doesn't directly repeat nonces across = associations.
I didn't see an answer to = this.

Nonces are = specified as 64-bit IV (usually counter and we are forcing it to be a = counter) plus 32-bit salt in RFC 4106.  We saw no reason to change = that.


S 2.
   This document does not consider AES-CBC = ([RFC3602])as AES-CBC
   requires the IV = to be unpredictable.  Deriving it directly from the
   packet counter as described below is = insecure.

Can = you provide a cite for this?

Even RFC 3602 requires that the = IV be randomly generated (and for good measure requires that it be = unpredictable)

That's just a cite to a requirement, = not to it being insecure. Do you have a citation to the relevant = threat?

We could cite = BEAST. Of course BEAST depends on HTTPS, so it=E2=80=99s not really = applicable - it=E2=80=99s harder to manipulate the first 16 bytes of the = IP header - but these have been the recommendations for using CBC in = both RFCs and NIST documentations for years before = BEAST. 

 
In any case, note that there = are
straightforward algorithms for deriving a CBC = IV from a counter
(e.g., run AES in counter mode = with a different key). That structure
would = actually be suitable for GCM as well (and would address
my point above).

If each implementation generates = a random key and uses this to generate the IVs this is fine, but you = still have to transmit the IV.  If we derive an =E2=80=9CIV key=E2=80= =9D from the keying material, then we don=E2=80=99t have to transmit the = IV. 

You generate the IV from the sequence = number, so you don't need to transmit the IV.
That gives you an unpredictable IV without the per-packet = overhead.


We did bring = this idea up at a WG meeting. This was not well-received for three = reasons: (1) it=E2=80=99s unnecessarily complicated. (2) The world is = going to AEAD. AES-CBC is the past, and (3) The perception was that = saving 8 bytes per packet was important mostly for IoT, and they don=E2=80= =99t care about CBC.

Sure, that's reasonable. I'm merely = observing that there are designs which work for CBC.


S 3.
  =  o  IV: Initialization Vector.  Although security = requirements vary,
      the common usage of this = term implies that the value is
    =   unpredictable.

I don't think that this = is true at all. I've frequently heard of a
zero IV. = It's also odd in that your IV is in fact predictable.


S 5.
I'm a bit surprised that you are = deciding to have duplicate
code points for every = algorithm rather than some sort of IKE
negotiation = payload. I see that the WG is currently defining
other extensions where you take that = approach.

See slide #7 of https://www.ietf.org/proceedings/96/slides/slides-96-ipsecme-0.pdf

The problem is that IKEv2 has strict rules about unexpected = attributes in the substructures of the SA payload. The sense of the room = was to go with new identifiers.

OK. Well, I agree it's = ultimately a WG decision, but it doesn't seem very = elegant.

I was in the = rough on this at first, but it was shown that every alternate = negotiation mechanism had unwanted consequences.

Yoav

= --Apple-Mail=_50C787C0-1426-4FF2-86C0-694713EA91B0-- --Apple-Mail=_A3303713-F582-4E8E-B2EC-A2926F04D2FF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYztOIAAoJELhJCxUKWMyZMt8IAK3vIj4qHVwqLcO7dMirpSaR 8K3HTwEp1nsb7QU6b0p0j8ZxGsCDqo+duTCNL65fcZfUgMumRr+U7ai2Tz/bzW/e dJwVZbZy1Yl6tIRooPHS37nGiXdcqWDVn6t0jCFOIrjWEJpZgKRZ5c9aUU8D4Eoy Q6RIgDBWv5Tt1cZT84tQfhgBNUyVirN+A9TNYjNitijd1lneZyLZue28xV62NMlJ 7ossluSHYv+opbnSCi2japyKWxFbzEExRAD8ZmoWx0n42PqxT+tm2dtHrBSPc94D LhOTPEYK3pcrzh0z8gabnx83osXwbBKOy2+AkVuUaDsRNnkVQYRZDgviw85HAPU= =Mosk -----END PGP SIGNATURE----- --Apple-Mail=_A3303713-F582-4E8E-B2EC-A2926F04D2FF-- From nobody Sun Mar 19 11:55:37 2017 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 7A2BD129353 for ; Sun, 19 Mar 2017 11:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsXWdCX4zIwJ for ; Sun, 19 Mar 2017 11:55:33 -0700 (PDT) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A04012932A for ; Sun, 19 Mar 2017 11:55:33 -0700 (PDT) Received: by mail-it0-x241.google.com with SMTP id g138so13083124itb.0 for ; Sun, 19 Mar 2017 11:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=N0JIGv0vrJgKOhvovm58c8lZSKf/t2cPt7EVCKJZjZs=; b=e/pksP5RhS5IVSfUssPMQVXPpmK9nMyfiyoY9LuKLfcU8wl/lAY4OUwVLI1Gte3dCn vf+7dIPuXP8LyRYSIwItfqYmM2gt/ZgxXmqtZqAsaj84KBjXIFG2eorgXPJEx7dTyaL8 o0gt3KtfQ/Q4DDQ8N5Iux1YUwsgILbhRs6SEwVjOGLVWI+SsN8WBjTgcsQMsiK5rx1Cq mDFnqvAGKwZmsQAmcdYCaLRvAGGZR8PWqRoJbxDWWi9WJMo+1NJIHpwtEff8cnEYkvVe gz2JNfaoSIjNTfv/mjSf1Ll4FLKqVJjALQrUXMNidI+19EB5M3ypZVtDkI6G0uC7jhUH /jHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=N0JIGv0vrJgKOhvovm58c8lZSKf/t2cPt7EVCKJZjZs=; b=Hixm7s4LlNtutCXDuDi4/iKeA7h07FyUu5AAJhgF5o3A9Opc77JtRN1mqHfGd8NL2j Qs/XvqB4AN8OoMF6ERxaArsiLKmKyurI3Rnx2jNeTlum2s04QZp4SzGWjaGKa0oTBHmf QCYr80kfyBJKJOFiks/jGAZe0AbSwXB6N8256rNzoi7TKc4BwspS9Kr3lx+j7GoAKUlS N+Hd+Tn+JsCZlRwT2qPGSKMZudSS9+kGEyydS+NSzVayrOhLCCvkTnhROtbrcoo+3VXr Y6ZFNgtWKNFsXqL+RLIG0V22DtqbgZIZXqPeseC3qqvT+Sv37Y3nQDgA1pFWjVn/U24B iqQg== X-Gm-Message-State: AFeK/H3/KdXseveOzUyO2f/rdPLTkT25WV7tATTyd1U3sGKMbaaLmX9wKRj9dS71lSN0eiD3ta26NKyY3SCuQg== X-Received: by 10.107.168.21 with SMTP id r21mr22127108ioe.45.1489949732895; Sun, 19 Mar 2017 11:55:32 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.35.213 with HTTP; Sun, 19 Mar 2017 11:55:32 -0700 (PDT) In-Reply-To: References: From: Daniel Migault Date: Sun, 19 Mar 2017 14:55:32 -0400 X-Google-Sender-Auth: kVQe9Hey-jr_s0I41BHQmQ8bMQc Message-ID: To: Eric Rescorla Cc: Yoav Nir , "ipsec@ietf.org" Content-Type: multipart/alternative; boundary=001a114215e8900569054b19f462 Archived-At: Subject: Re: [IPsec] Comments on draft-mglt-ipsecme-implicit-iv-02.tx X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 18:55:35 -0000 --001a114215e8900569054b19f462 Content-Type: text/plain; charset=UTF-8 S 2. > This document does not consider AES-CBC ([RFC3602])as AES-CBC >> requires the IV to be unpredictable. Deriving it directly from the >> packet counter as described below is insecure. >> >> Can you provide a cite for this? >> >> >> Even RFC 3602 requires that the IV be randomly generated (and for good >> measure requires that it be unpredictable) >> > > That's just a cite to a requirement, not to it being insecure. Do you have > a citation to the relevant threat? > Predictable IV can be exploited by chosen plain text attacks. RFC3602 cites [CRYPTO-B] in teh sceurity consideration section: """ For more information regarding the necessary use of random IV values, see [CRYPTO-B ]. """ with : [CRYPTO-B] Bellovin, S., "Probable Plaintext Cryptanalysis of the IP Security Protocols", Proceedings of the Symposium on Network and Distributed System Security, San Diego, CA, pp. 155-160, February 1997. http://www.research.att.com/~smb/papers/probtxt.pdf This links works: https://www.cs.columbia.edu/~smb/papers/probtxt.pdf --001a114215e8900569054b19f462 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
S 2.
=
= =C2=A0 =C2=A0This document does not consider AES-CBC ([RFC3602])as AES-CBC<= /div>
=C2=A0 =C2=A0requires the IV to be unpredictable.=C2=A0 Deriving = it directly from the
=C2=A0 =C2=A0packet counter as described bel= ow is insecure.

Can you provide a cite for this?

Even RFC 3602 requires t= hat the IV be randomly generated (and for good measure requires that it be = unpredictable)

That'= s just a cite to a requirement, not to it being insecure. Do you have a cit= ation to the relevant threat?

Predic= table IV can be exploited by chosen plain text attacks. RFC3602 cites [CRYPTO-B] in teh sceurit= y consideration section:
"""
For more information regarding the necessary use of random IV values, s=
ee [C=
RYPTO-B].
"""
with : 
[CRYPTO-B]   Bellovin, S., =
"Probable Plaintext Cryptanalysis of the
             IP Security Protocols", Proceedings of the Symposium on
             Network and Distributed System Security, San Diego, CA,
             pp. 155-160, February 1997.
             http://www.research.att.com/~smb/papers/probtxt.pdf

This lin=
ks works:
https://www.cs.columbia.edu/~smb/papers/probtxt.pdf
--001a114215e8900569054b19f462-- From nobody Sun Mar 19 12:05:59 2017 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 A6FA91292FD for ; Sun, 19 Mar 2017 12:05:58 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVYd2f3HmMbA for ; Sun, 19 Mar 2017 12:05:56 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::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 92DF612896F for ; Sun, 19 Mar 2017 12:05:56 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id o4so78856989ywd.3 for ; Sun, 19 Mar 2017 12:05:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BpgPlnJUZt6zAwEFI6cwPakjQY1I9CrTU5ktbiwnW1I=; b=tWOldoIpne7Q0I0aq9FDe9QpHybOlim2Bz7Wogfip5qrOBJlH434Buto+ZLhOQekXH cZD+IkoPqm5kUY3FXr4C4e6Wi1idBoZxoM6VWiMqqYn3BmEjmHexYtEfYLqdAE4m/wuH ltHZfjpR8Q/3vP0kn86Mh9FVM0qvryyzxWv7IMHHwlny8d5Z8w4f5cQjZHzUpTSakXVH YeyC/patw6lLFrX/kej3FujKnmpkODyR1Cx+9WwSdfzpRtWdTaFCskSpfrLGqveOR9rl qDmejtdOkUgxdf/0b5u9XAZpr+/NRKf/Ibb7MK3WyAOpwtDMBIWeH8BsxGtbOl5QNXcS Td/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BpgPlnJUZt6zAwEFI6cwPakjQY1I9CrTU5ktbiwnW1I=; b=udpI8Sj7ktuB4wjf/yERN9K/Q0JS9RUcWDsOASKLuCXMrulj3HHbuAB/RFUWd7JJ4t OPlc8gw9j+cSK5CAgKCRQNI7Vbv4sR7nYmm5/xUB2YmMZHjUzusMtZXUg3FHRHxMVCU8 N8StARskA6w9nGUAn+MgSPbn5YgPVCav/PRRvTE9bMUiJNUlWswMWS4kIqmPp6vPJZSc TTZPcmEZ67fU0jiGzKyjcofbgcfH0B/XeapMfbmkP/V1bh56qb7m++6k4VwcZnEvTuCy NgjjgvovDgj22ndzGf/RSCOVKVUxFcIczeYZ541MDZSkDslzu8tvTY64V6Ng1OE4STbX iRgg== X-Gm-Message-State: AFeK/H3iay/rvAX9gThtNgAKj69vKi8n9GIAi9rOjVcl+79MJDe544UrWAvMO7+0BL1WyO1jug9A8o//orXc8w== X-Received: by 10.37.171.66 with SMTP id u60mr16299888ybi.64.1489950355773; Sun, 19 Mar 2017 12:05:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Sun, 19 Mar 2017 12:05:15 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sun, 19 Mar 2017 12:05:15 -0700 Message-ID: To: Yoav Nir Cc: ipsec@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0c30f0b09898054b1a19c2 Archived-At: Subject: Re: [IPsec] Comments on draft-mglt-ipsecme-implicit-iv-02.tx X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 19:05:58 -0000 --94eb2c0c30f0b09898054b1a19c2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Mar 19, 2017 at 11:52 AM, Yoav Nir wrote: > > On 19 Mar 2017, at 19:30, Eric Rescorla wrote: > > > > On Sun, Mar 19, 2017 at 10:23 AM, Yoav Nir wrote: > >> >> On 19 Mar 2017, at 16:55, Eric Rescorla wrote: >> >> Overall: >> I notice that you are using a construction different from that used >> in TLS 1.3, which doesn't directly repeat nonces across associations. >> >> I didn't see an answer to this. > > > Nonces are specified as 64-bit IV (usually counter and we are forcing it > to be a counter) plus 32-bit salt in RFC 4106. We saw no reason to chang= e > that. > OK. This has a somewhat lower margin of safety than the TLS 1.3 construction, but it should be OK. S 2. >> This document does not consider AES-CBC ([RFC3602])as AES-CBC >> requires the IV to be unpredictable. Deriving it directly from the >> packet counter as described below is insecure. >> >> Can you provide a cite for this? >> >> >> Even RFC 3602 requires that the IV be randomly generated (and for good >> measure requires that it be unpredictable) >> > > That's just a cite to a requirement, not to it being insecure. Do you hav= e > a citation to the relevant threat? > > > We could cite BEAST. Of course BEAST depends on HTTPS, so it=E2=80=99s no= t really > applicable - it=E2=80=99s harder to manipulate the first 16 bytes of the = IP header > - but these have been the recommendations for using CBC in both RFCs and > NIST documentations for years before BEAST. > Sure. I just think claims like this should have a citation. -Ekr > In any case, note that there are >> straightforward algorithms for deriving a CBC IV from a counter >> (e.g., run AES in counter mode with a different key). That structure >> would actually be suitable for GCM as well (and would address >> my point above). >> >> >> If each implementation generates a random key and uses this to generate >> the IVs this is fine, but you still have to transmit the IV. If we deri= ve >> an =E2=80=9CIV key=E2=80=9D from the keying material, then we don=E2=80= =99t have to transmit the >> IV. >> > > You generate the IV from the sequence number, so you don't need to > transmit the IV. > That gives you an unpredictable IV without the per-packet overhead. > > > We did bring this idea up at a WG meeting. This was not well-received for >> three reasons: (1) it=E2=80=99s unnecessarily complicated. (2) The world= is going >> to AEAD. AES-CBC is the past, and (3) The perception was that saving 8 >> bytes per packet was important mostly for IoT, and they don=E2=80=99t ca= re about >> CBC. >> > > Sure, that's reasonable. I'm merely observing that there are designs whic= h > work for CBC. > > > S 3. >> o IV: Initialization Vector. Although security requirements vary, >> the common usage of this term implies that the value is >> unpredictable. >> >> I don't think that this is true at all. I've frequently heard of a >> zero IV. It's also odd in that your IV is in fact predictable. >> >> >> S 5. >> I'm a bit surprised that you are deciding to have duplicate >> code points for every algorithm rather than some sort of IKE >> negotiation payload. I see that the WG is currently defining >> other extensions where you take that approach. >> >> >> See slide #7 of https://www.ietf.org/proceedings/96/slides/slides-96- >> ipsecme-0.pdf >> >> The problem is that IKEv2 has strict rules about unexpected attributes i= n >> the substructures of the SA payload. The sense of the room was to go wit= h >> new identifiers. >> > > OK. Well, I agree it's ultimately a WG decision, but it doesn't seem very > elegant. > > > I was in the rough on this at first, but it was shown that every alternat= e > negotiation mechanism had unwanted consequences. > > Yoav > > --94eb2c0c30f0b09898054b1a19c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 19, 2017 at 11:52 AM, Yoav Nir <ynir.ietf@gmail.com&= gt; wrote:

On 19= Mar 2017, at 19:30, Eric Rescorla <ekr@rtfm.com> wrote:



On Sun, Mar 19, 2017 at 10:23 = AM, Yoav Nir=C2= =A0<ynir.ietf@gmail.com>=C2=A0wrote:

On 19 Mar 2017, at 16:55, Eric Rescorla <ekr@rtfm.com> wrote:

Overall:
I notice that you are using a co= nstruction different from that used
in TLS 1.3, which doesn't= directly repeat nonces across associations.
=
I didn't see an answer to this.

Nonces are specified as 6= 4-bit IV (usually counter and we are forcing it to be a counter) plus 32-bi= t salt in RFC 4106.=C2=A0 We saw no reason to change that.

OK. This has a somewhat lower margin of safety = than the TLS 1.3 construction, but it should be OK.
=C2=A0
<= div>
S 2.
=C2=A0 =C2=A0This= document does not consider AES-CBC ([RFC3602])as AES-CBC
=C2=A0 = =C2=A0requires the IV to be unpredictable.=C2=A0 Deriving it directly from = the
=C2=A0 =C2=A0packet counter as described below is insecure.

Can you provide a cite for this?
<= /blockquote>

Even RFC 3602 requires that the IV be ran= domly generated (and for good measure requires that it be unpredictable)

That's just a cite to a requi= rement, not to it being insecure. Do you have a citation to the relevant th= reat?

We could cite BEAST. Of= course BEAST depends on HTTPS, so it=E2=80=99s not really applicable - it= =E2=80=99s harder to manipulate the first 16 bytes of the IP header - but t= hese have been the recommendations for using CBC in both RFCs and NIST docu= mentations for years before BEAST.=C2=A0

<= /div>
Sure. I just think claims like this should have a citation.
=
=C2=A0
=
-Ekr
=C2=A0
In any case, note that there are
straightforward algorit= hms for deriving a CBC IV from a counter
(e.g., run AES in counte= r mode with a different key). That structure
would actually be su= itable for GCM as well (and would address
my point above).
<= /div>

If each implementation genera= tes a random key and uses this to generate the IVs this is fine, but you st= ill have to transmit the IV.=C2=A0 If we derive an =E2=80=9CIV key=E2=80=9D= from the keying material, then we don=E2=80=99t have to transmit the IV.= =C2=A0

You generate the IV from= the sequence number, so you don't need to transmit the IV.
That gives you an unpredictable IV without the per-packet overhead.


We did bring this idea up at a WG meeting. This was not well-= received for three reasons: (1) it=E2=80=99s unnecessarily complicated. (2)= The world is going to AEAD. AES-CBC is the past, and (3) The perception wa= s that saving 8 bytes per packet was important mostly for IoT, and they don= =E2=80=99t care about CBC.

Sure= , that's reasonable. I'm merely observing that there are designs wh= ich work for CBC.


S 3.
=C2=A0 =C2=A0o =C2=A0IV: Initialization = Vector.=C2=A0 Although security requirements vary,
=C2=A0 =C2=A0 = =C2=A0=C2=A0the common usage of this term implies that the value is
=C2=A0= =C2=A0 =C2=A0= =C2=A0unpredictable.

I don't think that= this is true at all. I've frequently heard of a
zero IV. It&= #39;s also odd in that your IV is in fact predictable.

=

S 5.
I'm a bit surprised that you are dec= iding to have duplicate
code points for every algorithm rather th= an some sort of IKE
negotiation payload. I see that the WG is cur= rently defining
other extensions where you take that approach.

See slide #7 of=C2= =A0https://www.ietf.org/proceedings/96/slides/sl= ides-96-ipsecme-0.pdf

The problem is that IKEv2= has strict rules about unexpected attributes in the substructures of the S= A payload. The sense of the room was to go with new identifiers.

OK. Well, I agree it's ultimately a W= G decision, but it doesn't seem very elegant.
<= div>
I was in the rough on this at first, but it was shown = that every alternate negotiation mechanism had unwanted consequences.=

Yoav


--94eb2c0c30f0b09898054b1a19c2-- From nobody Mon Mar 20 08:38:14 2017 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 197A5127A97 for ; Mon, 20 Mar 2017 08:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] 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 hG75VrOU-Y3M for ; Mon, 20 Mar 2017 08:38:10 -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 90A07127601 for ; Mon, 20 Mar 2017 08:38:10 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vn0TD2SPrz3Fn; Mon, 20 Mar 2017 16:38:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1490024288; bh=gT3hXDkayW3/6U6KKAXuEt/7a9HlZZV1XgsPzvYm9zA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=NNQHEWfcP1WQyrVN56Nj/GxK6aGYMoUU0tWt8HXp8WKlEmwqQRC/b9KtNQrJR/G3R xcBEYUQP5vfpcGwzQ5DdND4fLLqKtdX+IH2vxMKpGFl/SjHnZ9b6ttigQsf4uIIc0F FDVidcuX+xuYraYeC62ylrFZeuZ3fUYHS62zp3ms= 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 78CTJbm3FWoO; Mon, 20 Mar 2017 16:38:07 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 20 Mar 2017 16:38:06 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 6DE2A39D3A6; Mon, 20 Mar 2017 11:38:05 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 6DE2A39D3A6 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5A9D64144902; Mon, 20 Mar 2017 11:38:05 -0400 (EDT) Date: Mon, 20 Mar 2017 11:38:05 -0400 (EDT) From: Paul Wouters To: Eric Rescorla cc: "ipsec@ietf.org WG" In-Reply-To: Message-ID: References: <08CAB6F1-EA5C-4FA6-A9E9-1D7A87997470@apple.com> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 15:38:12 -0000 On Sun, 19 Mar 2017, Eric Rescorla wrote: > I haven't fully thought this through, but if yu can switch-hit between TCP and UDP,why can't you just race the setup between TCP and UDP and then if you > start > getting packets on UDP, cut over to that.  There should really be a STRONG preference for UDP: - (encrypted) TCP in TCP with packetloss _really_ performs poorly and should be avoided at all costs - there is a reason IKE/IPsec uses UDP and ESP and not TCP. It is not susceptible to (spoofed) TCP-RST packets :P > Maybe I'm just too influenced by ICE :) Yes, we are not limited to flow-level security :) Paul From nobody Thu Mar 23 02:14:49 2017 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 EA8061314CC for ; Thu, 23 Mar 2017 02:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gETdNzwBMhpv for ; Thu, 23 Mar 2017 02:14:46 -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 540E61314CF for ; Thu, 23 Mar 2017 02:14: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 v2N9EYlk022597 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 23 Mar 2017 11:14:34 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v2N9EYvl023727; Thu, 23 Mar 2017 11:14:34 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22739.37370.402945.800855@fireball.acr.fi> Date: Thu, 23 Mar 2017 11:14:34 +0200 From: Tero Kivinen To: Paul Wouters Cc: ipsec@ietf.org In-Reply-To: References: <22644.61072.705632.343770@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 4 min Archived-At: Subject: Re: [IPsec] Review of draft-pauly-ipsecme-split-dns-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 09:14:48 -0000 Paul Wouters writes: > > When an IPsec connection is terminated, the DNS forwarding must be > > unconfigured. The DNS forwarding itself MUST be be deleted. All > > cached data of the INTERNAL_DNS_DOMAIN provided DNS domainis MUST be > > flushed. This includes negative cache entries. Obtained DNSSEC > > trust anchors MUST be removed from the list of trust anchors. The > > > > This might cause security issues. I.e., if you have mail.example.com > > resolved using internal dns server to have IP-address of 10.0.0.1, and > > then someone manages to tear down the VPN connection, and suddenly all > > these mappings go away, the next time your mail client tries to fetch > > email, it does mail.example.com lookup using external DNS servers, and > > will get IP-address of 1.1.1.1 from ns.evil.org, then then it will > > connect to wrong mail server... > > If you are afraid of this attack, deploy DNSSEC on your domain. I most likely would have configfured my internal domain with DNSSEC, bu tthe DNSSEC trust anchors got deleted when tunnel went down, and when it revers to external DNS that might or might not be signed depending whether the top level domain or service provider you are using supports DNSSEC. > > Perhaps we should keep the mappings for some time, just in case the > > connection comes back few seconds later when the vpn reconnects... > > I switch regularly from redhat.com to public, and that would really > cause me problems. It is really important to wipe all the now > unreachable cached DNS data. > > If you wish to stall for a few seconds, I'd recommend you would be > dropping the DNS packets instead of lingering old state, and I would > say that is a pure local implementation issue and shouldn't go into > the RFC. But the MUST delete DNS forwarding etc will not allow me to do that. -- kivinen@iki.fi From nobody Thu Mar 23 02:37:19 2017 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 3C6691314F6; Thu, 23 Mar 2017 02:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nd_FLnFGqepc; Thu, 23 Mar 2017 02:37:17 -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 B6290129A0B; Thu, 23 Mar 2017 02:37:16 -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 v2N9bDKu028155 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 23 Mar 2017 11:37:13 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v2N9bCwO007610; Thu, 23 Mar 2017 11:37:12 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22739.38728.808538.27709@fireball.acr.fi> Date: Thu, 23 Mar 2017 11:37:12 +0200 From: Tero Kivinen To: Paul Wouters Cc: Ben Campbell , The IESG , draft-ietf-ipsecme-rfc7321bis@ietf.org, ipsec@ietf.org, ipsecme-chairs@ietf.org, david.waltermire@nist.gov In-Reply-To: References: <148962889979.14189.965850110922865986.idtracker@ietfa.amsl.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 6 min Archived-At: Subject: Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 09:37:18 -0000 Paul Wouters writes: > > -3: I wonder why "... is not to be used..." is not "... MUST NOT be > > used...". But the section goes on to say if you do it anyway, you MUST > > NOT use certain cryptosuites. So, does "... is not to be used..." mean > > "SHOULD NOT"? Or is this one of those "MUST NOT BUT WE KNOW YOU WILL" > > sort of requirements? > > It is indeed. I think a SHOULD NOT would actually be appropriate ? We do not want to make the implementation of the manual keying MUST NOT, as it is still useful in testing and similar situations, but we do not want anybody using it in any real world use cases. As this document is mostly about the implementation and tries to stay out from the issues about what should be used (as explained in the 2nd paragraph of the section 1.3). On the other hand section 1.3 is really about the use of the manual keying, not about the implementation of manual keying, so that confuses things (we do have some other cases were we say things DES MUST NOT be used). I think the text needs to be clarified about this bit more, especially we do not want to say that ENCR_AES_CBC MUST be used, as there are other algorithms which can also be used (MUST be used would indicate no other algorithm is possible). > > - Table in section 6: > > I'm boggled by the first entry being labeled "MUST/MUST NOT". I don't see > > anything in the text to explain the "MUST" part--did I miss something? > > > First paragraph under the table: > > AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT. The > only reason NULL is acceptable is when authenticated encryption > algorithms are selected from Section 5. In all other cases, NULL > MUST NOT be selected. It does not make it easier that there is typo in that paragraph, and it talks about NULL, when it should be talking about AUTH_NONE... -- kivinen@iki.fi From nobody Thu Mar 23 06:04:59 2017 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 A89F81296EF; Thu, 23 Mar 2017 06:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.496 X-Spam-Level: X-Spam-Status: No, score=-5.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.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 bhi7MHljltSq; Thu, 23 Mar 2017 06:04:51 -0700 (PDT) Received: from esa5.dell-outbound.iphmx.com (esa5.dell-outbound.iphmx.com [68.232.153.95]) (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 06FED1293F8; Thu, 23 Mar 2017 06:04:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1490274243; x=1521810243; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ks5J5TNMEYaivjyHcjMQD6auzDc7GKsDvgGtUpqOfNE=; b=rd5Js55gX2xxtYuxWrbn4QgDTHvbQFOF6JD2KCUlOf9/zF//XsN1hWgL gTIl3eK6HMGrpTaKnxIVxWHpcJZrZLM4hwci8xVsqhDuYK0B2Oe9PFmI0 GSraD/RDnfTORwgddMQa2Jq5PbiFLk/yyZ4boZH30bcod2tqsN5dGP2p5 8=; Received: from esa5.dell-outbound2.iphmx.com ([68.232.153.203]) by esa5.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Mar 2017 08:04:03 -0500 From: Received: from ausxippc101.us.dell.com ([143.166.85.207]) by esa5.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Mar 2017 19:02:49 +0600 X-LoopCount0: from 10.175.216.250 X-IronPort-AV: E=Sophos;i="5.36,209,1486447200"; d="scan'208";a="925050817" To: CC: , , , , , , Thread-Topic: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT) Thread-Index: AQHSnfd0XQvvES+uGkGEDF04hrQ/d6GYB3wAgAqCfwCAADo4AA== Date: Thu, 23 Mar 2017 13:04:47 +0000 Message-ID: References: <148962889979.14189.965850110922865986.idtracker@ietfa.amsl.com> <22739.38728.808538.27709@fireball.acr.fi> In-Reply-To: <22739.38728.808538.27709@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.178.128.191] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 13:04:53 -0000 > On Mar 23, 2017, at 5:37 AM, Tero Kivinen wrote: >=20 > Paul Wouters writes: >>> -3: I wonder why "... is not to be used..." is not "... MUST NOT be >>> used...". But the section goes on to say if you do it anyway, you MUST >>> NOT use certain cryptosuites. So, does "... is not to be used..." mean >>> "SHOULD NOT"? Or is this one of those "MUST NOT BUT WE KNOW YOU WILL" >>> sort of requirements? >>=20 >> It is indeed. I think a SHOULD NOT would actually be appropriate ? >=20 > We do not want to make the implementation of the manual keying MUST > NOT, as it is still useful in testing and similar situations, but we > do not want anybody using it in any real world use cases. As this > document is mostly about the implementation and tries to stay out from > the issues about what should be used (as explained in the 2nd > paragraph of the section 1.3). The problem is that currently USGv6 mandates support for manual keying base= d on earlier RFC text. I wonder if the proposed text is strong enough to m= ake them understand this is wrong. This is why I was pushing for MUST NOT. Exotic test scenarios aren't all that good an argument, for those you can h= ack the code and ignore the RFC. paul From nobody Thu Mar 23 09:26:09 2017 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 C66E11298AA; Thu, 23 Mar 2017 09:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 e9GFPb6v1rnJ; Thu, 23 Mar 2017 09:25:58 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0095.outbound.protection.outlook.com [104.47.2.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2E171294A0; Thu, 23 Mar 2017 09:25:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0iv+moMiCxRcjgx661pGIZKIuUcF1fEzmMPhIMdriDM=; b=RKmAuiJGHxeFKlVNntHbrZPtKYx1J9LqNasrpoI+y+FQTR+gy89xpmbzG4BhQdWmJllTfIAH1qOL94IFk9fzqyQn9K7vXrTscChG9Sct77F5Ds5F56Z8WSzC+0wLFRls9Myn3ZF9QR3v4xRVzAK+Ll8u2yV2+r4eIoXJX7jTxQ4= Received: from HE1PR07MB1417.eurprd07.prod.outlook.com (10.169.122.15) by HE1PR07MB1420.eurprd07.prod.outlook.com (10.169.122.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.4; Thu, 23 Mar 2017 16:25:53 +0000 Received: from HE1PR07MB1417.eurprd07.prod.outlook.com ([10.169.122.15]) by HE1PR07MB1417.eurprd07.prod.outlook.com ([10.169.122.15]) with mapi id 15.01.0991.013; Thu, 23 Mar 2017 16:25:53 +0000 From: "Hu, Jun (Nokia - US/Mountain View)" To: "Paul.Koning@dell.com" , "kivinen@iki.fi" CC: "draft-ietf-ipsecme-rfc7321bis@ietf.org" , "ben@nostrum.com" , "ipsecme-chairs@ietf.org" , "ipsec@ietf.org" , "iesg@ietf.org" , "paul@nohats.ca" , "david.waltermire@nist.gov" Thread-Topic: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT) Thread-Index: AQHSo7kV5lIftz+KZECrKBONojl6I6GiZKaAgAA3Y6A= Date: Thu, 23 Mar 2017 16:25:53 +0000 Message-ID: References: <148962889979.14189.965850110922865986.idtracker@ietfa.amsl.com> <22739.38728.808538.27709@fireball.acr.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dell.com; dkim=none (message not signed) header.d=none;dell.com; dmarc=none action=none header.from=nokia.com; x-originating-ip: [98.210.180.51] x-microsoft-exchange-diagnostics: 1; HE1PR07MB1420; 7:smiOPRribQVhro0Sx2D0A/Th+eVsMNxL93pXklbHIL3P24HS+pu9q50QF78lz6/nxL3DMA2uIUT3Pn4wsYnEC1plcCYr6kEY8JY6t/mMC6OGudaKTGBZ3aUMfzi5MJet695TMt5E9Ruz73rs9hExiuiyG3wmQzyApBfZi1ySc37ij8UZVUJfdvBz1swsoNpQjw/NyycDika7mYpadkKSAtkGCiRailfagrxcv+1BWm2X+i8wQfHkpdhyghng3sXmsDhD2PjXo5HQnlixIeyphZFMxEFhzlVq06DJg8nrOc8KbsPJREQwwmfy3yYc5ZLXntMhTFUTfZvC+GndCIac1A== x-ms-office365-filtering-correlation-id: 050f4651-c67d-4a67-c963-08d4720946e8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:HE1PR07MB1420; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(56004941905204); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(20161123558025)(6072148); SRVR:HE1PR07MB1420; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1420; x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39840400002)(39450400003)(39410400002)(39850400002)(52314003)(13464003)(24454002)(54094003)(377454003)(3660700001)(86362001)(50986999)(7736002)(189998001)(93886004)(7696004)(76176999)(74316002)(8936002)(54356999)(8676002)(2900100001)(81166006)(305945005)(122556002)(25786009)(66066001)(53546009)(4326008)(102836003)(55016002)(2906002)(2501003)(230783001)(77096006)(33656002)(3846002)(2950100002)(3280700002)(6116002)(6506006)(9686003)(6246003)(6436002)(53936002)(6306002)(5660300001)(38730400002)(8656002)(229853002)(99286003)(8666007)(54906002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1420; H:HE1PR07MB1417.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2017 16:25:53.3393 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1420 Archived-At: Subject: Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 16:26:01 -0000 A very real use case is OSPFv3 authentication (RFC 4552), all major router = vendor supports OSPFv3 implement that, and it is deployed around world; Plus I don't see any realistic alternative for the use case > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of > Paul.Koning@dell.com > Sent: Thursday, March 23, 2017 6:05 AM > To: kivinen@iki.fi > Cc: draft-ietf-ipsecme-rfc7321bis@ietf.org; ben@nostrum.com; ipsecme- > chairs@ietf.org; ipsec@ietf.org; iesg@ietf.org; paul@nohats.ca; > david.waltermire@nist.gov > Subject: Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-= 05: > (with COMMENT) >=20 >=20 > > On Mar 23, 2017, at 5:37 AM, Tero Kivinen wrote: > > > > Paul Wouters writes: > >>> -3: I wonder why "... is not to be used..." is not "... MUST NOT be > >>> used...". But the section goes on to say if you do it anyway, you > >>> MUST NOT use certain cryptosuites. So, does "... is not to be > >>> used..." mean "SHOULD NOT"? Or is this one of those "MUST NOT BUT WE > KNOW YOU WILL" > >>> sort of requirements? > >> > >> It is indeed. I think a SHOULD NOT would actually be appropriate ? > > > > We do not want to make the implementation of the manual keying MUST > > NOT, as it is still useful in testing and similar situations, but we > > do not want anybody using it in any real world use cases. As this > > document is mostly about the implementation and tries to stay out from > > the issues about what should be used (as explained in the 2nd > > paragraph of the section 1.3). >=20 > The problem is that currently USGv6 mandates support for manual keying > based on earlier RFC text. I wonder if the proposed text is strong enoug= h to > make them understand this is wrong. This is why I was pushing for MUST N= OT. >=20 > Exotic test scenarios aren't all that good an argument, for those you can= hack > the code and ignore the RFC. >=20 > paul >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Mar 23 11:55:44 2017 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 8E1B5129BC8 for ; Thu, 23 Mar 2017 11:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] 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 VxUByxnE2AeQ for ; Thu, 23 Mar 2017 11:55:42 -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 07F6F129BAB for ; Thu, 23 Mar 2017 11:55:42 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vpwjl17pXzD49; Thu, 23 Mar 2017 19:55:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1490295339; bh=tK9UhjDi+cZhlcAYqGCzO1fq3e6NmFLxFf8jkJenoeU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=C+IcJWgrfqY9auqrWITufWG7gRdWHFkHyKfeR6PGTuqnCH+5dHnGAS39c4J/KA5Sg KvlfN9Ks+2wClnnhZay9SpkACz4Y7bG5NfkqLq6F/h+yKLkluMTq/Emvo33pRu4sbM fCIhRrY8qz9Cbn92clc+93/nlnpdVAAZrfElrmC8= 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 xhZ140gkCyer; Thu, 23 Mar 2017 19:55:37 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 23 Mar 2017 19:55:37 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 64D8F4CA350; Thu, 23 Mar 2017 14:55:36 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 64D8F4CA350 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5C7E84000880; Thu, 23 Mar 2017 14:55:36 -0400 (EDT) Date: Thu, 23 Mar 2017 14:55:36 -0400 (EDT) From: Paul Wouters To: Tero Kivinen cc: ipsec@ietf.org In-Reply-To: <22739.37370.402945.800855@fireball.acr.fi> Message-ID: References: <22644.61072.705632.343770@fireball.acr.fi> <22739.37370.402945.800855@fireball.acr.fi> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Review of draft-pauly-ipsecme-split-dns-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 18:55:43 -0000 On Thu, 23 Mar 2017, Tero Kivinen wrote: >>> then someone manages to tear down the VPN connection, and suddenly all >>> these mappings go away, the next time your mail client tries to fetch >>> email, it does mail.example.com lookup using external DNS servers, and >>> will get IP-address of 1.1.1.1 from ns.evil.org, then then it will >>> connect to wrong mail server... >> >> If you are afraid of this attack, deploy DNSSEC on your domain. > > I most likely would have configfured my internal domain with DNSSEC, > bu tthe DNSSEC trust anchors got deleted when tunnel went down, and > when it revers to external DNS that might or might not be signed > depending whether the top level domain or service provider you are > using supports DNSSEC. If you are in a split view, we can't really retain DNS cache. When the split goes away you would not be able to reach these. For example, bugzilla.redhat.com has an internal and external IP. If DNS cache is retaining, when my VPN goes down, I can no longer connect to bugzilla. So I think my use case trumps your use case because you should just sign your external DNS too :P >>> Perhaps we should keep the mappings for some time, just in case the >>> connection comes back few seconds later when the vpn reconnects... >> >> I switch regularly from redhat.com to public, and that would really >> cause me problems. It is really important to wipe all the now >> unreachable cached DNS data. >> >> If you wish to stall for a few seconds, I'd recommend you would be >> dropping the DNS packets instead of lingering old state, and I would >> say that is a pure local implementation issue and shouldn't go into >> the RFC. > > But the MUST delete DNS forwarding etc will not allow me to do that. That's semantics :P If you linger the Child SA, you haven't torn it down yet, so you can also leave your DNS entries. Paul From nobody Fri Mar 24 13:16:59 2017 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 67B4C12986E; Fri, 24 Mar 2017 13:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, 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 Y_Z6XxPEUed7; Fri, 24 Mar 2017 13:16:48 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9748B129473; Fri, 24 Mar 2017 13:16:48 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id 190so1096544itm.0; Fri, 24 Mar 2017 13:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=TORAk6Sld8EeLP2oo6TPc/Uq+BYh4X7VbiaNK9+rwsc=; b=nhvVAQx0Pzwx5SiLTtfS8R26vkQzngNOnOeRdAHMVEcndZCBcTZfYofH11aGEBYhnK RIeCjZ6RTDu4t2MzWXFAfotaB4m2SUMB3PsnPIeJTB4JMh9rf10em1xtsuzPfocAdbxk D5p476+K9CqEP5P2Chaf+TfA9MFVM3sdSgoInQyCeBSjjSJIKaeFWeoTMRKNJ5ZbXsdF AHcBMNBtSGrjr7wKaXf9plvw4xt07bizbdJoDgQPJwfc7wJEbyLDj3G8dOVKlKevypek tT67jh7BInt7tJnah3EriKwwiPTJq902bEhMCz397Py+xArv6xQJuDa0wwUCpoLsIU1x HLog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=TORAk6Sld8EeLP2oo6TPc/Uq+BYh4X7VbiaNK9+rwsc=; b=PBbm3Q/qh3iwUF0a54XHO/k8kBpzXniXyO037xfNO8i1cCuS7uxPCNDrD0dE/iJ6w/ aF/2HzHc0BsByOu224qmi7jNxgq2tn1xq/ByT7zqzSWkgHySMvtMRg3Rkr0gk1vqPjhY ZruR0Ks7J41nnQZHefln5lFUt3DmFhX9lpjg+kE17+OV+XprSTyuMSdInS2eJjRlD9eG uZXL0Mc1Hv2yDxOug9Lfe488tkuh1g627DRkpzGoScrlTbIb1qDA0uXkJj8f50potnBe b6B0vfvK+tAHQDNjxF1gWqTer/8xRRuzHpCZVCjQst0Vk+cmasVGQSA1fKTuLdjTtR3O bJ+A== X-Gm-Message-State: AFeK/H1ltYAQF1yv1eE7ZU9caHiO7TP10UXyV0lRFpdD+EVPH2BURbRPR+1dUPHABnL/G6gAZA4owYXDaxncaQ== X-Received: by 10.107.174.27 with SMTP id x27mr9908197ioe.35.1490386607755; Fri, 24 Mar 2017 13:16:47 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.35.213 with HTTP; Fri, 24 Mar 2017 13:16:47 -0700 (PDT) From: Daniel Migault Date: Fri, 24 Mar 2017 16:16:47 -0400 X-Google-Sender-Auth: 6Ak-AWWuzn3pJmimYV2UYMrZfhI Message-ID: To: "lwip@ietf.org" , IPsecME WG Content-Type: multipart/alternative; boundary=001a11449ffc555c01054b7facb6 Archived-At: Subject: [IPsec] Number of fixed SPI X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 20:16:52 -0000 --001a11449ffc555c01054b7facb6 Content-Type: text/plain; charset=UTF-8 Hi, I have a question regarding devices that are not able to randomly generate SPI, but instead store fix values. The question is how much fix values could be provisioned. For unicast communications, a single SPI can be used over multiple nodes as long as the remote peer, as long as both nodes uses IP addresses and SPI to index the SAs. With the transport mode, the number of SPI is equivalent to the number of hosts, while with tunnel mode, the number of SPI is equivalent to the number of tunnels. For that reason I would recommend that a minimal implementation supporting unicast only has as many SPI values as ESP session per host or per security gateways, and that lookup includes the IP addresses. However this would not work with a security gateway that performs lookup only based on the SPI. Such security gateway would still be ESP.compliant. Does it sounds reasonable that security gateways implements the longest match lookup or at least lookup considering IP addresses ? Yours, Daniel On Mon, Mar 13, 2017 at 9:58 AM, Daniel Migault wrote: > Hi, > > Please find an update of a guidance for light implementation of standard > ESP. Feel free to comment! > > Yours, > Daniel > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, March 13, 2017 9:57 AM > To: Tobias Guggemos ; Daniel Migault < > daniel.migault@ericsson.com> > Subject: New Version Notification for draft-mglt-lwig-minimal-esp-04.txt > > > A new version of I-D, draft-mglt-lwig-minimal-esp-04.txt > has been successfully submitted by Daniel Migault and posted to the IETF > repository. > > Name: draft-mglt-lwig-minimal-esp > Revision: 04 > Title: Minimal ESP > Document date: 2017-03-13 > Group: Individual Submission > Pages: 10 > URL: https://www.ietf.org/internet-drafts/draft-mglt-lwig- > minimal-esp-04.txt > Status: https://datatracker.ietf.org/doc/draft-mglt-lwig-minimal- > esp/ > Htmlized: https://tools.ietf.org/html/draft-mglt-lwig-minimal-esp-04 > Diff: https://www.ietf.org/rfcdiff?url2=draft-mglt-lwig-minimal- > esp-04 > > Abstract: > This document describes a minimal version of the IP Encapsulation > Security Payload (ESP) described in RFC 4303 which is part of the > IPsec suite. > > ESP is used to provide confidentiality, data origin authentication, > connectionless integrity, an anti-replay service (a form of partial > sequence integrity), and limited traffic flow confidentiality. > > This document does not update or modify RFC 4303, but provides a > compact description of how to implement the minimal version of the > protocol. If this document and RFC 4303 conflicts then RFC 4303 is > the authoritative description. > > > > > 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 > --001a11449ffc555c01054b7facb6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I have a question regardi= ng devices that are not able to randomly generate SPI, but instead store fi= x values.=C2=A0 The question is how much fix values could be provisioned. <= br>
For unicast communications, a single SPI can be used over= multiple nodes as long as the remote peer, as long as both nodes uses IP a= ddresses and SPI to index the SAs. With the transport mode, the number of S= PI is equivalent to the number of hosts, while with tunnel mode, the number= of SPI is equivalent to the number of tunnels.=C2=A0
For that reason I= would recommend that a minimal implementation supporting unicast only has = as many SPI values as ESP session per host or per security gateways, and th= at lookup includes the IP addresses.

However this would not wo= rk with a security gateway that performs lookup only based on the SPI. Such= security gateway would still be ESP.compliant. Does it sounds reasonable t= hat security gateways implements the longest match lookup or at least looku= p considering IP addresses ?

Yours,
Daniel= =C2=A0 =C2=A0

On Mon, Mar 13, 2017 at 9:58 AM, Daniel Migault &l= t;daniel.m= igault@ericsson.com> wrote:
Hi,

Please find an update of a guidance for light implementation of standard ES= P. Feel free to comment!

Yours,
Daniel

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Monday, March 13, 2017 9:57 AM
To: Tobias Guggemos <guggemos@m= nm-team.org>; Daniel Migault <daniel.migault@ericsson.com>
Subject: New Version Notification for draft-mglt-lwig-minimal-esp-04.t= xt


A new version of I-D, draft-mglt-lwig-minimal-esp-04.txt
has been successfully submitted by Daniel Migault and posted to the IETF re= pository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mglt-lwig-minimal-esp Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A004
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Minimal ESP
Document date:=C2=A0 2017-03-13
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mglt-lwig-= minimal-esp-04.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mglt-lwig-minimal-esp/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:= //tools.ietf.org/html/draft-mglt-lwig-minimal-esp-04
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-mglt-lwig-minima= l-esp-04

Abstract:
=C2=A0 =C2=A0This document describes a minimal version of the IP Encapsulat= ion
=C2=A0 =C2=A0Security Payload (ESP) described in RFC 4303 which is part of = the
=C2=A0 =C2=A0IPsec suite.

=C2=A0 =C2=A0ESP is used to provide confidentiality, data origin authentica= tion,
=C2=A0 =C2=A0connectionless integrity, an anti-replay service (a form of pa= rtial
=C2=A0 =C2=A0sequence integrity), and limited traffic flow confidentiality.=

=C2=A0 =C2=A0This document does not update or modify RFC 4303, but provides= a
=C2=A0 =C2=A0compact description of how to implement the minimal version of= the
=C2=A0 =C2=A0protocol.=C2=A0 If this document and RFC 4303 conflicts then R= FC 4303 is
=C2=A0 =C2=A0the authoritative description.




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

--001a11449ffc555c01054b7facb6-- From nobody Fri Mar 24 13:41:57 2017 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 06940129981; Fri, 24 Mar 2017 13:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yscE1N7JpQqc; Fri, 24 Mar 2017 13:41:49 -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 A3204129962; Fri, 24 Mar 2017 13:41:49 -0700 (PDT) X-AuditID: c618062d-d73ff700000009d8-3d-58d595f90654 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by (Symantec Mail Security) with SMTP id DE.D1.02520.9F595D85; Fri, 24 Mar 2017 22:56:12 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0319.002; Fri, 24 Mar 2017 16:41:36 -0400 From: Daniel Migault To: "Paul.Koning@dell.com" CC: IPsecME WG , "lwip@ietf.org" Thread-Topic: [IPsec] Number of fixed SPI Thread-Index: AQHSpNzABrDXwZOU10SXLftJp6gwyKGkdCyg Date: Fri, 24 Mar 2017 20:41:28 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118BB6EE6@eusaamb107.ericsson.se> References: <4EF73939-B0F0-4E80-96B5-619E416D8AB6@dell.com> In-Reply-To: <4EF73939-B0F0-4E80-96B5-619E416D8AB6@dell.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyuXRPiO6fqVcjDN5tkLDYv+UFm8W8fcIW a55XODB7TJo5g9ljyZKfTAFMUVw2Kak5mWWpRfp2CVwZX17aFSwTrFj9upuxgfELbxcjJ4eE gInEgQnLmLsYuTiEBNYzSmy/288K4SxnlOh4c5oJpIpNwEii7VA/O4gtImAo8WTxE1YQm1nA QeLOsy1ANRwcwgIaElNeqkOUaEpM33uXEcI2kvi29QwLiM0ioCpx/uNusDG8Ar4Ss45sh9rV xCgx+/UssJmcAjYSHa9Ogu1lFBCT+H5qDRPELnGJW0/mM0FcLSCxZM95ZghbVOLl43+sELaS xMff89kh6nUkFuz+xAZha0ssW/iaGWKxoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKkaO0 uCAnN93IYBMjMCaOSbDp7mC8P93zEKMAB6MSD6/BnysRQqyJZcWVuYcYJTiYlUR4H1pfjRDi TUmsrEotyo8vKs1JLT7EKM3BoiTOO+H8hQghgfTEktTs1NSC1CKYLBMHp1QDo9zmOT2q69qM Dne1+GaGHw3L3rDUzlkp0/d4vEDZ0nMzGbeX+V1wnCd8sM3xvcZZBibH0DW7382R2HUsM//p dzf3qAPvEsPT7T9aJLMsFVBRcuv3Wlfmrbxpq5kAj4n1qzr39WnsT+cyclakTPQ37epU29TU nc7sPnlKwb3TTnkOJ2a/twlVYinOSDTUYi4qTgQA5Eu+DoUCAAA= Archived-At: Subject: Re: [IPsec] Number of fixed SPI X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 20:41:51 -0000 Hi Paul,=20 My understanding of RFC4301 section 4.1, is that nodes supporting only unic= ast communications can index their SA only using the SPI while nodes suppor= ting multicast communications must also use the IP addresses and thus SA lo= okup needs to be performed using the longest match. I guess that multipurpose interoperability is achieved with the longest mat= ch lookup. But I agree I am also confused.=20 Yours,=20 Daniel -----Original Message----- From: Paul.Koning@dell.com [mailto:Paul.Koning@dell.com]=20 Sent: Friday, March 24, 2017 4:25 PM To: Daniel Migault Subject: Re: [IPsec] Number of fixed SPI > On Mar 24, 2017, at 4:16 PM, Daniel Migault = wrote: >=20 > Hi,=20 >=20 > I have a question regarding devices that are not able to randomly generat= e SPI, but instead store fix values. The question is how much fix values c= ould be provisioned.=20 >=20 > For unicast communications, a single SPI can be used over multiple nodes = as long as the remote peer, as long as both nodes uses IP addresses and SPI= to index the SAs. With the transport mode, the number of SPI is equivalent= to the number of hosts, while with tunnel mode, the number of SPI is equiv= alent to the number of tunnels. =20 > For that reason I would recommend that a minimal implementation supportin= g unicast only has as many SPI values as ESP session per host or per securi= ty gateways, and that lookup includes the IP addresses. >=20 > However this would not work with a security gateway that performs lookup = only based on the SPI. Such security gateway would still be ESP.compliant.= =20 I must be missing something. Maybe I'm remembering older documents. My un= derstanding of ESP and the security architecture RFC is that lookup is requ= ired to be by SPI and IP address. Where do you see text that suggests SPI-only lookup is compliant? A principle of communication standards design is that conformance should im= ply interoperability, so if the RFC really does permit one node to send som= ething that another node would not be able to handle, that would be an RFC = bug. paul From nobody Fri Mar 24 15:30:18 2017 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 824CA12894E; Fri, 24 Mar 2017 15:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] 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 PFETb67k912K; Fri, 24 Mar 2017 15:30:08 -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 C161B12894A; Fri, 24 Mar 2017 15:30:08 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vqdQk4y4JzD36; Fri, 24 Mar 2017 23:30:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1490394606; bh=ZY9Rj3/s8nv5KOqnyAQhyhhUTLu+Z82wWXX5PFGchSU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=GK/5UnmP7P2YwSBAIzhUGiqB/elQEvRdTSGPuKHl3oOXHZjmaXdqIKRXCF3+2gZsI 0vUvhSzqgmQhl1vpze9BIXwJI7e+5iQkeKQWHgyOeP1hngbv92OFrfTdeEruweTBSx 76TZrYlA3Jf3Mz3YpWMZhV37fhg8PwJDGHHkeRxY= 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 G22T8nwgSciJ; Fri, 24 Mar 2017 23:30:05 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 24 Mar 2017 23:30:05 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id DEA9731C858; Fri, 24 Mar 2017 18:30:04 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca DEA9731C858 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C8022420ACA1; Fri, 24 Mar 2017 18:30:04 -0400 (EDT) Date: Fri, 24 Mar 2017 18:30:04 -0400 (EDT) From: Paul Wouters To: Daniel Migault cc: "lwip@ietf.org" , IPsecME WG In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] Number of fixed SPI X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 22:30:11 -0000 On Fri, 24 Mar 2017, Daniel Migault wrote: > I have a question regarding devices that are not able to randomly generate SPI, but instead > store fix values.  The question is how much fix values could be provisioned. This is pretty dangerous. Half a year ago or so we saw the Transcript Collsion Attacks that could have succeeded if we hadn't used random SPI numbers to prevent pre-calculation in the attack. Using a set of 10 non-random SPI numbers would potentially make this device vulnerable to this attack. Paul From nobody Sat Mar 25 07:44:52 2017 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 D578812940B for ; Sat, 25 Mar 2017 07:44:50 -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 L9WvFYRoF9T7 for ; Sat, 25 Mar 2017 07:44:49 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0122.outbound.protection.outlook.com [23.103.200.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 201E51204DA for ; Sat, 25 Mar 2017 07:44:48 -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=7DMVyRIJQGnfOkiC/sKUSd8Ys1zj2Az/vHCr/VavSL4=; b=kl1ijubA1pM0tFibvjncvyvZjBGsNOKUfImahTOrLJqPoWVUqp8z0JIg5jfUkz8WAnrtN051NGTbpgT5lj5YCaWG9BKPUZaS0r+tTzVIB2wwfdOAbUqj9to18JckXHqjDaksmDHfxIlKM7ik3bSb84L+h4Rn2WObLEQtmFN/dZU= 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_128_CBC_SHA256_P256) id 15.1.991.14; Sat, 25 Mar 2017 14:44:46 +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.0977.021; Sat, 25 Mar 2017 14:44:46 +0000 From: "Waltermire, David A. (Fed)" To: IPsecME WG Thread-Topic: Slides for IPSecME @ IETF 98 Thread-Index: AdKldkQO9a/JSrVKTtuk6FLaYc1HmQ== Date: Sat, 25 Mar 2017 14:44:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.222.60] x-microsoft-exchange-diagnostics: 1; MWHPR09MB1438; 7:KjnDiRrchZwCPsszKPrCoSIQPGbjBayplveBsVtXZOpDcMU/KMn/rlJUFCxNsFWVvOvxKlgTkPPMuhFcXNB/UQ6I7MSKWdWO3zEJWMlYXY915n5QyOkDD9et6hS+o3axROioJAOYfzfX6zZReumYESd1baicOdje0tIXYVDd/yvARzifhpxxdvTpgguE0B/Zv7uAeuyjDVwmeWZfQGg/SQWo2RpO1k6lZtk8P5JmjQjZSy+pkSuYigN7UPZBlTa934qv+ZMX9KIXPHnIGEyiILYQApp5Jfp+ogCWqgQ5GJV4HQ7DityCmFJl8OKCldCyXgjL/QPC7kxnsPxfEk9iEA== x-ms-office365-filtering-correlation-id: a5d668fc-b8f1-42bd-f592-08d4738d7b9b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:MWHPR09MB1438; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123555025)(20161123562025)(20161123558025)(20161123560025)(6072148); SRVR:MWHPR09MB1438; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1438; x-forefront-prvs: 025796F161 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39850400002)(39450400003)(39410400002)(66066001)(2900100001)(5660300001)(8936002)(8676002)(81166006)(86362001)(33656002)(122556002)(25786009)(50986999)(3280700002)(558084003)(38730400002)(2906002)(110136004)(54356999)(3846002)(6116002)(102836003)(3660700001)(7736002)(74316002)(53936002)(99286003)(55016002)(9686003)(6916009)(7696004)(305945005)(77096006)(6436002)(6506006)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1438; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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: 25 Mar 2017 14:44:46.5652 (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: [IPsec] Slides for IPSecME @ IETF 98 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Mar 2017 14:44:51 -0000 We are still in need of slides for draft-pauly-ipsecme-split-dns and draft-= fluhrer-qr-ikev2. If I missed your slides or if you haven't sent them, plea= se send your slides by the end of day Monday. Thank you, Dave and Tero From nobody Sat Mar 25 08:14:20 2017 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 04C431293E3 for ; Sat, 25 Mar 2017 08:14:19 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 fxPo6llS1ER7 for ; Sat, 25 Mar 2017 08:14:16 -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 9AB6912714F for ; Sat, 25 Mar 2017 08:14:16 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vr3jJ6fgTz3FQ; Sat, 25 Mar 2017 16:14:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1490454853; bh=F7MwXyahyZomYbRuA6V7BBim38JmOUKBMbJ77qJxUgo=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=hCxUlx/doE7QBZSGILESg2C/OBjhRlIAR0Mt2yLi+L9C5P6CYW1WVfbkf+pTQvnE2 Z1JOWW1r43s37CgxwrGimtDOHex9mRDLei7Gvrwf0kRybWiXyGS4D8lG8Nkol6qlth uXAepn5JYba4D4yHvIfPrwGVZ6lPQYYeJixTVzds= 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 c6ScguBpty-T; Sat, 25 Mar 2017 16:14:11 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 25 Mar 2017 16:14:09 +0100 (CET) Received: from [10.255.252.115] (unknown [207.164.2.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 127EF22709A; Sat, 25 Mar 2017 11:14:09 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 127EF22709A Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (14D27) In-Reply-To: Date: Sat, 25 Mar 2017 11:14:08 -0400 Cc: IPsecME WG Content-Transfer-Encoding: quoted-printable Message-Id: <675CABC4-5614-4B01-86EC-CCCAAC5B2E15@nohats.ca> References: To: "Waltermire, David A. (Fed)" Archived-At: Subject: Re: [IPsec] Slides for IPSecME @ IETF 98 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Mar 2017 15:14:19 -0000 In transit, will make slides=20 Sent from my iPhone > On Mar 25, 2017, at 10:44, Waltermire, David A. (Fed) wrote: >=20 > We are still in need of slides for draft-pauly-ipsecme-split-dns and draft= -fluhrer-qr-ikev2. If I missed your slides or if you haven't sent them, plea= se send your slides by the end of day Monday. >=20 > Thank you, > Dave and Tero >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Sun Mar 26 05:23:43 2017 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 68343129540 for ; Sun, 26 Mar 2017 05:23:42 -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 LqYUgjQDmCNJ for ; Sun, 26 Mar 2017 05:23:40 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0133.outbound.protection.outlook.com [23.103.201.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27B0F1293FB for ; Sun, 26 Mar 2017 05:23:40 -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=Ojn9JG/uNqvkhSZeT9NwWxzDwx+u5o+YmGHXfl39KnQ=; b=iORuZky+ajLi9US0HGibpSn9peEqPPCydNbA21vLtQ4icTOfRBykZleUjs4xfflM1FwQ9DFW+voQUwNLblX7zyGYtPTfLimTrecxWSHzyA08Y9+db8F2KZFhhe9nJLJRYiBQi3vLQqOkfO7HCw9Nd9+5fH4sZz9olGpPLTc/Oc0= Received: from MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) by MWHPR09MB1440.namprd09.prod.outlook.com (10.173.50.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.991.14; Sun, 26 Mar 2017 12:23:38 +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.0991.020; Sun, 26 Mar 2017 12:23:38 +0000 From: "Waltermire, David A. (Fed)" To: IPsecME WG Thread-Topic: IETF 98 Meeting Change of Time and Location Thread-Index: AQHSpivLW2hkoO4DREqQSv54yHKysQ== Date: Sun, 26 Mar 2017 12:23:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [2600:1008:b066:f10a:3001:f2cd:3b3d:73e9] x-microsoft-exchange-diagnostics: 1; MWHPR09MB1440; 7:l0ZPHWNIY8kYLZqxbHTGHdVHSnUpAID0ShziXguIZcALS/n0lZwDJdgVAWnJ8OnIQfLBR3blYCKwDIuydLHk4gksxqKItHFPbU0iKQgdd0seFC86tbGSRtq/wchQVxU0+JrSyo0b1EYrlC7yVXAeCi8VT2LYg/TIkw2B3D0QUI48Xuli4nVxgBRYwV5i66ZMCdOL7DAO0/d/PfpZkpfmNWYgOK6+HBUN1jYA5KdN9W4/j/D+odDAwF/mSf2LM8Tjsium+LK6XggZa8Bvb8jnfNahyPpoNQafARwAkZ2crS6M5KZj/ei35Q6z5vS4kh4VswEz1R86T3Qm799G2cIZmQ== x-ms-office365-filtering-correlation-id: cf23d590-d77c-4265-2f4a-08d47442ee5a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:MWHPR09MB1440; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558025)(6072148); SRVR:MWHPR09MB1440; BCL:0; PCL:0; RULEID:; SRVR:MWHPR09MB1440; x-forefront-prvs: 0258E7CCD4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39850400002)(39840400002)(39410400002)(33656002)(54896002)(33716001)(53936002)(99286003)(6512007)(9686003)(8676002)(6916009)(81166006)(6506006)(110136004)(54356999)(38730400002)(189998001)(558084003)(6486002)(77096006)(6436002)(25786009)(50986999)(5660300001)(2906002)(3660700001)(3280700002)(6116002)(102836003)(2920100001)(55846006)(2930100002)(8936002)(86362001)(7736002)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR09MB1440; H:MWHPR09MB1440.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_E383CB0F6FDFB188B32A696BA2076B5A63E5AFE4unknown_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2017 12:23:38.0232 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR09MB1440 Archived-At: Subject: [IPsec] IETF 98 Meeting Change of Time and Location X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 12:23:42 -0000 --_000_E383CB0F6FDFB188B32A696BA2076B5A63E5AFE4unknown_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The IPsecME meeting at IETF 98 has been moved to a new day, time, and locat= ion. The meeting will be Wednesday, March 29 during the afternoon session 1 from= 13:00 to 15:00 CDT. We will be in room Montreux 3. Thanks, Dave --_000_E383CB0F6FDFB188B32A696BA2076B5A63E5AFE4unknown_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The IPsecME meeting at IETF 98 has been moved to a new day, time, and locat= ion.

The meeting will be Wednesday, March 29 during the afterno= on session 1 from 13:00 to 15:00 CDT. We will be in room Montreux 3.

Thanks,
Dave



--_000_E383CB0F6FDFB188B32A696BA2076B5A63E5AFE4unknown_-- From nobody Sun Mar 26 10:40:26 2017 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 AC5021205D3; Sun, 26 Mar 2017 10:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] 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 iKprLRwBeLV3; Sun, 26 Mar 2017 10:40:17 -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 A19391294D1; Sun, 26 Mar 2017 10:40:17 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vrkvM0K9Wz37r; Sun, 26 Mar 2017 19:40:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1490550015; bh=DmsX4n8X0bU8MKHnnXIlG0PDkqVU3SG1NacEwIbbulY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=jzTgsEvPs7asRherFCpUv0Wvz8gWqCW1iqnZ2EWNLhGglDGPh5WrqPHvIYQOPCIks IhTWDnwAFNE5ND7biQ0dkU1Zh8a0d2hg/h0Y/aNG7m/mtQcNsfJtrAAOg1YiyS3gm7 PJjR+18E0+RhnFH8DyZwXB4084zfwkgRBlAD+OME= 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 VPaeRZnGqKkk; Sun, 26 Mar 2017 19:40:13 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 26 Mar 2017 19:40:13 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id D52983943A0; Sun, 26 Mar 2017 13:40:12 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca D52983943A0 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CD7E540D358A; Sun, 26 Mar 2017 13:40:12 -0400 (EDT) Date: Sun, 26 Mar 2017 13:40:12 -0400 (EDT) From: Paul Wouters To: Daniel Migault cc: IPsecME WG , "lwip@ietf.org" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] Number of fixed SPI X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 17:40:20 -0000 On Fri, 24 Mar 2017, Paul Wouters wrote: > On Fri, 24 Mar 2017, Daniel Migault wrote: > >> I have a question regarding devices that are not able to randomly generate >> SPI, but instead >> store fix values.  The question is how much fix values could be >> provisioned. > > This is pretty dangerous. Half a year ago or so we saw the Transcript > Collsion Attacks that could have succeeded if we hadn't used random > SPI numbers to prevent pre-calculation in the attack. Using a set of 10 > non-random SPI numbers would potentially make this device vulnerable to > this attack. As Tero pointed out to me just now, those were IKE SPI's and not ESP SPI's to I guess there is no security issue here :) Paul From nobody Sun Mar 26 11:45:47 2017 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 0801612785F; Sun, 26 Mar 2017 11:45: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 AAY-rXB14l2j; Sun, 26 Mar 2017 11:45:39 -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 EB119124217; Sun, 26 Mar 2017 11:45: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 v2QIjYWO021384 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 26 Mar 2017 21:45:34 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v2QIjWUk012321; Sun, 26 Mar 2017 21:45:32 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <22744.3148.820880.102484@fireball.acr.fi> Date: Sun, 26 Mar 2017 21:45:32 +0300 From: Tero Kivinen To: Daniel Migault Cc: "lwip\@ietf.org" , IPsecME WG In-Reply-To: References: X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 6 min Archived-At: Subject: [IPsec] [Lwip] Number of fixed SPI X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Mar 2017 18:45:41 -0000 Daniel Migault writes: > For unicast communications, a single SPI can be used over multiple > nodes as long as the remote peer, as long as both nodes uses IP > addresses and SPI to index the SAs. With the transport mode, the > number of SPI is equivalent to the number of hosts, while with > tunnel mode, the number of SPI is equivalent to the number of > tunnels.=A0 For that reason I would recommend that a minimal > implementation supporting unicast only has as many SPI values as ESP > session per host or per security gateways, and that lookup includes > the IP addresses. >=20 > However this would not work with a security gateway that performs > lookup only based on the SPI. Such security gateway would still be > ESP.compliant. Does it sounds reasonable that security gateways > implements the longest match lookup or at least lookup considering > IP addresses =3F ESP SPI is allocated by the receiving host. It is up to the node receiving the ESP packets with SPI it gave out to decide how the SPI is allocated, and used. The sender can have multiple SAs going out each having same outbound SPI, and that does not cause any issues. The receiver will either have unique SPI for each Child SA, or it might use SPI with combination of the protocol number (AH or ESP), or it might even use the destination address (i.e., its own address or multicast address) etc. But there is no issues in there, as the node who does the receiving is also the same node who allocates the SPIs, so he can enforce his own rules on the SPI allocatons, and the other end does not need to know those rules. --=20 kivinen@iki.fi From nobody Tue Mar 28 09:16:53 2017 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 9AFFB1294A8 for ; Tue, 28 Mar 2017 09:16:51 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAGxRmdVSROe for ; Tue, 28 Mar 2017 09:16:49 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::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 9DE9512940E for ; Tue, 28 Mar 2017 09:16:48 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id 81so62622532pgh.2 for ; Tue, 28 Mar 2017 09:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q5Xnc7BfELiV8bEm1b0dIbBkDXECwSN4HJKnhKLuQVg=; b=Mtc72FTA0x5hj2R/J42XqDs+qlMkXpCR/JOrsvf6V6JHfnImfbUdpRBtuD+ML3KDTv PgC3X/fTRjiFipy7o+ARv6yCUlmW88bv/+VD5KWuhdUHsGzZIQ8HTPZvPfCYjXp9JPnD cQgXQc0gx6KrBoe11IMdqH95AGeZKekuckEHvuAkoRXmh3GDoAI5eWWqLjuIIlGwRGon 66VMSDax6RbZtnlXs01tNTIp5fOY9X1GjpVz5eG8hRtpOYlN9K60Pmmni3V//gx9QP4P LoRI8LEnXtQDTdKhcs0kQGNUUWipmdoZ52lhpxP7GM+Op1vSodFtU92B1/9r/sDD+8+J sSMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q5Xnc7BfELiV8bEm1b0dIbBkDXECwSN4HJKnhKLuQVg=; b=N3V0+mj+SHL4ePjUMu4SysSdJ6nJe/DARgis1s9yeVN0pmwGcva5dsGk1ZrPvSAJ2U rl4h6qKC2aqMYw12Ts30uNT7f6AmE0mJ6wRLEn4hajmvsJD9NsN0XMQL2eRH7W3I2v8v MTJMPSNMofCdl2tlO4wemaENqoXB5ezf8YWvdmmiuBelN2tDeGQZkgmv3s4iomkoLWC5 jCj6CM/w+SrrtFNjPBnYAEwBOWdfAWNsy5egV5LJ5zpe8j7BkCOU08ocYCf0Xj5jezVC TM1HS9Cd5qvfM4uAPNPRgzRXDzGTAc1Ug6zoOBtFO4xF2ocfIuXh0QJmJx7BWhpLBF0g UpjA== X-Gm-Message-State: AFeK/H3KhllshpEOqQyiWpRXzFGxmo2Nngo/BbdgyeJnKr5loZLQktmRPXoqJgQ5ySx2ZKAhUuwJqHPbssNOJA== X-Received: by 10.99.159.1 with SMTP id g1mr32046467pge.88.1490717808227; Tue, 28 Mar 2017 09:16:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.183.98 with HTTP; Tue, 28 Mar 2017 09:16:47 -0700 (PDT) In-Reply-To: <20E77229-492A-478B-8B92-7B963EAFC685@apple.com> References: <25B4F448-EB83-4CE6-8714-38AC0A98AA9A@apple.com> <20E77229-492A-478B-8B92-7B963EAFC685@apple.com> From: Kathleen Moriarty Date: Tue, 28 Mar 2017 12:16:47 -0400 Message-ID: To: Tommy Pauly Cc: "ipsec@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 16:16:52 -0000 Hi Tommy, Sorry I dropped the ball. I can start IETF last call, but since we are in IETF week, should it be extended a week? Thanks, Kathleen On Sun, Mar 12, 2017 at 3:11 PM, Tommy Pauly wrote: > Hi Kathleen, > > I've just posted a new version to fix some minor nits and add a reference > for the SHA-1 digest used for NAT detection: > https://www.ietf.org/id/draft-ietf-ipsecme-tcp-encaps-09.txt > > From my perspective, I think starting a IETF last call now make sense. > > Thanks! > Tommy > > On Mar 9, 2017, at 10:48 AM, Kathleen Moriarty > wrote: > > On Thu, Mar 9, 2017 at 12:47 PM, Tommy Pauly wrote: > > Hi Kathleen, > > Yes, this is referring to how the existing NAT detection works in IKEv2: > > https://tools.ietf.org/html/rfc7296 > > Section 2.23. NAT Traversal > > o The data associated with the NAT_DETECTION_SOURCE_IP notification > is a SHA-1 digest of the SPIs (in the order they appear in the > header), IP address, and port from which this packet was sent. > > We can add a pointer to the section of the RFC. > > > Great. Please let me know when that is done and I can start IETF last > call. Does the WG want me to start that right away or to wait until > after Chicago? I'm inclined to start it right away and have it on the > first telechat after. > > Thanks, > Kathleen > > > Thanks, > Tommy > > On Mar 9, 2017, at 9:39 AM, Kathleen Moriarty > wrote: > > Hello, > > Thank you for your work on draft-ietf-ipsecme-tcp-encaps. It's a well > written draft and I just have one question. > > Section 7: Why is SHA-1 used? If this is a result of the protocol and > prior RFCs, please include a reference. And an explanation on list > would be helpful (pointer is fine if this was already discussed. > > > > -- > > Best regards, > Kathleen > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > -- > > Best regards, > Kathleen > > -- Best regards, Kathleen From nobody Tue Mar 28 09:21:18 2017 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 CA2D5129671 for ; Tue, 28 Mar 2017 09:21:16 -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 EVSQhpCy_4YK for ; Tue, 28 Mar 2017 09:21:15 -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 1829812963F for ; Tue, 28 Mar 2017 09:21:13 -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 v2SGL3JC007994 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Mar 2017 19:21:03 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v2SGL3F1011673; Tue, 28 Mar 2017 19:21:03 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22746.36207.204899.788217@fireball.acr.fi> Date: Tue, 28 Mar 2017 19:21:03 +0300 From: Tero Kivinen To: Kathleen Moriarty Cc: Tommy Pauly , "ipsec\@ietf.org" In-Reply-To: References: <25B4F448-EB83-4CE6-8714-38AC0A98AA9A@apple.com> <20E77229-492A-478B-8B92-7B963EAFC685@apple.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 16:21:17 -0000 Kathleen Moriarty writes: > Sorry I dropped the ball. I can start IETF last call, but since we > are in IETF week, should it be extended a week? Yes, I think extending it by a week would be better. -- kivinen@iki.fi From nobody Tue Mar 28 09:25:26 2017 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 8FDE612944B; Tue, 28 Mar 2017 09:25:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk CC: ipsecme-chairs@ietf.org, Tero Kivinen , kivinen@iki.fi, ipsec@ietf.org, Kathleen.Moriarty.ietf@gmail.com, draft-ietf-ipsecme-tcp-encaps@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149071831749.1219.863787683067180572.idtracker@ietfa.amsl.com> Date: Tue, 28 Mar 2017 09:25:17 -0700 Archived-At: Subject: [IPsec] Last Call: (TCP Encapsulation of IKE and IPsec Packets) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 16:25:18 -0000 The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'TCP Encapsulation of IKE and IPsec Packets' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-04-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a 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 Security Association establishment and ESP packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Mar 28 15:43:58 2017 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 5350D127B57; Tue, 28 Mar 2017 15:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ey7jtiiybL2t; Tue, 28 Mar 2017 15:43:49 -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 0D145124234; Tue, 28 Mar 2017 15:43:49 -0700 (PDT) X-AuditID: c6180641-c3fff70000000a06-42-58daa0c92dec Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by (Symantec Mail Security) with SMTP id 50.A7.02566.9C0AAD85; Tue, 28 Mar 2017 19:43:40 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0339.000; Tue, 28 Mar 2017 18:43:44 -0400 From: Daniel Migault To: Jim Schaad , "curdle@ietf.org" CC: "saag@ietf.org" , "spasm@ietf.org" , "tls@ietf.org" , IPsecME WG Thread-Topic: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.txt Thread-Index: AQEf37CDGDDCSU9BXbxVbCIypDLQd6MQV6aggAAQoyA= Date: Tue, 28 Mar 2017 22:43:44 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118BB7D3A@eusaamb107.ericsson.se> References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> In-Reply-To: <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZXLonQffMglsRBlf/qlhsXTiL2WL19O9s Fvu3vGCzmNLfyWQx71qyxafzXYwObB4b50xn81iy5CdTAFMUl01Kak5mWWqRvl0CV8bMva+Z CmaJV7z5MI2xgfG1UBcjB4eEgIlEU6dJFyMXh5DABkaJ3YfPsEE4yxklju+/wNTFyMnBJmAk 0Xaonx3EFhHwkbjy4AwrSBGzQAujxIorPxlBEsICYRKzZ79ngygKlzjd+ZkFwraSmLd/CyuI zSKgKnHh2XdGkM28Ar4SU954QSxrYpS4crgZbA6ngIPErca5YIsZBcQkvp9aA2YzC4hL3Hoy H8yWEBCQWLLnPDOELSrx8vE/VghbSeLj7/nsEPU6Egt2f2KDsLUlli18DVbPKyAocXLmE5YJ jKKzkIydhaRlFpKWWUhaFjCyrGLkKC0uyMlNNzLcxAiMmmMSbI47GPf2eh5iFOBgVOLhVTC5 FSHEmlhWXJl7iFGCg1lJhHf+MqAQb0piZVVqUX58UWlOavEhRmkOFiVx3nflFyKEBNITS1Kz U1MLUotgskwcnFINjOsanG9H7tCr+HAwitn45eSlPqKHWv7UhyuH2VjdcGmW6cxYespAukhA xKd0ztH7NgIdAeoLOLdfzTl4bnpTcm4jx/vHuueYL89ZMXtK9butNncZzPfo/H9RsmfHnw13 jD/lbOg4NHfRFfufv24uyFCb2m7X3fF9rk3Ywy9eb/4nm4tfr+UzmqbEUpyRaKjFXFScCAAN fttwlgIAAA== Archived-At: Subject: Re: [IPsec] [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 22:43:51 -0000 Hi,=20 Thank you Jim for the update. Here is the version resulting from the discus= sion we had during the WG meeting yesterday. Please review the document an= d provide your feed backs by April 4 so we can move the draft to the IESG.= =20 Yours,=20 Daniel -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Tuesday, March 28, 2017 4:40 PM To: curdle@ietf.org Subject: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-0= 4.txt Here is the promised updated draft. Changes: 1. Fixed an example that David Benjamin found was wrong. (Incorrect sign = bit in public key.) 2. Remove all of the pre-hash text except to note that= it does exist. 3. No changes to the OID arc being used despite the agreement during the m= eeting. After the meeting, Russ, the chairs and I had a short talk and dec= ided that this did not need to occur. The problem was only with getting ne= w values assigned not with the current values which were already assigned. That should be the final issues in the draft Jim > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, March 28, 2017 4:31 PM > To: Jim Schaad ; Simon Josefsson=20 > > Subject: New Version Notification for draft-ietf-curdle-pkix-04.txt >=20 >=20 > A new version of I-D, draft-ietf-curdle-pkix-04.txt has been=20 > successfully submitted by Jim Schaad and posted to the IETF repository. >=20 > Name: draft-ietf-curdle-pkix > Revision: 04 > Title: Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for > use in the Internet X.509 Public Key Infrastructure > Document date: 2017-03-28 > Group: curdle > Pages: 15 > URL: https://www.ietf.org/internet-drafts/draft-ietf-curdle-pk= ix-04.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ > Htmlized: https://tools.ietf.org/html/draft-ietf-curdle-pkix-04 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-curdle-p= kix-04 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-pki= x-04 >=20 > Abstract: > This document specifies algorithm identifiers and ASN.1 encoding > formats for Elliptic Curve constructs using the Curve25519 and > Curve448 curves. The signature algorithms covered are Ed25519 and > Ed448. The key agreement algorithm covered are X25519 and X448. The > encoding for Public Key, Private Key and EdDSA digital signature > structures is provided. >=20 >=20 >=20 >=20 > 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.iet= f.org. >=20 > The IETF Secretariat _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Tue Mar 28 16:10:10 2017 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 AADDA129546 for ; Tue, 28 Mar 2017 16:10:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149074260869.1232.10896758156678744796.idtracker@ietfa.amsl.com> Date: Tue, 28 Mar 2017 16:10:08 -0700 From: IETF Secretariat Archived-At: Subject: [IPsec] Milestones changed for ipsecme WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 23:10:09 -0000 Changed milestone "IETF Last Call on cryptographic algorithms for ESP / AH", resolved as "Done". Changed milestone "IETF Last Call on TCP Encapsulation of IKE and IPsec", resolved as "Done". URL: https://datatracker.ietf.org/wg/ipsecme/about/ From nobody Tue Mar 28 20:49:49 2017 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 B26D5128D3E; Tue, 28 Mar 2017 20:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsolTJtcvntf; Tue, 28 Mar 2017 20:49:46 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 359B7127058; Tue, 28 Mar 2017 20:49:46 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id y18so43914982itc.1; Tue, 28 Mar 2017 20:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=CWkd6cums51+gRxINd/IXGGVMNf9sH9/tDNxS3VSqKs=; b=e2Bq9QIlcWxPUDR2iFzQlaq65eK2gGlIWT+OzWpndGAECWf6UwfMfaYCTicZFGNKRo nETaB6K8LW5UiDpPn/kBvqASfVis+tcsT7jwzJTIr6gLo4+6bD/VeTKr2DiDQPIHk0+p 96vRUvSgBFfAAqSl41Y2ssGXllly/dOESu0oAo45L4NTWY/EWmN0BgeMGNN0/ExNyn/g 2noZAHqXNfXQtQYfiO457XfGZWmML9mP82hp9ZmnARGlBaCV5whlb/r3T3AFKB9HTaaW btzyEZDYq3Li81RCQmd3/KnMXmR0FI+C1QMiQ/o0Mbbu7MRO4pyviTdjN1LPXNUuhj7T zZsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=CWkd6cums51+gRxINd/IXGGVMNf9sH9/tDNxS3VSqKs=; b=jM+jSH2HNuC5f5IzCotODcpNmJDzb9hY4loYC7LAarNUSSFSExeWWOodiKVk/r1eDi XVQEvfiawEMGwD2Fn0c1PkzYMYwugGONTGiwWOlxNNu+k3b5afaxdw5EpBaLTUeYh2xG RgaPSRlkJo2aHbFuAahHqAdJHAtvGUnlurGJauMVMXIxWREkDa9JsU5LtqtMKCTCZbPq WqV+HjS8Rhr0Q2BKW7/XcqIEIAxYxdI1u8IbwjnYjsRbnyaRS7NWE/c3Mu2+ypFGPwyh dzi/qeTB6ZCwxzA4i86mdNIqqTBdtT1pyZZuW68HCZK1rLYQFsnjB3Em9HcVHEgCHbgE nFpw== X-Gm-Message-State: AFeK/H3ZSTWdx5VluN/RdnmeyvnPlMYrlyZlBwq1wbT+kR6oMMrsQTuDS5XovPXpRwgY9YBZmGEQsuBSMHDrSw== X-Received: by 10.107.168.21 with SMTP id r21mr29006593ioe.45.1490759385664; Tue, 28 Mar 2017 20:49:45 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.35.213 with HTTP; Tue, 28 Mar 2017 20:49:45 -0700 (PDT) In-Reply-To: <22744.3148.820880.102484@fireball.acr.fi> References: <22744.3148.820880.102484@fireball.acr.fi> From: Daniel Migault Date: Tue, 28 Mar 2017 22:49:45 -0500 X-Google-Sender-Auth: u2rz2Js_vcQXIor4so0AisDF2TY Message-ID: To: Tero Kivinen Cc: IPsecME WG , "lwip@ietf.org" Content-Type: multipart/alternative; boundary=001a114215e8a0d237054bd67711 Archived-At: Subject: Re: [IPsec] [Lwip] Number of fixed SPI X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 03:49:49 -0000 --001a114215e8a0d237054bd67711 Content-Type: text/plain; charset=UTF-8 Thank you for the clarification. My initial problem was if multiple nodes connects with the same SPI to a gateway, does the gateway needs some specific ways to lookup. As mentioned by Tero, this is not the case as the SPI is not used for inbound traffic by the gateway. The limitation due to a limited number of SPI are on the node side.Thanks! On Sun, Mar 26, 2017 at 1:45 PM, Tero Kivinen wrote: > Daniel Migault writes: > > For unicast communications, a single SPI can be used over multiple > > nodes as long as the remote peer, as long as both nodes uses IP > > addresses and SPI to index the SAs. With the transport mode, the > > number of SPI is equivalent to the number of hosts, while with > > tunnel mode, the number of SPI is equivalent to the number of > > tunnels. For that reason I would recommend that a minimal > > implementation supporting unicast only has as many SPI values as ESP > > session per host or per security gateways, and that lookup includes > > the IP addresses. > > > > However this would not work with a security gateway that performs > > lookup only based on the SPI. Such security gateway would still be > > ESP.compliant. Does it sounds reasonable that security gateways > > implements the longest match lookup or at least lookup considering > > IP addresses ? > > ESP SPI is allocated by the receiving host. It is up to the node > receiving the ESP packets with SPI it gave out to decide how the SPI > is allocated, and used. > > The sender can have multiple SAs going out each having same outbound > SPI, and that does not cause any issues. The receiver will either have > unique SPI for each Child SA, or it might use SPI with combination of > the protocol number (AH or ESP), or it might even use the destination > address (i.e., its own address or multicast address) etc. > > But there is no issues in there, as the node who does the receiving > is also the same node who allocates the SPIs, so he can enforce his > own rules on the SPI allocatons, and the other end does not need to > know those rules. > -- > kivinen@iki.fi > > _______________________________________________ > Lwip mailing list > Lwip@ietf.org > https://www.ietf.org/mailman/listinfo/lwip > --001a114215e8a0d237054bd67711 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you for the clarification. My initial problem was if= multiple nodes connects with the same SPI to a gateway, does the gateway n= eeds some specific ways to lookup. As mentioned by Tero, this is not the ca= se as the SPI is not used for inbound traffic by the gateway. The limitatio= n due to a limited number of SPI are on the node side.Thanks!=C2=A0 =C2=A0 =

On Sun,= Mar 26, 2017 at 1:45 PM, Tero Kivinen <kivinen@iki.fi> wrote:<= br>
Daniel Migault writes: > For unicast communications, a single SPI can be used over multiple
> nodes as long as the remote peer, as long as both nodes uses IP
> addresses and SPI to index the SAs. With the transport mode, the
> number of SPI is equivalent to the number of hosts, while with
> tunnel mode, the number of SPI is equivalent to the number of
> tunnels.=C2=A0 For that reason I would recommend that a minimal
> implementation supporting unicast only has as many SPI values as ESP > session per host or per security gateways, and that lookup includes > the IP addresses.
>
> However this would not work with a security gateway that performs
> lookup only based on the SPI. Such security gateway would still be
> ESP.compliant. Does it sounds reasonable that security gateways
> implements the longest match lookup or at least lookup considering
> IP addresses ?

ESP SPI is allocated by the receiving host. It is up to the node
receiving the ESP packets with SPI it gave out to decide how the SPI
is allocated, and used.

The sender can have multiple SAs going out each having same outbound
SPI, and that does not cause any issues. The receiver will either have
unique SPI for each Child SA, or it might use SPI with combination of
the protocol number (AH or ESP), or it might even use the destination
address (i.e., its own address or multicast address) etc.

But there is no issues in there, as the node who does the receiving
is also the same node who allocates the SPIs, so he can enforce his
own rules on the SPI allocatons, and the other end does not need to
know those rules.
--
kivinen@iki.fi

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

--001a114215e8a0d237054bd67711-- From nobody Wed Mar 29 08:52:17 2017 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 B3CE9126557 for ; Wed, 29 Mar 2017 08:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtiaWzQbIpOI for ; Wed, 29 Mar 2017 08:52:07 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 0AA5512985A for ; Wed, 29 Mar 2017 08:52:07 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id 68so3948489itx.0 for ; Wed, 29 Mar 2017 08:52:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=6dzsgZUrLntB9Mk+9jcpgyPXeVCTdGGWRIQa1Dn+dPw=; b=LVmvORdIQJQVww/tEsNK4/Qj0VsESLhvhKNNEXqH82/iuSvqV0K6VsxBZqnghk6Box N3gew0fkQysj84MIdfqFKnmt03PFggAQObA4BeTbGBfd0zfgIQmJDVSK0s7gEnW3QfZF gdw6mVh3e/pvQd+qvuTLEWdTRcMpwRvxHnK5CBWxaMnT4ADl4BqeZgiX6/f1yizSIJd9 IQP4PLRhapg3BuwCwNCk1HSzatlOUh2YlzgkE6N11q3y4QIWlnc9P5zF10+eFAaK48v+ oTj/+Qogzi1x7Wtu4Vs6RfC/HL4yt7vRWwiZ+QJnyIaLeJ6DuYfexE1xU5dZiltbic4Q 2xEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=6dzsgZUrLntB9Mk+9jcpgyPXeVCTdGGWRIQa1Dn+dPw=; b=AJKWVsbb/WW4dJqDhbAO+YYH8cBPIMF8ZX8Yl6dS0B74oWi8A/OJO+FPSjSAc4umfd hdoAxPIHVTv7fTLJJUWVTsv4BIegmRwSNEl38BBHrZ6Itgs13FuJ8hADQ2LTmSaqJ9Ze youXschp+seDxjYxHatRrt9V89PJB6OBE/0kK+EvmLY9jqYIl1Np+Jk/cBB44vQthTpd kyTBiMUFfJWa+ZqvqusMLiYXjjFMbZ6xGIXBWX1uyhUyojH+ddn+P8ETP/0ObbsbMuds SDElGsm5xFNewc/M7MjLDXfOxXn19fS1fctbvDw1+sJQ/NsMfwaVfRi5H847dEwNuJ+q TsMw== X-Gm-Message-State: AFeK/H2Kujh9fklYaSBor5fy0TMzopk7XDWIXwPl8DZT7VYEVxa/QGXFfwVGyYT8LFl3t1Rmt+vC1YEzi3/P+w== X-Received: by 10.36.206.6 with SMTP id v6mr1460920itg.48.1490802726160; Wed, 29 Mar 2017 08:52:06 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.35.213 with HTTP; Wed, 29 Mar 2017 08:52:05 -0700 (PDT) In-Reply-To: References: From: Daniel Migault Date: Wed, 29 Mar 2017 10:52:05 -0500 X-Google-Sender-Auth: rj4SF1GGQFDtUEI57Lb2I5A_Jgo Message-ID: To: Eric Rescorla Cc: Yoav Nir , "ipsec@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0b0c58ec4ff3054be08ec5 Archived-At: Subject: Re: [IPsec] Comments on draft-mglt-ipsecme-implicit-iv-02.tx X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 15:52:11 -0000 --94eb2c0b0c58ec4ff3054be08ec5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Eric, Thank you for the review and comments. Do you have any preference on what we should cite for the chosen clear text attack?: Our local version currently refers to Security Consideration of RFC3602. The sentence in the terminology section mentioning that IV are usually unpredictable has been removed. Thanks for catching that. Yours, Daniel On Sun, Mar 19, 2017 at 2:05 PM, Eric Rescorla wrote: > > > On Sun, Mar 19, 2017 at 11:52 AM, Yoav Nir wrote: > >> >> On 19 Mar 2017, at 19:30, Eric Rescorla wrote: >> >> >> >> On Sun, Mar 19, 2017 at 10:23 AM, Yoav Nir wrote: >> >>> >>> On 19 Mar 2017, at 16:55, Eric Rescorla wrote: >>> >>> Overall: >>> I notice that you are using a construction different from that used >>> in TLS 1.3, which doesn't directly repeat nonces across associations. >>> >>> I didn't see an answer to this. >> >> >> Nonces are specified as 64-bit IV (usually counter and we are forcing it >> to be a counter) plus 32-bit salt in RFC 4106. We saw no reason to chan= ge >> that. >> > > OK. This has a somewhat lower margin of safety than the TLS 1.3 > construction, but it should be OK. > > > S 2. >>> This document does not consider AES-CBC ([RFC3602])as AES-CBC >>> requires the IV to be unpredictable. Deriving it directly from the >>> packet counter as described below is insecure. >>> >>> Can you provide a cite for this? >>> >>> >>> Even RFC 3602 requires that the IV be randomly generated (and for good >>> measure requires that it be unpredictable) >>> >> >> That's just a cite to a requirement, not to it being insecure. Do you >> have a citation to the relevant threat? >> >> >> We could cite BEAST. Of course BEAST depends on HTTPS, so it=E2=80=99s n= ot really >> applicable - it=E2=80=99s harder to manipulate the first 16 bytes of the= IP header >> - but these have been the recommendations for using CBC in both RFCs and >> NIST documentations for years before BEAST. >> > > Sure. I just think claims like this should have a citation. > > > -Ekr > > >> In any case, note that there are >>> straightforward algorithms for deriving a CBC IV from a counter >>> (e.g., run AES in counter mode with a different key). That structure >>> would actually be suitable for GCM as well (and would address >>> my point above). >>> >>> >>> If each implementation generates a random key and uses this to generate >>> the IVs this is fine, but you still have to transmit the IV. If we der= ive >>> an =E2=80=9CIV key=E2=80=9D from the keying material, then we don=E2=80= =99t have to transmit the >>> IV. >>> >> >> You generate the IV from the sequence number, so you don't need to >> transmit the IV. >> That gives you an unpredictable IV without the per-packet overhead. >> >> >> We did bring this idea up at a WG meeting. This was not well-received fo= r >>> three reasons: (1) it=E2=80=99s unnecessarily complicated. (2) The worl= d is going >>> to AEAD. AES-CBC is the past, and (3) The perception was that saving 8 >>> bytes per packet was important mostly for IoT, and they don=E2=80=99t c= are about >>> CBC. >>> >> >> Sure, that's reasonable. I'm merely observing that there are designs >> which work for CBC. >> >> >> S 3. >>> o IV: Initialization Vector. Although security requirements vary, >>> the common usage of this term implies that the value is >>> unpredictable. >>> >>> I don't think that this is true at all. I've frequently heard of a >>> zero IV. It's also odd in that your IV is in fact predictable. >>> >>> >>> S 5. >>> I'm a bit surprised that you are deciding to have duplicate >>> code points for every algorithm rather than some sort of IKE >>> negotiation payload. I see that the WG is currently defining >>> other extensions where you take that approach. >>> >>> >>> See slide #7 of https://www.ietf.org/procee >>> dings/96/slides/slides-96-ipsecme-0.pdf >>> >>> The problem is that IKEv2 has strict rules about unexpected attributes >>> in the substructures of the SA payload. The sense of the room was to go >>> with new identifiers. >>> >> >> OK. Well, I agree it's ultimately a WG decision, but it doesn't seem ver= y >> elegant. >> >> >> I was in the rough on this at first, but it was shown that every >> alternate negotiation mechanism had unwanted consequences. >> >> Yoav >> >> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --94eb2c0b0c58ec4ff3054be08ec5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Eric,

Thank you=C2=A0 for = the review and comments. Do you have any preference on what we should cite = for the chosen clear text attack?: Our local version currently refers to Se= curity Consideration of RFC3602.

The sentence in the term= inology section mentioning that IV are usually unpredictable has been remov= ed. Thanks for catching that.=C2=A0

Yours,
Daniel=C2=A0 =C2=A0

On Sun, Mar 19, 2017 at 2:05 PM, Eric Rescorla <ekr@rtfm.com= > wrote:
<= br>

On Sun, Mar 19, 2017 at 11:52 AM, Yoav Nir <ynir.ietf@gmail.com&g= t; wrote:

On 19 Mar 2017, a= t 19:30, Eric Rescorla <ekr@rtfm.com> wrote:



On Sun, Mar 19, 2017 at 10:23 AM, Yoav Nir=C2=A0<ynir.iet= f@gmail.com>=C2=A0wrote:

On 19 Mar 2017, at 16:55, Eric Rescorla <ekr@rtfm.com> wrote:

Overall:
I notice t= hat you are using a construction different from that used
in TLS = 1.3, which doesn't directly repeat nonces across associations.
I didn't see= an answer to this.

Non= ces are specified as 64-bit IV (usually counter and we are forcing it to be= a counter) plus 32-bit salt in RFC 4106.=C2=A0 We saw no reason to change = that.

OK. This has a som= ewhat lower margin of safety than the TLS 1.3 construction, but it should b= e OK.
=C2=A0

S 2.
=C2=A0 =C2=A0This document does not consider AES-CBC ([RF= C3602])as AES-CBC
=C2=A0 =C2=A0requires the IV to be unpredictabl= e.=C2=A0 Deriving it directly from the
=C2=A0 =C2=A0packet counte= r as described below is insecure.

Can you provide = a cite for this?

Even R= FC 3602 requires that the IV be randomly generated (and for good measure re= quires that it be unpredictable)

That's just a cite to a requirement, not to it being insecure. Do you= have a citation to the relevant threat?

<= /div>We could cite BEAST. Of course BEAST depends on HTTPS, so it=E2= =80=99s not really applicable - it=E2=80=99s harder to manipulate the first= 16 bytes of the IP header - but these have been the recommendations for us= ing CBC in both RFCs and NIST documentations for years before BEAST.=C2=A0<= /div>

Sure. I just think claim= s like this should have a citation.
=C2=A0

-Ekr
<= div>
=C2=A0
<= div style=3D"word-wrap:break-word">
In any case, n= ote that there are
straightforward algorithms for deriving a CBC = IV from a counter
(e.g., run AES in counter mode with a different= key). That structure
would actually be suitable for GCM as well = (and would address
my point above).

If each implementation generates a random key and us= es this to generate the IVs this is fine, but you still have to transmit th= e IV.=C2=A0 If we derive an =E2=80=9CIV key=E2=80=9D from the keying materi= al, then we don=E2=80=99t have to transmit the IV.=C2=A0

You generate the IV from the sequence number, so = you don't need to transmit the IV.
That gives you an unpr= edictable IV without the per-packet overhead.


=
We did brin= g this idea up at a WG meeting. This was not well-received for three reason= s: (1) it=E2=80=99s unnecessarily complicated. (2) The world is going to AE= AD. AES-CBC is the past, and (3) The perception was that saving 8 bytes per= packet was important mostly for IoT, and they don=E2=80=99t care about CBC= .

Sure, that's reasonable. = I'm merely observing that there are designs which work for CBC.


S 3.<= /div>
=C2=A0 =C2=A0o =C2=A0IV: Initialization Vector.=C2=A0 Although se= curity requirements vary,
=C2=A0 =C2=A0 =C2=A0=C2=A0= the common usage of this term implies that the value is
=C2=A0 = =C2=A0 =C2=A0=C2=A0unpredictable.

I d= on't think that this is true at all. I've frequently heard of a
zero IV. It's also odd in that your IV is in fact predictable.


S 5.
I'm a bit surpris= ed that you are deciding to have duplicate
code points for every = algorithm rather than some sort of IKE
negotiation payload. I see= that the WG is currently defining
other extensions where you tak= e that approach.

= See slide #7 of=C2=A0https://www.ietf.org/procee= dings/96/slides/slides-96-ipsecme-0.pdf

The pro= blem is that IKEv2 has strict rules about unexpected attributes in the subs= tructures of the SA payload. The sense of the room was to go with new ident= ifiers.

OK. Well, I agree it= 9;s ultimately a WG decision, but it doesn't seem very elegant.

I was in the rough on this at first,= but it was shown that every alternate negotiation mechanism had unwanted c= onsequences.

Yoav



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


--94eb2c0b0c58ec4ff3054be08ec5-- From nobody Wed Mar 29 08:54:58 2017 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 D88FB12941A for ; Wed, 29 Mar 2017 08:54:56 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_UinLEFp93J for ; Wed, 29 Mar 2017 08:54:53 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F30B8126D74 for ; Wed, 29 Mar 2017 08:54:52 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id d191so13709371ywe.2 for ; Wed, 29 Mar 2017 08:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZR0TsRcnMoxyXkU7IwZtWwxYVK2nODeMM1j5JnDioN8=; b=JgNYI/rIJabOgFyPxpwCU21ox1exiPX3v94YjiPlvrTb2VPSQXJ77lD7nSR1jgRX8J 0WKec4sRUtQrBah/gS4lHf/87j6BPvRTWFpJzHdOTM1WEJ/LC6QwfVHTGcZhsZa9+yoa mkroFBi0wRlURYeJXK1CtKKnD5vV2oDyv8uOZx63Uxg3ZoJO/Gpo4S7HfgOhtbiYijBm DOp3su3piGn2XcmG+nogkVV0gi9h8DQ8fiMN8IDIwzc2rcTgPAhw4cVqGk1nYp2bQzPP dI5hx79hvuxQClEip7xHzo3eY7Z/uztVRBuYIVugSMdZpPrK1ZCc0M7IsWP+ADTjvMtQ Htxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZR0TsRcnMoxyXkU7IwZtWwxYVK2nODeMM1j5JnDioN8=; b=I2d3iylQ/bwSWwa+eDXIQr/29B1qiHeWRPG8FgConssSWVjsJCL4aO2l2GbEIBhkAD T6Z6CK2Zap1z4BDwDeZIUJo+uW2QQxtEJrmyoy14bHkfasF36+Te2BKV4Awe36wrA4xc nWkZ9QEc7/GfTAlxqcXKnTtaqQbNHpflUfRYoUGuwLLcqzHzZcPQSSwobuVsro3Pyk8Q rJaAWxHHqa0ZapiPLJvkhWRU8A/LPMK+B/oa1wZ7fX67aiy+YQo9HD31Z/7z4rA5T2B2 3k+xRFODY8DnMLFrab2EnJXxqeT1NkMfqoFBBrh04a/N1FHzzxpl0Km+K82onEqml1uM +eBA== X-Gm-Message-State: AFeK/H0U+8qvh4Vc+k7QSzobMF4EIIs3BK2aEapErqkDAe94uH8t0vu2FV5gXUdvZwSOZopAbLU572B/c7nPJQ== X-Received: by 10.129.125.5 with SMTP id y5mr985577ywc.120.1490802892098; Wed, 29 Mar 2017 08:54:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Wed, 29 Mar 2017 08:54:11 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 29 Mar 2017 10:54:11 -0500 Message-ID: To: Daniel Migault Cc: Yoav Nir , "ipsec@ietf.org" Content-Type: multipart/alternative; boundary=001a11493644d05f6b054be098a8 Archived-At: Subject: Re: [IPsec] Comments on draft-mglt-ipsecme-implicit-iv-02.tx X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 15:54:57 -0000 --001a11493644d05f6b054be098a8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think Yoav's suggestion to cite BEAST as evidence that predictable IVs are bad is a good plan. -Ekr On Wed, Mar 29, 2017 at 10:52 AM, Daniel Migault < daniel.migault@ericsson.com> wrote: > Hi Eric, > > Thank you for the review and comments. Do you have any preference on wha= t > we should cite for the chosen clear text attack?: Our local version > currently refers to Security Consideration of RFC3602. > > The sentence in the terminology section mentioning that IV are usually > unpredictable has been removed. Thanks for catching that. > > Yours, > Daniel > > On Sun, Mar 19, 2017 at 2:05 PM, Eric Rescorla wrote: > >> >> >> On Sun, Mar 19, 2017 at 11:52 AM, Yoav Nir wrote: >> >>> >>> On 19 Mar 2017, at 19:30, Eric Rescorla wrote: >>> >>> >>> >>> On Sun, Mar 19, 2017 at 10:23 AM, Yoav Nir wrote: >>> >>>> >>>> On 19 Mar 2017, at 16:55, Eric Rescorla wrote: >>>> >>>> Overall: >>>> I notice that you are using a construction different from that used >>>> in TLS 1.3, which doesn't directly repeat nonces across associations. >>>> >>>> I didn't see an answer to this. >>> >>> >>> Nonces are specified as 64-bit IV (usually counter and we are forcing i= t >>> to be a counter) plus 32-bit salt in RFC 4106. We saw no reason to cha= nge >>> that. >>> >> >> OK. This has a somewhat lower margin of safety than the TLS 1.3 >> construction, but it should be OK. >> >> >> S 2. >>>> This document does not consider AES-CBC ([RFC3602])as AES-CBC >>>> requires the IV to be unpredictable. Deriving it directly from the >>>> packet counter as described below is insecure. >>>> >>>> Can you provide a cite for this? >>>> >>>> >>>> Even RFC 3602 requires that the IV be randomly generated (and for good >>>> measure requires that it be unpredictable) >>>> >>> >>> That's just a cite to a requirement, not to it being insecure. Do you >>> have a citation to the relevant threat? >>> >>> >>> We could cite BEAST. Of course BEAST depends on HTTPS, so it=E2=80=99s = not >>> really applicable - it=E2=80=99s harder to manipulate the first 16 byte= s of the IP >>> header - but these have been the recommendations for using CBC in both = RFCs >>> and NIST documentations for years before BEAST. >>> >> >> Sure. I just think claims like this should have a citation. >> >> >> -Ekr >> >> >>> In any case, note that there are >>>> straightforward algorithms for deriving a CBC IV from a counter >>>> (e.g., run AES in counter mode with a different key). That structure >>>> would actually be suitable for GCM as well (and would address >>>> my point above). >>>> >>>> >>>> If each implementation generates a random key and uses this to generat= e >>>> the IVs this is fine, but you still have to transmit the IV. If we de= rive >>>> an =E2=80=9CIV key=E2=80=9D from the keying material, then we don=E2= =80=99t have to transmit the >>>> IV. >>>> >>> >>> You generate the IV from the sequence number, so you don't need to >>> transmit the IV. >>> That gives you an unpredictable IV without the per-packet overhead. >>> >>> >>> We did bring this idea up at a WG meeting. This was not well-received >>>> for three reasons: (1) it=E2=80=99s unnecessarily complicated. (2) The= world is >>>> going to AEAD. AES-CBC is the past, and (3) The perception was that sa= ving >>>> 8 bytes per packet was important mostly for IoT, and they don=E2=80=99= t care about >>>> CBC. >>>> >>> >>> Sure, that's reasonable. I'm merely observing that there are designs >>> which work for CBC. >>> >>> >>> S 3. >>>> o IV: Initialization Vector. Although security requirements vary, >>>> the common usage of this term implies that the value is >>>> unpredictable. >>>> >>>> I don't think that this is true at all. I've frequently heard of a >>>> zero IV. It's also odd in that your IV is in fact predictable. >>>> >>>> >>>> S 5. >>>> I'm a bit surprised that you are deciding to have duplicate >>>> code points for every algorithm rather than some sort of IKE >>>> negotiation payload. I see that the WG is currently defining >>>> other extensions where you take that approach. >>>> >>>> >>>> See slide #7 of https://www.ietf.org/procee >>>> dings/96/slides/slides-96-ipsecme-0.pdf >>>> >>>> The problem is that IKEv2 has strict rules about unexpected attributes >>>> in the substructures of the SA payload. The sense of the room was to g= o >>>> with new identifiers. >>>> >>> >>> OK. Well, I agree it's ultimately a WG decision, but it doesn't seem >>> very elegant. >>> >>> >>> I was in the rough on this at first, but it was shown that every >>> alternate negotiation mechanism had unwanted consequences. >>> >>> Yoav >>> >>> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> > --001a11493644d05f6b054be098a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think Yoav's suggestion to cite BEAST as evidence th= at predictable IVs are bad is a good plan.

-Ekr


On Wed, Mar 29, 2017 at 10:52 AM, Daniel Migault <daniel.migaul= t@ericsson.com> wrote:
Hi Eric,

Thank you=C2=A0 for the = review and comments. Do you have any preference on what we should cite for = the chosen clear text attack?: Our local version currently refers to Securi= ty Consideration of RFC3602.

The sentence in the terminol= ogy section mentioning that IV are usually unpredictable has been removed. = Thanks for catching that.=C2=A0

Yours,
D= aniel=C2=A0 =C2=A0

On Sun, Mar 19, 2017 at 2:05 PM, Eric Re= scorla <ekr@rtfm.com> wrote:


On Sun, Mar 19, 2017 at 11:52 AM= , Yoav Nir <ynir.ietf@gmail.com> wrote:

On 19 Mar 2017, at 19:30, Eric Rescorla <ekr@rtfm.com> wrote:


On Sun, Mar 19, 2017 at 10:23 AM, Yoav Nir=C2=A0<ynir.ietf@gmail.com>=C2=A0wrote:

On 19 Mar 2017= , at 16:55, Eric Rescorla <ekr@rtfm.com> wrote:

Overall:
I notice tha= t you are using a construction different from that used
in TLS 1.= 3, which doesn't directly repeat nonces across associations.
I didn't see a= n answer to this.

Nonce= s are specified as 64-bit IV (usually counter and we are forcing it to be a= counter) plus 32-bit salt in RFC 4106.=C2=A0 We saw no reason to change th= at.

OK. This has a somew= hat lower margin of safety than the TLS 1.3 construction, but it should be = OK.
=C2=A0

S 2.
=
=C2=A0 =C2=A0This document does not consider AES-CBC ([RFC3602])as AES= -CBC
=C2=A0 =C2=A0requires the IV to be unpredictable.=C2=A0 Deri= ving it directly from the
=C2=A0 =C2=A0packet counter as describe= d below is insecure.

Can you provide a cite for th= is?

Even RFC 3602 requi= res that the IV be randomly generated (and for good measure requires that i= t be unpredictable)

That's = just a cite to a requirement, not to it being insecure. Do you have a citat= ion to the relevant threat?

W= e could cite BEAST. Of course BEAST depends on HTTPS, so it=E2=80=99s not r= eally applicable - it=E2=80=99s harder to manipulate the first 16 bytes of = the IP header - but these have been the recommendations for using CBC in bo= th RFCs and NIST documentations for years before BEAST.=C2=A0

Sure. I just think claims like this s= hould have a citation.
=C2=A0

-Ekr
=C2=A0
In any = case, note that there are
straightforward algorithms for deriving= a CBC IV from a counter
(e.g., run AES in counter mode with a di= fferent key). That structure
would actually be suitable for GCM a= s well (and would address
my point above).

If each implementation generates a random key= and uses this to generate the IVs this is fine, but you still have to tran= smit the IV.=C2=A0 If we derive an =E2=80=9CIV key=E2=80=9D from the keying= material, then we don=E2=80=99t have to transmit the IV.=C2=A0
=

You generate the IV from the sequence numb= er, so you don't need to transmit the IV.
That gives you = an unpredictable IV without the per-packet overhead.


We d= id bring this idea up at a WG meeting. This was not well-received for three= reasons: (1) it=E2=80=99s unnecessarily complicated. (2) The world is goin= g to AEAD. AES-CBC is the past, and (3) The perception was that saving 8 by= tes per packet was important mostly for IoT, and they don=E2=80=99t care ab= out CBC.

Sure, that's reaso= nable. I'm merely observing that there are designs which work for CBC.<= /div>


S 3.
=C2=A0 =C2=A0o =C2=A0IV: Initialization Vector.=C2=A0 Alt= hough security requirements vary,
=C2=A0 =C2=A0 =C2=A0=C2=A0the common usage of this term implies that the= value is
=C2=A0 =C2=A0 =C2=A0=C2=A0unpredictable.

I don't think that this is= true at all. I've frequently heard of a
zero IV. It's al= so odd in that your IV is in fact predictable.

S 5.
I'm a bit surprised that you are deciding to= have duplicate
code points for every algorithm rather than some = sort of IKE
negotiation payload. I see that the WG is currently d= efining
other extensions where you take that approach.

See slide #7 of=C2=A0https://www.ietf.org/proceedings/96/slides/slides-96-i= psecme-0.pdf

The problem is that IKEv2 has stri= ct rules about unexpected attributes in the substructures of the SA payload= . The sense of the room was to go with new identifiers.

OK. Well, I agree it's ultimately a WG decisio= n, but it doesn't seem very elegant.

<= /div>I was in the rough on this at first, but it was shown that ever= y alternate negotiation mechanism had unwanted consequences.

Yoav



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



--001a11493644d05f6b054be098a8-- From nobody Wed Mar 29 09:08:03 2017 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 918761296F3 for ; Wed, 29 Mar 2017 09:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZI8H-zkYIa4z for ; Wed, 29 Mar 2017 09:07:58 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 82C7A127201 for ; Wed, 29 Mar 2017 09:07:58 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id e75so96546205itd.1 for ; Wed, 29 Mar 2017 09:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=1uVDXD/15aLtUvoo0O0T2rPrnDH7FqsUKrs8c8m2Vno=; b=tQjH+FB350Sr+Ns8PkY+mrnqw6x+T5mAIWcLT6WNNXEhzM7MHciH1K7EzIXJXZ3+w3 eVB1nU2aVcL5hjFhukmTwj+9ZR0anUSE8t3mbmmPhcVzBQPPoFafJWOOQnI5yBMy5IZX 1r0T4H9qRWyBAxKSMYIeDyDsQhFOgJSmHhP6F6RFzg6uT4pKqzI88p0n/gkUhHfhwt9T LvHae2XgvilwD1eOFQsK5unfvSUqCVPDF6lHQF3Ru1dr8SM8Nr5lwdjppQ/qU2AaxUsy mj5XqJyCsPRa3wYhNor+PNSpsSlO8UcntmdLcX8NmHlN+MQBkIbVgEEB/jbIU/GfurNr K5gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=1uVDXD/15aLtUvoo0O0T2rPrnDH7FqsUKrs8c8m2Vno=; b=s06C6qywPrSr1e/0CYM23FFs//UG77a5CpemYFkVddbBfIdB0mRa/rCHzzr8iq3QWQ SopBYKWecVQIJDcWOMTFqdcI/c+6DFD1ecMqjEhdUz5rq9dAwhOqQovi1cEUvydVtNdL nl1JdJupKlB75RxktwIvMmRC/lp2Z7b6uoz9MEQbVQeBVqMKWYne/l1oQ8njEIHxzD7u Kl4UcGdR3c4nDrn8YUBH76MUiKhZtYdGbmEfQhkU/1uiAEycbTG2sNjCoJld3fAhcsQk b+tE+r/qBRnP4yiSWdTxfG5g43mWfr4wrTzqkT7zuZT/POkEsGMjj7V0Xz1+ylxxc38W EoZg== X-Gm-Message-State: AFeK/H3ZanZXIlV5dG8WgYGDkTXUwQ3O1uNwfeQsU/xTva22wlinKyri/gMYLwuFlqsjLrTXSPWuoyp9nikIqQ== X-Received: by 10.36.189.134 with SMTP id x128mr1914281ite.48.1490803677854; Wed, 29 Mar 2017 09:07:57 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.35.213 with HTTP; Wed, 29 Mar 2017 09:07:57 -0700 (PDT) In-Reply-To: References: From: Daniel Migault Date: Wed, 29 Mar 2017 11:07:57 -0500 X-Google-Sender-Auth: a_0mIh8LUX1e-QEdeNnr1K9sHbY Message-ID: To: Eric Rescorla Cc: "ipsec@ietf.org" , Yoav Nir Content-Type: multipart/alternative; boundary=94eb2c0e4166a60d85054be0c705 Archived-At: Subject: Re: [IPsec] Comments on draft-mglt-ipsecme-implicit-iv-02.tx X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 16:08:02 -0000 --94eb2c0e4166a60d85054be0c705 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am planning to add this reference.Let me know if you prefer another reference. Rizzo, J. and T. Duong. "Here come the xor ninjas", 2011. http://netifera.com/research/beast/beast_DRAFT_0621.pdf. Thanks for the feed back. Yours, Daniel On Wed, Mar 29, 2017 at 10:54 AM, Eric Rescorla wrote: > I think Yoav's suggestion to cite BEAST as evidence that predictable IVs > are bad is a good plan. > > -Ekr > > > On Wed, Mar 29, 2017 at 10:52 AM, Daniel Migault < > daniel.migault@ericsson.com> wrote: > >> Hi Eric, >> >> Thank you for the review and comments. Do you have any preference on >> what we should cite for the chosen clear text attack?: Our local version >> currently refers to Security Consideration of RFC3602. >> >> The sentence in the terminology section mentioning that IV are usually >> unpredictable has been removed. Thanks for catching that. >> >> Yours, >> Daniel >> >> On Sun, Mar 19, 2017 at 2:05 PM, Eric Rescorla wrote: >> >>> >>> >>> On Sun, Mar 19, 2017 at 11:52 AM, Yoav Nir wrote: >>> >>>> >>>> On 19 Mar 2017, at 19:30, Eric Rescorla wrote: >>>> >>>> >>>> >>>> On Sun, Mar 19, 2017 at 10:23 AM, Yoav Nir wrote= : >>>> >>>>> >>>>> On 19 Mar 2017, at 16:55, Eric Rescorla wrote: >>>>> >>>>> Overall: >>>>> I notice that you are using a construction different from that used >>>>> in TLS 1.3, which doesn't directly repeat nonces across associations. >>>>> >>>>> I didn't see an answer to this. >>>> >>>> >>>> Nonces are specified as 64-bit IV (usually counter and we are forcing >>>> it to be a counter) plus 32-bit salt in RFC 4106. We saw no reason to >>>> change that. >>>> >>> >>> OK. This has a somewhat lower margin of safety than the TLS 1.3 >>> construction, but it should be OK. >>> >>> >>> S 2. >>>>> This document does not consider AES-CBC ([RFC3602])as AES-CBC >>>>> requires the IV to be unpredictable. Deriving it directly from th= e >>>>> packet counter as described below is insecure. >>>>> >>>>> Can you provide a cite for this? >>>>> >>>>> >>>>> Even RFC 3602 requires that the IV be randomly generated (and for goo= d >>>>> measure requires that it be unpredictable) >>>>> >>>> >>>> That's just a cite to a requirement, not to it being insecure. Do you >>>> have a citation to the relevant threat? >>>> >>>> >>>> We could cite BEAST. Of course BEAST depends on HTTPS, so it=E2=80=99s= not >>>> really applicable - it=E2=80=99s harder to manipulate the first 16 byt= es of the IP >>>> header - but these have been the recommendations for using CBC in both= RFCs >>>> and NIST documentations for years before BEAST. >>>> >>> >>> Sure. I just think claims like this should have a citation. >>> >>> >>> -Ekr >>> >>> >>>> In any case, note that there are >>>>> straightforward algorithms for deriving a CBC IV from a counter >>>>> (e.g., run AES in counter mode with a different key). That structure >>>>> would actually be suitable for GCM as well (and would address >>>>> my point above). >>>>> >>>>> >>>>> If each implementation generates a random key and uses this to >>>>> generate the IVs this is fine, but you still have to transmit the IV.= If >>>>> we derive an =E2=80=9CIV key=E2=80=9D from the keying material, then = we don=E2=80=99t have to >>>>> transmit the IV. >>>>> >>>> >>>> You generate the IV from the sequence number, so you don't need to >>>> transmit the IV. >>>> That gives you an unpredictable IV without the per-packet overhead. >>>> >>>> >>>> We did bring this idea up at a WG meeting. This was not well-received >>>>> for three reasons: (1) it=E2=80=99s unnecessarily complicated. (2) Th= e world is >>>>> going to AEAD. AES-CBC is the past, and (3) The perception was that s= aving >>>>> 8 bytes per packet was important mostly for IoT, and they don=E2=80= =99t care about >>>>> CBC. >>>>> >>>> >>>> Sure, that's reasonable. I'm merely observing that there are designs >>>> which work for CBC. >>>> >>>> >>>> S 3. >>>>> o IV: Initialization Vector. Although security requirements vary= , >>>>> the common usage of this term implies that the value is >>>>> unpredictable. >>>>> >>>>> I don't think that this is true at all. I've frequently heard of a >>>>> zero IV. It's also odd in that your IV is in fact predictable. >>>>> >>>>> >>>>> S 5. >>>>> I'm a bit surprised that you are deciding to have duplicate >>>>> code points for every algorithm rather than some sort of IKE >>>>> negotiation payload. I see that the WG is currently defining >>>>> other extensions where you take that approach. >>>>> >>>>> >>>>> See slide #7 of https://www.ietf.org/procee >>>>> dings/96/slides/slides-96-ipsecme-0.pdf >>>>> >>>>> The problem is that IKEv2 has strict rules about unexpected attribute= s >>>>> in the substructures of the SA payload. The sense of the room was to = go >>>>> with new identifiers. >>>>> >>>> >>>> OK. Well, I agree it's ultimately a WG decision, but it doesn't seem >>>> very elegant. >>>> >>>> >>>> I was in the rough on this at first, but it was shown that every >>>> alternate negotiation mechanism had unwanted consequences. >>>> >>>> Yoav >>>> >>>> >>> >>> _______________________________________________ >>> 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 > > --94eb2c0e4166a60d85054be0c705 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am planning to add this reference.Let me = know if you prefer another reference. 
Rizz=
o, J. and T. Duong. "Here come the xor ninjas", 2011. http://netifera.co=
m/research/beast/beast_DRAFT_0621.pdf.

Thanks for the feed back= .

Yours,
Daniel

On Wed, Mar 29, 2017 at 10:54 AM, Eric Resc= orla <ekr@rtfm.com> wrote:
I think Yoav's suggestion to cite BEAST as evidence that p= redictable IVs are bad is a good plan.

-Ekr

On Wed, Mar 29, 2017 at 10:52 AM, Dani= el Migault <daniel.migault@ericsson.com> wrote:
Hi Eric,
Thank you=C2=A0 for the review and comments. Do you have any pr= eference on what we should cite for the chosen clear text attack?: Our loca= l version currently refers to Security Consideration of RFC3602.

The sentence in the terminology section mentioning that IV are usua= lly unpredictable has been removed. Thanks for catching that.=C2=A0

Yours,
Daniel=C2=A0 =C2=A0

On Sun, Mar 19, 2017 at 2:05 PM, Eric Rescorla <ekr@rtfm.com= > wrote:
<= div class=3D"m_1694175281846905149h5">


On Sun, Mar 19, 2017 at 11:= 52 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:

On 19 Mar 2017, at 19:30, Eric Rescorla <ekr@rtfm.com> wrote:<= /div>


On Sun, Mar 19, 201= 7 at 10:23 AM, Yoav Nir=C2= =A0<ynir.ietf@gmail.com>=C2=A0wrote:

On= 19 Mar 2017, at 16:55, Eric Rescorla <ekr@rtfm.com> wrote:

Ov= erall:
I notice that you are using a construction different f= rom that used
in TLS 1.3, which doesn't directly repeat nonce= s across associations.
I didn't see an answer to this.

Nonces are specified as 64-bit IV (usually coun= ter and we are forcing it to be a counter) plus 32-bit salt in RFC 4106.=C2= =A0 We saw no reason to change that.

OK. This has a somewhat lower margin of safety than the TLS 1.= 3 construction, but it should be OK.
=C2=A0

<= /div>
=
S 2.
=C2=A0 =C2=A0This document does not= consider AES-CBC ([RFC3602])as AES-CBC
=C2=A0 =C2=A0requires the= IV to be unpredictable.=C2=A0 Deriving it directly from the
=C2= =A0 =C2=A0packet counter as described below is insecure.

Can you provide a cite for this?
=
Even RFC 3602 requires that the IV be randomly generated (= and for good measure requires that it be unpredictable)

That's just a cite to a requirement, not to it= being insecure. Do you have a citation to the relevant threat?
=

We could cite BEAST. Of course BEAST dep= ends on HTTPS, so it=E2=80=99s not really applicable - it=E2=80=99s harder = to manipulate the first 16 bytes of the IP header - but these have been the= recommendations for using CBC in both RFCs and NIST documentations for yea= rs before BEAST.=C2=A0

S= ure. I just think claims like this should have a citation.
=C2=A0=

=
-Ekr
=C2=A0=
In any case, note tha= t there are
straightforward algorithms for deriving a CBC IV from= a counter
(e.g., run AES in counter mode with a different key). = That structure
would actually be suitable for GCM as well (and wo= uld address
my point above).
<= br>
If each implementation generates a random key and uses this= to generate the IVs this is fine, but you still have to transmit the IV.= =C2=A0 If we derive an =E2=80=9CIV key=E2=80=9D from the keying material, t= hen we don=E2=80=99t have to transmit the IV.=C2=A0

You generate the IV from the sequence number, so you d= on't need to transmit the IV.
That gives you an unpredict= able IV without the per-packet overhead.


We did bring thi= s idea up at a WG meeting. This was not well-received for three reasons: (1= ) it=E2=80=99s unnecessarily complicated. (2) The world is going to AEAD. A= ES-CBC is the past, and (3) The perception was that saving 8 bytes per pack= et was important mostly for IoT, and they don=E2=80=99t care about CBC.

Sure, that's reasonable. I'= ;m merely observing that there are designs which work for CBC.

S 3.
=
=C2=A0 =C2=A0o =C2=A0IV: Initialization Vector.=C2=A0 Although securit= y requirements vary,
=C2=A0 =C2=A0 =C2=A0=C2=A0the common usage of this term implies = that the value is
=C2=A0 =C2=A0 =C2=A0=C2=A0unpredictable.

I= don't think that this is true at all. I've frequently heard of a
zero IV. It's also odd in that your IV is in fact predictable.=


S 5.
I'm a bit surpr= ised that you are deciding to have duplicate
code points for ever= y algorithm rather than some sort of IKE
negotiation payload. I s= ee that the WG is currently defining
other extensions where you t= ake that approach.

See slide #7 of=C2=A0https://www.ietf.org/proceedings/96/slides/slides-96-ipsecme-0.pdf

The p= roblem is that IKEv2 has strict rules about unexpected attributes in the su= bstructures of the SA payload. The sense of the room was to go with new ide= ntifiers.

OK. Well, I agree it&= #39;s ultimately a WG decision, but it doesn't seem very elegant.
=

I was in the rough on this at firs= t, but it was shown that every alternate negotiation mechanism had unwanted= consequences.

Yoav



_______________________________________________
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


--94eb2c0e4166a60d85054be0c705-- From nobody Wed Mar 29 09:12:53 2017 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 1A425129841 for ; Wed, 29 Mar 2017 09:12:52 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgVM15w0OfVo for ; Wed, 29 Mar 2017 09:12:49 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::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 41B9A129871 for ; Wed, 29 Mar 2017 09:12:46 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id d191so14113215ywe.2 for ; Wed, 29 Mar 2017 09:12:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b/pD0hjPnqQIawJ5cws7O3PcHnJEZb0jD1UGpHafkDY=; b=WO12HVg0iM/Qg0aO4byFCIsnRGAFFnH8QNCFSAoIJT/JyRkYQ/4BlBsJzrmhDrhpBE k7R4i2ezh3SLRLuRpXrEzMpJlqQV8WzhwmdW/zj41nLgFja20n4GvvI1PyFaNCA7cKVO dNngoENveWD3rOjaDMZxHqb/BUjPQOwbVgIdGYI9B24BAph6sMOTKGfzuDdd0KCOSItN Ha7pPYHFaSm1R4cZ3Ozi9pj8zb5njYDjNgaFfOmx3t/rOG5KTt64gO4Gmpkw4VD2uE0r rLb/XN6P69+8niLxMTV1ce2a1sARPJBvO4qxJOLQBsYmGEZ21/kjrLiLlCOnfQaucDNt SfSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=b/pD0hjPnqQIawJ5cws7O3PcHnJEZb0jD1UGpHafkDY=; b=I5M944V5HU9cOK2jJTewk6NUn5oI2VAbj/+eJCnXBBxSof/1uyu0catFyeSWR7BJha NFdNPD2FmZtUO14ZOtSXg8SzZMwnWkd6WAUDDyr2dCazYaHTUgoP+cNLvr9z6umGVeak y1QcoAqGMTA/wN5e6MDTgz8lPQX3VHYGLZlmw12HlV8P4/xHma4BXd4BIazCl6LP0DJa +B43GdVR75AozuEy4gILcNnUV8FPSh46CQR/OI2yLy8RkrVGyMOTY8Tcbgtek5Gz9lqf n1xnFBU5sGZ90WtiJhE27qluGV9WDhsQJWbsw+cSHN5ai2j9jtYLGQMQILHCbn+n6FRX /qTw== X-Gm-Message-State: AFeK/H0SHdkQEDZEh04UWgth3Tvfvg5W6H9LjhQEhtEUntYB2cpoGTYUD8t6cdG4FT4ryGVBlY4DWfld/5NHWQ== X-Received: by 10.129.177.8 with SMTP id p8mr1120985ywh.327.1490803965340; Wed, 29 Mar 2017 09:12:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Wed, 29 Mar 2017 09:12:04 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 29 Mar 2017 11:12:04 -0500 Message-ID: To: Daniel Migault Cc: "ipsec@ietf.org" , Yoav Nir Content-Type: multipart/alternative; boundary=94eb2c13ce38c8fa95054be0d8d6 Archived-At: Subject: Re: [IPsec] Comments on draft-mglt-ipsecme-implicit-iv-02.tx X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 16:12:52 -0000 --94eb2c13ce38c8fa95054be0d8d6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This LGTM On Wed, Mar 29, 2017 at 11:07 AM, Daniel Migault < daniel.migault@ericsson.com> wrote: > I am planning to add this reference.Let me know if you prefer another > reference. > > Rizzo, J. and T. Duong. "Here come the xor ninjas", 2011. http://netifera= .com/research/beast/beast_DRAFT_0621.pdf. > > > Thanks for the feed back. > > Yours, > Daniel > > On Wed, Mar 29, 2017 at 10:54 AM, Eric Rescorla wrote: > >> I think Yoav's suggestion to cite BEAST as evidence that predictable IVs >> are bad is a good plan. >> >> -Ekr >> >> >> On Wed, Mar 29, 2017 at 10:52 AM, Daniel Migault < >> daniel.migault@ericsson.com> wrote: >> >>> Hi Eric, >>> >>> Thank you for the review and comments. Do you have any preference on >>> what we should cite for the chosen clear text attack?: Our local versio= n >>> currently refers to Security Consideration of RFC3602. >>> >>> The sentence in the terminology section mentioning that IV are usually >>> unpredictable has been removed. Thanks for catching that. >>> >>> Yours, >>> Daniel >>> >>> On Sun, Mar 19, 2017 at 2:05 PM, Eric Rescorla wrote: >>> >>>> >>>> >>>> On Sun, Mar 19, 2017 at 11:52 AM, Yoav Nir wrote= : >>>> >>>>> >>>>> On 19 Mar 2017, at 19:30, Eric Rescorla wrote: >>>>> >>>>> >>>>> >>>>> On Sun, Mar 19, 2017 at 10:23 AM, Yoav Nir wrot >>>>> e: >>>>> >>>>>> >>>>>> On 19 Mar 2017, at 16:55, Eric Rescorla wrote: >>>>>> >>>>>> Overall: >>>>>> I notice that you are using a construction different from that used >>>>>> in TLS 1.3, which doesn't directly repeat nonces across associations= . >>>>>> >>>>>> I didn't see an answer to this. >>>>> >>>>> >>>>> Nonces are specified as 64-bit IV (usually counter and we are forcing >>>>> it to be a counter) plus 32-bit salt in RFC 4106. We saw no reason t= o >>>>> change that. >>>>> >>>> >>>> OK. This has a somewhat lower margin of safety than the TLS 1.3 >>>> construction, but it should be OK. >>>> >>>> >>>> S 2. >>>>>> This document does not consider AES-CBC ([RFC3602])as AES-CBC >>>>>> requires the IV to be unpredictable. Deriving it directly from t= he >>>>>> packet counter as described below is insecure. >>>>>> >>>>>> Can you provide a cite for this? >>>>>> >>>>>> >>>>>> Even RFC 3602 requires that the IV be randomly generated (and for >>>>>> good measure requires that it be unpredictable) >>>>>> >>>>> >>>>> That's just a cite to a requirement, not to it being insecure. Do you >>>>> have a citation to the relevant threat? >>>>> >>>>> >>>>> We could cite BEAST. Of course BEAST depends on HTTPS, so it=E2=80=99= s not >>>>> really applicable - it=E2=80=99s harder to manipulate the first 16 by= tes of the IP >>>>> header - but these have been the recommendations for using CBC in bot= h RFCs >>>>> and NIST documentations for years before BEAST. >>>>> >>>> >>>> Sure. I just think claims like this should have a citation. >>>> >>>> >>>> -Ekr >>>> >>>> >>>>> In any case, note that there are >>>>>> straightforward algorithms for deriving a CBC IV from a counter >>>>>> (e.g., run AES in counter mode with a different key). That structure >>>>>> would actually be suitable for GCM as well (and would address >>>>>> my point above). >>>>>> >>>>>> >>>>>> If each implementation generates a random key and uses this to >>>>>> generate the IVs this is fine, but you still have to transmit the IV= . If >>>>>> we derive an =E2=80=9CIV key=E2=80=9D from the keying material, then= we don=E2=80=99t have to >>>>>> transmit the IV. >>>>>> >>>>> >>>>> You generate the IV from the sequence number, so you don't need to >>>>> transmit the IV. >>>>> That gives you an unpredictable IV without the per-packet overhead. >>>>> >>>>> >>>>> We did bring this idea up at a WG meeting. This was not well-received >>>>>> for three reasons: (1) it=E2=80=99s unnecessarily complicated. (2) T= he world is >>>>>> going to AEAD. AES-CBC is the past, and (3) The perception was that = saving >>>>>> 8 bytes per packet was important mostly for IoT, and they don=E2=80= =99t care about >>>>>> CBC. >>>>>> >>>>> >>>>> Sure, that's reasonable. I'm merely observing that there are designs >>>>> which work for CBC. >>>>> >>>>> >>>>> S 3. >>>>>> o IV: Initialization Vector. Although security requirements var= y, >>>>>> the common usage of this term implies that the value is >>>>>> unpredictable. >>>>>> >>>>>> I don't think that this is true at all. I've frequently heard of a >>>>>> zero IV. It's also odd in that your IV is in fact predictable. >>>>>> >>>>>> >>>>>> S 5. >>>>>> I'm a bit surprised that you are deciding to have duplicate >>>>>> code points for every algorithm rather than some sort of IKE >>>>>> negotiation payload. I see that the WG is currently defining >>>>>> other extensions where you take that approach. >>>>>> >>>>>> >>>>>> See slide #7 of https://www.ietf.org/procee >>>>>> dings/96/slides/slides-96-ipsecme-0.pdf >>>>>> >>>>>> The problem is that IKEv2 has strict rules about unexpected >>>>>> attributes in the substructures of the SA payload. The sense of the = room >>>>>> was to go with new identifiers. >>>>>> >>>>> >>>>> OK. Well, I agree it's ultimately a WG decision, but it doesn't seem >>>>> very elegant. >>>>> >>>>> >>>>> I was in the rough on this at first, but it was shown that every >>>>> alternate negotiation mechanism had unwanted consequences. >>>>> >>>>> Yoav >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> > --94eb2c13ce38c8fa95054be0d8d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This LGTM

On Wed, Mar 29, 2017 at 11:07 AM, Daniel Migault <daniel.migault@ericsson.com> wrote:
I am planning to add this ref= erence.Let me know if you prefer another reference. 
Rizzo, J. and T. Duong. "Here come the =
xor ninjas", 2011. http://netifera.com/research/beast/=
beast_DRAFT_0621.pdf.

Thanks for the feed back.

Y= ours,
Daniel

On Wed, Mar 29, 2017= at 10:54 AM, Eric Rescorla <ekr@rtfm.com> wrote:
I think Yoav's suggestion to cite B= EAST as evidence that predictable IVs are bad is a good plan.

-Ekr


=
On Wed, Mar 29, 2017 at 10:52 AM, Daniel Migault= <daniel.migault@ericsson.com> wrote:
Hi Eric,

Thank you=C2=A0 for the review and comments. Do you have any preference o= n what we should cite for the chosen clear text attack?: Our local version = currently refers to Security Consideration of RFC3602.

Th= e sentence in the terminology section mentioning that IV are usually unpred= ictable has been removed. Thanks for catching that.=C2=A0
Yours,
Daniel=C2=A0 =C2=A0

On Sun, Mar 19, 2017 at 2:05 PM, Eric Rescorla = <ekr= @rtfm.com> wrote:


On Sun, Mar 19, 2017 at 11:52 AM, Yoav Nir <ynir.ietf@gmail.com&g= t; wrote:

On 19 Mar 2017, a= t 19:30, Eric Rescorla <ekr@rtfm.com> wrote:



On Sun, Mar 19, 2017 a= t 10:23 AM, Yoav Nir=C2=A0<ynir.ietf@gmail.com>=C2=A0wro= te:

<= span>
On 19 Mar 2017, at 16:55, Eric Rescorla= <ekr@rtfm.com>= wrote:

Overall:
=
I notice that you are using a construction different from that used
in TLS 1.3, which doesn't directly repeat nonces across associa= tions.
I= didn't see an answer to this.

<= /div>Nonces are specified as 64-bit IV (usually counter and we are f= orcing it to be a counter) plus 32-bit salt in RFC 4106.=C2=A0 We saw no re= ason to change that.

OK.= This has a somewhat lower margin of safety than the TLS 1.3 construction, = but it should be OK.
=C2=A0

S 2.
=C2=A0 =C2=A0This document does not consider AES-CBC = ([RFC3602])as AES-CBC
=C2=A0 =C2=A0requires the IV to be unpredic= table.=C2=A0 Deriving it directly from the
=C2=A0 =C2=A0packet co= unter as described below is insecure.

Can you prov= ide a cite for this?

Ev= en RFC 3602 requires that the IV be randomly generated (and for good measur= e requires that it be unpredictable)

That's just a cite to a requirement, not to it being insecure. Do= you have a citation to the relevant threat?
<= br>
We could cite BEAST. Of course BEAST depends on HTTPS, so i= t=E2=80=99s not really applicable - it=E2=80=99s harder to manipulate the f= irst 16 bytes of the IP header - but these have been the recommendations fo= r using CBC in both RFCs and NIST documentations for years before BEAST.=C2= =A0

Sure. I just think c= laims like this should have a citation.
=C2=A0

-Ekr
=C2= =A0
In any case, note tha= t there are
straightforward algorithms for deriving a CBC IV from= a counter
(e.g., run AES in counter mode with a different key). = That structure
would actually be suitable for GCM as well (and wo= uld address
my point above).
<= br>
If each implementation generates a random key and uses this= to generate the IVs this is fine, but you still have to transmit the IV.= =C2=A0 If we derive an =E2=80=9CIV key=E2=80=9D from the keying material, t= hen we don=E2=80=99t have to transmit the IV.=C2=A0

You generate the IV from the sequence number, so you d= on't need to transmit the IV.
That gives you an unpredict= able IV without the per-packet overhead.


We did bring thi= s idea up at a WG meeting. This was not well-received for three reasons: (1= ) it=E2=80=99s unnecessarily complicated. (2) The world is going to AEAD. A= ES-CBC is the past, and (3) The perception was that saving 8 bytes per pack= et was important mostly for IoT, and they don=E2=80=99t care about CBC.

Sure, that's reasonable. I'= ;m merely observing that there are designs which work for CBC.

S 3.
=
=C2=A0 =C2=A0o =C2=A0IV: Initialization Vector.=C2=A0 Although securit= y requirements vary,
=C2=A0 =C2=A0 =C2=A0=C2=A0the common usage = of this term implies that the value is
=C2=A0 =C2=A0 =C2=A0=C2=A0unpredictable.

I don't think that this is tru= e at all. I've frequently heard of a
zero IV. It's also o= dd in that your IV is in fact predictable.


S 5.
I'm a bit surprised that you are deciding to hav= e duplicate
code points for every algorithm rather than some sort= of IKE
negotiation payload. I see that the WG is currently defin= ing
other extensions where you take that approach.

See slide #7 of=C2=A0https://www.ietf.org/proceedings/96/slides/slides-96-ipse<= wbr>cme-0.pdf

The problem is that IKEv2 has strict r= ules about unexpected attributes in the substructures of the SA payload. Th= e sense of the room was to go with new identifiers.

OK. Well, I agree it's ultimately a WG decision, b= ut it doesn't seem very elegant.

I was in the rough on this at first, but it was shown that every al= ternate negotiation mechanism had unwanted consequences.

Yoav



_______________________________________________
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



--94eb2c13ce38c8fa95054be0d8d6-- From nobody Wed Mar 29 11:34:08 2017 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 33A89127077 for ; Wed, 29 Mar 2017 11:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yA8fEMEaflDp for ; Wed, 29 Mar 2017 11:33:56 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::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 4B63912894A for ; Wed, 29 Mar 2017 11:33:55 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id g2so14852079pge.3 for ; Wed, 29 Mar 2017 11:33:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=x/2SzbkYo8qEC9u0Ou4aQ6ecrZchApXiX0HnF56ubNM=; b=QA8KWM9DvmJFvaCG1iUHMgyZxTnlb8bxrDZzTFROHIE6hkjtphlhZuk+M6M7lY42tz k0dbqOV2cJbH6ilSfxNC6527VbTb+qtgtVQKgG3KValh2thHcwfULLVdcRSasACNchmn hVdbXO7NsHfWuZ62RTz6UNyFeo5MMxIUUT6tWmfNBUmD26U0K5C2qvb9pMz4OAhmFp7+ 8z3JAC5NDM+MvdH2rY+43lrP6aiOQXTrvlysoKfOP9vOK37+/s7NWj+ZJTYyfh2MlvFv 3x0uJq7DYqbrl82f8SyG18xG9N+7ErW4OYTu+mkY9wO47VJgJtwqRlqdvgb26g9xLDwR 3rcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=x/2SzbkYo8qEC9u0Ou4aQ6ecrZchApXiX0HnF56ubNM=; b=NtFvlWQ59rGzPwRwhzYuaHQUHOQDwAnbdiv1KqefzdLZoaWlfChGhIjUPGfJSCI409 zYkE7htiPqUx3vr8nd9FxillnV9cSykIPuZcNn2FJe+WmY8Xodc7PsiAZy6J8/e5jxju 49EiWQHBixh3m4+PNYejllMnEbPpTSPgcSn0jCh0ZfBVajSfIiky+9IjL4StHdDqdEOO akUQMFIadZ8T+N0Zs5rCj1xTON0TkGO6S95Xsr5Jq8zw8ekh75dpjJBxHwMsyRvjEZfC QOpcN1XAOmniOlJIxd7X1EkZd4GlDWFHyeTVD/z7K1RSeGaxkGHHXDwNTXBLc/v9x/xp SPgw== X-Gm-Message-State: AFeK/H1941OXAB57EZBjvKBvtN81LgyfJk8C67jqDIBI77byn4hQt8vVKkZ7RvIOhuXO/OD+oYn7jRpg0cO7qA== X-Received: by 10.99.159.1 with SMTP id g1mr2031084pge.88.1490812434783; Wed, 29 Mar 2017 11:33:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.183.98 with HTTP; Wed, 29 Mar 2017 11:33:14 -0700 (PDT) From: Kathleen Moriarty Date: Wed, 29 Mar 2017 14:33:14 -0400 Message-ID: To: "ipsec@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [IPsec] Code X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 18:33:58 -0000 Hello, If you have an implementation to standards or drafts for this WG, please considering entering them into CodeStand. Listing can be to open source or proprietary implementations, where the open source ones would link to code repositories. Before entering your code project, check to see if the standard, draft, or set of standards/drafts is already listed as a project as we do have some listed for IPsec related protocols. https://codestand.ietf.org/ CodeStand is fairly new, so if you have any issues, let me know or codestand-develop@ietf.org Thanks to those of you that have done this already! If you are not familiar with CodeStand, here's some more information: https://codestand.ietf.org/codestand/about/ -- Best regards, Kathleen From nobody Wed Mar 29 12:11:23 2017 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 422121293E8; Wed, 29 Mar 2017 12:11:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149081467620.27431.4459925782189543427@ietfa.amsl.com> Date: Wed, 29 Mar 2017 12:11:16 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-18.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 19:11:16 -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-18.txt Pages : 18 Date : 2017-03-29 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-18 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-rfc4307bis-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-18 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 Wed Mar 29 12:17:30 2017 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 97C2F12953F; Wed, 29 Mar 2017 12:17:28 -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.48.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149081504852.27410.5181982242499611414.idtracker@ietfa.amsl.com> Date: Wed, 29 Mar 2017 12:17:28 -0700 Archived-At: Subject: [IPsec] The IPSECME WG has placed draft-mglt-ipsecme-implicit-iv in state "Call For Adoption By WG Issued" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 19:17:29 -0000 The IPSECME WG has placed draft-mglt-ipsecme-implicit-iv in state Call For Adoption By WG Issued (entered by Tero Kivinen) The document is available at https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ From nobody Wed Mar 29 14:26:47 2017 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 88268127078 for ; Wed, 29 Mar 2017 14:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 WOSMBOkEIPjz for ; Wed, 29 Mar 2017 14:26:45 -0700 (PDT) Received: from mail-in21.apple.com (mail-out21.apple.com [17.171.2.31]) (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 285EE12948C for ; Wed, 29 Mar 2017 14:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1490822804; 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=j+xv/bAgDVbwFlbD4PM6B6CKze3f1MV/YOt7C7jElYM=; b=HtSCamfGPRq0cS7UXOzNcqHsiTVYJdczVKX+vFs7J7ZFUXzSg34gdyJUDAd3xwPD 7P0mMgRNHyfkOyoCpi+5d+3DJjVSegEmVsbmG9HWMMC7Kd/Vgbm/xBatq8ZDvrmh 0uLIlnwNuMyC1co0DbIBPhaFK9LZhBZS+1t6Z9ysrrrhqvHqfQpkpu16rktjfR3j db5EETGdKIUCdbfL3iCpCNH3LiWKSofvN8nW6M2YqGwN6Xk1iSvj0mfOMloyI1uB CoRwG8mqRrM1sQdkjJC5cUj+/pX3DC9dAnAxNO2843ZwOJ1WBZ/MdL22sMn3e1KS gPFtIK39KIWgFwqcYLtXpw==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) by mail-in21.apple.com (Apple Secure Mail Relay) with SMTP id C8.49.24065.4962CD85; Wed, 29 Mar 2017 14:26:44 -0700 (PDT) X-AuditID: 11ab0215-f3f9b9a000005e01-4a-58dc2694547e Received: from kencur (kencur.apple.com [17.151.62.38]) by relay8.apple.com (Apple SCV relay) with SMTP id 6A.DD.07296.3962CD85; Wed, 29 Mar 2017 14:26:43 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.104.113.236] (unknown [17.104.113.236]) by kencur.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ONL00DB8I8GN200@kencur.apple.com> for ipsec@ietf.org; Wed, 29 Mar 2017 14:26:43 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Date: Wed, 29 Mar 2017 16:26:40 -0500 References: <149081504852.27410.5181982242499611414.idtracker@ietfa.amsl.com> To: "IPsecme WG (ipsec@ietf.org)" In-reply-to: <149081504852.27410.5181982242499611414.idtracker@ietfa.amsl.com> Message-id: X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FCYpjtF7U6EQe9SGYv9W16wOTB6LFny kymAMYrLJiU1J7MstUjfLoErY87lS0wFu1kqtv74zNbAeIO5i5GTQ0LARGLRt9tsXYxcHEIC +xkl7p6+yAiTOHJ3OlRiBaPEhiMdrCAJXgFBiR+T77F0MXJwMAvISxw8LwsSZhbQkvj+qJUF on4ak8SxZzPB6oUFpCW6LtxlBalnAyo6sMYIIlwpcW5iP9guFgFVicafx8BsIQFfia2tm8Fa RQSMJLadfMACYnMK+EnMWHMT6gQbiV+br7FC3Ckr8en5T3aQvRICPWwSm2+9Y5/AKDQLyamz EE6dheTUBYzMqxiFcxMzc3Qz84wM9RILCnJS9ZLzczcxgsJ1NZPoDsb5rwwPMQpwMCrx8Cqs vh0hxJpYVlyZe4hRmoNFSZy3TP5OhJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGCr4DxwvM 97NGTHzAOu+j7PrlDzv5WP6+WCC7efp3VcGvJwLcV53X+S+a+Fbz0LT0JYuKHCbvtVp3T431 pPmp9rn/rz5YcfOz2qKbqm/3Vb6Q/anzXnbf6QPu7zu0L5p0qzcqhCts0D4vKtP9Ymbwm5sZ n/IM2ta/M9zOvcD83iEHyelPz5zfuUmJpTgj0VCLuag4EQDAoT6COAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUiON1OTXey2p0Ig8dPTS32b3nB5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujDmXLzEV7Gap2PrjM1sD4w3mLkZODgkBE4kjd6ezdTFycQgJ rGCU2HCkgxUkwSsgKPFj8j2WLkYODmYBeYmD52VBwswCWhLfH7WyQNRPY5I49mwmWL2wgLRE 14W7rCD1bEBFB9YYQYQrJc5N7GcEsVkEVCUafx4Ds4UEfCW2tm4GaxURMJLYdvIBC4jNKeAn MWPNTagTbCR+bb7GCnGnrMSn5z/ZJzDyz0Jy3SyE62YhuW4BI/MqRoGi1JzESgu9xIKCnFS9 5PzcTYyg4GooTNvB2LTc6hCjAAejEg+vwurbEUKsiWXFlbmHGCU4mJVEeLU+AYV4UxIrq1KL 8uOLSnNSiw8xVgHdP5FZSjQ5Hxj4eSXxhiYmBibGxmbGxuYm5lQRVhLn9bcH2iyQnliSmp2a WpBaBLOciYNTqoFx1l+LKXY3Yvo2ar9Yv3aVxZ4T6ZdTzT6m3Ez/UvBDO+BvzJpH1xRvse4y cZeyZlL4HZAYx/pwNafSc/awY0f+btvzP06ffXPFwmYhocpdt6Wljrm3vmrauarTLmSbZElH 6arLMnP+X6+WazDPeP7o2LxP292bI2WDjD2VV3NP3XVVc0KE8+WrSizFGYmGWsxFxYkAUcAZ DokCAAA= Archived-At: Subject: Re: [IPsec] The IPSECME WG has placed draft-mglt-ipsecme-implicit-iv in state "Call For Adoption By WG Issued" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 21:26:46 -0000 Hello all, I strongly support the WG adoption of this draft. Regards, David Schinazi > On Mar 29, 2017, at 14:17, IETF Secretariat wrote: > > > The IPSECME WG has placed draft-mglt-ipsecme-implicit-iv in state > Call For Adoption By WG Issued (entered by Tero Kivinen) > > The document is available at > https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Mar 29 14:44:55 2017 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 986C912949E for ; Wed, 29 Mar 2017 14:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NUk6sMttXF6 for ; Wed, 29 Mar 2017 14:44:51 -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 91D1F129494 for ; Wed, 29 Mar 2017 14:44:49 -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 v2TLikaO011882 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 30 Mar 2017 00:44:46 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v2TLikFq023696; Thu, 30 Mar 2017 00:44:46 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22748.10958.314148.242611@fireball.acr.fi> Date: Thu, 30 Mar 2017 00:44:46 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 1 min Archived-At: Subject: [IPsec] Starting two week working group adoptation call for draft-mglt-ipsecme-implicit-iv X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 21:44:54 -0000 As discussed in the meeting, we are starting two week working group adoptation call for the draft-mglt-ipsecme-implicit-iv. Please read the draft and send your comments to this list, and also tell if you support adoptation of this draft as WG draft. The document is available at https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ -- kivinen@iki.fi From nobody Wed Mar 29 14:59:03 2017 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 998A712949E for ; Wed, 29 Mar 2017 14:59:02 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3atmPg7qGQT for ; Wed, 29 Mar 2017 14:59:01 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 138A41279E5 for ; Wed, 29 Mar 2017 14:59:01 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id b140so8006447iof.1 for ; Wed, 29 Mar 2017 14:59:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=cMjcONcC1jTdzN1Cr3SbEnayPiIfgWyIwd6icfEjx7I=; b=NigtC4qE3G7cqy8KgDJUfWwAvH/5b8TtStXDcTYQYeMgwrfDqDEUr6d2p9B2yRM/Vg P3+67AWLtmn3cL3OpZnKMvV0A0kEXu1eaCWr8B8m7GFQLvcW4zbCLQJec2Ia4DvhFbK2 QlMzfnUxtuzxNK1X0QopPUOacIWwT54E8hcctpLQmq8TM0gmOa4omazpvW9IC65VkwV8 nSMncoqwXjNvSe6biVnfiA1Afqd3PZnAV4+2pWcnytSa80cYZE1WKg4wGX8Pcs+BystR zw23yPXkynLW8kZ1Y7HOPqLNEg58qs8kY9DWuRxtboVWSgoo5hHsBU90Ay1bW9qDuZkv aeaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=cMjcONcC1jTdzN1Cr3SbEnayPiIfgWyIwd6icfEjx7I=; b=YhImiUJS/BNqjeUN3XM/Ti0160htzhBr9RKTfUEl2wER+Hru/lvGvDST/pf6+coUHh Hw3kXOHkjF39xL//FM/pXmXgbHWjwRZ+bKF8XV11Pa8TbARg/CHR5sRW19KdYxPxEEco 82bid8JvdcwdXrcSQCUpqtbxf36r/pj3H57fLHj4uC2Dn24c7g3CClWZWN6NCn4SbKvA XQYxpXKDu4Cl2y12n3ljIxjkcomcJE9O/yqfJ5xel0le7qatUzMXEuDpOR74hw6zRIn+ PiupxHWnGm8Xs4IxQ1tUw/6KZmoSlcsNtC36TVSDJUZpR77iKIFiZPkZPIZzYz+tko/L q28w== X-Gm-Message-State: AFeK/H30bD3d8mS+IByGwLtgDMPdYd2sF7c497E+Gtqtvw1g4gge/Yb78r7jJY/OpZi8WA== X-Received: by 10.107.59.76 with SMTP id i73mr3553633ioa.152.1490824740471; Wed, 29 Mar 2017 14:59:00 -0700 (PDT) Received: from t2001067c03700128f5d7507edd3635c6.v6.meeting.ietf.org (t2001067c03700128f5d7507edd3635c6.v6.meeting.ietf.org. [2001:67c:370:128:f5d7:507e:dd36:35c6]) by smtp.gmail.com with ESMTPSA id e191sm3993345ita.9.2017.03.29.14.58.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Mar 2017 14:58:59 -0700 (PDT) From: Yoav Nir Message-Id: <6BA2AA95-11A1-4A6E-B606-2DE8D4A07785@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_F33FADBF-61C6-4ACE-A929-B4644FED2348"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 29 Mar 2017 16:58:57 -0500 In-Reply-To: <22748.10958.314148.242611@fireball.acr.fi> Cc: ipsec@ietf.org To: Tero Kivinen References: <22748.10958.314148.242611@fireball.acr.fi> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] Starting two week working group adoptation call for draft-mglt-ipsecme-implicit-iv X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 21:59:03 -0000 --Apple-Mail=_F33FADBF-61C6-4ACE-A929-B4644FED2348 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Not surprising (me being a co-author) but I support adoption. > On 29 Mar 2017, at 16:44, Tero Kivinen wrote: > > As discussed in the meeting, we are starting two week working group > adoptation call for the draft-mglt-ipsecme-implicit-iv. > > Please read the draft and send your comments to this list, and also > tell if you support adoptation of this draft as WG draft. > > The document is available at > https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_F33FADBF-61C6-4ACE-A929-B4644FED2348 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJY3C4iAAoJELhJCxUKWMyZ080H/0pMMifwfhcsIUBRURDzG55T bFuH8ESGxVyxR5i8Gg4Kb/879WyZ9ZqgMAh+GVhTd77bm9rF/h9hA7sZwkcvISRk PPf/f2jvapCkT02ZZvh6VYPumZrj2GhHVh23LNS+bq7yVL92DlRWOj49Bwm5dvin 3CF1jTgUfqUqNK0JpFVeDTV1Ruhlwp7sJWxVGchbDXUWmVRhlJfavNwszg2lDaCI 5gFcGYA08L7tNE1NW5tuWgoh+yK8OsSDgmTavNo5wgnOfiY+glQitiZBplrxXjBw VDslYSf89s8RSII+lqlUtzovxxkhFWm6whVpWoeSGkFYezhFCocuoSghIdIcbEg= =aQf6 -----END PGP SIGNATURE----- --Apple-Mail=_F33FADBF-61C6-4ACE-A929-B4644FED2348-- From nobody Wed Mar 29 15:03:05 2017 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 43C7B129632 for ; Wed, 29 Mar 2017 15:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 C90Gddl3hDEn for ; Wed, 29 Mar 2017 15:03:02 -0700 (PDT) Received: from mail-in22.apple.com (mail-out22.apple.com [17.171.2.32]) (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 B54A4126C2F for ; Wed, 29 Mar 2017 15:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1490824981; 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=qNkx6+PQW5e6r9wbUxk3XIagxYYhX2NRjgobnneDCtM=; b=m6jTo0Tj0m9VuWwPzEP6YW+xcDYNlSb5v9INvcxNAaPvbk21fglPCMpgtTjDAuBJ Py4FOiseGhCPtxuDImAF2/WtrA7qcRcq6pRGgSwxjSfXjrEsu7g70+ZwYjZ0cGT6 E5qREeHtm/2lCBapiubcI2YREPg/F0XLYSPrdwvcorVbxoUEpnBlfS9awq5/4cCf FDJuKICTbGBa41LXlh5HY78zqnZjq6awcGLOVV0H7rPtU54YzWmxAF1cRoNqgVWG hXDpDDOBwDFZG6w3mkKu4KfiYRSxkWkJ86sQOl0NfOkxYfdtGCRcCe+nXwiZ/c7A 5+cnGTMrZ8eEa+KItS2OIg==; Received: from relay21.apple.com (relay21.apple.com [17.171.128.102]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in22.apple.com (Apple Secure Mail Relay) with SMTP id 96.46.23264.51F2CD85; Wed, 29 Mar 2017 15:03:01 -0700 (PDT) X-AuditID: 11ab0216-e218d9a000005ae0-c5-58dc2f15d867 Received: from russet.apple.com (st1-02-mail-lb2-v365-snip.apple.com [17.171.128.5]) by relay21.apple.com (Apple SCV relay) with SMTP id 7C.23.19192.51F2CD85; Wed, 29 Mar 2017 18:03:01 -0400 (EDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from t2001067c03701998440986ccd0b23187.v6.meeting.ietf.org (nat64-c3.meeting.ietf.org [31.130.238.195]) by russet.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ONL008M5JX0F020@russet.apple.com>; Wed, 29 Mar 2017 15:03:01 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <6BA2AA95-11A1-4A6E-B606-2DE8D4A07785@gmail.com> Date: Wed, 29 Mar 2017 17:03:00 -0500 Cc: Tero Kivinen , Yoav Nir Message-id: <60012DA8-3C6E-40A8-94DF-D6F97C9B7A1E@apple.com> References: <22748.10958.314148.242611@fireball.acr.fi> <6BA2AA95-11A1-4A6E-B606-2DE8D4A07785@gmail.com> To: "IPsecme WG (ipsec@ietf.org)" X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUiuLohTVdU/06EwYI5Rhb7t7xgszh6/jmb xdJjH5gcmD12zrrL7rFkyU8mj8NfF7IEMEdx2aSk5mSWpRbp2yVwZRx528pesJaz4v+LR6wN jLfZuxg5OSQETCSuL+0Gs4UE1jNJvPwgChPff+kkcxcjF1D8GKNE57NFrCAJXgFBiR+T77F0 MXJwMAvISxw8LwsSZhbQkvj+qJUFon4fk8S9Q3OZQRLCAtISXRfuskLYmRI7px1jAullA2o4 sMYIxOQUsJX4OUsApIJFQFVi8et97BAjHSVuPzzBArHVRuL5zvVQZ2ZJNG+/yAhiiwgYSWw7 +YAF4mRZiU/Pf7KDnCAhMIFN4vWklcwTGIVnIbl6FsLVs5BcvYCReRWjcG5iZo5uZp6RkV5i QUFOql5yfu4mRnCoM4ntYLz32vAQowAHoxIPb8Xa2xFCrIllxZW5hxilOViUxHnL5O9ECAmk J5akZqemFqQWxReV5qQWH2Jk4uCUamDkKmCe12fWZMwYu21jc8fsk9e5vk46Grv/+IGl6/dp F9a+effb41Wi0MVzCknhhsEWOWtOSn4+l+lRUvnL1jn/uXLckw/fps76qRCnU+A4WebWxIAL N6Yv6MhsfM3FcO+yo1XG/3rL3a9fbRDkWeuWk6iUIra245Vnvn3u7xkaWx4tf5x0ifmVEktx RqKhFnNRcSIAQDsXHVYCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUiuLqBVVdU/06Ewa+buhb7t7xgszh6/jmb xdJjH5gcmD12zrrL7rFkyU8mj8NfF7IEMEdx2aSk5mSWpRbp2yVwZRx528pesJaz4v+LR6wN jLfZuxg5OSQETCT2XzrJ3MXIxSEkcIxRovPZIlaQBK+AoMSPyfdYuhg5OJgF5CUOnpcFCTML aEl8f9TKAlG/j0ni3qG5zCAJYQFpia4Ld1kh7EyJndOOMYH0sgE1HFhjBGJyCthK/JwlAFLB IqAqsfj1PnaIkY4Stx+eYIHYaiPxfOd6sLiQQJZE8/aLjCC2iICRxLaTD1ggTpaV+PT8J/sE RoFZSA6dhXDoLCSHLmBkXsUoWJSak1hpZKiXWFCQk6qXnJ+7iRESnGk7GP+fMzzEKMDBqMTD W7H2doQQa2JZcWXuIUYJDmYlEV6tT0Ah3pTEyqrUovz4otKc1OJDjNIcLErivHvsgVIC6Ykl qdmpqQWpRTBZJg5OqQbG5VbnN8hVf1LP9e/eV+31VePLw273CI9Nr9Rbsz0F7HjUQxZ9kzjP dmvK9xsdYjNKCl07ObIk2Z0yDmy0n/+n9c2Nn34bluoJz+2bwyd49J+Bs9vy9R1t/Ie2O5y8 y7AzXD9w7hHdNm2Jhtlrq6qM/L1F+y1vd5k2M3rdcxDOvrDi25uOsh9KLMUZiYZazEXFiQA7 aFORSgIAAA== Archived-At: Subject: Re: [IPsec] Starting two week working group adoptation call for draft-mglt-ipsecme-implicit-iv X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 22:03:04 -0000 Hello all, I strongly support adoption of this document. I have read it and implemented it. The document reads well, and allows independent implementations. I personally think Implicit IV is a great step forward for IKEv2/IPsec, even outside of IoT. Regards, David Schinazi > On Mar 29, 2017, at 16:58, Yoav Nir wrote: > > Not surprising (me being a co-author) but I support adoption. > >> On 29 Mar 2017, at 16:44, Tero Kivinen wrote: >> >> As discussed in the meeting, we are starting two week working group >> adoptation call for the draft-mglt-ipsecme-implicit-iv. >> >> Please read the draft and send your comments to this list, and also >> tell if you support adoptation of this draft as WG draft. >> >> The document is available at >> https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ >> -- >> kivinen@iki.fi >> >> _______________________________________________ >> 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 Wed Mar 29 15:09:37 2017 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 A0572128D40 for ; Wed, 29 Mar 2017 15:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzlsdBMq-jCm for ; Wed, 29 Mar 2017 15:09:34 -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 53D031279E5 for ; Wed, 29 Mar 2017 15:09: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 v2TM9WMt013816 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 30 Mar 2017 01:09:32 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v2TM9WXZ026976; Thu, 30 Mar 2017 01:09:32 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22748.12444.151820.557270@fireball.acr.fi> Date: Thu, 30 Mar 2017 01:09:32 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: Subject: [IPsec] IPsecME document status X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 22:09:35 -0000 Here is the current status of the working group documents: ---------------------------------------------------------------------- Document Status: - draft-ietf-ipsecme-rfc4307bis (David) Approved. Revised ID already done. - draft-ietf-ipsecme-rfc7321bis (David) Approved. Revised ID needed. - draft-ietf-ipsecme-eddsa (Tero) WGLC done, agreed on new number, ready to go forward. Shepherd writeup needed. - draft-ietf-ipsecme-tcp-encaps (Tero) Submitted to IESG for publication, on 2017-04-27 telechat, now in IETF LC, ending 2017-04-18. - draft-ietf-ipsecme-split-dns (David) Work ongoing. Questins about the what to do when IKEv2 goes down with cached dns entries. New work: - Quantum Resistance (David) Adopted as WG document. - draft-mglt-ipsecme-implicit-iv (Tero) In WG adaptation call. -- kivinen@iki.fi From nobody Wed Mar 29 16:02:09 2017 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 5F36B129631 for ; Wed, 29 Mar 2017 16:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m12XFMhn0bHb for ; Wed, 29 Mar 2017 16:02:05 -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 36A8F129634 for ; Wed, 29 Mar 2017 16:01:58 -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 v2TN1qWS026136 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 30 Mar 2017 02:01:52 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v2TN1qRb007950; Thu, 30 Mar 2017 02:01:52 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22748.15584.159093.284972@fireball.acr.fi> Date: Thu, 30 Mar 2017 02:01:52 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 2 min Archived-At: Subject: [IPsec] Preleminary minutes of the IPsecME meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 23:02:07 -0000 Here are the preliminary minutes of the IPsecME meeting in Chicago. Send corrections, and additions etc to me. Thanks to Michael and Tommy for taking the minutes. ---------------------------------------------------------------------- IPSECme meeting. IETF98. Tero and David as Chairs. Room Montreux 3. 13:00, March 29, 2017. - Slides about finished and almost finished WG drafts. -bis drafts are approved by IESG but have minor changes needed. TCP Encaps in IETF last call, pushed out by a week. - 4307bis issues. - will fix ENCR_3DES will be "MAY" - EcDSA based auth expected downgrade, but we are still "SHOULD", and this will be retained: because there is no hash negotiation. - If things go fine, and we move to EdDSA ("safecurves"), then we might get rid of EcDSA, but this is far from a foregone conclusion. Much discussion about intention here, and why it is SHOULD, and not SHOULD-. This document is past the IESG approval, so only minor inconsistency changes will be acceptable. - We do not have enough implementations to move Digital Signatures from SHOULD to SHOULD+. (ditto ecdsa-with-sha256). - ChaCha is believed to be SHOULD, not SHOULD+, but that may not be reflected in the draft? (confirmed to be the case) - GPP3 -13 will use Digital Signatures, and so it will be pushed forward. - 7321bis IESG issues. - Manual keying issues - ENCR_AES_CBC will need to be fixed. - Clarify that some algorithms MUST NOT be used, while ones not mentioned MAY be used. - Comments that manual key seems the only way to do multicast IPsec.... (PAUL suggests that in a few years there will be no safe algorithms.) - EdDSA issues - Some kind of chicken and egg problem with openssl. - The algorithm we use is determined by the certificate type, and so far no CAs provide EdDSA certificates. - Report from Tommy that he has EdDSA. We request the authors to ask for the codepoint, as 5. - Split DNS - Recent changes: Removed the way to request the list of domains. The sender can only request a 0 size list. Removed requirement for Child SA to contain the DNS server IP address. - IKEv2 says you can send requests optionally, so the text needs to be updated - Open question is what to do with cache entries on disconnect. Paul thinks we should flush the cache whenever you change the resolver. Tero thinks there could be issues if the IKE SA goes down and comes back up and connections fail. Yoav says that if you don't flush, you'll have stale records. Tero says you'll try to access the old addresses and bring up the tunnel again. Michael says that if you have two answers inside and out it is insecure. Tommy says that sometimes deployments use different addresses not for security, but for keeping track of what context the client is from. The problem is the real world vs the ideal DNS world. Proposing that we soften the language to say that this is a client policy, and the options are to always flush the cache, or if you know that your domains are globably valid still, you can not flush the cache. Tero agrees that it is not an interop issue, since it's a local policy issue. The current text says "MUST" flush the cache, and that MUST is the problem. Paul: should we just change MUST to SHOULD, or do we include the discussion. Authors will decide. - Quantum Resistant IKEv2 - Current proposal is to stir in shared secret to derived keys. The entropy makes it infeasible to break. - Last meeting agreed that algorithm agility is important, that ESP needs to be protected but IKE is not as important - Open issues: how to stir in the shared secret. Draft stirs into each Child SA derivation. Valery suggested just using the SK_d, which will apply for all future derivations. It helps to not have to remember which key you used. Dan Harkins proposed only modifying KEYMAT. - Darrell: We need to do something about this before NIST. Tero: wants to do something in IKE not just in KEYMAT so that IKE would fail if something goes wrong. SK_d has a good property since it is in IKE SA rekeys. We want PPK failures to look like auth failures. Michael: I agree with Tero-whatever we do, it should be locally loggable about which one failed. Some people may think "if I've gone through the trouble of sharing a PPK, why do I need other auth?". How easy do we want to make this, to encourage potentially less secure implentations from adopting. If we don't make it easy, why bother? We should have a way to distribute PPKs. Tero: It should be easy to implement regardless of how important implementers think it is. We don't need to specify the format here, will likely be binary blob. - Implicit IV - Why? Save 8 bytes on every ESP packet. Counter-based algorithms are becoming more widely used. They don't need unpredictable IVs, so the IV can just be a counter (like the sequence number). Just remove the IV in the packets when negotiated. Requires new transform IDs. AES GCM, CCM, and ChaCha. - Talked to EKR since and pointed out that it may be inefficent to have the new IDs, but we may not have better alternatives. There is a way to do with other algorithms that are AES based. - Minimal ESP - This is draft about doing the minimal implementation of the ESP, i.e., still keep in line with the normal ESP, but what kind of tricks implementor can do to make the actual code smaller on the constrained devices. Similar to the minimal IKEv2 RFC but for ESP. -- kivinen@iki.fi From nobody Wed Mar 29 16:11:31 2017 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 762E81287A0 for ; Wed, 29 Mar 2017 16:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmbBRYpmUOhG for ; Wed, 29 Mar 2017 16:11:28 -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 BC7EA129676 for ; Wed, 29 Mar 2017 16:11:27 -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 v2TNBP5v010950 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 30 Mar 2017 02:11:25 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v2TNBPSt012747; Thu, 30 Mar 2017 02:11:25 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22748.16157.573889.454241@fireball.acr.fi> Date: Thu, 30 Mar 2017 02:11:25 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 9 min Archived-At: Subject: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 23:11:29 -0000 So I have proposed earlier that we should mix the ppk to SK_d, SK_pi, and SK_pr, i.e., something like this: SKEYSEED = prf(Ni | Nr, g^ir) {SK_d' | SK_ai | SK_ar | SK_ei | SK_er | SK_pi' | SK_pr'} = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr) If no PPK available, then SK_d = SK_d' SK_pi = SK_pi' SK_pr = SK_pr' If PPK is available then SK_d = prf(PPK, SK_d') SK_pi = prf(PPK, SK_pi') SK_pr = prf(PPK, SK_pr') This has the follolowing benefits. The SK_d modification will mean that IKEv2 SA will gain protection against Quantum Resistance after the IKEv2 SA irs rekeyed, as rekeyed SA will be using SK_d to derive new keys. SK_d also used to derive the KEYMAT, meaning the Child SA will gain protection. Modifying the SK_pi, and SK_pr will mean that if the PPK is wrong the IKEv2 authentication will fail, and we will get exactly same failure for wrong PPK than we do with wrong shared key or digital signature failures. This means that attacker do not gain any information which part of the authentication failed. I do so that in the early cases the PPKs are going to be configured manually in the system and there is quite big propability they being wrong, and catching the misconfigurations with proper error code is better, than just getting the random garbage on the Child SA data. -- kivinen@iki.fi From nobody Wed Mar 29 17:22:34 2017 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 B9192126DEE for ; Wed, 29 Mar 2017 17:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrZt6HyGT5QJ for ; Wed, 29 Mar 2017 17:22:30 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 3E90A124D68 for ; Wed, 29 Mar 2017 17:22:30 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id 190so66317551itm.0 for ; Wed, 29 Mar 2017 17:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=03BedzGhmFcd9fN2aNAkTHX0YNo+f7axy5EaBMsgVEY=; b=Y3cIrc+L+Y+Pvkncm9ZSpqElAe9T2vhPZ75uFEebJxX9k98E6CRnMcAJGaN7ZzkqtO WPYZOHuNuxhw6giMJvrUoIRuTNgpjYa+voA0FOi5Yrgy5e9xhErEJEBKoIgs2yJwsJCF +XdUJvBvYqV4NM4Tls8bmtaEnY8/ROKXI2wTD4GYRv4Y0sGlu80DkjRUPjxTXGUznjfx K3lwrKtArsUhC5QhBtTxcBJvt1rXTN4+7m0OrstgVJmvLdeLoSvL48tKC1qUO1OYtit3 /FcPH76OGt9xYE6tLoCGccRUVJ91YKQYsVm7+HXTVn/nfhwo2coqeKJ8Kw0Fea8CdJgB RL6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=03BedzGhmFcd9fN2aNAkTHX0YNo+f7axy5EaBMsgVEY=; b=DHLSjFVTIugDpY7rXxdI4qqmTCNGuBo+0Y5nMTUK0IzyAMi4YhKzdReRztdD/hBu65 xD1H4R6CiXeTcRHqzUWP2BXVKyBPrU952udJkMVVUMoQcd6uxL5pRcMdeq1MTINsay8E 5PGaxVYZrI5hpLr+ASvWIvu/5alZEKoSpOmfMCxu04nXBQHc6ODA5A52X3WnM9Y5kesn p3VYTEAWlOyGp08RzVgToL+9tLhaMwQVHkDLccUpAzKvKLM2uDtRDv5JE1Tf8wUEf17a 2Ww9j8jUrdVpQ9T4Ob4HaWSnwKHjfknWN+kdMO+QH6N4P/VSTdRNd0tgKBdc88BJ82tv pZ7A== X-Gm-Message-State: AFeK/H2FcmX1pBqZiV5PcOy90aPHcyWUPn2QhCWtouz8GLPekquE5ncy/p9TJe/F/eEAQFmwMQYWcSjxKEANiw== X-Received: by 10.36.206.6 with SMTP id v6mr1499236itg.48.1490833349615; Wed, 29 Mar 2017 17:22:29 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.35.213 with HTTP; Wed, 29 Mar 2017 17:22:29 -0700 (PDT) In-Reply-To: <60012DA8-3C6E-40A8-94DF-D6F97C9B7A1E@apple.com> References: <22748.10958.314148.242611@fireball.acr.fi> <6BA2AA95-11A1-4A6E-B606-2DE8D4A07785@gmail.com> <60012DA8-3C6E-40A8-94DF-D6F97C9B7A1E@apple.com> From: Daniel Migault Date: Wed, 29 Mar 2017 19:22:29 -0500 X-Google-Sender-Auth: 1R84incAJXdSaPy99QCf95s_lLk Message-ID: To: David Schinazi Cc: "IPsecme WG (ipsec@ietf.org)" , Yoav Nir , Tero Kivinen Content-Type: multipart/alternative; boundary=94eb2c0b0c583927fa054be7b081 Archived-At: Subject: Re: [IPsec] Starting two week working group adoptation call for draft-mglt-ipsecme-implicit-iv X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 00:22:33 -0000 --94eb2c0b0c583927fa054be7b081 Content-Type: text/plain; charset=UTF-8 Hi, I am also supporting the draft as a co-author. Yours, Daniel On Wed, Mar 29, 2017 at 5:03 PM, David Schinazi wrote: > Hello all, > > I strongly support adoption of this document. > I have read it and implemented it. > The document reads well, and allows independent implementations. > I personally think Implicit IV is a great step forward for IKEv2/IPsec, > even outside of IoT. > > Regards, > David Schinazi > > > > On Mar 29, 2017, at 16:58, Yoav Nir wrote: > > > > Not surprising (me being a co-author) but I support adoption. > > > >> On 29 Mar 2017, at 16:44, Tero Kivinen wrote: > >> > >> As discussed in the meeting, we are starting two week working group > >> adoptation call for the draft-mglt-ipsecme-implicit-iv. > >> > >> Please read the draft and send your comments to this list, and also > >> tell if you support adoptation of this draft as WG draft. > >> > >> The document is available at > >> https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ > >> -- > >> kivinen@iki.fi > >> > >> _______________________________________________ > >> 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 > --94eb2c0b0c583927fa054be7b081 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I am also supporting the = draft as a co-author.

Yours,
Daniel

On Wed, Mar 29, 2017 at= 5:03 PM, David Schinazi <dschinazi@apple.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Hello all,

I strongly support adoption of this document.
I have read it and implemented it.
The document reads well, and allows independent implementations.
I personally think Implicit IV is a great step forward for IKEv2/IPsec, eve= n outside of IoT.

Regards,
David Schinazi


> On Mar 29, 2017, at 16:58, Yoav Nir <ynir.ietf@gmail.com> wrote:
>
> Not surprising (me being a co-author) but I support adoption.
>
>> On 29 Mar 2017, at 16:44, Tero Kivinen <kivinen@iki.fi> wrote:
>>
>> As discussed in the meeting, we are starting two week working grou= p
>> adoptation call for the draft-mglt-ipsecme-implicit-iv.
>>
>> Please read the draft and send your comments to this list, and als= o
>> tell if you support adoptation of this draft as WG draft.
>>
>> The document is available at
>> https://datatracker.ietf.or= g/doc/draft-mglt-ipsecme-implicit-iv/
>> --
>> kivinen@iki.fi
>>
>> _______________________________________________
>> 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

--94eb2c0b0c583927fa054be7b081-- From nobody Thu Mar 30 09:23:15 2017 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 CFA931297AA for ; Thu, 30 Mar 2017 09:23:13 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 LdosqG372lxq for ; Thu, 30 Mar 2017 09:23:10 -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 8F449129865 for ; Thu, 30 Mar 2017 09:23:09 -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 A476394A251; Thu, 30 Mar 2017 18:23:07 +0200 (CEST) From: "Tobias Guggemos" To: "'Daniel Migault'" , "David Schinazi" Cc: "IPsecme WG" , "Tero Kivinen" , "Yoav Nir" References: <22748.10958.314148.242611@fireball.acr.fi> <6BA2AA95-11A1-4A6E-B606-2DE8D4A07785@gmail.com> <60012DA8-3C6E-40A8-94DF-D6F97C9B7A1E@apple.com> In-Reply-To: Date: Thu, 30 Mar 2017 18:23:07 +0200 Message-ID: <000001d2a971$eab31850$c01948f0$@nm.ifi.lmu.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D2A982.AE3CD2B0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHSqNXIoO75LUbtEEmIZXMKE0Ov/KGsPCGAgAABIQCAACb5gIABLdpQ Content-Language: de Archived-At: Subject: Re: [IPsec] Starting two week working group adoptation call for draft-mglt-ipsecme-implicit-iv X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 16:23:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01D2A982.AE3CD2B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hy,=20 We=E2=80=99ve started implementing the Implicit IV draft as a part of a = minimal implementation of ESP for the RIOT operating system [1].=20 We=E2=80=99re also planning on an implementation for Linux. For that reason (and because I=E2=80=99m also co-author ;-) ) I support = adoption! Regards Tobias =20 [1] http://riot-os.org/ =20 =20 Von: IPsec [mailto:ipsec-bounces@ietf.org] Im Auftrag von Daniel Migault Gesendet: Donnerstag, 30. M=C3=A4rz 2017 02:22 An: David Schinazi Cc: IPsecme WG (ipsec@ietf.org) ; Tero Kivinen = ; Yoav Nir Betreff: Re: [IPsec] Starting two week working group adoptation call for = draft-mglt-ipsecme-implicit-iv =20 Hi,=20 I am also supporting the draft as a co-author.=20 Yours,=20 Daniel =20 On Wed, Mar 29, 2017 at 5:03 PM, David Schinazi > wrote: Hello all, I strongly support adoption of this document. I have read it and implemented it. The document reads well, and allows independent implementations. I personally think Implicit IV is a great step forward for IKEv2/IPsec, = even outside of IoT. Regards, David Schinazi > On Mar 29, 2017, at 16:58, Yoav Nir > wrote: > > Not surprising (me being a co-author) but I support adoption. > >> On 29 Mar 2017, at 16:44, Tero Kivinen > wrote: >> >> As discussed in the meeting, we are starting two week working group >> adoptation call for the draft-mglt-ipsecme-implicit-iv. >> >> Please read the draft and send your comments to this list, and also >> tell if you support adoptation of this draft as WG draft. >> >> The document is available at >> https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ >> -- >> kivinen@iki.fi =20 >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org =20 >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org =20 > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org =20 https://www.ietf.org/mailman/listinfo/ipsec =20 ------=_NextPart_000_0001_01D2A982.AE3CD2B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hy,

We=E2=80=99ve started implementing the = Implicit IV draft as a part of a minimal implementation of ESP for the = RIOT operating system [1].

We=E2=80=99re also planning on an = implementation for Linux.

For that reason (and because I=E2=80=99m = also co-author ;-) ) I support adoption!

Regards

Tobias

 

[1] http://riot-os.org/

 

 

Von: = IPsec [mailto:ipsec-bounces@ietf.org] Im Auftrag von Daniel = Migault
Gesendet: Donnerstag, 30. M=C3=A4rz 2017 = 02:22
An: David Schinazi = <dschinazi@apple.com>
Cc: IPsecme WG (ipsec@ietf.org) = <ipsec@ietf.org>; Tero Kivinen <kivinen@iki.fi>; Yoav Nir = <ynir.ietf@gmail.com>
Betreff: Re: [IPsec] Starting two = week working group adoptation call for = draft-mglt-ipsecme-implicit-iv

 

Hi, =

I am also supporting the draft as a = co-author.

Yours, =

Daniel

 

On Wed, = Mar 29, 2017 at 5:03 PM, David Schinazi <dschinazi@apple.com> = wrote:

Hello = all,

I strongly support adoption of this document.
I have read = it and implemented it.
The document reads well, and allows = independent implementations.
I personally think Implicit IV is a = great step forward for IKEv2/IPsec, even outside of = IoT.

Regards,
David Schinazi



> On Mar 29, 2017, at 16:58, Yoav Nir = <ynir.ietf@gmail.com> = wrote:
>
> Not surprising (me being a co-author) but I = support adoption.
>
>> On 29 Mar 2017, at 16:44, Tero = Kivinen <kivinen@iki.fi> = wrote:
>>
>> As discussed in the meeting, we are = starting two week working group
>> adoptation call for the = draft-mglt-ipsecme-implicit-iv.
>>
>> Please read the = draft and send your comments to this list, and also
>> tell if = you support adoptation of this draft as WG = draft.
>>
>> The document is available at
>> = https://datatracker.ietf.org/doc/draft-mglt-ipsecme-imp= licit-iv/
>> --
>> kivinen@iki.fi
>>
>>= _______________________________________________
>> 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

 

------=_NextPart_000_0001_01D2A982.AE3CD2B0-- From nobody Fri Mar 31 07:48:02 2017 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 9E0681299D4 for ; Fri, 31 Mar 2017 07:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 0hMRE4Vh8BMI for ; Fri, 31 Mar 2017 07:47:59 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.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 30629129998 for ; Fri, 31 Mar 2017 07:47: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=1490971658; 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=6bFRfZaJkiQjTWL5JzhW8E1JJDGumaLJ+6ELimmbQ9k=; b=fAeEbNXCTIfq8j2GGrFFLVPuw6C7dfJjLpN4ySEe+7wJoUOswH6G9Tfof0koEYBW YS0H9IfoyorondFehCyW9EQwm4I/1Z/1HjeD0YUiMnlG4BX+KtvYe/4PgnPK1X5G ibdxLUxSTeZ57jNxsArkDJ1t5Hssb3W0j4+2gvAbLN7lIRS4H+hYN+bEiUC4csDQ 328xSe+NZSLf2s6A3SGWcjDj/GTgMMVuLQG/zt+ue1FbXJP0rAT5FjJ9twR5b6n7 hYkteFY5bYRISNl0vhyljTaOcBclkIJjtTigxX9qvLeZtdW3rAvpaTebTq9nvsyh RAY3v/v0sgvyU/m7U45tDQ==; Received: from relay21.apple.com (relay21.apple.com [17.171.128.102]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id D5.E8.18333.90C6ED85; Fri, 31 Mar 2017 07:47:38 -0700 (PDT) X-AuditID: 11973e16-bbf9d9a00000479d-f7-58de6c0934ab Received: from ma1-mmpp-sz11.apple.com (st1-02-mail-lb2-v365-snip.apple.com [17.171.128.5]) by relay21.apple.com (Apple SCV relay) with SMTP id F1.5D.19192.80C6ED85; Fri, 31 Mar 2017 10:47:37 -0400 (EDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_sjeJ2jYSu7AAB8wVFRGR5w)" Received: from [17.168.168.221] by ma1-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ONO00L07P3BZR40@ma1-mmpp-sz11.apple.com>; Fri, 31 Mar 2017 07:47:36 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <05CD2FEE-2233-4049-84AD-471674150B6B@apple.com> Date: Fri, 31 Mar 2017 09:47:35 -0500 In-reply-to: <000001d2a971$eab31850$c01948f0$@nm.ifi.lmu.de> Cc: Daniel Migault , David Schinazi , IPsecme WG , Yoav Nir , Tero Kivinen To: Tobias Guggemos References: <22748.10958.314148.242611@fireball.acr.fi> <6BA2AA95-11A1-4A6E-B606-2DE8D4A07785@gmail.com> <60012DA8-3C6E-40A8-94DF-D6F97C9B7A1E@apple.com> <000001d2a971$eab31850$c01948f0$@nm.ifi.lmu.de> X-Mailer: Apple Mail (2.3263) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUiuLohTZcr516Ewe6HTBZTpu9hs/h+xtZi /5YXbBZHzz9ns1h67AOTA6vHr69X2Tx2zrrL7rFkyU8mj8NfF7J4/P+3nyWANYrLJiU1J7Ms tUjfLoEro/HORJaCJxMYK84ccW5g3N7A2MXIySEhYCLx8dQ5JhBbSGAdk0TfDoEuRg6weNeW kC5GLqDwWUaJ/tUd7CA1vAKCEj8m32MBsZkFwiQ2HN3FClH0jVFi2cmtrCDNwgISEpv3JILU sAmoSBz/toEZotdG4v6TG2C7hAUyJXZOOwZmswioSvx/8o0NxOYEqjnZ28gEMpNZYBujxNGV p8GaRQR0JF6d3sgCsWwak8TddxOYID6QleheOI0ZJCEhcIJNYuePB6wTGIVmIbl2FpJrZwEd yCygLjFlSi5EWFviybsLrBC2msTC34uYkMUXMLKtYhTKTczM0c3MM9dLLCjISdVLzs/dxAiK o+l2YjsYH66yOsQowMGoxMN7wvtehBBrYllxZe4hRmkOFiVxXrauuxFCAumJJanZqakFqUXx RaU5qcWHGJk4OKUaGM+cZjTw1vMwv+4Vl32rQiNcdN7yLeXSV83WHFrl58cRI8uq8XbtUq4J EyVOP0qPr56rYh68WezPpBeJz1gyeu91+Njfnro+Rq3kc6npO5Wz6wWqWIIKc16+KLWa8ado pfdNzgvfFk3PmDlzgV6hBM/Lif+DGR815T1Zaa/w32sZ04k1CqmsVkosxRmJhlrMRcWJALbW 6eqEAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUiuLqBVZcz516Ewd2LghZTpu9hs/h+xtZi /5YXbBZHzz9ns1h67AOTA6vHr69X2Tx2zrrL7rFkyU8mj8NfF7J4/P+3nyWANYrLJiU1J7Ms tUjfLoEro/HORJaCJxMYK84ccW5g3N7A2MXIwSEhYCLRtSWki5GLQ0jgLKNE/+oO9i5GTg5e AUGJH5PvsYDYzAJhEhuO7mKFKPrGKLHs5FZWkGZhAQmJzXsSQWrYBFQkjn/bwAzRayNx/8kN JhBbWCBTYue0Y2A2i4CqxP8n39hAbE6gmpO9jUwgM5kFtjFKHF15GqxZREBH4tXpjSwQy6Yx Sdx9NwGsW0JAVqJ74TTmCYz8s5AcOAvJgbOAbmIWUJeYMiUXIqwt8eTdBVYIW01i4e9FTMji CxjZVjEKFqXmJFYaGeolFhTkpOol5+duYoSEftoOxv/nDA8xCnAwKvHwnvC+FyHEmlhWXJl7 iFGCg1lJhJcpDijEm5JYWZValB9fVJqTWnyIUZqDRUmc1/X0nQghgfTEktTs1NSC1CKYLBMH p1QDY9vLf6sjuDlyJ69SUKq4o1n+9qLWntO33iQ4zpn6S060P6H/at0Rwf4F7hOO5X2d/1Kj 9P/htMs+Xx2+aB5YFpbQ0mwp9Eqrg+mD4vW/P24VsC2y+tZXbu8ycVPeq3cb9VfcXfX40lLz l3n1zX3vpBg9lzRVT3xuJBe3fZ1x4jO+/yz8Uu2dp5VYijMSDbWYi4oTARXLd0d5AgAA Archived-At: Subject: Re: [IPsec] Starting two week working group adoptation call for draft-mglt-ipsecme-implicit-iv X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 14:48:02 -0000 --Boundary_(ID_sjeJ2jYSu7AAB8wVFRGR5w) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable +1 supporting adoption =E2=80=94Tommy > On Mar 30, 2017, at 11:23 AM, Tobias Guggemos = wrote: >=20 > Hy,=20 > We=E2=80=99ve started implementing the Implicit IV draft as a part of = a minimal implementation of ESP for the RIOT operating system [1].=20 > We=E2=80=99re also planning on an implementation for Linux. > For that reason (and because I=E2=80=99m also co-author ;-) ) I = support adoption! > Regards > Tobias > =20 > [1] http://riot-os.org/ > =20 > =C2=A0 <> > Von: IPsec [mailto:ipsec-bounces@ietf.org] Im Auftrag von Daniel = Migault > Gesendet: Donnerstag, 30. M=C3=A4rz 2017 02:22 > An: David Schinazi > Cc: IPsecme WG (ipsec@ietf.org) ; Tero Kivinen = ; Yoav Nir > Betreff: Re: [IPsec] Starting two week working group adoptation call = for draft-mglt-ipsecme-implicit-iv > =20 > Hi,=20 >=20 > I am also supporting the draft as a co-author.=20 >=20 > Yours,=20 > Daniel > =20 > On Wed, Mar 29, 2017 at 5:03 PM, David Schinazi > wrote: >> Hello all, >>=20 >> I strongly support adoption of this document. >> I have read it and implemented it. >> The document reads well, and allows independent implementations. >> I personally think Implicit IV is a great step forward for = IKEv2/IPsec, even outside of IoT. >>=20 >> Regards, >> David Schinazi >>=20 >>=20 >> > On Mar 29, 2017, at 16:58, Yoav Nir > wrote: >> > >> > Not surprising (me being a co-author) but I support adoption. >> > >> >> On 29 Mar 2017, at 16:44, Tero Kivinen > wrote: >> >> >> >> As discussed in the meeting, we are starting two week working = group >> >> adoptation call for the draft-mglt-ipsecme-implicit-iv. >> >> >> >> Please read the draft and send your comments to this list, and = also >> >> tell if you support adoptation of this draft as WG draft. >> >> >> >> The document is available at >> >> https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ = >> >> -- >> >> kivinen@iki.fi >> >> >> >> _______________________________________________ >> >> 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 = >>=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_sjeJ2jYSu7AAB8wVFRGR5w) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable
+1 supporting adoption
=E2=80=94Tommy

On = Mar 30, 2017, at 11:23 AM, Tobias Guggemos <guggemos@nm.ifi.lmu.de> wrote:

Hy, 
We=E2=80=99ve started = implementing the Implicit IV draft as a part of a minimal implementation = of ESP for the RIOT operating system [1]. 
We=E2=80=99re also = planning on an implementation for Linux.
For that reason (and = because I=E2=80=99m also co-author ;-) ) I support adoption!
Regards
Tobias
 
 
 
Von: IPsec [mailto:ipsec-bounces@ietf.org] Im Auftrag = von Daniel = Migault
Gesendet: Donnerstag, 30. M=C3=A4rz = 2017 02:22
An: David Schinazi <dschinazi@apple.com>
Cc: IPsecme WG (ipsec@ietf.org) <ipsec@ietf.org>; Tero = Kivinen <kivinen@iki.fi>; Yoav Nir <ynir.ietf@gmail.com>
Betreff: Re: [IPsec] Starting two = week working group adoptation call for = draft-mglt-ipsecme-implicit-iv
 

Hi, 

I am = also supporting the draft as a co-author. 

Yours, 
Daniel
 
On Wed, Mar 29, 2017 = at 5:03 PM, David Schinazi <dschinazi@apple.com> wrote:
Hello = all,

I strongly support adoption of this = document.
I have read it and implemented it.
The document reads well, and allows independent = implementations.
I personally think Implicit IV is a great = step forward for IKEv2/IPsec, even outside of IoT.

Regards,
David Schinazi


> On Mar = 29, 2017, at 16:58, Yoav Nir <ynir.ietf@gmail.com> wrote:
>
> Not surprising (me being a co-author) but I support = adoption.
>
>> On 29 Mar 2017, at = 16:44, Tero Kivinen <kivinen@iki.fi> = wrote:
>>
>> As discussed in the = meeting, we are starting two week working group
>> = adoptation call for the draft-mglt-ipsecme-implicit-iv.
>>
>> Please read the draft and = send your comments to this list, and also
>> tell if = you support adoptation of this draft as WG draft.
>>
>> The document is available = at
>> https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv= /
>> --
>> kivinen@iki.fi
>>
>> _______________________________________________
>> 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
 
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Boundary_(ID_sjeJ2jYSu7AAB8wVFRGR5w)-- From nobody Fri Mar 31 08:23:57 2017 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 8D5481296A8 for ; Fri, 31 Mar 2017 08:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 8zZDL52qaict for ; Fri, 31 Mar 2017 08:23:52 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 713FF1298B7 for ; Fri, 31 Mar 2017 08:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28866; q=dns/txt; s=iport; t=1490973825; x=1492183425; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1xV6YzDv7T0NEj94Y5RL7I17p37JJ3PW8rhEEu6nYNA=; b=HIkYhqpPZC+BnjDo/AmXRzppfC4WnsxDerSsiZO9KPfnvYz0K/Lr5v5S UfOSC1LdYwEwElL3GvqtmuOvTowEkaClO5qldfyZfoBOo9OFiVP9W2TM6 xKcSaB85DUYzlUpGnHnIf0jBj0DDOSAMn5jqsj9ont71zycn8dP6XzEhi 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DwAQA3c95Y/5tdJa1ZAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJuZmGBCweDW4oSkVWIGY03gg4fAQqFeAIagyw/GAECAQEBAQE?= =?us-ascii?q?BAWsohRUBAQEBAgEBARsGSwsFCwIBCBAIIAcDAgICHwYLFBECBA4FiXUDDQgOr?= =?us-ascii?q?WiCJocrDYMjAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYhTgmqCUYFVEQEzChUICYI?= =?us-ascii?q?/LoIxBYoLkiQ7AYZ8hxuEOIF9hSyDWYY4inaIegEfOD4/CFsVQREBhH2BSnWHL?= =?us-ascii?q?YEhgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,252,1486425600"; d="scan'208,217";a="402786116" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Mar 2017 15:23:44 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2VFNh4B019931 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 31 Mar 2017 15:23:44 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 31 Mar 2017 11:23:43 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1210.000; Fri, 31 Mar 2017 11:23:43 -0400 From: "Brian Weis (bew)" To: Tero Kivinen CC: Tobias Guggemos , Tommy Pauly , IPsecme WG , Daniel Migault , David Schinazi , Yoav Nir Thread-Topic: [IPsec] Starting two week working group adoptation call for draft-mglt-ipsecme-implicit-iv Thread-Index: AQHSqjLIzAFriZEshUCTkL/cwAjVJg== Date: Fri, 31 Mar 2017 15:23:43 +0000 Message-ID: References: <22748.10958.314148.242611@fireball.acr.fi> <6BA2AA95-11A1-4A6E-B606-2DE8D4A07785@gmail.com> <60012DA8-3C6E-40A8-94DF-D6F97C9B7A1E@apple.com> <000001d2a971$eab31850$c01948f0$@nm.ifi.lmu.de> <05CD2FEE-2233-4049-84AD-471674150B6B@apple.com> In-Reply-To: <05CD2FEE-2233-4049-84AD-471674150B6B@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.48.48] Content-Type: multipart/alternative; boundary="_000_BD3CC4F0AC2944CF9C341FF00C6778A0ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Starting two week working group adoptation call for draft-mglt-ipsecme-implicit-iv X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2017 15:23:56 -0000 --_000_BD3CC4F0AC2944CF9C341FF00C6778A0ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IGFkb3B0aW9uLCBiZWNhdXNlIEkgdGhpbmsgaXQgd2lsbCBiZSB1c2VmdWwgaW4g c29tZSB1c2UgY2FzZXMuIEJ1dCBJ4oCZbSB3YXJ5IG9mIGltcGxpY2l0IElWcyBiZWluZyBnZW5l cmFsbHkgdXNlZCB3aXRoIGNvdW50ZXIgbW9kZSBjaXBoZXJzLg0KDQpUaGUgU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMgbmVlZHMgdG8gcHJvdmlkZSBzb21lIGludGVuc2Ugd2FybmluZ3MgYWdhaW5z dCB0aGUgcmV1c2Ugb2YgY291bnRlcnMuIEFzIFNlY3Rpb24gNCBzYXlzLCAiV2l0aCB0aGUgYWxn b3JpdGhtcyBsaXN0ZWQgaW4gU2VjdGlvbiAyLCB0aGUgOCBieXRlIG5vbmNlIE1VU1QgTk9UIHJl cGVhdC7igJ0gQnV0IGlmIGFuIGltcGxlbWVudGF0aW9uIGlzIG5vdCBjYXJlZnVsLCB0aGVyZSBh cmUgYXQgbGVhc3QgdHdvIHdheXMgaW4gd2hpY2ggYW4gaW1wbGVtZW50YXRpb24gY2FuIGRvIHRo aXMsIHBlcmhhcHMgdW53aXR0aW5nbHkuDQoNCigxKSBXaGVuIHRoZSBzZXF1ZW5jZSBudW1iZXIg Z2VuZXJhdGlvbiBsb2dpYyBpcyBvdXRzaWRlIG9mIHRoZSBzYW1lIGNyeXB0byBib3VuZGFyeSBh cyB0aGUgY2lwaGVyIHByb2Nlc3NpbmcsIHRoZW4gdGhlcmUgaXMgdGhlIHJpc2sgdGhhdCBjaXBo ZXIgY2FuIGJlIGZvb2xlZCBpbnRvIG5vbmNlIHJldXNlIGJ5IGFuIGF0dGFja2VyIHdobyBzZXRz IHRoZSBzZXF1ZW5jZSBudW1iZXIgdG8gYSBzbWFsbGVyIHZhbHVlLg0KDQooMikgVGhlcmUgbWF5 IGJlIG1hbmFnZW1lbnQgb3BlcmF0aW9ucyBhbGxvd2luZyB0aGUgc2V0dGluZyBvciByZS1zZXR0 aW5nIHRoZSBzZXF1ZW5jZSBudW1iZXIgZm9yIGFuIFNBLCB3aGljaCBmb3IgYW4gU0Egd2l0aCBh biBpbXBsaWNpdCBJViB3aWxsIGFsc28gY2F1c2UgdGhlIGNvdW50ZXIgbW9kZSB0byByZXVzZSB2 YWx1ZXMgd2hlbiBpdCBpcyBzZXQgdG8gYSBzbWFsbGVyIHZhbHVlLg0KDQpJbiBib3RoIG9mIHRo ZXNlIGNhc2VzLCB0aGUgY2lwaGVyIGNvZGUgaXRzZWxmIHdpbGwgbm8gbG9uZ2VyIGJlIGFibGUg dG8gZ3VhcmFudGVlIHRoYXQgdGhhdCB0aGUgbm9uY2UgaXMgbm90IHJldXNlZC4gVGhpcyBpcyBh IHNlcmlvdXMgcmVhbC13b3JsZCBpc3N1ZS4NCg0KVGhhbmtzLA0KQnJpYW4NCg0KDQpPbiBNYXIg MzEsIDIwMTcsIGF0IDk6NDcgQU0sIFRvbW15IFBhdWx5IDx0cGF1bHlAYXBwbGUuY29tPG1haWx0 bzp0cGF1bHlAYXBwbGUuY29tPj4gd3JvdGU6DQoNCisxIHN1cHBvcnRpbmcgYWRvcHRpb24NCg0K 4oCUVG9tbXkNCg0KT24gTWFyIDMwLCAyMDE3LCBhdCAxMToyMyBBTSwgVG9iaWFzIEd1Z2dlbW9z IDxndWdnZW1vc0BubS5pZmkubG11LmRlPG1haWx0bzpndWdnZW1vc0BubS5pZmkubG11LmRlPj4g d3JvdGU6DQoNCkh5LA0KV2XigJl2ZSBzdGFydGVkIGltcGxlbWVudGluZyB0aGUgSW1wbGljaXQg SVYgZHJhZnQgYXMgYSBwYXJ0IG9mIGEgbWluaW1hbCBpbXBsZW1lbnRhdGlvbiBvZiBFU1AgZm9y IHRoZSBSSU9UIG9wZXJhdGluZyBzeXN0ZW0gWzFdLg0KV2XigJlyZSBhbHNvIHBsYW5uaW5nIG9u IGFuIGltcGxlbWVudGF0aW9uIGZvciBMaW51eC4NCkZvciB0aGF0IHJlYXNvbiAoYW5kIGJlY2F1 c2UgSeKAmW0gYWxzbyBjby1hdXRob3IgOy0pICkgSSBzdXBwb3J0IGFkb3B0aW9uIQ0KUmVnYXJk cw0KVG9iaWFzDQoNClsxXSBodHRwOi8vcmlvdC1vcy5vcmcvDQoNCg0KVm9uOiBJUHNlYyBbbWFp bHRvOmlwc2VjLWJvdW5jZXNAaWV0Zi5vcmddIEltIEF1ZnRyYWcgdm9uIERhbmllbCBNaWdhdWx0 DQpHZXNlbmRldDogRG9ubmVyc3RhZywgMzAuIE3DpHJ6IDIwMTcgMDI6MjINCkFuOiBEYXZpZCBT Y2hpbmF6aSA8ZHNjaGluYXppQGFwcGxlLmNvbTxtYWlsdG86ZHNjaGluYXppQGFwcGxlLmNvbT4+ DQpDYzogSVBzZWNtZSBXRyAoaXBzZWNAaWV0Zi5vcmc8bWFpbHRvOmlwc2VjQGlldGYub3JnPikg PGlwc2VjQGlldGYub3JnPG1haWx0bzppcHNlY0BpZXRmLm9yZz4+OyBUZXJvIEtpdmluZW4gPGtp dmluZW5AaWtpLmZpPG1haWx0bzpraXZpbmVuQGlraS5maT4+OyBZb2F2IE5pciA8eW5pci5pZXRm QGdtYWlsLmNvbTxtYWlsdG86eW5pci5pZXRmQGdtYWlsLmNvbT4+DQpCZXRyZWZmOiBSZTogW0lQ c2VjXSBTdGFydGluZyB0d28gd2VlayB3b3JraW5nIGdyb3VwIGFkb3B0YXRpb24gY2FsbCBmb3Ig ZHJhZnQtbWdsdC1pcHNlY21lLWltcGxpY2l0LWl2DQoNCkhpLA0KSSBhbSBhbHNvIHN1cHBvcnRp bmcgdGhlIGRyYWZ0IGFzIGEgY28tYXV0aG9yLg0KWW91cnMsDQpEYW5pZWwNCg0KT24gV2VkLCBN YXIgMjksIDIwMTcgYXQgNTowMyBQTSwgRGF2aWQgU2NoaW5hemkgPGRzY2hpbmF6aUBhcHBsZS5j b208bWFpbHRvOmRzY2hpbmF6aUBhcHBsZS5jb20+PiB3cm90ZToNCkhlbGxvIGFsbCwNCg0KSSBz dHJvbmdseSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQuDQpJIGhhdmUgcmVhZCBp dCBhbmQgaW1wbGVtZW50ZWQgaXQuDQpUaGUgZG9jdW1lbnQgcmVhZHMgd2VsbCwgYW5kIGFsbG93 cyBpbmRlcGVuZGVudCBpbXBsZW1lbnRhdGlvbnMuDQpJIHBlcnNvbmFsbHkgdGhpbmsgSW1wbGlj aXQgSVYgaXMgYSBncmVhdCBzdGVwIGZvcndhcmQgZm9yIElLRXYyL0lQc2VjLCBldmVuIG91dHNp ZGUgb2YgSW9ULg0KDQpSZWdhcmRzLA0KRGF2aWQgU2NoaW5hemkNCg0KDQo+IE9uIE1hciAyOSwg MjAxNywgYXQgMTY6NTgsIFlvYXYgTmlyIDx5bmlyLmlldGZAZ21haWwuY29tPG1haWx0bzp5bmly LmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQo+DQo+IE5vdCBzdXJwcmlzaW5nIChtZSBiZWluZyBh IGNvLWF1dGhvcikgYnV0IEkgc3VwcG9ydCBhZG9wdGlvbi4NCj4NCj4+IE9uIDI5IE1hciAyMDE3 LCBhdCAxNjo0NCwgVGVybyBLaXZpbmVuIDxraXZpbmVuQGlraS5maTxtYWlsdG86a2l2aW5lbkBp a2kuZmk+PiB3cm90ZToNCj4+DQo+PiBBcyBkaXNjdXNzZWQgaW4gdGhlIG1lZXRpbmcsIHdlIGFy ZSBzdGFydGluZyB0d28gd2VlayB3b3JraW5nIGdyb3VwDQo+PiBhZG9wdGF0aW9uIGNhbGwgZm9y IHRoZSBkcmFmdC1tZ2x0LWlwc2VjbWUtaW1wbGljaXQtaXYuDQo+Pg0KPj4gUGxlYXNlIHJlYWQg dGhlIGRyYWZ0IGFuZCBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhpcyBsaXN0LCBhbmQgYWxzbw0K Pj4gdGVsbCBpZiB5b3Ugc3VwcG9ydCBhZG9wdGF0aW9uIG9mIHRoaXMgZHJhZnQgYXMgV0cgZHJh ZnQuDQo+Pg0KPj4gVGhlIGRvY3VtZW50IGlzIGF2YWlsYWJsZSBhdA0KPj4gaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWdsdC1pcHNlY21lLWltcGxpY2l0LWl2Lw0KPj4g LS0NCj4+IGtpdmluZW5AaWtpLmZpPG1haWx0bzpraXZpbmVuQGlraS5maT4NCj4+DQo+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gSVBzZWMgbWFp bGluZyBsaXN0DQo+PiBJUHNlY0BpZXRmLm9yZzxtYWlsdG86SVBzZWNAaWV0Zi5vcmc+DQo+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjDQo+DQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElQc2VjIG1haWxpbmcg bGlzdA0KPiBJUHNlY0BpZXRmLm9yZzxtYWlsdG86SVBzZWNAaWV0Zi5vcmc+DQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklQc2VjIG1haWxpbmcgbGlzdA0KSVBzZWNA aWV0Zi5vcmc8bWFpbHRvOklQc2VjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pcHNlYw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KSVBzZWMgbWFpbGluZyBsaXN0DQpJUHNlY0BpZXRmLm9yZzxtYWlsdG86 SVBzZWNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lw c2VjDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJ UHNlYyBtYWlsaW5nIGxpc3QNCklQc2VjQGlldGYub3JnPG1haWx0bzpJUHNlY0BpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMNCg0KLS0NCkJyaWFu IFdlaXMNClNlY3VyaXR5LCBDU0csIENpc2NvIFN5c3RlbXMNClRlbGVwaG9uZTogKzEgNDA4IDUy NiA0Nzk2DQpFbWFpbDogYmV3QGNpc2NvLmNvbTxtYWlsdG86YmV3QGNpc2NvLmNvbT4NCg0K --_000_BD3CC4F0AC2944CF9C341FF00C6778A0ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSSBzdXBwb3J0IGFkb3B0aW9uLCBi ZWNhdXNlIEkgdGhpbmsgaXQgd2lsbCBiZSB1c2VmdWwgaW4gc29tZSB1c2UgY2FzZXMuIEJ1dCBJ 4oCZbSB3YXJ5IG9mIGltcGxpY2l0IElWcyBiZWluZyBnZW5lcmFsbHkgdXNlZCB3aXRoIGNvdW50 ZXIgbW9kZSBjaXBoZXJzLg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+VGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIG5lZWRzIHRvIHByb3ZpZGUg c29tZSBpbnRlbnNlIHdhcm5pbmdzIGFnYWluc3QgdGhlIHJldXNlIG9mIGNvdW50ZXJzLiBBcyBT ZWN0aW9uIDQgc2F5cywgJnF1b3Q7V2l0aCB0aGUgYWxnb3JpdGhtcyBsaXN0ZWQgaW4mbmJzcDtT ZWN0aW9uIDIsIHRoZSA4IGJ5dGUgbm9uY2UgTVVTVCBOT1QmbmJzcDtyZXBlYXQu4oCdIEJ1dCBp ZiBhbiBpbXBsZW1lbnRhdGlvbiBpcyBub3QgY2FyZWZ1bCwgdGhlcmUgYXJlDQogYXQgbGVhc3Qg dHdvIHdheXMgaW4gd2hpY2ggYW4gaW1wbGVtZW50YXRpb24gY2FuIGRvIHRoaXMsIHBlcmhhcHMg dW53aXR0aW5nbHkuJm5ic3A7DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+KDEpIFdoZW4gdGhlIHNlcXVlbmNlIG51bWJl ciBnZW5lcmF0aW9uIGxvZ2ljIGlzIG91dHNpZGUgb2YgdGhlIHNhbWUgY3J5cHRvIGJvdW5kYXJ5 IGFzIHRoZSBjaXBoZXIgcHJvY2Vzc2luZywgdGhlbiB0aGVyZSBpcyB0aGUgcmlzayB0aGF0IGNp cGhlciBjYW4gYmUgZm9vbGVkIGludG8gbm9uY2UgcmV1c2UgYnkgYW4gYXR0YWNrZXIgd2hvIHNl dHMgdGhlIHNlcXVlbmNlIG51bWJlciB0byBhIHNtYWxsZXIgdmFsdWUuPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4oMikgVGhlcmUgbWF5 IGJlIG1hbmFnZW1lbnQgb3BlcmF0aW9ucyBhbGxvd2luZyB0aGUgc2V0dGluZyBvciByZS1zZXR0 aW5nIHRoZSBzZXF1ZW5jZSBudW1iZXIgZm9yIGFuIFNBLCB3aGljaCBmb3IgYW4gU0Egd2l0aCBh biBpbXBsaWNpdCBJViB3aWxsIGFsc28gY2F1c2UgdGhlIGNvdW50ZXIgbW9kZSB0byByZXVzZSB2 YWx1ZXMgd2hlbiBpdCBpcyBzZXQgdG8gYSBzbWFsbGVyIHZhbHVlLjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SW4gYm90aCBvZiB0aGVz ZSBjYXNlcywgdGhlIGNpcGhlciBjb2RlIGl0c2VsZiB3aWxsIG5vIGxvbmdlciBiZSBhYmxlIHRv IGd1YXJhbnRlZSB0aGF0IHRoYXQgdGhlIG5vbmNlIGlzIG5vdCByZXVzZWQuIFRoaXMgaXMgYSBz ZXJpb3VzIHJlYWwtd29ybGQgaXNzdWUuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGFua3MsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkJy aWFuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBNYXIgMzEsIDIwMTcsIGF0IDk6 NDcgQU0sIFRvbW15IFBhdWx5ICZsdDs8YSBocmVmPSJtYWlsdG86dHBhdWx5QGFwcGxlLmNvbSIg Y2xhc3M9IiI+dHBhdWx5QGFwcGxlLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNz PSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtp dC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij4mIzQzOzEgc3VwcG9ydGluZyBhZG9wdGlvbjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+4oCUVG9tbXk8L2Rpdj4NCjxiciBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+T24gTWFyIDMwLCAyMDE3LCBhdCAxMToyMyBBTSwgVG9iaWFzIEd1Z2dlbW9z ICZsdDs8YSBocmVmPSJtYWlsdG86Z3VnZ2Vtb3NAbm0uaWZpLmxtdS5kZSIgY2xhc3M9IiI+Z3Vn Z2Vtb3NAbm0uaWZpLmxtdS5kZTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBs ZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBXb3JkU2VjdGlvbjE7IGZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIg Y2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIg Y2xhc3M9IiI+SHksPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6 IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5XZeKAmXZlIHN0YXJ0ZWQgaW1wbGVtZW50aW5n IHRoZSBJbXBsaWNpdCBJViBkcmFmdCBhcyBhIHBhcnQgb2YgYSBtaW5pbWFsIGltcGxlbWVudGF0 aW9uIG9mIEVTUCBmb3IgdGhlIFJJT1Qgb3BlcmF0aW5nIHN5c3RlbSBbMV0uPHNwYW4gY2xhc3M9 IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFz cz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFz cz0iIj5XZeKAmXJlIGFsc28gcGxhbm5pbmcgb24gYW4gaW1wbGVtZW50YXRpb24gZm9yIExpbnV4 LjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw Y20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJn YigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5Gb3IgdGhhdCByZWFzb24gKGFuZCBiZWNhdXNlIEni gJltIGFsc28gY28tYXV0aG9yIDstKSApIEkgc3VwcG9ydCBhZG9wdGlvbiE8bzpwIGNsYXNzPSIi PjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUp OyIgY2xhc3M9IiI+UmVnYXJkczxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5Ub2JpYXM8bzpwIGNs YXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAw LjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbics IHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDcz LCAxMjUpOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPlsxXTwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cDovL3Jpb3Qtb3Mub3JnLyIg c3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9 IiI+aHR0cDovL3Jpb3Qtb3Mub3JnLzwvYT48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+PG86cCBj bGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBj bSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGEgbmFtZT0iX01haWxFbmRDb21wb3NlIiBjbGFz cz0iIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9 IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvZGl2Pg0KPHNwYW4gY2xh c3M9IiI+PC9zcGFuPg0KPGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxlOiBub25lIG5vbmUgbm9uZSBz b2xpZDsgYm9yZGVyLWxlZnQtd2lkdGg6IDEuNXB0OyBib3JkZXItbGVmdC1jb2xvcjogYmx1ZTsg cGFkZGluZzogMGNtIDBjbSAwY20gNHB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0iYm9yZGVyLXN0eWxlOiBzb2xpZCBub25lIG5vbmU7IGJvcmRlci10b3Atd2lkdGg6 IDFwdDsgYm9yZGVyLXRvcC1jb2xvcjogcmdiKDIyNSwgMjI1LCAyMjUpOyBwYWRkaW5nOiAzcHQg MGNtIDBjbTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0 OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Vm9uOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+SVBzZWMgWzxhIGhyZWY9Im1haWx0bzppcHNlYy1ib3VuY2VzQGlldGYub3JnIiBj bGFzcz0iIj5tYWlsdG86aXBzZWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dPHNwYW4gY2xhc3M9IkFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiIGNsYXNzPSIiPkltDQogQXVmdHJh ZyB2b248c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9i PkRhbmllbCBNaWdhdWx0PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+R2VzZW5kZXQ6PC9iPjxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5Eb25uZXJzdGFn LCAzMC4gTcOkcnogMjAxNyAwMjoyMjxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPkFuOjwvYj48 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RGF2aWQgU2No aW5hemkgJmx0OzxhIGhyZWY9Im1haWx0bzpkc2NoaW5hemlAYXBwbGUuY29tIiBjbGFzcz0iIj5k c2NoaW5hemlAYXBwbGUuY29tPC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5DYzo8 L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPklQc2Vj bWUgV0cgKDxhIGhyZWY9Im1haWx0bzppcHNlY0BpZXRmLm9yZyIgY2xhc3M9IiI+aXBzZWNAaWV0 Zi5vcmc8L2E+KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlwc2VjQGlldGYub3JnIiBjbGFzcz0iIj5p cHNlY0BpZXRmLm9yZzwvYT4mZ3Q7OyBUZXJvIEtpdmluZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpr aXZpbmVuQGlraS5maSIgY2xhc3M9IiI+a2l2aW5lbkBpa2kuZmk8L2E+Jmd0OzsNCiBZb2F2IE5p ciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnluaXIuaWV0ZkBnbWFpbC5jb20iIGNsYXNzPSIiPnluaXIu aWV0ZkBnbWFpbC5jb208L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPkJldHJlZmY6 PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTog W0lQc2VjXSBTdGFydGluZyB0d28gd2VlayB3b3JraW5nIGdyb3VwIGFkb3B0YXRpb24gY2FsbCBm b3IgZHJhZnQtbWdsdC1pcHNlY21lLWltcGxpY2l0LWl2PG86cCBjbGFzcz0iIj48L286cD48L3Nw YW4+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAxMnB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCkhp LDxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNs YXNzPSIiPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbjogMGNtIDBjbSAxMnB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7Ij4NCkkgYW0gYWxzbyBzdXBwb3J0aW5nIHRoZSBkcmFmdCBhcyBh IGNvLWF1dGhvci48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PG86cCBjbGFzcz0iIj48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpZb3Vycyw8c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCkRh bmllbDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFz cz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KT24gV2VkLCBNYXIgMjksIDIwMTcgYXQg NTowMyBQTSwgRGF2aWQgU2NoaW5hemkgJmx0OzxhIGhyZWY9Im1haWx0bzpkc2NoaW5hemlAYXBw bGUuY29tIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3Jh dGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+ZHNjaGluYXppQGFwcGxlLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy LXN0eWxlOiBub25lIG5vbmUgbm9uZSBzb2xpZDsgYm9yZGVyLWxlZnQtd2lkdGg6IDFwdDsgYm9y ZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgcGFkZGluZzogMGNtIDBjbSAwY20g NnB0OyBtYXJnaW4tbGVmdDogNC44cHQ7IG1hcmdpbi1yaWdodDogMGNtOyIgY2xhc3M9IiIgdHlw ZT0iY2l0ZSI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi Pg0KSGVsbG8gYWxsLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkkgc3Ryb25nbHkgc3Vw cG9ydCBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50LjxiciBjbGFzcz0iIj4NCkkgaGF2ZSByZWFk IGl0IGFuZCBpbXBsZW1lbnRlZCBpdC48YnIgY2xhc3M9IiI+DQpUaGUgZG9jdW1lbnQgcmVhZHMg d2VsbCwgYW5kIGFsbG93cyBpbmRlcGVuZGVudCBpbXBsZW1lbnRhdGlvbnMuPGJyIGNsYXNzPSIi Pg0KSSBwZXJzb25hbGx5IHRoaW5rIEltcGxpY2l0IElWIGlzIGEgZ3JlYXQgc3RlcCBmb3J3YXJk IGZvciBJS0V2Mi9JUHNlYywgZXZlbiBvdXRzaWRlIG9mIElvVC48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpSZWdhcmRzLDxiciBjbGFzcz0iIj4NCkRhdmlkIFNjaGluYXppPG86cCBjbGFz cz0iIj48L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCiZndDsgT24gTWFyIDI5LCAyMDE3LCBhdCAxNjo1OCwgWW9hdiBOaXIg Jmx0OzxhIGhyZWY9Im1haWx0bzp5bmlyLmlldGZAZ21haWwuY29tIiBzdHlsZT0iY29sb3I6IHB1 cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj55bmlyLmlldGZAZ21h aWwuY29tPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZn dDsgTm90IHN1cnByaXNpbmcgKG1lIGJlaW5nIGEgY28tYXV0aG9yKSBidXQgSSBzdXBwb3J0IGFk b3B0aW9uLjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBPbiAyOSBN YXIgMjAxNywgYXQgMTY6NDQsIFRlcm8gS2l2aW5lbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtpdmlu ZW5AaWtpLmZpIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxp bmU7IiBjbGFzcz0iIj5raXZpbmVuQGlraS5maTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgQXMgZGlzY3Vzc2VkIGluIHRoZSBtZWV0 aW5nLCB3ZSBhcmUgc3RhcnRpbmcgdHdvIHdlZWsgd29ya2luZyBncm91cDxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7IGFkb3B0YXRpb24gY2FsbCBmb3IgdGhlIGRyYWZ0LW1nbHQtaXBzZWNtZS1pbXBs aWNpdC1pdi48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IFBs ZWFzZSByZWFkIHRoZSBkcmFmdCBhbmQgc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoaXMgbGlzdCwg YW5kIGFsc288YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyB0ZWxsIGlmIHlvdSBzdXBwb3J0IGFkb3B0 YXRpb24gb2YgdGhpcyBkcmFmdCBhcyBXRyBkcmFmdC48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0Ozxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7IFRoZSBkb2N1bWVudCBpcyBhdmFpbGFibGUgYXQ8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1t Z2x0LWlwc2VjbWUtaW1wbGljaXQtaXYvIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBw dXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWdsdC1pcHNlY21lLWltcGxpY2l0LWl2LzwvYT48 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAtLTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7PHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpr aXZpbmVuQGlraS5maSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5k ZXJsaW5lOyIgY2xhc3M9IiI+a2l2aW5lbkBpa2kuZmk8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZn dDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IElQc2VjIG1haWxpbmcgbGlz dDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpJUHNlY0BpZXRmLm9yZyIgc3R5bGU9ImNv bG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+SVBzZWNA aWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyZndDs8c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pcHNlYyIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogcHVy cGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWM8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OzxiciBj bGFzcz0iIj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnIgY2xhc3M9IiI+DQomZ3Q7IElQc2VjIG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4N CiZndDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEg aHJlZj0ibWFpbHRvOklQc2VjQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1k ZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5JUHNlY0BpZXRmLm9yZzwvYT48YnIgY2xh c3M9IiI+DQomZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMi IHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1 bmRlcmxpbmU7IiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lwc2VjPC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KSVBzZWMgbWFpbGlu ZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOklQc2VjQGlldGYub3JnIiBzdHls ZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5J UHNlY0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9y OiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYzwvYT48bzpwIGNsYXNzPSIiPjwvbzpw PjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5i c3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlu bGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1j YXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50 OyIgY2xhc3M9IiI+SVBzZWMNCiBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZh bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlu bGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+PGEgaHJlZj0ibWFpbHRvOklQc2VjQGlldGYub3Jn IiBjbGFzcz0iIj5JUHNlY0BpZXRmLm9yZzwvYT48L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGlu ZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pcHNlYyIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pcHNlYzwvYT48L3NwYW4+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpJUHNlYyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9 IiI+DQo8YSBocmVmPSJtYWlsdG86SVBzZWNAaWV0Zi5vcmciIGNsYXNzPSIiPklQc2VjQGlldGYu b3JnPC9hPjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaXBzZWM8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJy IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4tLSZuYnNwOzxiciBjbGFzcz0iIj4NCkJyaWFuIFdl aXM8YnIgY2xhc3M9IiI+DQpTZWN1cml0eSwgQ1NHLCBDaXNjbyBTeXN0ZW1zPGJyIGNsYXNzPSIi Pg0KVGVsZXBob25lOiAmIzQzOzEgNDA4IDUyNiA0Nzk2PGJyIGNsYXNzPSIiPg0KRW1haWw6IDxh IGhyZWY9Im1haWx0bzpiZXdAY2lzY28uY29tIiBjbGFzcz0iIj5iZXdAY2lzY28uY29tPC9hPiA8 L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_BD3CC4F0AC2944CF9C341FF00C6778A0ciscocom_-- From nobody Fri Mar 31 23:52:39 2017 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 9C109128C81 for ; Fri, 31 Mar 2017 23:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 wyC82kJojLpq for ; Fri, 31 Mar 2017 23:52:35 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFF901270B4 for ; Fri, 31 Mar 2017 23:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7385; q=dns/txt; s=iport; t=1491029555; x=1492239155; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=7HzR8KcjbJcczDYOWtGgg6gJWF8OdHXZJf9ZA8q9tDQ=; b=TzO1mBjvoj73fgNcU+it4Ex1vUSmjETWxuYkaP3RuEm3QZdMawngwkVl HgmsQL4+iaIAllvFnUVBhg3M+BK3UtMKc8joHQrgpSOeL+C5G9u3ZO3Gw nkp4Qc5J+3bstqU5g+sB8rBdLyNcnu2WLWrWSiYz1xp8fDpaAscCd4T2T Y=; X-Files: smime.p7s : 4557 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BgAgDSTd9Y/4sNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQsHg1uKEqcmgg4fC4V4AiODJj8YAQIBAQEBAQEBayiFFgI?= =?us-ascii?q?BAwEBGwZLGwIBCEICAgIlCyUCBAESDol/DqlagiaKXgEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQ4KBYZOggWCaoRrgm8ugjEFnGoBg3uCDHWLU4F9hSyDWYY4k3ABHzg?= =?us-ascii?q?+R1sVQREBhH2BSnWJMYENAQEB?= X-IronPort-AV: E=Sophos;i="5.36,256,1486425600"; d="p7s'?scan'208";a="231069466" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Apr 2017 06:52:09 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v316q8JI006841 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 1 Apr 2017 06:52:08 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 1 Apr 2017 01:52:08 -0500 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1210.000; Sat, 1 Apr 2017 01:52:07 -0500 From: "Graham Bartlett (grbartle)" To: Tero Kivinen , "ipsec@ietf.org" Thread-Topic: [IPsec] Starting two week working group adoptation call for draft-mglt-ipsecme-implicit-iv Thread-Index: AQHSqNW5zddYbQrXekWiLjqOpdiUYKGv22MA Date: Sat, 1 Apr 2017 06:52:07 +0000 Message-ID: References: <22748.10958.314148.242611@fireball.acr.fi> In-Reply-To: <22748.10958.314148.242611@fireball.acr.fi> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1a.0.160910 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.142.70] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3573843464_1304712826" MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Starting two week working group adoptation call for draft-mglt-ipsecme-implicit-iv X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Apr 2017 06:52:38 -0000 --B_3573843464_1304712826 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Just a minor nit, nowhere in the draft is the term =E2=80=9CIIV=E2=80=9D defined.. cheers On 29/03/2017, 22:44, "IPsec on behalf of Tero Kivinen" wrote: As discussed in the meeting, we are starting two week working group adoptation call for the draft-mglt-ipsecme-implicit-iv. =20 Please read the draft and send your comments to this list, and also tell if you support adoptation of this draft as WG draft. =20 The document is available at https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ --=20 kivinen@iki.fi =20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 --B_3573843464_1304712826 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIRyQYJKoZIhvcNAQcCoIIRujCCEbYCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGggg9+MIIFbTCCBFWgAwIBAgIQDZu2aTrsxkrY+ilxZLyNgTANBgkqhkiG9w0BAQsFADBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTYw NTE2MDAwMDAwWhcNMTgwNTE2MTIwMDAwWjCBkDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNh bGlmb3JuaWExETAPBgNVBAcTCFNhbiBKb3NlMRwwGgYDVQQKExNDaXNjbyBTeXN0ZW1zLCBJ bmMuMRgwFgYDVQQDEw9HcmFoYW0gQmFydGxldHQxITAfBgkqhkiG9w0BCQEWEmdyYmFydGxl QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMqOS+hfMCqvKj+e gZdgQIEPbPvc6Mv9fJvK/hNbeOiOwBepKx73eSUh+gABrR8i7ui5/V7XlyMPg/OgQr/6UZX2 QGaqBNkiVkOqNDjwjDz6+voKVS2MNU0cCvxP5Xwb9VXgw2JzFAMMshknhP7G+9V6qxda7e5m fmBzYgCgewiITHD83tGiS/YuoOogmPfYnpQyCcnSdwj8MqnlvVfBQVdAOg+a7hv8zPcTA4mH H0Y3dqCIdNtj1QEm9D9YbDlCS1MZl/7byqLpEZA+la8Pva/r/lydbVuM7BXygqI+itXM9963 8kZim8zTh4r/wCi8uklBSeMRUHSmgocw5BpnIk8CAwEAAaOCAeswggHnMB8GA1UdIwQYMBaA FOcCI4AAT9jXvJQL2T90OUkyPIp5MB0GA1UdDgQWBBQmnj6AyXbjUyNRGN6Y2JOK17/CkzAM BgNVHRMBAf8EAjAAMB0GA1UdEQQWMBSBEmdyYmFydGxlQGNpc2NvLmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZI AYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hB MkFzc3VyZWRJRENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUH MAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2Vy dHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0B AQsFAAOCAQEAna7Ws4vfNhrcm0Od6wb6xiOBURSSXAgX7LE8chrD7UfTF+b7DKits6QY1Vvo 5s0ryCy2T4ikMMKzpAnQ9O0vvF5wbb2iF9zTyKv2M36uY6L6EbMC7QoQAihAiOGnLy4wwhsB qtoGHPL8f1ROW2xpK3twQm2jthhv7fzHRPnFFh4bwWLLISHsw7JKzaL1GuxghNr9W9CN7o2r OtnnvoSwdkPBlMmquWrUgCZ06UQfsD6nbVDvqlBlJGBsrfXk3y8yg3q+rN6LTqHccW4Rk1KS OkE8i/8NKTo8QXHSOa+jcK0o7mnjGXERklDnFGMiNVLbVhVa9CJynUpLjNct3q6+ATCCBk4w ggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMC VVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAwMFoX DTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZ MBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1 cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/AJ3kb LQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAf JUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ 9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1x GOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgw BgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0 LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6 Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1s AAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQG CCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUA cgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAA dABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAA UwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIA ZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQA eQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUA aQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8lAvZ P3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQEL BQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mg VgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0 k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEy br1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3MIIC n6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYTAlVT MRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0z MTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAX BgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQg Um9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5 cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+Y MjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nY Lxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGY M2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSS plazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8G A1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQY MBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w43Jz emSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbGeasS 2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59PyvztyY1 bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2BxZ/ N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdhAbHS oyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYICDzCCAgsCAQEweTBlMQswCQYDVQQG EwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29t MSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA2btmk67MZK2PopcWS8 jYEwDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgNKqOdx015WZyp5bTpiHKAkcl BTa8wBeKylH77lQ1dxwwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTcwMzMxMjExNzQ0WjANBgkqhkiG9w0BAQEFAASCAQBHrJ7HVxBgfkoSUI+3osZQ6YSk IHC1SfoTpcwSfGmUhoeiIAb5cTaq3zAHHYTS+S02jan0vcyBJFhW+ZUFqqIe0zHJUJD/KHqg +ao8XGtTyb5+EaRIpBAijh2mvlBesd49tZelAeREBxGozyRAfyqJgy0jJ5NX9RVpN5DOOUol vMHEY+BhPMg1zputdeuRgR3Urzfl79mW2vPrDk7f4WHcN8pZisn2LoWYFT1aJ8Gqo00NFVDk jl8RrA/wRQqpM5XsL8zPkU0laKPlLXE7oXpL0qSAN9US0I69dYNTUeF2RRbSf3BU10kc30Pd eBwCItxOHDbP2HTjLJ7PEALyxy/0 --B_3573843464_1304712826--