Re: [TLS] Revision 10: possible attack if client authentication is allowed during PSK

[Ilari Liusvaara]

On Sun, Nov 01, 2015 at 04:36:43AM +0900, Eric Rescorla wrote:
> 
> I've been planning to do a big rewrite of the security "analysis" sections
> and while I don't think it's worth having a real analysis in the protocol
> (the literature is going to do a much better job here than we can), this
> seems like exactly the kind of thing that we do want to capture to
> explain the design and for future extensions.

What I think is also very important with regards to security is
explaining the properties of interfaces to applications.

E.g. I want to be able to find answer to "Can I authenticate a client
by reading value off TLS-EXTRACTOR and signing it?"[1][2] in the final
RFC.

Or "Can I key something non-TLS off TLS-Extractor" (yes).


And with regards to protocol analysis, the thing that nails
you with highest probability (after known bad ideas) is some
oddball feature that nobody really analyzes (or analyzes in
non-realistic ways, for this documenting assumptions at
external interface is VERY useful). These often allow taking
cracks in one part of the protocol and then amplifying those
to actual attacks.


[1] The answer being: Yes, but:
- You also need ciphersuite if you need cross-collision resistance
  (TLS certificate auth would be vulernable to CC if another PRF-
  hash with 256 or 384 bit output was added).
