Re: [TLS] chacha/poly interop?

[Jeffrey Walton]

On Mon, Sep 12, 2016 at 8:10 PM, David Benjamin  wrote:
> On Mon, Sep 12, 2016 at 7:35 PM Jeffrey Walton  wrote:
>>
>> On Wed, Dec 9, 2015 at 8:02 PM, Salz, Rich  wrote:
>> > OpenSSL just landed our chacha/poly implementation into master.  We pass
>> > the
>> > RFC test vectors, looking for other implementations to test against.
>>
>> Sorry to dig up an old thread
>>
>> I tested against Bernstein/ECRYPT ChaCha and test vectors from
>> http://tools.ietf.org/html/draft-strombergson-chacha-test-vectors.
>> TLS-ChaCha does not inter-operate with ChaCha.
>>
>> The name should probably be disambiguated somehow.
>
>
> TLS-ChaCha is actually RFC 7539 which comes with its own test vectors and
> isn't TLS-specific.

Oh, my bad... I grabbed the 5 vectors from
http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305. I used them
because I believe the kernel-crypto is using them.

Let me try with RFC 7539 and see how things react with the 7539 vectors.

Jeff

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] chacha/poly interop?

[David Benjamin]

On Mon, Sep 12, 2016 at 7:35 PM Jeffrey Walton  wrote:

> On Wed, Dec 9, 2015 at 8:02 PM, Salz, Rich  wrote:
> > OpenSSL just landed our chacha/poly implementation into master.  We pass
> the
> > RFC test vectors, looking for other implementations to test against.
>
> Sorry to dig up an old thread
>
> I tested against Bernstein/ECRYPT ChaCha and test vectors from
> http://tools.ietf.org/html/draft-strombergson-chacha-test-vectors.
> TLS-ChaCha
> 
> does not inter-operate with ChaCha.
>
> The name should probably be disambiguated somehow.
>

TLS-ChaCha is actually RFC 7539 which comes with its own test vectors and
isn't TLS-specific.

Our implementation matches RFC 7539 and seems to match the one test vector
I tried too. Note that that draft includes a number of things like 128-bit
keys and 8 or 12 rounds which are not applicable. The test vector whose
answer begins "0x76 0xb8 0xe0 0xad 0xa0" is the one you want.

Were you perhaps using the 128-bit key test vector? RFC 7539 doesn't use
that mode. It doesn't seem even be described in the paper, though it is in
the reference implementation. (Looks like the constants change and you put
two copies of the key in.)

David
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] chacha/poly interop?

[Jeffrey Walton]

On Wed, Dec 9, 2015 at 8:02 PM, Salz, Rich  wrote:
> OpenSSL just landed our chacha/poly implementation into master.  We pass the
> RFC test vectors, looking for other implementations to test against.

Sorry to dig up an old thread

I tested against Bernstein/ECRYPT ChaCha and test vectors from
http://tools.ietf.org/html/draft-strombergson-chacha-test-vectors.
TLS-ChaCha does not inter-operate with ChaCha.

The name should probably be disambiguated somehow.

Jeff

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Short Authentication Strings for TLS

[Christian Huitema]

On Friday, September 9, 2016 7:28 AM, Hannes Tschofenig wrote:
> ...
> Hi Christian,
> 
> could you provide a bit more background why you are working on such a
> solution?

Daniel and are working on "privacy for DNS-SD discovery." Daniel presented
in Berlin this draft:
https://datatracker.ietf.org/doc/draft-huitema-dnssd-privacy/. The private
discovery solution relies on pre-existing pairings, which provide shared
keys between paired devices. The working group consensus was to adopt the
work on private discovery, but to separate the pairing work in a different
work item.

The pairing algorithms typically combine the establishment of a shared
secret through an [EC]DH exchange, with the verification of that secret
through display and comparisons of "Short Authentication String" (SAS). The
secure comparison requires a "commit before disclose" mechanism.

