Subject: Re: [TLS] RFC4492bis - Removing ECDH

From: Yoav Nir <[email-masked]>
Date: Wed, 7 Jan 2015 16:23:43 +0200

Hi.

I realize this was sent right in the middle of the holiday season, so I’ll give it another try.

Please have a look at the pull request and post comments to the list about whether you’re fine with removing ECDH.

Thanks

Yoav

> On Dec 16, 2014, at 12:29 AM, Yoav Nir <[email-masked]> wrote:
> 
> Hi.
> 
> I’ve created pulll request #2 for removing references to ECDH (static elliptic curve key) key exchange and ciphersuites.
> 
> https://github.com/tlswg/rfc4492bis/pull/2 <https://github.com/tlswg/rfc4492bis/pull/2>
> 
> Nikos suggested it here: http://www.ietf.org/mail-archive/web/tls/current/msg14555.html <http://www.ietf.org/mail-archive/web/tls/current/msg14555.html>
> Yes, there are other suggestions there, but I’d like to take them one by one.
> 
> Let me know what you think
> 
> Yoav
>

---

From: Michael Clark <[email-masked]>
Date: Thu, 08 Jan 2015 10:21:42 +0800

Hi,

After spending 14 years in Asia I get mixed up with holidays and started
calling them Solstice holidays and Lunar holidays (Feb 19th this year).
I'm hoping I can have a break in the Lunar New Year. My family in New
Zealand celebrated Solstice holidays without us... as we still trying to
/Escape from Singapore/ (reminds me of Snake Plissken)... we'll make it
out. We still have Internet access here. (*1,*2) ;-).

Yes. You might want more consensus, however as a data point, I am in
support of ephemeral key negotiation mechanisms that /in theory/
preserve forward secrecy and for removing those that leave
administrators hamstrung (and aren't implemented). i.e. fine with
removing ECDH. There appears to be an emerging consensus from server
administrators and the certificates issued from all major vendors have
"Parameters: None". In the case they were used in practice, they would
make attack mitigation depend on third parties.

My understanding is the DH-RSA and ECDH-(RSA|ECDSA) are practically
unused and that implementations use DHE-RSA and ECDHE-(RSA|ECDSA). ECDH
requires the CA to embed static named or explicit points in
certificates. The practice is that implementations let server
administrators choose and /sign/ *somewhat* ephemeral parameters e.g.
secp256r1,  secp384r1 works widely, but secp521r1 failed in my tests
with Win8.1 IE11; this report matches my data point: (*3). I use the
word /sign/ loosely until we have a proof that handshake messages can't
be replaced in situ (*4). i.e. the client and server establish a chain
of trust from their first Hellos to the pre-master secret establishment;
which is possible with careful refinements to the protocol (constant
salt in AD across all handshake messages). This of course then pushes an
integrity problem down to another layer. i.e. DNSSEC (*5).

It raises another question. Is DH_anon a misnomer? Should it be
DHE_anon? Is it used anywhere in practice?

Michael.

[1] http://foreignpolicy.com/2014/07/29/the-social-laboratory/
[2] https://tools.ietf.org/html/rfc7258
[3] https://twitter.com/ericlaw/status/532296076670533632
[4]
http://arstechnica.com/security/2015/01/gogo-issues-fake-https-certificate-to-users-visiting-youtube/
[5] http://www.internetsociety.org/deploy360/dnssec/maps/

On 7/1/15 10:23 pm, Yoav Nir wrote:
> Please have a look at the pull request and post comments to the list
> about whether you’re fine with removing ECDH.
>
> Thanks
>
> Yoav
>
>> On Dec 16, 2014, at 12:29 AM, Yoav Nir <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Hi.
>>
>> I’ve created pulll request #2 for removing references to ECDH (static
>> elliptic curve key) key exchange and ciphersuites.
>>
>> https://github.com/tlswg/rfc4492bis/pull/2
>>
>> Nikos suggested it
>> here: http://www.ietf.org/mail-archive/web/tls/current/msg14555.html

---

From: Yoav Nir <[email-masked]>
Date: Thu, 8 Jan 2015 06:42:30 +0200

Hi, Michael