- In versions previous to TLS 1.3, you need extended_master_secret
  negotiated (because otherwise TLS-Extractor outputs aren't nonces).

[2] While TLS does have built-in client certificate authentication,
application-layer certificate authentication can be much more
flexible, doing things that are just plain infeasible to do in
TLS layer (like fine-grained authentication).



-Ilari

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

Re: [TLS] Revision 10: possible attack if client authentication is allowed during PSK

[Karthikeyan Bhargavan]

Nice analysis! I think that the composition of different mechanisms in the 
protocol is likely to
be where many subtle issues lie, and analyses like this one support that 
concern.

Several other composition examples were already discussed on this list (for 
previous drafts).
For example, when composing 0-RTT with 1-RTT in the most natural way, many 
attacks appeared:
   (1) 0-RTT application data  may be replayed (See note (2) in 6.2.2.)
   (2) an unknown key share attack on 0-RTT encryption keys (leading to the 
inclusion of ServerCertificate in 0-RTT handshake hash in 7.2.1)
   (3) a key compromise impersonation attack on 0-RTT (See note (3) in 6.2.2)

The addition of resumption, PSK, and client-auth provide plenty of further 
composition possibilies
that are (in my surely biased opinion) best handled by automated formal 
analysis. 
So, I’m looking forward to the full Tamarin results!

Best,
Karthik

> On 31 Oct 2015, at 12:19, Sam Scott  wrote:
> 
> Dear all,
> 
> We [1] are in the process of performing an automated symbolic analysis
> of the TLS 1.3 specification draft (revision 10) using the Tamarin
> prover [2], which is a tool for automated security protocol analysis.
> 
> While revision 10 does not yet appear to permit certificate-based client
> authentication in PSK (and in particular resumption using PSK), we modelled
> what we believe is the intended functionality. By enabling client
> authentication either in the initial handshake, or with a post- handshake
> signature over the handshake hash, our Tamarin analysis finds an attack. The
> result is a complete breakage of client authentication, as the attacker can
> impersonate a client when communicating with a server:
> 
> Suppose a client Alice performs an initial handshake with Charlie. Charlie,
> masquerading as Alice, subsequently performs a handshake with Bob. Following a
> PSK resumption, Bob requests authentication from Charlie (impersonating 
> Alice).
> Charlie then requests authentication from Alice, and the returned signature
> will also be a valid signature for the session with Bob.
> 
> Initial h/s  Initial h/s
>  |<-->|   |<-->|
>  |  exchange PSK  |   |  exchange PSK  |
>  ||   ||
>  |Start PSK resume|   |Start PSK resume|
>  |--->|   |--->|
>  |client_random nc|   |client_random nc|
>  ||   ||
>  |  Accept resume |   |  Accept resume |
> Alice|<---|(as Charlie) Charlie (as Alice)|<---|Bob
>  |server_random ns|   |server_random ns|
>  ||   ||
>  ||   ||
>  |Client auth req |   |Client auth req |
>  |<---|   |<---|
>  ||   ||
>  |  Client auth   |   |  Client auth   |
>  |--->|   |--->|
>sign nc,ns,...  relay signature
> 
> 
> 
> This attack is possible because the client signature is over the handshake
> hash, which only covers the nonces and other easily duplicated information,
> and in particular does not contain the server certificate (because none is
> presented in PSK mode [3]) or the server Finished.
> 
> While the modifications proposed in PR#316 [4] explicitly allow client
> authentication in these contexts, the PR also redefines the client signature
> based on a new "Handshake Context" value which includes the server Finished
> message. Intuitively, this new definition appears to address the attack
> because the attacker cannot transplant the Finished message between
> connections. We are currently working towards a Tamarin proof that PR#316
> indeed prevents our attack.
> 
> Therefore we would like to support the inclusion of Finished as
> part of the handshake context, in order to address this problem.
> 
> Many thanks,
> 
> Sam Scott
> 
> [1] Cas Cremers, Marko Horvat - University of Oxford;
> Thyla van der Merwe, Sam Scott - Royal Holloway, University of London.
> [2] http://www.infsec.ethz.ch/research/software/tamarin.html 
> 
> [3] Except in 0-RTT where the server's Certificate is explicitly
> included.
> [4] https://github.com/tlswg/tls13-spec/pull/316/ 
> ___
> TLS mailing list
> TLS@ietf.org
> https

[TLS] FW: New Version Notification for draft-jay-tls-omit-aead-explicit-nonce-extension-00.txt

[Jayaraghavendran k]

Hi All,

A new TLS extension draft for omitting the explicit nonce included in every 
record when AEAD ciphers are used has been proposed. This extension allows the 
Client Hello & Server Hello messages to negotiate a method for generating 
explicit nonce and thereby omit including it in every TLS/DTLS record.

Request your comments & suggestions.

Thanks!
 
Regards,
Jay

***
This e-mail and attachments contain confidential information from HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any 
use of the information contained herein in any way (including, but not limited 
to, total or partial disclosure, reproduction, or dissemination) by persons 
other than the intended recipient's) is prohibited. If you receive this e-mail 
in error, please notify the sender by phone or email immediately and delete it!
***

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: 29 September 2015 21:17
To: Jayaraghavendran k; Jayaraghavendran k; Raja ashok; Raja ashok
Subject: New Version Notification for 
draft-jay-tls-omit-aead-explicit-nonce-extension-00.txt


A new version of I-D, draft-jay-tls-omit-aead-explicit-nonce-extension-00.txt
has been successfully submitted by Jayaraghavendran K and posted to the IETF 
repository.

Name:   draft-jay-tls-omit-aead-explicit-nonce-extension
Revision:   00
Title:  TLS/DTLS Omit AEAD Explicit Nonce from Record Extension
Document date:  2015-09-29
Group:  Individual Submission
Pages:  8
URL:
https://www.ietf.org/internet-drafts/draft-jay-tls-omit-aead-explicit-nonce-extension-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-jay-tls-omit-aead-explicit-nonce-extension/
Htmlized:   
https://tools.ietf.org/html/draft-jay-tls-omit-aead-explicit-nonce-extension-00


Abstract:
   With emergence of Internet of Things(IoT), DTLS is being widely
   considered as a protocol of choice for communication security in IoT
   applications. Further, AES_CCM has emerged as the cipher of choice in
   constrained environments. Constrained Application Protocol (CoAP),
   which is the application layer protocol for resource constrained
   environments, mandates DTLS as underlying security protocol and
   proposes AES_CCM based ciphers to be used with different key exchange
   methods. AEAD ciphers requires an explicit nonce of 8 bytes must be
   carried in each transmitted record.This document defines a TLS (and
   DTLS) extension, which will allow clients and servers to omit the
   explicit nonce sent in TLS/DTLS records.  This document can be
   considered as an extended version of "Transport Layer Security (TLS)
   Extensions : Extension Definitions". The extension defined in this
   document apply equally to both DTLS and TLS protocols.


  


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

Re: [TLS] draft-jay-tls-omit-aead-explicit-nonce-extension

[Jayaraghavendran k]

Hi Eric,

Thanks for your response.

1. There is already no requirement that you have an explicit nonce. RFC5246
merely requires that you specify the length of the explicit nonce, but that
length can be 0, as it is in the ChaCha/Poly drafts. So, rather than build
an extension it would be better to just define a new cipher suite if you think
this is important.
[Jay]: The extension idea was mainly for the already defined ciphers in RFC 
6655 (for AES_CCM usage in TLS) & RFC 5288 (for AES_GCM usage in TLS). Both 
these RFCs state that an explicit nonce of 8 bytes MUST be carried in each 
record. So, in these cases to avoid the overhead, the options as I understand 
are defining a new extension or a new cipher suite (which suggests the new 
explicit nonce generation mechanism and makes the record iv length as 0).

This new extension is more like a framework for negotiating the type of 
explicit nonce generation mechanisms. If a particular way of generating the 
explicit nonce is found to be exploitable in future, a new mechanism can be 
defined and negotiated through the extension.  Defining  a new cipher for each 
new mechanism of explicit nonce generation may increase the number of ciphers 
that the client has to carry in it’s client hello by a good amount 
(considering, it needs to carry old ciphers also for backward compatibility 
with servers not supporting new ciphers).


2. TLS 1.3 already omits the explicit nonce entirely.
[Jay]:  My primary goal is for DTLS 1.2 which is used with CoAP in various IoT 
Scenarios. Usage of DTLS 1.2 with CoAP has already started in many products I 
believe and DTLS 1.3 may take some time and will not be immediately adapted by 
products already released.

Requesting your suggestions in the above context.

Thanks Again.

Best Regards,
Jay
***
This e-mail and attachments contain confidential information from HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any 
use of the information contained herein in any way (including, but not limited 
to, total or partial disclosure, reproduction, or dissemination) by persons 
other than the intended recipient's) is prohibited. If you receive this e-mail 
in error, please notify the sender by phone or email immediately and delete it!
***

From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: 24 October 2015 01:35
To: tls@ietf.org; 
draft-jay-tls-omit-aead-explicit-nonce-extens...@tools.ietf.org
Subject: [TLS] draft-jay-tls-omit-aead-explicit-nonce-extension

I took a quick look at this draft and IMO it is unnecessary, for two reasons:

1. There is already no requirement that you have an explicit nonce. RFC5246
merely requires that you specify the length of the explicit nonce, but that
length can be 0, as it is in the ChaCha/Poly drafts. So, rather than build
an extension it would be better to just define a new cipher suite if you think
this is important.

2. TLS 1.3 already omits the explicit nonce entirely.

-Ekr



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

[TLS] Fwd: [pkix] Updated elliptic curve drafts

[Phillip Hallam-Baker]

I strongly oppose any new crypto that does not include a fix for the
ephemeral keygen.

The reason logjam is possible is that the key negotiation is essentially

1) Negotiate a shared secret S1 using the strong, long term server key.
2) Use the shared secret to authenticate ephemeral key parameters Ec, Es
3) Derive the session keys S2 from the ephemeral key parameters only
and throw away the output from the strong long term keys.

It is not just 512 bit keys that are vulnerable. 1024 bit DH keys are also
weak:
https://freedom-to-tinker.com/blog/haldermanheninger/how-is-nsa-breaking-so-much-crypto/

If we are changing the crypto suites we can and should fix this
instead of S2 being a function of Ec, Es alone, add in the original S1
as a salt.  e.g. S2 = SHA512 (S1 + f(Ec, Es))

This ensures that no matter how broken the ephemeral crypto is, the
key exchange is always at least as secure as either the long term or
the ephemeral key.


Logjam isn't the only way that the system can be compromised.

Oh and damn right I think BULLRUN might have had a part in keeping the
spec broken.


There is a right way to design an ephemeral key exchange and it is to
'Do no harm'. Logjam shows that our current key negotiation mechanism
has a hole that makes it possible for the ephemeral to do harm.

The move to the CFRG curves will mean a backwards incompatible change
to the deployed infrastructure so this is a perfect time to fix
ephemeral key establishment.

I am going to keep raising this until the issue is fixed.



On Mon, Oct 12, 2015 at 4:25 PM, Simon Josefsson 
wrote:
> Hi,
>
> I've updated my drafts on Curve25519/Curve448 support in PKIX to refer
> to the CFRG-Curves and CFRG-EdDSA drafts.
>
> The following document adds new EdDSA key/signature OIDs directly:
>
> https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04
>
> The following document adds new namedCurve OIDs, thus going indirectly
> through the existing ECDSA 3279 route:
>
> https://tools.ietf.org/html/draft-josefsson-pkix-newcurves-01
>
> These two drafts take different approaches to including the new curves
> into PKIX, and currently both lack applicability statements.  There is
> potential for overlap and conflict right now.  It recently came up that
> for PKCS#11 a namedCurve approach would be useful, but for normal PKIX
> Certificates, it may be that the first direct approach is preferrable.
> The former lack the possibility of encoding keys for DH.  I believe each
> approach can be useful on its own, but we need to include text adressing
> use-cases that can be resolved by both documents to avoid conflicts.
>
> /Simon
>
> ___
> pkix mailing list
> p...@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] TLS 1.3 - Just ditch compression