We have three possible designs: create a pairing algorithm from scratch,
specifying our own crypto exchanges; use an [EC]DH version of TLS to
negotiate a shared secret, export the key to the application, and implement
the "commit before disclose" and SAS verification as part of the pairing
application; or, use TLS, integrate the "commit before disclose" and SAS
verification as TLS extensions, and export the verified key to the
application.

I would rather not create an algorithm from scratch. We would need to
reinvent a lot of the negotiation capabilities that are part of TLS, not to
mention algorithm agility, post quantum, and all that sort of things. EKR
pointed me towards the expired draft by Ian Miers, Matthew Green and him:
https://tools.ietf.org/html/draft-miers-tls-sas-00. It is a very close match
to our third design option, full integration of SAS in TLS. Hence the
interest.

Of course, we could also use the middle ground option -- use TLS for [EC]DH,
and implement the SAS verification as part of the pairing application. We
need to export the key from TLS to the pairing context in any case. The
middle ground option would only require us to implement a couple of hashes.
The downside is that we would need to negotiate the hash algorithm, unless
maybe we can export that too from the TLS context. And then, there are the
typical implementation issues. Application level minimizes the dependency on
TLS implementing the extensions, but increases the risk of doing it wrong.
And vice versa.

-- Christian Huitema








> On 08/18/2016 07:47 PM, Christian Huitema wrote:
> > Daniel Kaiser and I are working on a “pairing” specification in the
> > context of DNS SD. Short Authentication Strings are one of the preferred
> > methods for verifying pairings. I would like to use TLS as much as
> > possible in the pairing protocol. EKR pointed me to the expired draft by
> > Ian Miers, Matthew Green and him:
> > https://tools.ietf.org/html/draft-miers-tls-sas-00. I am interested in
> > reviving that draft.
> >
> >
> >
> > The draft implements a classic “coin flipping” protocol into TLS, using
> > a “commit before disclose” logic to prevent Nessie from hiding as an
> > MITM between Alice and Bob. From my superficial reading, this looks
> > fine. I could use a reference to
> > http://people.csail.mit.edu/shaih/pubs/hm96.pdf, both to explain why the
> > attack by Halevi and Micali does not apply to this particular construct,
> > and also to provide a 20 years old reference to similar algorithms,
> > which may be useful in this day and age.
> >
> >
> >
> > One nit, though. If Nessie has infinite computing resource, she can
> > build a catalog of multiple random values that all hash to the same
> > string, and then use that catalog to work around the commitment
> > protocol. The scheme in the draft prevents that attack by using a hash
> > keyed with the master secret, which defeats catalog attacks, and also by
> > limiting the length of the nonce to be below the length of the hash,
> > which in theory prevents collision attacks. Explaining that would be
neat.
> >
> >
> >
> > As I said, I am interested in reviving that draft, and adapting it to
> > TLS 1.3. Does someone else share the feeling?
> >
> >
> >
> > -- Christian Huitema
> >
> >
> >
> >
> >
> >
> >
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] [Errata Held for Document Update] RFC4492 (4633)

[RFC Errata System]

The following errata report has been held for document update 
for RFC4492, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport 
Layer Security (TLS)". 

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4492=4633

--
Status: Held for Document Update
Type: Editorial

Reported by: Kurt Roeckx 
Date Reported: 2016-03-02
Held by: Stephen Farrell (IESG)

Section: 5.1.1

Original Text
-
struct {
NamedCurve elliptic_curve_list<1..2^16-1>
} EllipticCurveList;

Corrected Text
--
struct {
NamedCurve elliptic_curve_list<2..2^16-1>
} EllipticCurveList;

Notes
-
The count is in bytes, not items.

--
RFC4492 (draft-ietf-tls-ecc-12)
--
Title   : Elliptic Curve Cryptography (ECC) Cipher Suites for 
Transport Layer Security (TLS)
Publication Date: May 2006
Author(s)   : S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk, B. Moeller
Category: INFORMATIONAL
Source  : Transport Layer Security
Area: Security
Stream  : IETF
Verifying Party : IESG

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls