[Cfrg] FW: theoretical question ... RE: Task for the CFRG

["Igoe, Kevin M." <[e-mail]>]

(Forgot to add the CFRG mailing list to this reply)

 

From: Igoe, Kevin M. 
Sent: Friday, August 09, 2013 2:54 PM
To: 'Dan Brown'
Subject: RE: theoretical question ... RE: Task for the CFRG

 

To answer the concrete question about TLS, the client handshake passes a
list of

cipher suites the client is willing to use to the server.   The server
selects a cipher 

suite that  it supports from the client’s list and passes their selection
back to the 

client , or signals failure if there is no cipher suite they both support.
The standard 

doesn’t specify how the server selects a cipher suite, it is free to
implement

this as it sees fit.

 

Each cipher suite consists of a quadruplet 

      ( key agreement algorithm,  authentication algorithm, 

        encryption algorithm, hash algorithm).

IANA maintains a list of TLS cipher suites registry with entries like

 

  TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x09 }

 

which breaks out as ephemeral elliptic curve Diffie Hellman for key
agreement,

elliptic curve DSA for authentication, AES with 128-bit key for encryption,
and SHA-1 

for hash.  (Note: thanks to IANA, the client’s list of cipher suite is just
a list of 

2-octet values rather than list of long character strings).  The IANA
registry also

points to an RFC which provides further details on the cipher suite (RFC
4492

in this case).

 

At any rate, TLS already supports dozens of cipher suites (the soon to come
TLS 1.3

hopes to cull this down). Adding a handful of SALSA based suites shouldn’t
be an issue.

 

 

From: Dan Brown [mailto:[e-mail]] 
Sent: Friday, August 09, 2013 1:21 PM
To: Igoe, Kevin M.; '[e-mail]'
Subject: theoretical question ... RE: Task for the CFRG

 

I cannot offer an expert opinion on these symmetric algorithms, only a
generic concern and a naïve question, both theoretical and tangential (to
the original thread).

 

 

Generic Concern

 

The proposal is in the form of: change from algorithm A to algorithm A or B.


 

(+) This improves security in the sense that if we know A or B is broken, we
can shut if off, and then use the other.

 

(-) If we do not know that A or B is broken, or if we cannot easily shut off
one, then the adversary can perhaps just attack the weakest choice of A or
B.

 

Arguably (+) already outweighs (-)., but furthermore, many crypto protocols,
including TLS, take two parties, perhaps one of whom can shut off A or B and
be presumed to be more knowledgeable.  In other words, one side can do (+)
to mitigate the (-) above on the other side, if the enforcement to use the
secure choice can be securely conveyed.

 

 

Naïve (and theoretical) Questions

 

How does TLS enable one side to enforce the choice of A or B? Does it use a
mechanism other than A or B?   For a concrete example, suppose a server
implements (+), choosing MAC algorithm A, shutting off B. In TLS, the server
does not sign the algorithm choice of A, right?  Consequently, if MAC
algorithm B is sufficiently broken, can an adversary fool the client into
using the broken MAC alg B, leveraging the fact that B is broken to
mis-authenticate the approval to use B?  A similar question might be asked
about the encryption algorithm.  So, I am concerned that, while the server
will not use the broken algorithms, then client is still at risk, because
the adversary can impersonate the server, or the else, the client leak
plaintexts to the adversary.  

 

I guess what I am suggesting that for (+) to successfully mitigate (-) as
outlined above, some method other than a broken algorithm should be used to
enforce the other side to use the unbroken algorithm.  In the case of TLS,
this may occur at the public key level, or pre-shared key.  Maybe TLS
already does this: I’ve misunderstood TLS several times already, so maybe my
concerns are unfounded.

 

Also, all this is not suggest that specific alg might be weak, as in the
hypothesis above, but rather to establish how much is gained by the change
to A or B. .Put another way, maybe AàB substitution I outlined is possible
only if B is disasterously weak, and we can be very confident that B is not
so weak, in which case there may be no downside to allowing A or B at all.
So, this is a theoretical question, not a practical question.  

 

Authentication of algorithm has already been discussed a few times on this
list and others, but I forget the conclusions.   

 

Best regards,

 

Dan

 

 

 

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of
Igoe, Kevin M.
Sent: Thursday, August 08, 2013 3:46 PM
To: [e-mail]
Subject: [Cfrg] Task for the CFRG

 

The TLS WG has asked the CFRG for their opinion for a stream cipher,
eSTREAM-SALSA20, 

and two MAC algorithms, UMAC and POLY1305, that have been suggested for use
in TLS

(draft-josefsson-salsa20-tls-02).  This was presented to the TLS WG at
IETF-87, slides can

be found at http://www.ietf.org/proceedings/87/slides/slides-87-tls-2.pdf.

The SALSA family works on blocks of 512 bits, and forms a key stream in
512-bit blocks by

applying a fixed map V^{512}->V^{512} to an input consisting of the key
(either 16 octets or

32 octets), an 8-octet block counter, an 8-octet IV, and 16 constant octets.

 

SALSA20 was one of the five finalists for a software stream cipher in the
eSTREAM

contest run by ECRYPTII (see http://www.ecrypt.eu.org/stream/).

 

UMAC has been around since 1999 and is described in RFC 4418.

 

POLY1305 first showed up as POLY1305-AES, but all it needs from AES is a 16
byte block

of output. Adapting this to SALSA is straightforward. The 1305 in the name
reflects the

fact that it uses arithmetic modulo 2^{130} – 5.  See
http://cr.yp.to/mac/poly1305-20050329.pdf

for a description of poly1305-AES.

 

Off the top of my head, the only objection I can see is that SALSA may be
difficult to

implement efficiently in hardware.  Hardware TLS acceleration can be useful
at heavily 

utilized servers.

 

The most current attempt to attack SALSA that I could find is a 2012 paper
on the IACR

e-print server.

 

----------------+--------------------------------------------------

Kevin M. Igoe   | "We can't solve problems by using the same kind

[e-mail]  | of thinking we used when we created them." 

                |              - Albert Einstein -

----------------+--------------------------------------------------