[Scott Arciszewski]

Based on CRIME and BREACH we know that this construction is not secure:

C = encrypt(compress(A || B))

If you control B and A contains sensitive information, strlen(C) tells you
information about A. Vice versa if you control A and B contains sensitive
information.

In the context of a web application, this can lead to the compromise the
contents of HTTP-Only cookies.

This is known to be safe: C = encrypt(A || B). (No compression.)

This might be safe: C = encrypt(A || compress(B) ).

If an application needs to compress data before encryption, it shouldn't be
a Transport Layer protocol's job to do so.

Compression has no place in Transport Layer Security. Please nix it until
we can, in a provably secure manner, make C = encrypt(compress(A || B)) not
leak information about A when an attacker controls B.

I await your IACR papers that prove the contrary, or a swift and decisive
vote to kill TLS encryption in 1.3. Further bikeshedding is just
embarrassing.

Just my $0.02.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Design Alternatives for Kerberos + DH

[Rick van Rein]

Hello Benjamin,

> No, mutual authentication requires the client to receive a message from
> the server.

Yes, I know -- the server needs to handle the session key or the subkey
to prove posession of its KDC-stored service key.  By using it, the client
can be convinced or server identity.

> This could be implicit

I think it automatically is with TLS, since the Finished messages won't
succeed until both parties have derived the same master secret, which
if it involves the session key or subkey proves the server's identity in an
implicit manner.

I do believe a long-enough Finished message is required though.  For
the TLS_ECDHE_KRB_ CipherSuites I've proposed a verify_data_lenth
to match the required certainty from the message; if we mix Kerberos
client "certificates" info other CipherSuites like TLS_ECDHE_RSA_ then
a client SHOULD negotiate a high-enough value and the server MUST
support that.  It requires TLS 1.2 to do these things.

-Rick

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

Re: [TLS] TLS 1.3 - Support for compression to be removed

[takamichi saito]

2015/10/03 0:24、Salz, Rich  のメッセージ:

> 
>> 1) We know CRIME threat, but it can not be risk for everyone.
>> e.g., CVSS v2 Base Score: 2.6 (LOW)
> 
> CVSS isn't always appropriate; CVSS2 called Heartbleed a 5; CVS v3 called it 
> 7.5

We know it, but one of indicators.
How can you say the dangerous or risk instead of it? 
My point is, CRIME is risk for every case? even when we have option  in tls1.3, 
in case that default is off. 

> 
>> Which one is safer, "tls1.2" v.s. "tls1.3 with comp/decomp" ?
> 
> They are equivalent.  If you use AES-GCM and ECDHE, and you don't need 0RTT, 
> then there is no compelling reason to use TLS 1.3.

If so, some people can skip tls1.3.

;; takamixhi saito
c2xhYWlidHNvcw___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 - Support for compression to be removed

[takamichi saito]

> Browsers are not a concern as they already have their own comp/decomp codes. 
> HTTP/1 can compress content (Content-encoding and transfer-encoding) and 
> HTTP2 has additional header compression.
> 

