IETF Logo Mail Archive

Re: [TLS] Curve25519 in TLS and Additional Curves in TLS

Bill Frantz <frantz@pwpconsult.com> Wed, 29 January 2014 00:11 UTC

Return-Path: <frantz@pwpconsult.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C311A02F1 for <tls@ietfa.amsl.com>; Tue, 28 Jan 2014 16:11:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nPkMhwTEvq1 for <tls@ietfa.amsl.com>; Tue, 28 Jan 2014 16:11:39 -0800 (PST)
Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id D4AD51A018F for <tls@ietf.org>; Tue, 28 Jan 2014 16:11:39 -0800 (PST)
Received: from [173.75.83.192] (helo=Williams-MacBook-Pro.local) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <frantz@pwpconsult.com>) id 1W8Iki-0004T8-M3 for tls@ietf.org; Tue, 28 Jan 2014 19:11:36 -0500
Date: Tue, 28 Jan 2014 16:11:34 -0800
From: Bill Frantz <frantz@pwpconsult.com>
To: tls@ietf.org
X-Priority: 3
In-Reply-To: <CABqy+sop_OPk1y1aLkRtrPs3RToYOc9b_xCoCMBg9SwntN0qqA@mail.gmail.com>
Message-ID: <r422Ps-1075i-D59E808B7F6C48DAA6BA987493044A7B@Williams-MacBook-Pro.local>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.3.1 (422)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec7936fa02abe799ff64fe4efe27272c9457350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 173.75.83.192
Subject: Re: [TLS] Curve25519 in TLS and Additional Curves in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jan 2014 00:11:41 -0000

There is two thing that all long-term endian warriors have in 
common. (1) They have a strong opinion about what the right 
answer is; and (2) They wish the other side had won a complete victory.

In this spirit, please look at RFC1762 which says:

       Exactly one length field and one DNA Phase IV Routing 
packet are
       encapsulated in the information field of a PPP Data Link Layer
       frame where the Protocol field indicates type hex 0027 
(DNA Phase
       IV Routing).  The length field contains a count of the 
number of
       octets in the DNA Phase IV Routing packet.  It is two 
octets in
       length itself, and is stored in VAX byte ordering, to be more
       consistent with DNA Phase IV Routing over Ethernet (i.e. least
       significant byte first).  It is needed to disambiguate optional
       padding octets from real information.

So it would not be unprecedented to have little endian data in 
an Internet Protocol.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Privacy is dead, get over    | Periwinkle
(408)356-8506      | it.                          | 16345 
Englewood Ave
www.pwpconsult.com |              - Scott McNealy | Los Gatos, 
CA 95032

v2.23.0 | Report a Bug | By Email