Subject: [Hipsec] Welcome to 5201-bis-02

From: Robert Moskowitz <[email-masked]>
Date: Thu, 01 Jul 2010 12:12:29 -0400

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.

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 01 Jul 2010 12:31:02 -0400

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.
>
> 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.
>
> 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.
>
> 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.
>
> 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 
> 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.
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec
>

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 01 Jul 2010 12:32:51 -0400

I hit Enter, rather then End...

> for the 5201-bis reading gathering.

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