I see, 
but contrary,
tls is only for browser? 

And more, 
if you kick out comp/decomp from tls,
can we be safer when we use tls?
If you know the paper, please teach me.

Or, rfc or good teacher should notify us,
"When you use TLSv1.3, you never use compression, sorry!"
I know it may be out scope, 
but we have to estimate the risk.

regards,


> Regards,
> Roland
> 
> 
> Am 02.10.2015 um 15:08 schrieb takamichi saito:
>>> Do we know how many protocols currently suffer from CRIME?
>>> 
>>> 
>>> Maybe a best practice could be suggested by UTA for the implementation of 
>>> TLS in software, to disable compression if vulnerable.  And for the others, 
>>> to implement a way to enable/disable compression in case one day a 
>>> vulnerability is found.
>> I agree.
>> 
>> Again,
>> 
>> 1) We know CRIME threat, but it can not be risk for everyone.
>> e.g., CVSS v2 Base Score: 2.6 (LOW)
>> 
>> 2) If we need to have comp/decomp in an application layer,
>>  clients such like browser need their own comp/decomp codes.
>> 
>> 3) If there is no comp in tls1.3, some people may continue to use tls1.2.
>> Which one is safer, "tls1.2" v.s. "tls1.3 with comp/decomp" ?
>> 
>> That's why we explore the way to keep compression in TLSv1.3.
>> How about making an option only in server-side?
>> The spec has the compression but default is off, and also provides the 
>> suggestion.
>> 
>> 
>>> -- 
>>> Julien ÉLIE
>>> 
>>> « La vraie valeur d'un homme se mesure lorsqu'il a tout perdu. »
>>> 
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>> 
>> ;; takamixhi saito
>> c2xhYWlidHNvcw
>> 
>> ___
>> 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

;; takamixhi saito
c2xhYWlidHNvcw___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 - Just ditch compression

[Russ Housley]

I thought we already decided to remove compression from TLS 1.3.

Russ


On Oct 8, 2015, at 10:10 PM, Scott Arciszewski wrote:

> Based on CRIME and BREACH we know that this construction is not secure:
> 
> C = encrypt(compress(A || B))
> 
> If you control B and A contains sensitive information, strlen(C) tells you 
> information about A. Vice versa if you control A and B contains sensitive 
> information.
> 
> In the context of a web application, this can lead to the compromise the 
> contents of HTTP-Only cookies.
> 
> This is known to be safe: C = encrypt(A || B). (No compression.)
> 
> This might be safe: C = encrypt(A || compress(B) ).
> 
> If an application needs to compress data before encryption, it shouldn't be a 
> Transport Layer protocol's job to do so.
> 
> Compression has no place in Transport Layer Security. Please nix it until we 
> can, in a provably secure manner, make C = encrypt(compress(A || B)) not leak 
> information about A when an attacker controls B.
> 
> I await your IACR papers that prove the contrary, or a swift and decisive 
> vote to kill TLS encryption in 1.3. Further bikeshedding is just embarrassing.
> 
> Just my $0.02.
> 
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises

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

Re: [TLS] TLS 1.3 - Just ditch compression

[Dave Garrett]

On Sunday, November 01, 2015 07:53:50 pm Russ Housley wrote:
> I thought we already decided to remove compression from TLS 1.3.

We did.

See here:
https://www.ietf.org/mail-archive/web/tls/current/msg17941.html

On Thursday, October 08, 2015 10:10:51 pm Scott Arciszewski wrote:
> Compression has no place in Transport Layer Security.
[...]
> Further bikeshedding is just embarrassing.

The bikeshed was officially demolished. Compression will not be in TLS 1.3.


Dave

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

[TLS] IETF 94 - TLS agenda

[Sean Turner]

I’ve uploaded the agenda:
https://www.ietf.org/proceedings/94/agenda/agenda-94-tls
I’ll post slides as I get them.

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

Re: [TLS] TLS 1.3 - Just ditch compression

[Sean Turner]

My bad there were some messages sitting in the moderator queue that I let go.

spt