> On Jan 8, 2015, at 4:21 AM, Michael Clark <[email-masked]> wrote:
> 
> Hi,
> 
> After spending 14 years in Asia I get mixed up with holidays and started calling them Solstice holidays and Lunar holidays (Feb 19th this year). I'm hoping I can have a break in the Lunar New Year. My family in New Zealand celebrated Solstice holidays without us... as we still trying to /Escape from Singapore/ (reminds me of Snake Plissken)... we'll make it out. We still have Internet access here. (*1,*2) ;-).
> 
> Yes. You might want more consensus, however as a data point, I am in support of ephemeral key negotiation mechanisms that /in theory/ preserve forward secrecy and for removing those that leave administrators hamstrung (and aren't implemented). i.e. fine with removing ECDH. There appears to be an emerging consensus from server administrators and the certificates issued from all major vendors have "Parameters: None". In the case they were used in       practice, they would make attack mitigation depend on third parties.
> 
> My understanding is the DH-RSA and ECDH-(RSA|ECDSA) are practically unused and that implementations use DHE-RSA and ECDHE-(RSA|ECDSA). ECDH requires the CA to embed static named or explicit points in certificates. The practice is that implementations let server administrators choose and /sign/ *somewhat* ephemeral parameters e.g. secp256r1,  secp384r1 works widely, but secp521r1 failed in my tests with Win8.1 IE11; this report matches my data point: (*3). I use the word /sign/ loosely until we have a proof that handshake messages can't be replaced in situ (*4). i.e. the client and server establish a chain of trust from their first Hellos to the pre-master secret establishment; which is possible with careful refinements to the protocol (constant salt in AD across all handshake messages). This of course then pushes an integrity problem down to another layer. i.e. DNSSEC (*5).

#4 is a TLS proxy. And it does get noticed, because you don’t trust Gogo’s CA, so it’s not so great as an attack. I do wonder why they would apply it to Youtube of all services. Filter out video clips with crashing planes?

> It raises another question. Is DH_anon a misnomer? Should it be DHE_anon? Is it used anywhere in practice?

It is a misnomer. It is not used on the web, but it is used in some situations. For example, my company’s firewalls use it to establish the initial trust between a firewall and the management station. They will establish a TLS connection with DH_anon (should be DHE_anon, I guess), and then run certificate enrollment over that.

Yoav

---

From: Michael Clark <[email-masked]>
Date: Thu, 08 Jan 2015 14:40:54 +0800

Hi Yoav,

> #4 is a TLS proxy. And it does get noticed, because you don’t trust Gogo’s CA, so it’s not so great as an attack. I do wonder why they would apply it to Youtube of all services. Filter out video cl…

I watched "Non-Stop" on an Singapore Airlines flight from New Zealand to
Singapore in late-October, and at the same time noticed the plane
altered course at Darwin, and instead of flying direct, flew over East
Timor towards West Kalimantan (Borneo), completely avoiding the Java
sea. Coincidence. Likely planning. "Weather". An AirAsia plane however
sadly flew straight through the Java Sea during monsoon season. They had
requested for new flight path and were denied due to heavy air traffic;
so they flew on straight through a storm. My partner and I were boarding
an A320 to Bangkok to Singapore 2 days after on Dec 30.

    http://www.rottentomatoes.com/m/non_stop_2013/

"Non-Stop" was about an Air Marshall who was trying to trace an unknown
device on the plane sending him hijack threat messages, now they have
WiFI and GSM... The reality is anyone serious would be using LoFi.
"Non-Stop" is fiction. There is no need for MiFi. It human nature that
people are angry when they are denied security (physical or ephemeral).

I can separate fact from fiction. Rotten Tomatos gave it the thumbs. It
was an okay movie however I think I liked it more because I was watching
it on a plane.

I am aware in the case where the CA is not in the trust store; and this
is noticeable to the user, and there are techniques such as public key
pinning in HTTP headers (which relies on establishing the first
connection on a trusted network as a proxy could easily re-write the
pins). The security needs to go down to the next layer. I still believe
there is a rationale to (not in spite of RSA and other digital signature
algorithms, rather to enhance them), make the client software aware, not
just the user in the case of certificate tampering. Otherwise the
browser needs a database. The policy could be that the client can
indicate to the user that the handshake has been tampered and an
implementation chose to accept invalid tags however I suspect it might
be a slippery slope towards tamper free TLS handshakes. i.e. net
neutrality. packets that arrive as they were sent. Someone will like
derive a closed user group derivation of TLS once they are aware of
this, if this kind of strategy is not adopted (assuming it is possible).

I am still reasoning about adding HMAC on handshake messages with
constant (client|server)_random as AD in all handshake messages
(HMAC_SHA2_𝑛). My reasoning probably has flaws or this would have been
solved. The MAC from the ClientHello MAC from the client may need to be
signed by the cert and returned in the Finished message from the server.
We have to distinguish between the HMACs that are *sent* not *seen* and
perhaps use the *sent* in key derivation or tamper detection. This
allows the browser to know at the TLS level (versus via the trust store)
that the handshake was modified "in flight" (no pun intended). The
browser developers and therefor the user can distinguish and take
appropriate action. There is a distinction between untrusted cert and a
tampered handshake that isn't currently exposed to the TLS client.

I'm thinking of the rewriting case and reasoning about it... The client
knows the MAC of it's ClientHello so it may need to be included in the
Finished message signed by the servers certificate (and a MITM would
need to change it). The server *sees* the MAC of the ClientHello it
receives, not necessarily the one that was sent. It's almost like an
HMAC of the handshake messages (from both sides as they were *sent*)
needs to contribute to the pre-master secret, and each side knows what
they sent. The tamperer would need to HMAC his tampered message. I will
think some more about it... My thinking may have flaws...

> It is a misnomer. It is not used on the web, but it is used in some situations. For example, my company’s firewalls use it to establish the initial trust between a firewall and the management stati…

Forward progress. It probably wasn't incorrect at the time until there
was context for the distinction.

Michael.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 08 Jan 2015 10:04:35 +0100

> DHE_anon? Is it used anywhere in practice?

That's a nice question. No DH_anon and ECDH_anon was not a misnomer.
They are often (or always?) used with ephemeral keys, but some other use
of them is with static non ephemeral keys, which will be used to verify
the server's identity on reconnect. Pretty much, no authentication, but
key continuity. That was never documented in the text though, but I
remember seeing it in mailing list discussions. I think that's the
reason of the missing 'E'.

regards,
Nikos

---

From: Michael Clark <[email-masked]>
Date: Sun, 11 Jan 2015 10:17:09 +0800

tl;dr

> #4 is a TLS proxy. And it does get noticed, because you don’t trust Gogo’s CA, so it’s not so great as an attack. I do wonder why they would apply it to Youtube of all services. Filter out video cl…

I've come to the conclusion that the GoGo full proxy case is impossible
to do anything about but is highly visible to the user. It's like being
on an Island in the Sky without much Internet, a big cache and a high
latency satellite link. It reminds me of New Zealand Internet in the mid
90s when I worked at an ISP with sat and copper submarine cables. The
router guys did policy routes to send latency sensitive stuff over cable
(SYN,SYNACK,ACK) and bulk transfer to latency insensitive stuff over
satellite (NNTP). Similar mechanism to the grey box (see below).

| |
 O -< full proxy
| |

If GoGo were smarter, they would put a trusty looking logo on their WiFi
captive portal signin pop-up e.g. a gold crown with a red seal and
ribbon; like those on a Reader's Digest prize letter; asking users to
install and trust their certificate for "Enhanced in-flight security".
Put an advertisement for Fidelity A-ssurance and a picture of Benjamin
next to it, and then you can just generate certificates "on the fly"
after snarfing out all of the ASN.1 fields from the remote end. They
could even do EV and point to their own OCSP. Any address they like (NAT
and anycast). Conclusion: Bank in Hawaii, but fly there to make withdrawals.

However I believe that GoGo is kind of a cover story to show off crude
tampering to mask much more subtle tampering.

In fact there is no way around someone who is friends with a CA as they
can implement a full proxy, especially if they have insertion points at
all major POPs, deep packet inspection and selective policy routes to
send you off to their grey boxes. Public-Key-Pins will only work if you
initiate your first connection on a network you know is trusted. i.e. at
the office. When you know the Tier 1 (backbone) in your own country is
part of the five eyes then all bets are off. Vodafone fessed up and made
a public statement about the 5 countries and they *don't approve*
http://www.bbc.com/news/business-27732743

If *they* can compel Vodafone then they can compel a CA or 'Chorus' our
own Fibre backbone provider to do whatever they want. Who knows what
they are doing? Everyone. The law is "search warrant" and "probable
cause". Wholesale wiretapping is illegal in almost all democracies. OK,
it's a "representative" democracy. I'm a-political. Who cares what crowd
gets in. Mil is going to be there either way. Military or Militant.
What's the diff? One drives a fiat apparently.

| |
¦ ¦<- pass-through tampering.
| |

There is a more subtle pass through case where handshake messages can be
tampered with (without access to a CA, just an Internet coffee bucks
WiFi tap). Allows attacks such as editing cipher lists and any other
associated handshake metadata (curve format extensions, switching on
compression) that are not properly authenticated. Until I am certain
they are completely mitigated I remain skeptical.

I am still thinking about pass-through tamper mitigation using random
constant as AD and MAC for all pre-kex handshake messages and having the
server returning the client MAC it saw from the client signed with its
RSA or ECDSA key (and notify that all were equal including its original
ServerHello MAC signed in the Finished message (given ChangeCipherSpec
is proposed to be removed). Both can do this when they have a shared
chain of trust and the client offers a certificate.

Until I've finished my proxy, its just reasoning from auditing the spec.
I am curruently unsure how MITM handshake tampering in the rouge WiFi or
ISP active tapping case is mitigated. I've read SCSV but it confuses me
a little. If it's in the clear and unauthenticate it can be tampered
with. Any slightly milicious WiFi provider can do NAT and transparent
proxy, introduce delays, drop handshake messages and rewrite cipher
lists and extensions for anything not authenticated.

Just wiresharking again... I can't see why I can't try to emulate
WindowsXP ClientHello in a pass through proxy, by dropping, delaying or
rewriting messages I don't like (including fallback).

Windows XP IE 8 offers a 1.0 CLientHello often gets given
TLS_WITH_RSA_RC4_128_SHA. Firefox has a 1.2 ClientHello and it gets
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 but TLS_WITH_RSA_RC4_128_SHA is
offered in its ClientHello and it can talk TLS1.0.

MiFi could fool a client into thinking all servers are TLS1.0 (for
servers that still support TLS1.0)? and downgrade them to
TLS_WITH_RSA_RC4_128_SHA and rewrite/filter their responses. Still we
can't easily crack RC4. We'd need a huge black building in the dessert
with acres of GPUs or a cave under a mountain, protected by ninjas.

It seems the other direction is minimizing negotiation and removing
extensions. Make SNI mandatory field. No compression. No renegotiation.
It's all wise stuff. Label all cryptographic primitives with 'notional
labels' in the spec so everything is pre-negotiated. Sign the chosen
label with random salt. Return all offered and negotiated parameters
signed after the kex (small negotiation or an HMAC known to the other
end). Make TLSv1.3 require all of the existing primitives such as  curve
point formats, and make everything based on a tiny label.

enum ssf { ssf56, ssf112, ssf168, ssf224, ssf336, ssf448, mssf56,
mssf112, mssf168, mssf224, mssf336, mssf448 };

enum kex { kex_dh_anon, kex_psk_rsa, key_ffdhe_rsa, kex_ecdhe_rsa,
kex_psk_eddsa, kex_ecdhe_eddsa };

enum orphan { srp }; /* protocol layer auth? */

Still, even when the negotiation is small, if *all* parameters offered
in the Hellos are not returned signed (or by using a AD anti-tamper MAC
of the negotiation parameters), then we can still be downgraded to ssf56
if we were to offer it in the range we are willing to accept.

We want to know if we offer a range from ssf112 to ssf448 that ssf448 is
an option and we are not going to be downgraded to ssf112. All
negotiation parameters need to be signed no matter what the chosen kex
is, and in the symmetric case (psk or client and server certs), then
both ends can detect tampering (except in the crude case with RSA and
compromised CAs). It makes downgrading hard instead of trivial.

That said, SCSV helps mitigate without an overhaul of the handshake and
I can understand why it is there. This is not despite SCSV, as
fundamental changes to TLS negotiation and authentication are much more
intrusive changes; and even with a solid spec there are chances of
implementation bugs. We are humans.

P.S. I'm not on any sec list; as if I was I would have a duty to keep
quiet. I'm just auditing the spec based on public discourse and am not
under any non-disclosure agreements expressed or implied. Just a candid
third eye.

=====================================================================
TL;DR Free Idea - semi-off-topic - symmetry likely already considered
=====================================================================

It seems to me pinning and so forth are just papering around lack of
tamper-resistance in TLS handshakes and CA transparency and the price of
random bits. It's harder to change TLS but if you make changes to
servers and clients that have common issues then browsers can mitigate
using a common mechanism. Pinning. We all have a common interest. Public
audit records for CA make huge sense. The cert is offered by the server
so the CA should let you look in an audit trail of fingerprints. But
re-issue doesn't imply revocation (unless it's handled like a domain
transfer). Hard problem.

A TLS derivative (essentially policy) could add (or remove) symmetry and
make CertificateShare (either chained or self-signed) a requirement for
clients (browsers, or whatever). This would allow the servers to see if
clients were being impersonated if they stored client certs (or simply
fingerprints, like sessions, in a paxos/flashcached), on behalf of the
user, to allow service providers to give their users protection against
impersonation (most good people don't want their identity stolen), and
at the TLS level (essentially making them device certificates) using
pre-existing functionality. At the moment we have n-methods of
impersonation protection (all on behalf of users) for n-service
providers. HTTPS/SMTP(TLS) everywhere would let service providers
leverage RSA or EdDSA for protection of their users against identity
theft. We clearly need (tamper-resistant) TLS everywhere. In support of
AGL, Google, Firefox and everyone else working on TLS and Internet
security in general. I'm just adding to the fire. Soon we will need some
SMTP providers to start blocking based on certificate verification. Of
course an anonymous client cert with a random common name could only be
used for "confidence" after seeing it behave in a particular way
repeatedly. It seems Asia needs a lot of work:

  http://www.google.com/transparencyreport/saferemail/

Anonymity would then become at the expense of CPU cycles. i.e. Opening
up an incognito window would require cycles to generate a key and
self-signed certificate. Sending anonymous SPAM would require more CPU
cycles and it would have no effect on solicited bulk mail performance as
legitimate mailers aren't trying to get their certificate fingerprints
blacklisted. We could use certs in DNSSEC for SMTP blacklists (as one
example). Back to stamps for mail.

This would allow a server to detect someone trying to impersonate a
client using the same mechanisms the client can use. i.e. signing of the
handshake MAC in both directions when both sides have a cert.

Servers could have an MCU (most commonly used) cache to expire client
certs (or just their fingerprints). i.e. scaling the fingerprint expiry
based on frequency of usage. i.e. Bayesian confidence in the association
between a user and their certificate. Paranoid clients could generate a
new cert for each domain. It takes ~200ms to create a 2048bit RSA key.
This would make unsolicited bulk mail expensive.

Attackers that wanted to make wide attacks would be CPU bound as honest
clients and servers do key generation infrequently. Anyone who wanted to
be trusted would leave fingerprints.

This would make anonymous SPAM (SMTP with MX DVSNI vs self-signed certs)
add almost no extraordinary expense for normal usage but anyone covering
their tracks would have to use lots of CPU.

Browsers might someday start serving up certificates to servers. The
question is whether they prompt the user? prompt for policy choice? or
do so implicitly to protect the identity of their users? That's policy.
Not my area. Just putting ideas out there based on public knowledge from
lots of awesome people (judgement is half perspective).

Michael.

---

From: Michael Clark <[email-masked]>
Date: Sun, 11 Jan 2015 11:29:20 +0800

> tl;dr

please excuse any factual or typographic errors. my client is pedantic
and does not approve of any of them. unfortunately i am human.

consider my mail a draft draft comment on a request for comment. a
hopelessly meta stream of consciousness. it's the thought that counts.

it's dysgraphia or dyslexia. one or the other.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 11 Jan 2015 07:14:21 +0200

> they are completely mitigated I remain skeptical.

This attack won't work.

- TLS 1.3: The messages are hashed into hMS, so you can't decrypt the
  rest of the handshake due to having wrong keys.
- TLS 1.0-1.2 w/o false start: The Finished values will fail to verify.
- TLS 1.0-1.2 /w false start: The selected crypto must be strong, or
  endpoints won't enage in false start.

-Ilari

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 12 Jan 2015 10:13:26 +0100

----- Original Message -----
> whether you’re fine with removing ECDH.

I'm of course for it.

Another request for this document, would be to remove the following text:
"This is the byte string representation of an elliptic curve
      point following the conversion routine in Section 4.3.6 of ANSI
      X9.62 [7]. "
and replace it with a publicly available reference, or just describe the 
conversion. It is an important part of the protocol and unfortunately 
requires 100$ to read.

regards,
Nikos

---

From: Yoav Nir <[email-masked]>
Date: Tue, 13 Jan 2015 00:38:38 +0200

OK. Seeing as there was some support and no objection, the ECDH stuff is removed.

I’ll post version -01 in a minute.

Yoav

> On Jan 7, 2015, at 4:23 PM, Yoav Nir <[email-masked]> wrote:
> 
> Hi.
> 
>> On Dec 16, 2014, at 12:29 AM, Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi.
>>

---

From: Michael Clark <[email-masked]>
Date: Wed, 14 Jan 2015 20:02:39 +0800

>   rest of the handshake due to having wrong keys.

This was my thinking however I could not read this clearly in the text
as the record protection for handshake was stated as NULL NULL AEAD.

I am still looking for clear text in {{key-calculation}} that describes
that a strong authenticator of all sent handshake messages are returned
to each end signed in the Finished message.

Can we differentiate a tamper from garbled data?

Anyway it offers no protection against the yellow patch cable to the
grey box. There are many CA certs in the vendor trust stores. If you
sent 3 certs from CAs with no relationships then you could eliminate
this kind of tampering. multi-rooted. Verify is only a cost for 24H
(given session caching and ticket timeout is sorted).

>   endpoints won't enage in false start.

OK In TLS 1.2 the spec states there is no record protection for
handshake messages. I see verify_data field in Finished. It is vaguely
specified in RFC5426 and RFC5288 (AES-GCM) makes no reference to it.

However I am still skeptical as there is no record protection for
handshake messages so I don't know what is preventing the proxy from
returning illegal_parameter to the client hello until the client does a
TLS1.0 ClientHello and then edit the cipher list remove SCSV and cause
client to negotiate TLS_WITH_RSA_RC4_128_SHA with Windows XP.

I'm trying to find where the 12 octect verify_data is specified. If
*all* of the the handshake payload is in a MAC in verify data then you
could generate still generated ignored extensions to get a 96-bit hash
collision. Still reasoning about it...

Michael

---

From: Michael Clark <[email-masked]>
Date: Wed, 14 Jan 2015 20:21:38 +0800

> client to negotiate TLS_WITH_RSA_RC4_128_SHA with Windows XP.

*as* Windows XP.

> I'm trying to find where the 12 octet verify_data is specified. If

sorry garbled. I meant construct 96-bit collision to forge verify_data.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 14 Jan 2015 15:38:37 +0200

> to each end signed in the Finished message.

The first message keying includes hashes of all previous messages, so
those have to match for the keys to match.

For messages after the first keying, those are protected by the MAC built
into AEAD cipher.

> (given session caching and ticket timeout is sorted).

Yeah, certificates are another kettle of fish (made lots worse by
actual implementations that just plain don't work).

> specified in RFC5426 and RFC5288 (AES-GCM) makes no reference to it.

RFC5246 (TLS 1.2) you mean? And it does specify how Finished is computed,
and yes, it does include a hash of handshake messages in the computations.

Of course, if endpoint does not check the Finished message, things go
badly wrong (TLS 1.3 just blows up due to mismatched keys).

> client to negotiate TLS_WITH_RSA_RC4_128_SHA with Windows XP.

Not having client ever fall back (of course, browsers have historically
been pretty bad at this, which made POODLE more than just a curiosity).

> collision. Still reasoning about it...

It is specified in base TLS spec (Section 7.4.9 for TLS1.2 / RFC5246).

And given the realtime requirements, even ~2^48 work to collide a 96-
bit hash is a lot of work. And looks like one would need a preimage
to do anything interesting, which is ~2^96 work (regarded infeasible
even with lots of resource).

-Ilari

---

From: Michael Clark <[email-masked]>
Date: Thu, 15 Jan 2015 10:07:01 +0800

> even with lots of resource).

Makes sense. It's getting reachable in the relatively near future (for a
somewhat value of relatively). You could still do probabilistic attacks
with a smaller image. Like fishing.

>= 128-bits verify_data sounds better for draft a TLSv1.3 considering it
may be around for 10+ years. 256-bit MAC is 128 security bits (> 112).
The NIST requirement for signature strength beyond 2013 is 112 bits. I
suppose this mandates 256 bit MAC if the NIST requirement goes into FIPS
or any other national body requirements.

verify_data might be <16...64> octets instead of 12. 32 meets FIPS
signature strength requirements beyond 2013 if we interpret it as a
"handshake and signature" and 256-bit MAC as 128 security bits.

However verify_data is a "signature of a handshake" as RSA, PSK, EdDSA,
etc are used for signing. Either way you look at it, it is a signature.