[Hipsec] Ooops Re: Welcome to 5201-bis-02

Robert Moskowitz <rgm@htt-consult.com> Thu, 01 July 2010 16:33 UTC

Return-Path: <rgm@htt-consult.com>
X-Original-To: hipsec@core3.amsl.com
Delivered-To: hipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 475B93A684A for <hipsec@core3.amsl.com>; Thu, 1 Jul 2010 09:33:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.73
X-Spam-Level:
X-Spam-Status: No, score=-1.73 tagged_above=-999 required=5 tests=[AWL=0.869, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umVo7WEWoVGu for <hipsec@core3.amsl.com>; Thu, 1 Jul 2010 09:32:58 -0700 (PDT)
Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 6C6793A6824 for <hipsec@ietf.org>; Thu, 1 Jul 2010 09:32:53 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 2A21268B8B for <hipsec@ietf.org>; Thu, 1 Jul 2010 16:24:58 +0000 (UTC)
Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbCZLAu1eY-v for <hipsec@ietf.org>; Thu, 1 Jul 2010 12:24:47 -0400 (EDT)
Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id DA24668B81 for <hipsec@ietf.org>; Thu, 1 Jul 2010 12:24:47 -0400 (EDT)
Message-ID: <4C2CC333.1070605@htt-consult.com>
Date: Thu, 01 Jul 2010 12:32:51 -0400
From: Robert Moskowitz <rgm@htt-consult.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4
MIME-Version: 1.0
To: hipsec@ietf.org
References: <4C2CBE6D.8080800@htt-consult.com>
In-Reply-To: <4C2CBE6D.8080800@htt-consult.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [Hipsec] Ooops Re: Welcome to 5201-bis-02
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Jul 2010 16:33:02 -0000

I hit Enter, rather then End...

At the end of this I have added the changelog that Tobias pointed me to...

On 07/01/2010 12:12 PM, Robert Moskowitz wrote:
> Tobias Heer with my able assistance, has completed the lastest effort
> to move 5201 (and HIP!) to cryto agility and standards track.
>
> Well I will say that Tobias did most of the writing, but I'll take the
> heat on where we went with the changes.  Tobias figured out how to add
> the crypto agility and avoid some downgrade attacks.  I spent time
> figuring out how to add ECDSA to the document and changes to KEYMAT.
>
> There ARE a number of changes, we changed the version number.  HIP BEX
> still functions as in 5201, but we had to make the Hash negotiable,
> add ECDSA, and more Diffie-Hellman options (like ECDH).  This resulted
> in some interesting changes.
>
> Tobias, Miika, and I have spent considerable time debating what crypto
> suites to include.  We are trying to balance agility and compactness.
> Should we drop SHA-1 like a hot potato and just specify SHA-256 and
> -384 until SHA-3 comes out?  Or should SHA-1 still play and we
> downplay SHA_384?  Or is SHA-384 locked in to meet Suite-B needs?
> Which ECDSA key sizes, P160, P256, and P384 seem to be the minimum
> (read why for P160).  And finally which AES modes (duo modes excluded
> for HIP payloads).  So please think on this and weigh in with your views.
>
> First notice the change to the HIT.  We realized we need to encode a
> HIT_Suite_ID into the HIT.  Without this there were a number of
> complications and attack options.  But this cost us 4 bits from the
> hash.  We have a limited number of Suite ID slots and are concerned
> about how many we eat up right out the door.  Note that each hash eats
> TWO IDs, one for RSA/DSA and one for ECDSA (also HIP DEX will take one
> more).
>
> The only change to the previous state machine is a transition from
> state I1-SENT to I1-SENT - the restart option. An Initiator is
> required to restart the HIP exchange if the Responder does not support
> the HIT Suite of the Initiator.  Note that I have made additional
> changes to the state machine in HIP DEX to add aggresive
> retransmission.  Take a read of that and we can discuss if BEX would
> benefit from this feature.
>
> Next on the the puzzle.  Basically we made the size of I and J
> variable to the size of the keying needed.  Plus the hash is the one
> in the HIT_Suite_ID.
>
> We have added a Diffie-Hellman list into I1.  Read the text on what is
> going on here.  More choices, hints needed, downgrade attacks to avoid.
>
> HOST_ID parameter got reworked.  There is no ECDSA RDATA currently and
> the ID is limited to just NIST-ECDSA-256 and NIST-ECDSA-384.  We
> needed at least BrainpoolP160r1, and perhaps more.  So I changed even
> the handling of RSA and DSA to be ONLY the specifics from their DNSSEC
> RFCs.  Then I built up how ECDSA should be handled, using
> draft-mcgrew-fundamental-ecc-03.txt.
>
> The HMAC parameters are renamed MAC, but in 5201 they are still using
> HMAC with the hash specified in the HIT-Suite_ID.
>
> HIP_Transform has been replaced by HIP_Cipher.  The hash is locked
> down by the HIT_Suite_ID, so the only thing to negotiate is what
> cipher will be used for things like the ENCRYPTED parameter.
>
> I redid KEYMAT to directly use RFC 5869.  The changes were slight, but
> it puts us using a new standard for hash-based KEYMAT.
>
> IANA considerations has been increased.
>
> We need some help with the Appendices;.B and C in particular.
>
>
> Anyway, please start reading.  We will collect comments.  Those which
> are obvious we will incorporate in a -03 to publish just before the
> July 12th cutoff date.  Others we will organize into discussion points
> for the 5201-bis reading gathering.
>
>
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec
>


Change-log draft-moskowitz-RFC5201-bis-02
----------------------------------------
* Included HIT_SUITEs
* Renamed OGA list to HIT_SUITE_LIST
* Added DH negotiation to I1 and R1
* Added DH_LIST parameter
* Added text for DH Group negotiation
* Removed second DH public value from DH parameter
* Added ECC to HI generation
* Added Responder HIT selection to opportunistic mode
* Added ECDSA HI text and references (not complete yet)
* Added separate section on aborting BEX
* Added separate section on downgrade attack prevention
* Added text about DH Group selection for use cases without I1
* Removed type range allocation for parameters related to HIP transform 
types
* New type range allocation for parameters that are only covered by a 
signature if a signature is present (Applies to DH_GROUP_LIST)
* Renamed HIP_TRANSFORM to HIP_CIPHER and removed hashes from it - 
hashes are determined by RHASH
* The length of I and J for the puzzle now depends on RHASH
* New keymat generation
* Puzzle seed and solution now use RHASH and have variable length


Editorial changes:
* Moved timing definitions closer to state machine
* Simplified text regarding puzzle lifetime
* Clarified the description of the use of I in the puzzle
* Removed "Opportunistic mode" description from general definitions.
* Some other editorial changes including spelling and consistency of terms
* More consistency across the old RFC5201 text. Aligned capitalization 
and abbreviations.


Change-log draft-moskowitz-RFC5201-bis-01
----------------------------------------
* Extended protocol overview to include restart option
* Extended state machine to include restart option because of
   unsupported Algorithms
* Replaced SHA-1 with SHA-256 for required implementation
* Added OGA list parameter (715) for detecting the Responder's set of OGAs
* Added Appendix on ORCHID use in HITs
* Added truncated SHA-256 option for HITs
* Added truncated SHA-1 option for HITs
* Added text about new ORCHID structure to HIT overview
* Moved Editor role to Robert Moskowitz
* Added SHA-256 to puzzle parameter
* Generalized LTRUNC to be hash-function agnostic
* Added text about RHASH depending on OGA