> On Nov 02, 2015, at 10:01, Dave Garrett  wrote:
> 
> On Sunday, November 01, 2015 07:53:50 pm Russ Housley wrote:
>> I thought we already decided to remove compression from TLS 1.3.
> 
> We did.
> 
> See here:
> https://www.ietf.org/mail-archive/web/tls/current/msg17941.html
> 
> On Thursday, October 08, 2015 10:10:51 pm Scott Arciszewski wrote:
>> Compression has no place in Transport Layer Security.
> [...]
>> Further bikeshedding is just embarrassing.
> 
> The bikeshed was officially demolished. Compression will not be in TLS 1.3.
> 
> 
> Dave
> 
> ___
> 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

Re: [TLS] Fwd: [pkix] Updated elliptic curve drafts

[Martin Thomson]

It's not entirely clear what you are asking for here, but have you
looked at the key derivation in TLS 1.3?

On 16 October 2015 at 01:27, Phillip Hallam-Baker  wrote:
>
> I strongly oppose any new crypto that does not include a fix for the
> ephemeral keygen.
>
> The reason logjam is possible is that the key negotiation is essentially
>
> 1) Negotiate a shared secret S1 using the strong, long term server key.
> 2) Use the shared secret to authenticate ephemeral key parameters Ec, Es
> 3) Derive the session keys S2 from the ephemeral key parameters only
> and throw away the output from the strong long term keys.
>
> It is not just 512 bit keys that are vulnerable. 1024 bit DH keys are also
> weak:
> https://freedom-to-tinker.com/blog/haldermanheninger/how-is-nsa-breaking-so-much-crypto/
>
> If we are changing the crypto suites we can and should fix this
> instead of S2 being a function of Ec, Es alone, add in the original S1
> as a salt.  e.g. S2 = SHA512 (S1 + f(Ec, Es))
>
> This ensures that no matter how broken the ephemeral crypto is, the
> key exchange is always at least as secure as either the long term or
> the ephemeral key.
>
>
> Logjam isn't the only way that the system can be compromised.
>
> Oh and damn right I think BULLRUN might have had a part in keeping the
> spec broken.
>
>
> There is a right way to design an ephemeral key exchange and it is to
> 'Do no harm'. Logjam shows that our current key negotiation mechanism
> has a hole that makes it possible for the ephemeral to do harm.
>
> The move to the CFRG curves will mean a backwards incompatible change
> to the deployed infrastructure so this is a perfect time to fix
> ephemeral key establishment.
>
> I am going to keep raising this until the issue is fixed.
>
>
>
> On Mon, Oct 12, 2015 at 4:25 PM, Simon Josefsson 
> wrote:
>> Hi,
>>
>> I've updated my drafts on Curve25519/Curve448 support in PKIX to refer
>> to the CFRG-Curves and CFRG-EdDSA drafts.
>>
>> The following document adds new EdDSA key/signature OIDs directly:
>>
>> https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04
>>
>> The following document adds new namedCurve OIDs, thus going indirectly
>> through the existing ECDSA 3279 route:
>>
>> https://tools.ietf.org/html/draft-josefsson-pkix-newcurves-01
>>
>> These two drafts take different approaches to including the new curves
>> into PKIX, and currently both lack applicability statements.  There is
>> potential for overlap and conflict right now.  It recently came up that
>> for PKCS#11 a namedCurve approach would be useful, but for normal PKIX
>> Certificates, it may be that the first direct approach is preferrable.
>> The former lack the possibility of encoding keys for DH.  I believe each
>> approach can be useful on its own, but we need to include text adressing
>> use-cases that can be resolved by both documents to avoid conflicts.
>>
>> /Simon
>>
>> ___
>> pkix mailing list
>> p...@ietf.org
>> https://www.ietf.org/mailman/listinfo/pkix
>>
>
>
> ___
> 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] Collision issue in ciphertexts.

[Dang, Quynh]

Hi Eric,


As you asked the question about how many ciphertext blocks should be safe under 
a single key, I think it is safe to have 2^96 blocks under a given key if the 
IV (counter) is 96 bits.


When there is a collision between two ciphertext blocks when two different 
counter values are used , the chance of the same plaintext was used twice is 
1^128.  Collisions start to happen a lot when the number of ciphertext blocks 
are above 2^64. However, each collision just reveals that the corresponding 
plaintext blocks are probably different ones.



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