From SRS0=zENr=TL=acm.org=bmoeller@srs.kundenserver.de Tue Oct 1 04:32:41 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEBA221F9F96 for ; Tue, 1 Oct 2013 04:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYFX5i6qKEXs for ; Tue, 1 Oct 2013 04:32:36 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id ED26021F9F8E for ; Tue, 1 Oct 2013 04:32:32 -0700 (PDT) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0Lvx1t-1Vuphd0moX-017Y2i; Tue, 01 Oct 2013 13:27:12 +0200 Received: by mail-ie0-f175.google.com with SMTP id e14so13063556iej.20 for ; Tue, 01 Oct 2013 04:27:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=pxschSMzasUgeGRWa/8jX76yaXA+7b//OzBpWiHF41c=; b=LjeDsDW3kCv1BfxnyL3fTFfJYWevQP6fmmu+dO2L6v1ITl6PAEhbmdWLB9jEWejip9 sHYPiK1icdkztDl8p7fCSviorprywtNhlWVOKosYCC1X/Pl+wMzFhMH50MPwPicsPpUe ean2pyGihwqVBYWb4l19Nq5MbIx8YQXKYdODo2zvHGqfut5Z4x8xVDmzbu8mFFmPItED 0XsdGcVCgixTaON/at0tGYbEOvQKQFP/73U6vOq4pzHsG6BEU/DVkfoOR8z/j5q5JFNk 1/E0wPIj21Id8xOSE51qU0AmvqJn3EhNwTLnTWr0H8uFVeDEh0J9sy+2H6px2/Tbnwaa SafQ== MIME-Version: 1.0 X-Received: by 10.50.6.71 with SMTP id y7mr17217859igy.8.1380626830939; Tue, 01 Oct 2013 04:27:10 -0700 (PDT) Received: by 10.43.64.138 with HTTP; Tue, 1 Oct 2013 04:27:10 -0700 (PDT) In-Reply-To: <20130930171657.C8BE01A9C2@ld9781.wdf.sap.corp> References: <20130930171657.C8BE01A9C2@ld9781.wdf.sap.corp> Date: Tue, 1 Oct 2013 13:27:10 +0200 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7bd6c212d362ae04e7ac3b07 X-Provags-ID: V02:K0:URxAsmcVfKf19ZDIuBpMx7AcRycwq4JJ1Mtk0qZ+fNw lUWQYYYVYb2fh3WOvvhnrnq0R1g9Y0zTOYpYDmoB39MSigszPo IMPVIsihywr23i//R0bx6Y1GO6+kLByu6GS7xuhWQnZo71+NZl MBBCWPc5cHahbP54KbzAuFIDAPbPVk0xZaHg/GPq8V/VloOEdH GiT/dz+Feyl0AuU6lG5skymASuLlVjyBYU+GtuZhiu9XKHVqKP IR/DLePTbZDiXuKHNHRMTfAzCIROisceuApaMLQuQic/BQe+BG BgsmlcVTQF31uTvlucmrItQjIkVT5WcZ3cQbZybFC6wtguou0h MdSwzN19+Tjs5pdA/LMutctdDJ0N+RSy7x57CsUvMuO3ekJans Nz/5LGfgaDOffiKjww2mWak5mVdV/YpAU60GvqyOgaA0QnqHpi Hz+Ko Subject: Re: [TLS] Fwd: New Version Notification for draft-bmoeller-tls-downgrade-scsv-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 11:37:38 -0000 --047d7bd6c212d362ae04e7ac3b07 Content-Type: text/plain; charset=ISO-8859-1 Martin Rex : > To me, these two requirements amount to an unnecessary knee-jerk reaction, > while we are fully aware that most TLS version interop problems are > non-malicious, i.e. _not_ caused by an active attacker. > Well, it's still supposed to be a security protocol, so we *need* to be able to deal with the situation that the problem is caused by an active attacker. Also, even if a security-weakening downgrade is not an intentional attack, it's still security-weakening. > I really see harm in increasing the amount of TLS handshake failures > with new "abort" requirements of the TLS protocol itself. Any > new/additional > handshake failures ought to be left purely and entirely to the calling > applications and their security trade-offs / policies, which may or > may not involve the decision of an interactive user. Our concern in > TLS WG ought to be reducing handshake failures, and getting rid of > the reconnect fallback entirely. > Yes, downgraded retries are a pain and it would be much better to avoid them, but that's completely orthogonal to draft-bmoeller-tls-downgrade-scsv-00. Whenever you manage to avoid a retry, nothing in draft-bmoeller-tls-downgrade-scsv-00 applies to that handshake. If you have a retry, with draft-bmoeller-tls-downgrade-scsv-00, it *is* left to security trade-offs whether you'd rather see a handshake failure, or accept the downgraded protocol even though the client and server should have been able to negotiate something better. The specification is written to let the client make this decision, because such retry policies are necessarily client-driven. The specification currently does not explicitly recommend that TLS implementations let the calling application influence this policy (I certainly could add that, but then our specs don't typically identify the many protocol configuration settings that can typically be influenced by applications as such -- we're specifying protocols, not APIs for using those protocols from applications). > Another example for TLS version challenges are defective middle-boxes > (Bluecoat seems popular for internet access from company networks): > > https://kb.bluecoat.com/index?page=content&id=KB5493&actp=search&viewlocale=en_US&searchid=1380557656642 That's why the Security Considerations in my Internet Draft have this: Section 4 does not require client implementations to send TLS_DOWNGRADE_SCSV in any particular case, it merely recommends it; behavior can be adapted according to the client's security needs. For example, during the initial deployment of a new protocol version (when some interoperability problems may have to be expected), smoothly falling back to the previous protocol version in case of problems may be preferrable to potentially not being able to connect at all: so TLS_DOWNGRADE_SCSV could be omitted for this particular protocol downgrade step. > Yet another example would be the upgrade path for an installed server-farm, > where you would get yourself into trouble if the existing server-farm > causes clients to perform reconnect-fallbacks and trying to test > a new implementation of the kind you suggest would cause occasional > handshake failures for handshake where the first request went to an > old server, and the reconnect fallback to the updated server. > So for such a setup, this kind of feature would require a "flag day". > You mean something like the following, right? - Broken servers support TLS 1.1 only, and will barf on a TLS 1.2 ClientHello. - Fixed servers also supports TLS 1.2, and understand TLS_DOWNGRADE_SCSV. - Connection are distributed to servers in a round-robin fashion, say. You'd encounter a glitch in this scenario if a client tries a TLS 1.2 handshake to a broken server first, then retries with TLS 1.1 and TLS_DOWNGRADE_SCSV and happens to hit one of the fixed servers so that the connection attempt fails. (There's no such problem if both connections go to a broken server, or if the first connection goes to a fixed server.) So, for some proportion of cases, retrying clients wouldn't benefit from their retries, and instead would encounter similar brokenness as those clients that don't retry in the first place. There's no requirement for a "flag day" (by which I assume you mean changing the configuration for the entire server farm at once) if you roll out fixed TLS 1.1 servers first (at any pace), and subsequently enable TLS 1.2 support (at any pace). > http://tools.ietf.org/html/rfc5288#section-4 > http://tools.ietf.org/html/rfc6655#section-5 > > Implementing AEAD for TLSv1.0 or TLSv1.1 would be simple and straight- > forward, and the cipher suites (themselves) would exhibit the same > security properties. But this [...] prohibits clients from even > proposing these cipher suites when they're doing a fallback, independent > of what is causing the fallback. > [...] > To really improve the situation, new protocol features (including > TLS protocol versions >1.1) ought to be negotiated in a fashion that > increases the amount of successful TLS handshakes for the entire > installed base, and avoids the necessity for reconnect fallbacks-- > something that the majority of programmtic TLS clients do not > even have. I assume that those specs were written to disallow these AEAD cipher suites for earlier protocol versions specifically to improve interoperability, because a client wouldn't be able to indicate that it supports TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 for TLS 1.2 but not for TLS 1.1. Assigning additional cipher suite numbers for essentially the same cipher suites *with* support for earlier protocol versions might be worthwhile. Bodo --047d7bd6c212d362ae04e7ac3b07 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Martin Rex <mrex@sap.com>:
=A0
To me, these two requirements amount to an unnecessary knee-jerk reaction,<= br> while we are fully aware that most TLS version interop problems are
non-malicious, i.e. _not_ caused by an active attacker.

Well, it's still supposed to be a security protocol, s= o we *need* to be able to deal with the situation that the problem is cause= d by an active attacker. =A0Also, even if a security-weakening downgrade is= not an intentional attack, it's still security-weakening.

=A0
I really see harm in increasing the amount of TLS handshake failures
with new "abort" requirements of the TLS protocol itself. =A0Any = new/additional
handshake failures ought to be left purely and entirely to the calling
applications and their security trade-offs / policies, which may or
may not involve the decision of an interactive user. =A0Our concern in
TLS WG ought to be reducing handshake failures, and getting rid of
the reconnect fallback entirely.

Yes, d= owngraded retries are a pain and it would be much better to avoid them, but= that's completely orthogonal to=A0draft-bmoeller-tls-downgrade-scsv-00= . =A0Whenever you manage to avoid a retry, nothing in=A0draft-bmoeller-tls-= downgrade-scsv-00 applies to that handshake.

If you have a retry, with draft-bmoeller-tls-downgrade-= scsv-00, it *is* left to security trade-offs whether you'd rather see a= handshake failure, or accept the downgraded protocol even though the clien= t and server should have been able to negotiate something better. =A0The sp= ecification is written to let the client make this decision, because such r= etry policies are necessarily client-driven. =A0The specification currently= does not explicitly recommend that TLS implementations let the calling app= lication influence this policy (I certainly could add that, but then our sp= ecs don't typically identify the many protocol configuration settings t= hat can typically be influenced by applications as such -- we're specif= ying protocols, not APIs for using those protocols from applications).

=A0
Another example for TLS version challenges are defective middle-boxes
(Bluecoat seems popular for internet access from company networks):
https://kb.bluecoat.com/index?page=3Dcontent&id=3DKB5493&am= p;actp=3Dsearch&viewlocale=3Den_US&searchid=3D1380557656642

That's why the Security Considerations in my Intern= et Draft have this:

   Section 4 does no=
t require client implementations to send
   TLS_DOWNGRADE_SCSV in any particular case, it merely recommends it;
   behavior can be adapted according to the client's security needs.
   For example, during the initial deployment of a new protocol version
   (when some interoperability problems may have to be expected),
   smoothly falling back to the previous protocol version in case of
   problems may be preferrable to potentially not being able to connect
   at all: so TLS_DOWNGRADE_SCSV could be omitted for this particular=A0
   protocol downgrade step.

=A0
=A0

Yet another example would be the upgrade path for an installed server-farm,=


where you would get yourself into trouble if the existing server-farm

causes clients to perform reconnect-fallbacks and trying to test

a new implementation of the kind you suggest would cause occasional

handshake failures for handshake where the first request went to an

old server, and the reconnect fallback to the updated server.

So for such a setup, this kind of feature would require a "flag day&qu=
ot;.

You mean something like the follow=
ing, right?

- Broken servers support TLS 1.1 only,=
 and will barf on a TLS 1.2 ClientHello.


- Fixed servers also supports TLS 1.2, and understand TLS_DOWNGRADE_SC=
SV.
- Connection are distributed to servers in a round-robin fash=
ion, say.

You'd encounter a glitch in this sce=
nario if a client tries a TLS 1.2 handshake to a broken server first, then =
retries with TLS 1.1 and TLS_DOWNGRADE_SCSV and happens to hit one of the f=
ixed servers so that the connection attempt fails. =A0(There's no such =
problem if both connections go to a broken server, or if the first connecti=
on goes to a fixed server.) =A0So, for some proportion of cases, retrying c=
lients wouldn't benefit from their retries, and instead would encounter=
 similar brokenness as those clients that don't retry in the first plac=
e.



There's no requirement for a "flag day" (=
by which I assume you mean changing the configuration for the entire server=
 farm at once) if you roll out fixed TLS 1.1 servers first (at any pace), a=
nd subsequently enable TLS 1.2 support (at any pace).




=A0

=A0 http://tools.ietf.org/html/rfc5288#section-4

=A0 http://tools.ietf.org/html/rfc6655#section-5



Implementing AEAD for TLSv1.0 or TLSv1.1 would be simple and straight-

forward, and the cipher suites (themselves) would exhibit the same

security properties. =A0But this [...] prohibits clients from even

proposing these cipher suites when they're doing a fallback, independen=
t

of what is causing the fallback.
[...]=A0


To really improve the situation, new protocol features (including

TLS protocol versions >1.1) ought to be negotiated in a fashion that

increases the amount of successful TLS handshakes for the entire

installed base, and avoids the necessity for reconnect fallbacks--

something that the majority of programmtic TLS clients do not

even have.

I assume that those specs were w= ritten to disallow these AEAD cipher suites for earlier protocol versions s= pecifically to improve interoperability, because a client wouldn't be a= ble to indicate that it supports=A0TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 for = TLS 1.2 but not for TLS 1.1. =A0Assigning additional cipher suite numbers f= or essentially the same cipher suites *with* support for earlier protocol v= ersions might be worthwhile.

Bodo

--047d7bd6c212d362ae04e7ac3b07-- From mrex@sap.com Tue Oct 1 06:40:21 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1A911E8394 for ; Tue, 1 Oct 2013 06:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.186 X-Spam-Level: X-Spam-Status: No, score=-10.186 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PnFvNBdx+uC for ; Tue, 1 Oct 2013 06:40:16 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id D9A6B11E8229 for ; Tue, 1 Oct 2013 06:38:28 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r91DcJMb015194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Oct 2013 15:38:20 +0200 (MEST) In-Reply-To: To: Yoav Nir Date: Tue, 1 Oct 2013 15:38:19 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20131001133819.CAE281A9CB@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" , Kyle Hamilton Subject: Re: [TLS] Safe ECC usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 13:40:21 -0000 Yoav Nir wrote: > > Martin Rex wrote: > > > > I currently do not see any benefit from using EC for digital signatures, > > Other than certificate size and the speed of making those calculations? > Really, try "openssl speed rsa2048 ecdsap256" on any Linux or Mac machine. openssl 1.0.1c x86_64 tells me ecdsap256 is 10x faster than rsa2048 for signing and 10x slower than rsa2048 for verifying. So there would be a penalty for EC signatures on certificate chains, CRLs, OCSP and whathaveyou. ECDH with curve25519 could be made a small code change, local to TLS, and affecting _NONE_ of the stuff that deals with X.509 certificates. And you need only one server certificate (RSA-2048) for everything. > > > but instead a huge amount of code, complexity and IPR issues (did you > > look at the CertiCom idea how to charge?). > > Yes, I have: "If the standard is adopted, Patent Holder will not assert > any claims of any patents owned or controlled by the Patent Holder > against any party for making, using, selling importing or offering > for sale a product that implements the Standard?" > (weird capitalization theirs, not mine) They want to charge EC cert issuers (CAs) for issuing EC certs. The use of ECDHE with parameters authenticated by RSA certs would be royalty free. > > Also, there's RFC 6090 on how you can do all the ECC operations > with 1994 technology. Our current crypto codebase as well as the PKIX codebase is EC-free, and FIPS 140-2 certified. The amount of code necessary to implement EC (crypto, PKIX, rfc4492) is significant, and without any substantial benefits, the lid of that can is probably not going to be reopened soon (~3-5 years). > > IANAL and neither are you. What makes you think that the IPR issues > apply to P-256 more than they do to Curve25519? CertiCom intends to charge for X.509 certs. Don't use it for signing. > > > i.e. > > a small number of new cipher suites and an additional ClientKeyExchange > > and ServerKeyExchange variant specifically tailord for curve25519, so > > that there are real benefits to a full-blown and generic rfc4492 TLS EC > > crypto. > > ECDHE_RSA is slower than plain RSA. ECDHE_ECDSA is faster. What openssl-1.0.1c says, ECDHE_DSA is about par. Maybe there should be a middle-ground between RSA and ECDHE_RSA. Why is it OK for the RSA ciphersuites to perform a time-based validation of the Server certificate, but not OK to perform a time-based validation of the signature on the (EC)DH parameters? >From the performance perspective, the ration of TLS session resumes vs TLS full handshakes on a server should be 10:1 or better, otherwise something is going terribly wrong with either the servers session cache or the client's session caching strategy. > > Once you've dipped your toe in the ECC pool, there's no reason > not to have it in the signature as well. We haven't dipped our toe yet, and the complexity around it is certainly no motivator to consider adding this through software maintenance. -Martin From 57756671618275-ietf-tls@sublist.cr.yp.to Tue Oct 1 07:35:35 2013 Return-Path: <57756671618275-ietf-tls@sublist.cr.yp.to> X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B94211E8129 for ; Tue, 1 Oct 2013 07:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.114 X-Spam-Level: X-Spam-Status: No, score=0.114 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2k-GfkXCP0kE for ; Tue, 1 Oct 2013 07:35:30 -0700 (PDT) Received: from mace.cs.uic.edu (mace.cs.uic.edu [131.193.32.224]) by ietfa.amsl.com (Postfix) with SMTP id 5980F11E8153 for ; Tue, 1 Oct 2013 07:35:26 -0700 (PDT) Received: (qmail 5094 invoked by uid 1011); 1 Oct 2013 14:35:20 -0000 Received: from unknown (unknown) by unknown with QMTP; 1 Oct 2013 14:35:20 -0000 Received: (qmail 11011 invoked by uid 1001); 1 Oct 2013 14:35:11 -0000 Date: 1 Oct 2013 14:35:11 -0000 Message-ID: <20131001143511.11010.qmail@cr.yp.to> From: "D. J. Bernstein" To: tls@ietf.org Mail-Followup-To: tls@ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> <20130926152757.15842.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDB49B@XMB116CNC.rim.net> <20130928223648.1113.qmail@cr.yp.to> <20130929025714.5578895.47771.4422@certicom.com> Subject: Re: [TLS] Safe ECC usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 14:35:35 -0000 Dan Brown writes: > You noted that curve sizes p,p-1, and p+1 are weak. > These might be called special curve sizes, since for a random curve, > of order p+d, we expect |d| around p^(1/2), and for these d is much > smaller. There is already overwhelming evidence that the size of d is not what matters. For example, the next attack that you should learn is one that breaks group order p+6m+2 if p=12m^2-1; in this case the gap from p is more than 80% of its maximum possible value. What's actually going on is that the additive group F_p has order p; the multiplicative group F_p^* has order p-1; the group F_{p^2}^* has order p^2-1; the group F_{p^3}^* has order p^3-1; etc. For roughly the first dozen groups in this list we have discrete-logarithm algorithms fast enough to worry about. There are known methods to "transfer" ECDLP over F_p into these discrete-logarithm problems---but only if the EC group has order dividing p, p-1, p^2-1, p^3-1, etc. This is why p+1 is a problem (it divides p^2-1); it's why p+6m+2 is a problem if p=12m^2-1 (p+6m+2 divides p^3-1); etc. > Of course, it's a logical leap to > jump from small d to small curve coefficients, It's even worse than a logical leap: CM theory shows that each d that isn't extremely close to +-2 sqrt(p) corresponds to a huge number of different curve coefficients. There's overwhelming evidence that the correlation is negligible, making coefficient size useless as a predictor of the size of d---never mind the question of what any of this has to do with ECC security. > but if we are going to be prudent, then why not avoid small > coefficients too? Calling this "prudent" has zero justification from the extensive literature on ECC security analysis. You could, with exactly the same amount of justification, claim that _large_ coefficients are more likely to be weak and that choosing small coefficients is the safest strategy. What actually matters is that taking large coefficients imposes an extra cost, both in cryptographic performance and in the human effort required to rule out back doors. These are resources taken away from things that actually matter for security. If this were the only bad cryptographic decision then it wouldn't be a huge problem, but unfortunately it's just one of many things that people screw up. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago From dbrown@certicom.com Tue Oct 1 08:51:25 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9548E11E8125 for ; Tue, 1 Oct 2013 08:51:24 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -2.865 X-Spam-Level: X-Spam-Status: No, score=-2.865 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0vWBtrVjTLN for ; Tue, 1 Oct 2013 08:51:19 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC2C11E8143 for ; Tue, 1 Oct 2013 08:51:18 -0700 (PDT) Content-Type: multipart/mixed; boundary="===============1931553311==" MIME-Version: 1.0 Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs212cnc.rim.net with ESMTP/TLS/AES128-SHA; 01 Oct 2013 11:51:09 -0400 Received: from XCT104CNC.rim.net (10.65.161.204) by XCT106CNC.rim.net (10.65.161.206) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 1 Oct 2013 11:51:08 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT104CNC.rim.net ([::1]) with mapi id 14.03.0123.003; Tue, 1 Oct 2013 11:51:08 -0400 From: Dan Brown To: "'djb@cr.yp.to'" , "'tls@ietf.org'" Thread-Topic: [TLS] Safe ECC usage Thread-Index: AQHOvrNuxn3XJXmgAkKRAg2ZE6kwf5nf7Ylw Date: Tue, 1 Oct 2013 15:51:07 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF5BDE21E@XMB116CNC.rim.net> References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> <20130926152757.15842.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDB49B@XMB116CNC.rim.net> <20130928223648.1113.qmail@cr.yp.to> <20130929025714.5578895.47771.4422@certicom.com> <20131001143511.11010.qmail@cr.yp.to> In-Reply-To: <20131001143511.11010.qmail@cr.yp.to> Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.250] MIME-Version: 1.0 Subject: Re: [TLS] Safe ECC usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 15:51:25 -0000 --===============1931553311== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0144_01CEBE9C.83693990" ------=_NextPart_000_0144_01CEBE9C.83693990 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > D. J. Bernstein writes > > Dan Brown writes: > > You noted that curve sizes p,p-1, and p+1 are weak. > > These might be called special curve sizes, since for a random curve, > > of order p+d, we expect |d| around p^(1/2), and for these d is much > > smaller. > > There is already overwhelming evidence that the size of d is not what > matters. For example, the next attack that you should learn is one that [DB] Thanks for the advice, but what I need to learn, or remember, is no justification for the security of Curve25519. > breaks group order p+6m+2 if p=12m^2-1; in this case the gap from p is [DB] In case, anybody gets scared here, standards already have the MOV test rule this class out. In my weak defense, negligible fraction of p are affected here. More strongly, please remember that we are talking about hypotheticals here: maybe there exists undiscovered attacks, e.g. against P256 or Curve25519. If the evidence is so overwhelming, then maybe we should worry much less about P256? That said, your argument is cogent, and I take new, so this discussion has proven fruitful for improving the justification Curve25519, at least to me. > more than 80% of its maximum possible value. > > What's actually going on is that the additive group F_p has order p; > the multiplicative group F_p^* has order p-1; the group F_{p^2}^* has > order p^2-1; the group F_{p^3}^* has order p^3-1; etc. For roughly the > first dozen groups in this list we have discrete-logarithm algorithms > fast enough to worry about. There are known methods to "transfer" ECDLP > over F_p into these discrete-logarithm problems---but only if the EC > group has order dividing p, p-1, p^2-1, p^3-1, etc. This is why p+1 is > a problem (it divides p^2-1); it's why p+6m+2 is a problem if p=12m^2-1 > (p+6m+2 divides p^3-1); etc. [DB] Excellent explanation, though not one I needed. > > > Of course, it's a logical leap to > > jump from small d to small curve coefficients, > > It's even worse than a logical leap: CM theory shows that each d that > isn't extremely close to +-2 sqrt(p) corresponds to a huge number of [DB] Good point, the case for Curve25519 is growing yet stronger. But how much is huge? I have much to learn, I know, but my understanding is that there are about p isomorphism classes of curves, and on the order of p^(1/2) of curve orders, so about p/^(1/2) curves per order. I could be wrong, but I think that a reasonable heuristic is for a random curve by isomorphism class, its corresponding coefficient (if its equation is pushed into a one-parameter family of equations) is approximately. Hmm, let's see, so what the smallest coefficient be, on average? This problem is probably a well known problem, but here is a crude approximation: p^(1/2). Consider the probability that all coefficients have size larger than p^(1/2). For each individual coefficient the chance is (p - p^(1/2))/p = 1 - p^(-1/2). Now (1-p^(-1/2))^(p^(1/2)) is the probability that they all are larger, and this e^(-1). > different curve coefficients. There's overwhelming evidence that the > correlation is negligible, making coefficient size useless as a > predictor of the size of d---never mind the question of what any of > this has to do with ECC security. > > > but if we are going to be prudent, then why not avoid small > > coefficients too? > > Calling this "prudent" has zero justification from the extensive > literature on ECC security analysis. You could, with exactly the same [DB] I know, from the current literature, which is why I said I feel Curve25519 is safe. Again, I am only talking about unanticipated hypothetical attacks. > amount of justification, claim that _large_ coefficients are more > likely to be weak and that choosing small coefficients is the safest > strategy. [DB] Agreed to an extent: coefficient size is just an arbitrary way to test pseudo-random uniformity. For example, what is the P-value of the coefficient size of Curve25519? (Compared to random curves of any size). You correctly argue that coefficient-size is not a concern based on current literature, and that it improves efficiency, so therefore, it seems economical to ignore a low P-value for this statistic. Also, taking your argument further, one could apply any other arbitrary statistic. One could then contrive some weird statistic with a low P-value to deliberate reject some given curve. The point of coefficient size as a statistic is just that it is a nothing-up-my-sleeve statistic. I thought all that was implicit in what I said. > > What actually matters is that taking large coefficients imposes an > extra cost, both in cryptographic performance and in the human effort > required to rule out back doors. These are resources taken away from [DB] Back doors in the case P256, and pseudo-random curves, require unpublished attacks, perhaps surprising ones. (Aside: even if back doors are inserted by adversary #1, it may be possible for adversary #2 to find the attack too, so the concern may extend beyond the back door.) I am concentrating on the issue of unpublished attacks of elliptic curves, because that is one of logical pre-requisite to a back door. (An alternative logical pre-requisite is an unpublished attack on SHA-1, or how it is used in the generation of P256, but that is an orthogonal issue to Curve25519.) Brainpool and RFC 5639 recommends pseudo-random parameters to avoid unanticipated attacks, and you are arguing against this recommendation by anticipating from known attacks. ------=_NextPart_000_0144_01CEBE9C.83693990 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUgTCCBnAw ggVYoAMCAQICChfYCekAAwAXxTIwDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAz WUtGMB4XDTEzMDUyODE1NDQwOVoXDTE0MDUxNzAwMjMzM1owgYUxEzARBgoJkiaJk/IsZAEZFgNu ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xETAPBgNVBAsTCENlcnRpY29tMQ4wDAYDVQQLEwVVc2Vy czESMBAGA1UEAxMJRGFuIEJyb3duMSIwIAYJKoZIhvcNAQkBFhNkYnJvd25AY2VydGljb20uY29t MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDRc70RE0/FL9ZbfN64YjA0lkQOLR9ipGebc9nH jB93OfYfR7CVsCUYy3+v9PO1DiUS9MeWWR4nxB9Ztee32d3syDxGg3PGFwSrms/ORAW9pgiS/yKH An9SKRKyqMz9LSn/VQrEgoyPBPT0S/vg521MGH58MwMXyLm1cLBQU5gtCQIDAQABo4IDmDCCA5Qw CwYDVR0PBAQDAgWgMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQME AgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUAlQmTNpWxnzoCUVjxGTtDz2JvLww FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMB8GA1UdIwQYMBaAFLgwF25vZ5X+hYxoO6XhF7M/+CU6 MIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiGgctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu YXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1NQ0EwM1lLRixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIw U2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2Fs P2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRp b25Qb2ludIZIaHR0cDovL21jYTAzeWtmLnJpbS5uZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRp bmF0ZSUyMENBJTIwTUNBMDNZS0YuY3JsMIIBQQYIKwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUH MAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1BSUEs Q049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixE Qz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZp Y2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxodHRwOi8vbWNhMDN5a2YucmltLm5ldC9DZXJ0 RW5yb2xsL01DQTAzWUtGLnJpbS5uZXRfUklNJTIwU3Vib3JkaW5hdGUlMjBDQSUyME1DQTAzWUtG KDMpLmNydDApBgNVHSUEIjAgBgorBgEEAYI3CgMEBggrBgEFBQcDBAYIKwYBBQUHAwIwQQYDVR0R BDowOKAhBgorBgEEAYI3FAIDoBMMEWRhbmlicm93bkByaW0ubmV0gRNkYnJvd25AY2VydGljb20u Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQC6hxWgDv96DUDS3m8XfyVGAv1CKOcWSVOShz/jofFMFzoN o2dhc0Jg9XTTZBVS+ozakEM+87YUENfP3IODRbCiJBsbiXJxS+fVo7L/bqPp47TB+Lg2/tezlNa2 ab4psmc9xjZGU9+A4lBzS5PpRjvHofsIwETpwt/aPxHIbJ5Cf7kBi7B8hR4mIqc7EJMYXeI0xHLg k3NqBYSGC3XtbykuFV0vPFoTYLO7G3pAP2RzGhuxQoaH4fpWvE3rdakjd1MZFqJrarXSvWi6ah6G Alt7+sOTzlGNqoTQqb55VZEOrU2A1VbmAFjiFR1/229A2KaHhnN6cuNe8bhzoBcnuxtyMIIGvzCC BKegAwIBAgIQMhrzkrEUWZRNTS+VEbN74TANBgkqhkiG9w0BAQUFADBPMRUwEwYKCZImiZPyLGQB GRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBN Q0EwMVlLRjAeFw0wNjEwMTMwMTI0NTVaFw0xNjEwMTMwMTMwNDFaME8xFTATBgoJkiaJk/IsZAEZ FgVsb2NhbDEXMBUGCgmSJomT8ixkARkWB3dpbmRvd3MxHTAbBgNVBAMTFFJJTSBSb290IENBIE1D QTAxWUtGMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAxui6zvytVAEtPzv6NhK7OZna iw/jQEyEVskDf5yzcFkLT/+5PztIbv+eFmL1CP2FhvLv8eQZJDKF4Yv+UsjPEN1lX4DDGKKt0NPp yT9pwQzFaiUt0rnERgSabo7EtpS4S+DuL8G9c+lmWwDqb0UWtPMdVfbr3fDwigyz1yh+vVMAHdhg Oe9lPC6nPtiJ9IXTam7V5mJmDT0mNpq/0fJo3JEaNvDKoXBOkKv6IdbtKxKzPInG6VYaCdgJCAT3 mWgr9kxiEQEUJKrvI2fXI0zRYnlL648gvK84pdsT2xZLFtr4OdZAm4RkK8U+cgurlSCr6NVqnfbq 6/3N6MGmyc9SB2Ayhk2VS66757V4nBzeaeD+srpk4IXU3NTM/+YgR1zVS41XwvZaq9Uf59j0TJhN 9xGVZO871eVVr2VfNxr0xOqUpwcxh5JZYkWcmUJFlYiQh0CM2PrfaDRTTqRZQd4F3xUlcXFAXOGh vaXKvikeI6/utnX6vCnDwMUxmenzlv8epNatxDsuIgOWO4pfqgGMyzWo2hudQ97+5ynUqDLX34nr UzszGeIE3KoqYsksxMF3tqIgadt9hNWXaP/EknZpRAmaP0s0V5ZvgiyXw9UrqnWwmRbLQk7HnYc0 hHQBjXoByKSiOyhgSS9yL6a+7AA2rhBPpsSVI9LYBs2cNKlPsZcCAwEAAaOCAZUwggGRMBMGCSsG AQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTW aYJkJBbBzCTb8RR9RxJ83MlN7jCCASkGA1UdHwSCASAwggEcMIIBGKCCARSgggEQhoHEbGRhcDov Ly9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1NQ0EwMVlLRixDTj1DRFAsQ049UHVi bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5k b3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1j UkxEaXN0cmlidXRpb25Qb2ludIZHaHR0cDovL21jYTAxeWtmLndpbmRvd3MubG9jYWwvQ2VydEVu cm9sbC9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwDQYJ KoZIhvcNAQEFBQADggIBAEOeWFu4OVTnx9+jYk92iDra2f1Bc5j1WesEGINl4VCY9WJy6n17b/h2 fDmjj9KfIto3LE2Wej77lSJqv/LSd7wnfTQVZVb1wBe2Zt+LuPAqi6vWSDAQVOfdOMYVu5imznnf +ZNMLduTqXZ/bFQKTWsg2qhBWwaiYfxEY7nVg3+ZfStqwc9R3v/tHH+b9kX3FuKLoVQ6KSrqUyBi fhIRj57eOw6/JjPA+SId/p2yEZ+xmANQ31vE3BHFRm20kZHHqAfdCmTt1S7LDSLHBj3GZXIFUge9 aPKqzAXee2DCYTP3YYcgrP/FbFF2RqGRIhPM+MdjJraMjex+nNT+2KC/EIWsbU9DgFII0wHKpRx8 rlJNN8kmb/H9qGqcNaW9Q/pwUTpX1bXSdbzvYFs3NY7KmYYii4Q0RQCGr96OvDT0/S6/IrnW+vqZ jnPV2MXqEuyQ0L5HXVOnCi769uGYcRkEo5xzEJ/EMvj07vCWnG7h9ykNhLEEMcygVmBdXP9qOqog dyPJB0AzxAYGqCSMT8Ors1M/srZSXUCfSfENH5iBd7bxH7uXmF7kbOEghom7AccC2Clt4DU0tj9s FyIWg5H6zy6NLetm2/kzdD3mGY3u2tWtijVnd2CWY2YszYo1lbDAfEfjGL/9uFpH79Zt9ekRSD5Z bSn1SNr1njjeGpV3jwyuMIIHRjCCBS6gAwIBAgIKFnKQQQAAAAABuDANBgkqhkiG9w0BAQUFADBP MRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQD ExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjAeFw0xMjA1MTcwMDEzMzNaFw0xNDA1MTcwMDIzMzNaMFAx EzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBT dWJvcmRpbmF0ZSBDQSBNQ0EwM1lLRjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfx jFzEuYa/qd6dXu4HILtBdH3+Bgwz3uQakDcxvrf3fyVQBy69KFOS8/h5REe6bit3tp5wsQQv/nFV mmXK/jq9zD72zl3jv63UzZgOWC90846UxTTmmNEyHzo1M54B3LrnE6L2Q6QbEZMAnrJ96uV8pN2X Zsn5j+MvfI5ajFu+6oPbHeYzQjZB3GDju7sELm7cAcr0YYX3xeLTB2rLUUZF6Nyyc0btD57ARYEa 99A+6JslO8VcxtlgRddx17NB6gttNjwmJFT3l3UVcK5O5+UVSWpW1zQbZQBvl0iP7gXcrJW4Dv0p 036iHg9lgDV1qQChi9NCixwm7yYtCHLq9akCAwEAAaOCAyEwggMdMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFLgwF25vZ5X+hYxoO6XhF7M/+CU6MAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEE AwIBAzAjBgkrBgEEAYI3FQIEFgQUZUBVml3ak56Kwnbul6AULvNdck8wGQYJKwYBBAGCNxQCBAwe CgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNVHR8EggEg MIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Ys Q049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRp b25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6Ly9tY2Ew MXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Yu Y3JsMIIBPAYIKwYBBQUHAQEEggEuMIIBKjCBuwYIKwYBBQUHMAKGga5sZGFwOi8vL0NOPVJJTSUy MFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRvd3MsREM9bG9jYWw/Y0FDZXJ0aWZp Y2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwagYIKwYBBQUHMAKG Xmh0dHA6Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvTUNBMDFZS0Yud2luZG93 cy5sb2NhbF9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcnQwDQYJKoZIhvcNAQEFBQADggIB AK/ZTtcAxFAZJo37z0KG3EGIGIScPRus90jBJGQO9+Mrb4QRoMjkCwZP9GbYq2CxCqOBiKOZfkSK PMSupPLRlE70z9tGbsMz13ExQy50WZS9n4XRxglyDRga1fQVwGNF+SMPaBzQapiFi3CkBWNSdz+f aRdkdiqIvG3hxkbk6AXr6xhlu2mvnhJ/dE248lZDmN3FkWDHXEgEd5uHxwd7nWjxXVuzRV0oNgrG E96uTqLHVsdefHplPwyrIlgV4SY1ST1y8nKhZlB4IX8fDIj1Xr3rRssW+8XEKSILvawoU47n34x6 xZrO8nbramu3s3BPDnPBe5d1akBYA/nTKb9l6by6dNzJ7u1r73w7/tC53Hgf+826w6Gw+Z6Xs1d2 6RvukJ+7VCyKTR+rg+jASrfhS7naerxVMoOZwr6GxqqHYbK1gp3ag8Ek1U62/LYLqbvYMn58e23k q1pR6vLfQY4AhteMJipLmkxioYjHMCm9rTCZCnU2e/yvNNGXXq8WEeJpAc7hXbFR8L7VTaawkSxg jtJ2YTLvGH0cM/lEOAn3UGUG1lAhBBBzpLS4oW+ITZ5LsPWx2UiWAHLF79XE+PzvFE1+haf4HzJ0 KNKizMaj6DyVJN/oLOvdlVn32x70hCkr9zPFM6f4wEtQoY+qV3Q13zB7FePumyia5+/xmioObwts MYICrjCCAqoCAQEwXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmlt MSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwCQYFKw4D AhoFAKCCAaYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMDAx MTU1MTA2WjAjBgkqhkiG9w0BCQQxFgQUOd9cznOmIbUI/HwnixmInuhE0hgwZwYJKoZIhvcNAQkP MVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwbQYJKwYBBAGCNxAEMWAwXjBQMRMw EQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vi b3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwbwYLKoZIhvcNAQkQAgsxYKBeMFAxEzAR BgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBTdWJv cmRpbmF0ZSBDQSBNQ0EwM1lLRgIKF9gJ6QADABfFMjANBgkqhkiG9w0BAQEFAASBgMcGFivPmerZ PAcZX+8Bs83sNpb8rsrss3PieKbJ3Dw2bYplbsHxrHngs/4+VmBh1uWnKtaF3CHwRJrx/ZMA/Q/8 wynKOQR8tcmbd+jtmZFTPgYBgdH0+yJq3dTef5vU5yJyF3QNEi6XalFTDrGQIOZcdkPEvFsfdJn9 QYCCxjLqAAAAAAAA ------=_NextPart_000_0144_01CEBE9C.83693990-- --===============1931553311== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --===============1931553311==-- From Johannes.Merkle@secunet.com Tue Oct 1 09:23:11 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8279621E81B9 for ; Tue, 1 Oct 2013 09:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqRB-u3FVRtD for ; Tue, 1 Oct 2013 09:22:59 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 21E9311E8143 for ; Tue, 1 Oct 2013 09:22:17 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id D23431A0078; Tue, 1 Oct 2013 18:22:10 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SIRy58vzvzQt; Tue, 1 Oct 2013 18:22:09 +0200 (CEST) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 713871A006F; Tue, 1 Oct 2013 18:22:09 +0200 (CEST) Received: from [10.208.1.57] ([10.208.1.57]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Oct 2013 18:22:08 +0200 Message-ID: <524AF6AF.1070503@secunet.com> Date: Tue, 01 Oct 2013 18:22:07 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mrex@sap.com References: <20131001133819.CAE281A9CB@ld9781.wdf.sap.corp> In-Reply-To: <20131001133819.CAE281A9CB@ld9781.wdf.sap.corp> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Oct 2013 16:22:09.0042 (UTC) FILETIME=[6063F720:01CEBEC2] Cc: "tls@ietf.org" , Kyle Hamilton Subject: Re: [TLS] Safe ECC usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 16:23:11 -0000 >> Other than certificate size and the speed of making those calculations? >> Really, try "openssl speed rsa2048 ecdsap256" on any Linux or Mac machine. > > openssl 1.0.1c x86_64 tells me ecdsap256 is 10x faster than rsa2048 for > signing and 10x slower than rsa2048 for verifying. RSA is much faster for signing than for verifying, while for ECDSA the time for these operations are quite similar. So lets assume, ECDSA singing or verifying takes 1/10 s, then RSA signing takes 1 s and verifying 1/100 sec. Makes 0.2 s for ECDSA based handshake (one signing and one verifying operation) and 1.01 s for RSA. That is a huge difference. Johannes From mpg@elzevir.fr Tue Oct 1 10:29:15 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D234A21E8085 for ; Tue, 1 Oct 2013 10:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFNdcBCoMjD4 for ; Tue, 1 Oct 2013 10:29:15 -0700 (PDT) Received: from mordell.elzevir.fr (mordell.elzevir.fr [IPv6:2001:4b98:dc0:41:216:3eff:feeb:c406]) by ietfa.amsl.com (Postfix) with ESMTP id 4439B21E81B9 for ; Tue, 1 Oct 2013 10:29:14 -0700 (PDT) Received: from thue.elzevir.fr (unknown [IPv6:2a01:e35:8a5d:80b0:be5f:f4ff:fe2c:95bc]) by mordell.elzevir.fr (Postfix) with ESMTPS id 72298160E7 for ; Tue, 1 Oct 2013 19:29:12 +0200 (CEST) Received: from [192.168.0.124] (unknown [192.168.0.254]) by thue.elzevir.fr (Postfix) with ESMTPSA id 5BD6529956 for ; Tue, 1 Oct 2013 19:29:11 +0200 (CEST) Message-ID: <524B05E0.10103@elzevir.fr> Date: Tue, 01 Oct 2013 19:26:56 +0200 From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130413 Icedove/17.0.5 MIME-Version: 1.0 To: tls@ietf.org References: <20131001133819.CAE281A9CB@ld9781.wdf.sap.corp> <524AF6AF.1070503@secunet.com> In-Reply-To: <524AF6AF.1070503@secunet.com> X-Enigmail-Version: 1.5.2 OpenPGP: id=98EED379; url=https://elzevir.fr/gpg/mpg.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Safe ECC usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 17:29:15 -0000 On 01/10/2013 18:22, Johannes Merkle wrote: >>> Other than certificate size and the speed of making those >>> calculations? Really, try "openssl speed rsa2048 ecdsap256" on any >>> Linux or Mac machine. >> >> openssl 1.0.1c x86_64 tells me ecdsap256 is 10x faster than rsa2048 >> for signing and 10x slower than rsa2048 for verifying. > > RSA is much faster for signing than for verifying, while for ECDSA the > time for these operations are quite similar. > > So lets assume, ECDSA singing or verifying takes 1/10 s, then RSA > signing takes 1 s and verifying 1/100 sec. Makes 0.2 s for ECDSA based > handshake (one signing and one verifying operation) and 1.01 s for > RSA. That is a huge difference. > Let's do the math, using openssl speed's results (1.0.1e on x86_64 linux, slightly edited for clarity): sign verify rsa 2048 bits 0.001558s 0.000048s 256 bit ecdsa (nistp256) 0.0001s 0.0003s Now assuming the peer's certificate is signed by an intermediate CA, itself signed by a root CA, we have 1 sign, 1 verify for the KeyExchange or CertificateVerify message, 2 verify-s (signature by CA + crl) for the peer's certificate, same for the intermediate CA, a total of 1 sign + 5 verify-s: rsa 2048 bits: 1.8 ms ecdsa 256 bits: 1.6 ms So the two are mostly equivalent (with the NIST curve, a brainpool curve would probably be slower, and a modern curve such a Ed25519 faster). ECDSA has an advantage as soon as the certificate chain is shorter, up to a factor 4 for a 0-length certificate chain. (Also, this is assuming the same key size and type for all certificates. Certainly the best case for overall handshake speed is when the end-entity certificate uses ECDSA while CA certificates use RSA.) However, in a context where servers need to handle more handshakes per second than clients and most handshakes don't use client auth, ecdsa is interesting since it transfers some load from the server to the client, probably a good news for server operators. Manuel. From ynir@checkpoint.com Tue Oct 1 10:43:38 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626EF21F9DFA for ; Tue, 1 Oct 2013 10:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.238 X-Spam-Level: X-Spam-Status: No, score=-10.238 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nus6-5NDF85I for ; Tue, 1 Oct 2013 10:43:28 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6B621F9E00 for ; Tue, 1 Oct 2013 10:43:24 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r91HhGAb015783; Tue, 1 Oct 2013 20:43:16 +0300 X-CheckPoint: {524B09B4-18-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.30]) by IL-EX10.ad.checkpoint.com ([169.254.2.92]) with mapi id 14.02.0347.000; Tue, 1 Oct 2013 20:43:16 +0300 From: Yoav Nir To: =?iso-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= Thread-Topic: [TLS] Safe ECC usage Thread-Index: AQHOus0om0uHYDyqy0CSy5O2MDQzFJncJGEAgAKSogCAAGtCAIAAjNCAgAAtxICAABIcAIAABKEA Date: Tue, 1 Oct 2013 17:43:16 +0000 Message-ID: <4B2F58FD-9668-481A-B03F-72CFE910B4CC@checkpoint.com> References: <20131001133819.CAE281A9CB@ld9781.wdf.sap.corp> <524AF6AF.1070503@secunet.com> <524B05E0.10103@elzevir.fr> In-Reply-To: <524B05E0.10103@elzevir.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.231] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="iso-8859-1" Content-ID: <9142635286EDF541996A6C7F3EB4649F@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [TLS] Safe ECC usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 17:43:38 -0000 On Oct 1, 2013, at 8:26 PM, Manuel P=E9gouri=E9-Gonnard wr= ote: >>=20 > Let's do the math, using openssl speed's results (1.0.1e on x86_64 linux, > slightly edited for clarity): >=20 > sign verify > rsa 2048 bits 0.001558s 0.000048s > 256 bit ecdsa (nistp256) 0.0001s 0.0003s >=20 > Now assuming the peer's certificate is signed by an intermediate CA, > itself signed by a root CA, we have 1 sign, 1 verify for the KeyExchange > or CertificateVerify message, 2 verify-s (signature by CA + crl) for the > peer's certificate, same for the intermediate CA, a total of 1 sign + 5 > verify-s: >=20 > rsa 2048 bits: 1.8 ms > ecdsa 256 bits: 1.6 ms >=20 > So the two are mostly equivalent (with the NIST curve, a brainpool curve > would probably be slower, and a modern curve such a Ed25519 faster). ECDS= A has > an advantage as soon as the certificate chain is shorter, up to a factor = 4 for a > 0-length certificate chain. >=20 > (Also, this is assuming the same key size and type for all certificates. > Certainly the best case for overall handshake speed is when the end-entit= y > certificate uses ECDSA while CA certificates use RSA.) >=20 > However, in a context where servers need to handle more handshakes per > second than clients and most handshakes don't use client auth, ecdsa is > interesting since it transfers some load from the server to the client, > probably a good news for server operators. It's particularly good news coming after the hit that 2048-bit RSA caused (= note that "sign" and "RSA decrypt" have about the same speed): =20 sign verify sign/s verify/s rsa 1024 bits 0.000732s 0.000046s 1365.2 21720.1 rsa 2048 bits 0.004701s 0.000147s 212.7 6810.6 Yoav From Michael.Kain@unisys.com Tue Oct 1 11:59:10 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF7911E81AD for ; Tue, 1 Oct 2013 11:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.597 X-Spam-Level: X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmotNNW7Uo51 for ; Tue, 1 Oct 2013 11:59:03 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.105]) by ietfa.amsl.com (Postfix) with ESMTP id 8791211E81B9 for ; Tue, 1 Oct 2013 11:59:03 -0700 (PDT) Received: from [216.82.254.195:2105] by server-9.bemta-7.messagelabs.com id CA/48-13769-57B1B425; Tue, 01 Oct 2013 18:59:01 +0000 X-Env-Sender: Michael.Kain@unisys.com X-Msg-Ref: server-4.tower-200.messagelabs.com!1380653940!16309641!2 X-Originating-IP: [192.61.61.104] X-StarScan-Received: X-StarScan-Version: 6.9.12; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22357 invoked from network); 1 Oct 2013 18:59:01 -0000 Received: from unknown (HELO USEA-NAEDGE1.unisys.com) (192.61.61.104) by server-4.tower-200.messagelabs.com with RC4-SHA encrypted SMTP; 1 Oct 2013 18:59:01 -0000 Received: from usea-nahubcas3.na.uis.unisys.com (129.224.76.101) by USEA-NAEDGE1.unisys.com (192.61.61.104) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 1 Oct 2013 13:59:00 -0500 Received: from USEA-EXCH7.na.uis.unisys.com ([129.224.76.38]) by usea-nahubcas3.na.uis.unisys.com ([129.224.76.101]) with mapi; Tue, 1 Oct 2013 13:58:51 -0500 From: "Kain, Michael T" To: "'tls@ietf.org'" Date: Tue, 1 Oct 2013 13:58:50 -0500 Thread-Topic: TLS 1.2 clarification requested Thread-Index: Ac6+19Gy7ubypu9bSN6R9OEEKLlUhA== Message-ID: <45407AA8FD01AB4EA1D23EFE48EA29B9D57B9217DB@USEA-EXCH7.na.uis.unisys.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01F4_01CEBEB6.BD028F70" MIME-Version: 1.0 Subject: [TLS] TLS 1.2 clarification requested X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 18:59:11 -0000 ------=_NextPart_000_01F4_01CEBEB6.BD028F70 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01F5_01CEBEB6.BD028F70" ------=_NextPart_001_01F5_01CEBEB6.BD028F70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm trying to understand the TLS 1.2 restrictions and signature algorithms and how they interact. Is there a relation between the signature algorithm that is negotiated between client and server and the algorithm which signed the server certificate? Does that affect the hash algorithm of TLS 1.2 - or is that always SHA256? For example, if I've got a server configured with a server certificate signed with SHA256, can it still establish a connection using the TLS_RSA_WITH_AES_256_CBC_SHA? Does the signature algorithm for a certificate affect which Ciphersuites can be negotiated and used? Mike ------=_NextPart_001_01F5_01CEBEB6.BD028F70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m trying to understand the TLS 1.2 = restrictions and signature algorithms and how they interact.  Is = there a relation between the signature algorithm that is negotiated = between client and server and the algorithm which signed the server = certificate?

Does that affect the = hash algorithm of TLS 1.2 – or is that always = SHA256?

 

For example, if I’ve got a server configured = with a server certificate signed with SHA256, can it still establish a = connection using the TLS_RSA_WITH_AES_256_CBC_SHA?

 

Does the = signature algorithm for a certificate affect which Ciphersuites can be = negotiated and used?

 

Mike

------=_NextPart_001_01F5_01CEBEB6.BD028F70-- ------=_NextPart_000_01F4_01CEBEB6.BD028F70 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIgkDCCBJ8w ggQIoAMCAQICBEaekRowDQYJKoZIhvcNAQEFBQAwgcMxCzAJBgNVBAYTAlVTMRQwEgYDVQQKEwtF bnRydXN0Lm5ldDE7MDkGA1UECxMyd3d3LmVudHJ1c3QubmV0L0NQUyBpbmNvcnAuIGJ5IHJlZi4g KGxpbWl0cyBsaWFiLikxJTAjBgNVBAsTHChjKSAxOTk5IEVudHJ1c3QubmV0IExpbWl0ZWQxOjA4 BgNVBAMTMUVudHJ1c3QubmV0IFNlY3VyZSBTZXJ2ZXIgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkw HhcNMDkwMzIzMTUxODI3WhcNMTkwMzIzMTU0ODI3WjCBtDEUMBIGA1UEChMLRW50cnVzdC5uZXQx QDA+BgNVBAsUN3d3dy5lbnRydXN0Lm5ldC9DUFNfMjA0OCBpbmNvcnAuIGJ5IHJlZi4gKGxpbWl0 cyBsaWFiLikxJTAjBgNVBAsTHChjKSAxOTk5IEVudHJ1c3QubmV0IExpbWl0ZWQxMzAxBgNVBAMT KkVudHJ1c3QubmV0IENlcnRpZmljYXRpb24gQXV0aG9yaXR5ICgyMDQ4KTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAK1NS6kShrLqoyAHFRZkKitL0b8LSk2O7YB2pWe3eEDAc0LIaMDb UyvdXrh2mDWTixqdfBM6Dh9btx7P5SQUHrGBqY19uMxrSwPxAgzcq6VAJAB/dJShnQgps4gL9Yd3 nVXN5MN+12pkq4UUhpVblzJQbz3IumYM4/y9uEnBdolJGf3AqL2Jo2cvxp+8cRlguC3pLMmQdmZ7 lOKveNZlU1081pyyzykD+S+kULLUSM4FMlWK/bJkTA7kmAd123/fuQhVYIUwKfl7SKRphuM1Px6G XXp6Fb3vAI4VIlQXAJAmk7wOSWiRv/hH052VQsEOTd9vJs/DGCFiZkNw1tXAB+ECAwEAAaOCAScw ggEjMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MDMGCCsGAQUFBwEBBCcwJTAjBggr BgEFBQcwAYYXaHR0cDovL29jc3AuZW50cnVzdC5uZXQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDov L2NybC5lbnRydXN0Lm5ldC9zZXJ2ZXIxLmNybDA7BgNVHSAENDAyMDAGBFUdIAAwKDAmBggrBgEF BQcCARYaaHR0cDovL3d3dy5lbnRydXN0Lm5ldC9DUFMwHQYDVR0OBBYEFFXkgdERgL7YibkIozH5 oSQJFrlwMB8GA1UdIwQYMBaAFPAXYhNVPbP/CgBr+1CEl/PtYtAaMBkGCSqGSIb2fQdBAAQMMAob BFY3LjEDAgCBMA0GCSqGSIb3DQEBBQUAA4GBAI9lojCOJquK7DUWmOkD8I0XX7xMbAL2dFLgwsYf zvKmEQyosQ5NhItxNu+zNUXzwfiWxYtVpMxrgxYgMtq++6+bt5/hfoSfnjxQpz9cwr6LhrgIku74 QisNE+N2hUgKSr/QpTsKsFS4beMI+TSNC46LEswXGjOHlcieCtxQUxd7MIIEwjCCA6qgAwIBAgIE TA7OijANBgkqhkiG9w0BAQUFADCBtDEUMBIGA1UEChMLRW50cnVzdC5uZXQxQDA+BgNVBAsUN3d3 dy5lbnRydXN0Lm5ldC9DUFNfMjA0OCBpbmNvcnAuIGJ5IHJlZi4gKGxpbWl0cyBsaWFiLikxJTAj BgNVBAsTHChjKSAxOTk5IEVudHJ1c3QubmV0IExpbWl0ZWQxMzAxBgNVBAMTKkVudHJ1c3QubmV0 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5ICgyMDQ4KTAeFw0xMzA2MTQxNTUyNDhaFw0xNjA3MTQx OTMzNDRaMBYxFDASBgNVBAMTC1VJUy1JbnRCLUNBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA74swMiDpMOztnxQapl99mLCuclJ8/cKzbdf8YxGl12i7ALuTFhJOpkNxEsTVB3S7ymxH IjaQgdycg2qA5ZrKokk0NrrJzj749654jl80SGFg3pQeInCx0nedZum4jZ2hKlQa+YL43ArliGsQ DSlWBJHatvf7rgdqby4FCJtmc4uKwxfMKOpIwQklwFVjijZAW9Nj09cJvfhU3oEMKRpFClpxfNvS ZwE/iJom2R7IwKCFoZL7Iq3hYJwPzkFk+HXBbKzRpCB8KS4M1tDGv2zpq6HgwTqsqn07oGu1MhAo t7gidajkwyyIrv9lYXVUZq/d2Zf6hLOzIKPmW5MFVzsEcQIDAQABo4IBdzCCAXMwDgYDVR0PAQH/ BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQEwJwYDVR0lBCAwHgYIKwYBBQUHAwEGCCsGAQUFBwMC BggrBgEFBQcDBDB7BgNVHSAEdDByMDYGCmCGSAGG+mwKAQgwKDAmBggrBgEFBQcCARYaaHR0cDov L3d3dy5lbnRydXN0Lm5ldC9jcHMwOAYJYIZIAYb9MAEBMCswKQYIKwYBBQUHAgEWHWh0dHA6Ly91 aXNwa2kudW5pc3lzLmNvbS9yZXAvMDMGCCsGAQUFBwEBBCcwJTAjBggrBgEFBQcwAYYXaHR0cDov L29jc3AuZW50cnVzdC5uZXQwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5lbnRydXN0Lm5l dC8yMDQ4Y2EuY3JsMB8GA1UdIwQYMBaAFFXkgdERgL7YibkIozH5oSQJFrlwMB0GA1UdDgQWBBT1 xt0zj+A019VbRJT/NTVwffPsNTANBgkqhkiG9w0BAQUFAAOCAQEALdyvSctUmw8jCOiId5AUr8Tv tVc6cqMZXi/ZWkj2BGuApqMvjUrFsk+NThZN5aCc4v1AfwNhzjxim0d6JTEFhfMjsj2iLeux0ujB ngee+xcHVgyFi4zlKQ6sV675gmxUowRy4yX7YdJlhj2E2rU5xq0lDVDH2uxoQgKSYthRbf+RKNvb 4iqT8VN2A14KpoJr1scSPSFED5YuGop108YtOhH5vwwGLzt/f8KLb+YmY9ubc3WZ+2pVBDqyT70b CrAW+cV+Zwj9ismWwDHhZWnIPUKkYVkjLaLWWReCgsMotbAaHBXXS39ZQdQGBOyCqZe1veM7iCzN YJHVJPpnGK/jyjCCBNgwggRBoAMCAQICBDdK0kMwDQYJKoZIhvcNAQEFBQAwgcMxCzAJBgNVBAYT AlVTMRQwEgYDVQQKEwtFbnRydXN0Lm5ldDE7MDkGA1UECxMyd3d3LmVudHJ1c3QubmV0L0NQUyBp bmNvcnAuIGJ5IHJlZi4gKGxpbWl0cyBsaWFiLikxJTAjBgNVBAsTHChjKSAxOTk5IEVudHJ1c3Qu bmV0IExpbWl0ZWQxOjA4BgNVBAMTMUVudHJ1c3QubmV0IFNlY3VyZSBTZXJ2ZXIgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwHhcNOTkwNTI1MTYwOTQwWhcNMTkwNTI1MTYzOTQwWjCBwzELMAkGA1UE BhMCVVMxFDASBgNVBAoTC0VudHJ1c3QubmV0MTswOQYDVQQLEzJ3d3cuZW50cnVzdC5uZXQvQ1BT IGluY29ycC4gYnkgcmVmLiAobGltaXRzIGxpYWIuKTElMCMGA1UECxMcKGMpIDE5OTkgRW50cnVz dC5uZXQgTGltaXRlZDE6MDgGA1UEAxMxRW50cnVzdC5uZXQgU2VjdXJlIFNlcnZlciBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTCBnTANBgkqhkiG9w0BAQEFAAOBiwAwgYcCgYEAzSiDNFQbifMPrzeR Mf+vMWDJqOiyEGjtn+eTNvEKZLtH9QQXPyNHTcUnGYEmDFRyDYgt2R+aEp+8s3HTgBk/R2Z7jDUo 0rkK3yTanNZQeYF6WtM398JK2CmSJmTR5JhsOgCK9TSbZfjt4xD//bhJWNyg3oI5a4GxFhlhuVS2 5kMCAQOjggHXMIIB0zARBglghkgBhvhCAQEEBAMCAAcwggEZBgNVHR8EggEQMIIBDDCB3qCB26CB 2KSB1TCB0jELMAkGA1UEBhMCVVMxFDASBgNVBAoTC0VudHJ1c3QubmV0MTswOQYDVQQLEzJ3d3cu ZW50cnVzdC5uZXQvQ1BTIGluY29ycC4gYnkgcmVmLiAobGltaXRzIGxpYWIuKTElMCMGA1UECxMc KGMpIDE5OTkgRW50cnVzdC5uZXQgTGltaXRlZDE6MDgGA1UEAxMxRW50cnVzdC5uZXQgU2VjdXJl IFNlcnZlciBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTENMAsGA1UEAxMEQ1JMMTApoCegJYYjaHR0 cDovL3d3dy5lbnRydXN0Lm5ldC9DUkwvbmV0MS5jcmwwKwYDVR0QBCQwIoAPMTk5OTA1MjUxNjA5 NDBagQ8yMDE5MDUyNTE2MDk0MFowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFPAXYhNVPbP/CgBr +1CEl/PtYtAaMB0GA1UdDgQWBBTwF2ITVT2z/woAa/tQhJfz7WLQGjAMBgNVHRMEBTADAQH/MBkG CSqGSIb2fQdBAAQMMAobBFY0LjADAgSQMA0GCSqGSIb3DQEBBQUAA4GBAJDcMAL6ZHTCpwqlfCGN NBeo+0cO/yV8jRMK++SYte+M+MUQDfeSvvHD1dWVagS7LM4mNmXIMcbn7j/jV3WEehHvRk8Y9NOY u6iHMrpy9jziPZ/XHdnDYEOMWA4ili9ioywfuq0F76syeIegVHMZtVwF+VI+bS1FC/cKk+rtBvmy MIIFXDCCBESgAwIBAgITOQAArmR8O1tc5wAPOQADAACuZDANBgkqhkiG9w0BAQUFADBZMRMwEQYK CZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGdW5pc3lzMRMwEQYKCZImiZPyLGQBGRYD dWlzMRUwEwYDVQQDEwxVSVMtSXN1QjEtQ0EwHhcNMTMwMTExMjA0ODI0WhcNMTUwMTExMjA0ODI0 WjBCMRgwFgYDVQQDEw9LYWluLCBNaWNoYWVsIFQxJjAkBgkqhkiG9w0BCQEWF01pY2hhZWwuS2Fp bkB1bmlzeXMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkJheC9FkVUlXtAci pUWvVmePQNRTOARUN3Jb0kW+L2h59oMXQMF6F9SfZJigNrwz6KpofUGN0IacdT5fpUKAOgydTf4R 6kzGtRIHNMIAPf7kWyaPurkDNAiEXEC5Mxpg3sF6YnHV1CJuMEzLbhOK0BCVRV08dLTY14LptpCJ kbwXq2RmPd8RH1CHuUxmBFxNPTGUD5JB5xYE8r0+wT8CkjoYTrwiYpNOaYDyoOWuIrHEGNmJcEXs IyayjtqxfEZqK4cfquB/VC2/0ZAX1YRXyEzoHtiIhalOKz2cEOo0l1PBHi9Emwx/4iOK4w3i8rgI lQTdHY2XKHnzVOAyIwUzCQIDAQABo4ICMjCCAi4wDgYDVR0PAQH/BAQDAgbAMD4GCSsGAQQBgjcV BwQxMC8GJysGAQQBgjcVCIeEwhaDtrUpg5mZCISNli6Bq6IlMbve3RKEjryQEwIBZAIBETAdBgNV HQ4EFgQUOWHb0Cozi4dH74YulP6DenGf13UwHwYDVR0jBBgwFoAUQP3pGT+UmEbBe+VOggogEjLZ hdEwcwYDVR0fBGwwajBooGagZIYwaHR0cDovL3Vpc3BraS51bmlzeXMuY29tL3JlcC9VSVMtSXN1 QjEtQ0EoMikuY3JshjBsZGFwOi8vcGtpbGRwLnVuaXN5cy5jb20vcmVwL1VJUy1Jc3VCMS1DQSgy KS5jcmwwgYoGCCsGAQUFBwEBBH4wfDA8BggrBgEFBQcwAoYwaHR0cDovL3Vpc3BraS51bmlzeXMu Y29tL3JlcC9VSVMtSXN1QjEtQ0EoMykuY3J0MDwGCCsGAQUFBzAChjBsZGFwOi8vcGtpbGRwLnVu aXN5cy5jb20vcmVwL1VJUy1Jc3VCMS1DQSgzKS5jcnQwEwYDVR0lBAwwCgYIKwYBBQUHAwQwRAYD VR0gBD0wOzA5BgpghkgBhv0wAQECMCswKQYIKwYBBQUHAgEWHWh0dHA6Ly91aXNwa2kudW5pc3lz LmNvbS9yZXAvMBsGCSsGAQQBgjcVCgQOMAwwCgYIKwYBBQUHAwQwIgYDVR0RBBswGYEXTWljaGFl bC5LYWluQHVuaXN5cy5jb20wDQYJKoZIhvcNAQEFBQADggEBABtT4XORyxfSaLW3gNKvBssWaG/s 2IHDkLFQarNTcsvZdxaLe9+st8QHsOc3pDb92h8RAaP0L1dbSZ/vZsaTWkGsSZyhuFEbOB9Ex1aN Oa2lTmTCO94lJVkk7T5LkQ3TpmU23tGUIuQPXCRTcP4l4adBmIL0KFoXCm+OSC7hmGtX3hwSEu79 FdNPph78BoCor/PQZFBfibEGG89FUC0waZMzLt80cJSfjru7XEhKja1JajxaY30FhdNXAe8ZXgDA m9opZpX2XATzqE5XWaQHGb7mPDGESJSJ6ltRWyJRoSxdxQpq5AAWKGvIx3PKmG6FZEMnBFVGJhMF PsgRUWG+MgwwggWjMIIEi6ADAgECAhM5AACWdpTfGByt81fkAAIAAJZ2MA0GCSqGSIb3DQEBBQUA MFkxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZ1bmlzeXMxEzARBgoJkiaJ k/IsZAEZFgN1aXMxFTATBgNVBAMTDFVJUy1Jc3VCMS1DQTAeFw0xMjAxMTIxNTQ3MDFaFw0xNDAx MTExNTQ3MDFaMEIxGDAWBgNVBAMTD0thaW4sIE1pY2hhZWwgVDEmMCQGCSqGSIb3DQEJARYXTWlj aGFlbC5LYWluQHVuaXN5cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwLY74 emAQmsaqxY6GX4z7Rw9pmIqKw+jlW7AeCDL1RCfysnk24y+PsLmESN406qM6XKisIGPrCY4LnwTU OiOngpGc0NxptUraf5dPYvH8nnP3JzcfL7wP9xP4BbQz8UXNOeQGB1PDJPcahjZ50OjQX6jXTsZL B0SqcfcjwhKoYPdXmaDjjgUbtkKA0wmjVouTu9ppIZnAz/DN1abj8rFDrqCavjLV/KMEXtFkXfrE GpOu+OmxjePRyVd7EbthCz+gt3b6t803WsYC7zZJp/V0q7hcJZ1vDdWFfGo8C+eyWqMxQQLgcW+d dtj2n2Axwy6dUd5pumThG46JAzb28FA/AgMBAAGjggJ5MIICdTAOBgNVHQ8BAf8EBAMCBDAwRAYJ KoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAcGBSsOAwIHMAoG CCqGSIb3DQMHMB0GA1UdDgQWBBR5xB6r27I3bCLsYXiefiIJ+JOT5jAfBgNVHSMEGDAWgBRA/ekZ P5SYRsF75U6CCiASMtmF0TBzBgNVHR8EbDBqMGigZqBkhjBodHRwOi8vdWlzcGtpLnVuaXN5cy5j b20vcmVwL1VJUy1Jc3VCMS1DQSgyKS5jcmyGMGxkYXA6Ly9wa2lsZHAudW5pc3lzLmNvbS9yZXAv VUlTLUlzdUIxLUNBKDIpLmNybDCBigYIKwYBBQUHAQEEfjB8MDwGCCsGAQUFBzAChjBodHRwOi8v dWlzcGtpLnVuaXN5cy5jb20vcmVwL1VJUy1Jc3VCMS1DQSgyKS5jcnQwPAYIKwYBBQUHMAKGMGxk YXA6Ly9wa2lsZHAudW5pc3lzLmNvbS9yZXAvVUlTLUlzdUIxLUNBKDIpLmNydDA/BgkrBgEEAYI3 FQcEMjAwBigrBgEEAYI3FQiHhMIWg7a1KYOZmQiEjZYugauiJTGMkPHICYyRssNRAgFkAgELMBMG A1UdJQQMMAoGCCsGAQUFBwMEMEQGA1UdIAQ9MDswOQYKYIZIAYb9MAEBAzArMCkGCCsGAQUFBwIB Fh1odHRwOi8vdWlzcGtpLnVuaXN5cy5jb20vcmVwLzAbBgkrBgEEAYI3FQoEDjAMMAoGCCsGAQUF BwMEMCIGA1UdEQQbMBmBF01pY2hhZWwuS2FpbkB1bmlzeXMuY29tMA0GCSqGSIb3DQEBBQUAA4IB AQAh0xwx5tNUPsGLa3keIK0iOfV+soy5/85NGBo6981RCQE1H0t/0DhldGsGhHK0axMfjzcFxziD RfEQgCkM8mG/FEdjP/lx9v5TzPAosxlXixiIq6OCM1wDvmjERJd72QXFIoVKJYys1o/p0e1V2V2P Uh68bMdoFGt+HJqm5YFYkSMNIeuFZGsPoBN+MQNwBS0O16ukS7Cx8f/N/u+3gJqxQ10vtms4hqLM DbqPQHmpZgoobLTcFRlF+hNMVHEv+xYUxNn3L7Wazb7nJQcS0PjhPNSJOTl07chq2J446FP6BiaE XF8GB/HYopUMl8s0RM0WHQvTcZDn/jyzDuTUEpkzMIIHQDCCBiigAwIBAgIKE/Jo6AACAAAADDAN BgkqhkiG9w0BAQUFADAWMRQwEgYDVQQDEwtVSVMtSW50Qi1DQTAeFw0xMjAyMTExOTQxMjJaFw0x ODAyMTExOTUxMjJaMFkxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZ1bmlz eXMxEzARBgoJkiaJk/IsZAEZFgN1aXMxFTATBgNVBAMTDFVJUy1Jc3VCMS1DQTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANnzYKXND/mcPu6QBG0soLyzp0cJB8eEd53o8h0s0VYb8XOK zy/5BA5nqoC6PrxHqZUf4/zTm1a9Q5OdrDB4vARBFmaagvYXI9eY3UduXM/lgXIaHUzmkbeNtUcp +T7wF4Nah2PgDOCg3FJaP5Gtcs/j7YNMLfaSj41ECNAoHaex8v8BrqQzXDgL/K3m1WdDfVQHsHbj /t1NqXCcecre0MNpa21Nfvp2jrW791LWBEfAg9fjk8esNnuJzKifAkC99t2NmpxdP3xEZ/+2mecL Ik443Hff6swwUU/OloyGqwN4iRkNogzINx4Pz4mVnPJ/qs57F/EchZXlJhZZ0VAr9EcCAwEAAaOC BEswggRHMBIGCSsGAQQBgjcVAQQFAgMCAAMwIwYJKwYBBAGCNxUCBBYEFNsvlY6YnbZ7vTU38unK xdzx3zL+MB0GA1UdDgQWBBRA/ekZP5SYRsF75U6CCiASMtmF0TCCAiAGA1UdIASCAhcwggITMDkG CmCGSAGG/TABAQcwKzApBggrBgEFBQcCARYdaHR0cDovL3Vpc3BraS51bmlzeXMuY29tL3JlcC8w OQYKYIZIAYb9MAEBPTArMCkGCCsGAQUFBwIBFh1odHRwOi8vdWlzcGtpLnVuaXN5cy5jb20vcmVw LzA5BgpghkgBhv0wAQEDMCswKQYIKwYBBQUHAgEWHWh0dHA6Ly91aXNwa2kudW5pc3lzLmNvbS9y ZXAvMDkGCmCGSAGG/TABAQIwKzApBggrBgEFBQcCARYdaHR0cDovL3Vpc3BraS51bmlzeXMuY29t L3JlcC8wOQYKYIZIAYb9MAEBBDArMCkGCCsGAQUFBwIBFh1odHRwOi8vdWlzcGtpLnVuaXN5cy5j b20vcmVwLzA5BgpghkgBhv0wAQEFMCswKQYIKwYBBQUHAgEWHWh0dHA6Ly91aXNwa2kudW5pc3lz LmNvbS9yZXAvMDkGCmCGSAGG/TABAQ4wKzApBggrBgEFBQcCARYdaHR0cDovL3Vpc3BraS51bmlz eXMuY29tL3JlcC8wOQYKYIZIAYb9MAEBATArMCkGCCsGAQUFBwIBFh1odHRwOi8vdWlzcGtpLnVu aXN5cy5jb20vcmVwLzA5BgpghkgBhv0wAQEGMCswKQYIKwYBBQUHAgEWHWh0dHA6Ly91aXNwa2ku dW5pc3lzLmNvbS9yZXAvMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjAS BgNVHRMBAf8ECDAGAQH/AgEAMB8GA1UdIwQYMBaAFPXG3TOP4DTX1VtElP81NXB98+w1MIGkBgNV HR8EgZwwgZkwgZaggZOggZCGLGxkYXA6Ly9wa2lsZHAudW5pc3lzLmNvbS9yZXAvVUlTLUludEIt Q0EuY3Jshi9odHRwOi8vdWlzcGtpLnVuaXN5cy5jb20vcmVwL1VJUy1JbnRCLUNBKDEpLmNybIYv aHR0cDovL3BraXJlcC51bmlzeXMuY29tL3JlcC9VSVMtSW50Qi1DQSgxKS5jcmwwgcQGCCsGAQUF BwEBBIG3MIG0MDgGCCsGAQUFBzAChixsZGFwOi8vcGtpbGRwLnVuaXN5cy5jb20vcmVwL1VJUy1J bnRCLUNBLmNydDA7BggrBgEFBQcwAoYvaHR0cDovL3Vpc3BraS51bmlzeXMuY29tL3JlcC9VSVMt SW50Qi1DQSgyKS5jcnQwOwYIKwYBBQUHMAKGL2h0dHA6Ly9wa2lyZXAudW5pc3lzLmNvbS9yZXAv VUlTLUludEItQ0EoMikuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCdUyCDFhWFVMMdNODVj95vBioy MWg95dUlTarGbBtGEtpqXOf+S7gDI8yfbOvA4MGh+OiGy1dDbsdGl4dIbpTA7il8j5qlN4MTpEYU PGOUhF64LVQbmqosNDrcM//JYYE7klI0InEwk+cT09Pebfj8+pZ/+3k+l68fyhfwlauAbCLXheK7 ugiERxaUvELf8ZNXxlh3fY6awiV4FCp8uqBtea4pSM1c/tad9hFrJSuIsLPmFOA+cJGBH4kSYnkL mQFbu+UYsTCmEQN+zwrlrl05Xr7HZwSFfwBG6pbsv6a35FDFYRyuR3z//s1olttjCJkqR/zUsTKH nbb4jn97fa+UMYIDtzCCA7MCAQEwcDBZMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPy LGQBGRYGdW5pc3lzMRMwEQYKCZImiZPyLGQBGRYDdWlzMRUwEwYDVQQDEwxVSVMtSXN1QjEtQ0EC EzkAAK5kfDtbXOcADzkAAwAArmQwCQYFKw4DAhoFAKCCAhwwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMDAxMTg1ODUwWjAjBgkqhkiG9w0BCQQxFgQUrrLyXQTt fmrd4m9bnt7WNvDdAmUwfwYJKwYBBAGCNxAEMXIwcDBZMRMwEQYKCZImiZPyLGQBGRYDY29tMRYw FAYKCZImiZPyLGQBGRYGdW5pc3lzMRMwEQYKCZImiZPyLGQBGRYDdWlzMRUwEwYDVQQDEwxVSVMt SXN1QjEtQ0ECEzkAAJZ2lN8YHK3zV+QAAgAAlnYwgYEGCyqGSIb3DQEJEAILMXKgcDBZMRMwEQYK CZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGdW5pc3lzMRMwEQYKCZImiZPyLGQBGRYD dWlzMRUwEwYDVQQDEwxVSVMtSXN1QjEtQ0ECEzkAAJZ2lN8YHK3zV+QAAgAAlnYwgbcGCSqGSIb3 DQEJDzGBqTCBpjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFl AwQBAjAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwIC ASgwBwYFKw4DAhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwCgYIKoZI hvcNAgUwDQYJKoZIhvcNAQEBBQAEggEAaHJW9e+NpIABuWbOGDR8eESyVugf3cfxQwjn6biH0T7z Q20EYSISqltQQdGKvPqutsK7nvVbFpRPMHuV0TYCD3R4KjnPP9mk6NPv84mJsmLdhMTVFwCmhQzD ElQeIj0dlv4M3bd3TLRHzoQzFSNoAMVpq4nu0G9yu/Qdi1dJeVN+fEQRWc+8M4ngdtWqlqG5aoov tqb5YSdYtJWmtOkuSU7j10TtGxNwgmi3L7ZY/xJd4BS7geWzUacNRgjvtirr5Y2l9g/anHI+NHjn oTVOlarZUOHOcvZnE2tI6U+IKPb4jIQeENTIsvLDAF13t4kHK6li1S5nN7IGhC/6iokjtgAAAAAA AA== ------=_NextPart_000_01F4_01CEBEB6.BD028F70-- From martin.thomson@gmail.com Tue Oct 1 12:15:54 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDA521E80C7 for ; Tue, 1 Oct 2013 12:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jz5dfy4sJFYK for ; Tue, 1 Oct 2013 12:15:53 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id F1BD021F9CAC for ; Tue, 1 Oct 2013 12:15:19 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t61so1393332wes.34 for ; Tue, 01 Oct 2013 12:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=upAcbfwypmHgLuMArCnpiJFY80Mfs390xML2rAgn74s=; b=Oyq+S7yAvAvg3173Tf/+//GdeqTzL3D4A8o12kEMEo2/8zpjDcFGSWDOK+Zu4jkOxG AKvyEQXHbx8Brx2Ny1dUoMa9AdMELeYQiIQzbaxGzGzN81x5NOHE53+ppw0n18kcBtMg Hzsf9qtcDV2iWmsc0vHmD3I5ZrfGBJK0p0IPrbptAHUsAhEP25C/8yqwksNocgqnsKNC q1ksWz4F0Hm39n/tP6sDBALEU3gqFEZfwN/a/zItUbRPU0lBy9fbt3pzuOjVaQhHC4Av 4d40jBxfXIPIxZXWI4YIJmanF03m+h1SKT1nJkA2nU8yLMQUdZjiKmD4IHFVJpp1qM8B EdYg== MIME-Version: 1.0 X-Received: by 10.180.205.236 with SMTP id lj12mr20048325wic.22.1380654919178; Tue, 01 Oct 2013 12:15:19 -0700 (PDT) Received: by 10.227.202.194 with HTTP; Tue, 1 Oct 2013 12:15:18 -0700 (PDT) Received: by 10.227.202.194 with HTTP; Tue, 1 Oct 2013 12:15:18 -0700 (PDT) In-Reply-To: <5bbe4c7a3148466ba27406bb0f2b6d03@BL2PR03MB194.namprd03.prod.outlook.com> References: <5bbe4c7a3148466ba27406bb0f2b6d03@BL2PR03MB194.namprd03.prod.outlook.com> Date: Tue, 1 Oct 2013 12:15:18 -0700 Message-ID: From: Martin Thomson To: Andrei Popov Content-Type: multipart/alternative; boundary=001a11c25f1c03e07e04e7b2c6d4 Cc: tls@ietf.org Subject: Re: [TLS] Start of Working Group Last Call for ALPN (draft-ietf-tls-applayerprotoneg-01) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 19:15:54 -0000 --001a11c25f1c03e07e04e7b2c6d4 Content-Type: text/plain; charset=UTF-8 Looks good to me. On Sep 30, 2013 12:15 PM, "Andrei Popov" wrote: > A revised draft-ietf-tls-applayerprotoneg-02.html has been submitted. The > changes address the feedback we received during the TLS WG last call, and > include: > - Removal of the experimental namespace; > - Removal of the HTTP/2 protocol ID with the intent that the HTTP WG > request the appropriate protocol ID(s); > - More specific information in the IANA section. > > Thanks, > > Andrei > > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > Joseph Salowey (jsalowey) > Sent: Tuesday, September 10, 2013 10:17 AM > To: Joseph Salowey (jsalowey) > Cc: > Subject: Re: [TLS] Start of Working Group Last Call for ALPN > (draft-ietf-tls-applayerprotoneg-01) > > The working group last call for draft-ietf-tls-applayerprotoneg-01 has > completed. There is consensus in moving this work forward with some fixes > to the IANA section and some editorial nits. I am going to ask the > authors to submit a revised draft which will be submitted to the IESG. > > Thanks, > > Joe > > > On Aug 15, 2013, at 3:27 PM, Joseph Salowey (jsalowey) > wrote: > > > This is the working group last call for > draft-ietf-tls-applayerprotoneg-01. Please send your reviews and comments > to the TLS list by September 6, 2013. > > > > The draft can be found at > http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-01 > > > > Thanks, > > > > Joe > > > > > > _______________________________________________ > > 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 mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11c25f1c03e07e04e7b2c6d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Looks good to me.

On Sep 30, 2013 12:15 PM, "Andrei Popov&quo= t; <Andrei.Popov@microsoft= .com> wrote:
A revised draft-ietf-tls-applayerprotoneg-02.html has been submitted. The c= hanges address the feedback we received during the TLS WG last call, and in= clude:
- Removal of the experimental namespace;
- Removal of the HTTP/2 protocol ID with the intent that the HTTP WG reques= t the appropriate protocol ID(s);
- More specific information in the IANA section.

Thanks,

Andrei

-----Original Message-----
From: tls-bounces@ietf.org [mai= lto:tls-bounces@ietf.org] On Be= half Of Joseph Salowey (jsalowey)
Sent: Tuesday, September 10, 2013 10:17 AM
To: Joseph Salowey (jsalowey)
Cc: <tls@ietf.org>
Subject: Re: [TLS] Start of Working Group Last Call for ALPN (draft-ietf-tl= s-applayerprotoneg-01)

The working group last call for draft-ietf-tls-applayerprotoneg-01 has comp= leted. =C2=A0There is consensus in moving this work forward with some fixes= to the IANA section and some editorial nits. =C2=A0 I am going to ask the = authors to submit a revised draft which will be submitted to the IESG.

Thanks,

Joe


On Aug 15, 2013, at 3:27 PM, Joseph Salowey (jsalowey) <jsalowey@cisco.com> wrote:

> This is the working group last call for draft-ietf-tls-applayerprotone= g-01. Please send your reviews and comments to the TLS list by September 6,= 2013.
>
> The draft can be found at http://tools.ietf.org/html/= draft-ietf-tls-applayerprotoneg-01
>
> Thanks,
>
> Joe
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls
--001a11c25f1c03e07e04e7b2c6d4-- From ynir@checkpoint.com Tue Oct 1 12:48:03 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB4311E8270 for ; Tue, 1 Oct 2013 12:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4-fzKNAT8gS for ; Tue, 1 Oct 2013 12:47:51 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id B29C421E805F for ; Tue, 1 Oct 2013 12:46:20 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r91JkIvY016560; Tue, 1 Oct 2013 22:46:18 +0300 X-CheckPoint: {524B2689-F-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.30]) by IL-EX10.ad.checkpoint.com ([169.254.2.92]) with mapi id 14.02.0347.000; Tue, 1 Oct 2013 22:46:17 +0300 From: Yoav Nir To: "Kain, Michael T" Thread-Topic: [TLS] TLS 1.2 clarification requested Thread-Index: Ac6+19Gy7ubypu9bSN6R9OEEKLlUhP//2+0A Date: Tue, 1 Oct 2013 19:46:17 +0000 Message-ID: References: <45407AA8FD01AB4EA1D23EFE48EA29B9D57B9217DB@USEA-EXCH7.na.uis.unisys.com> In-Reply-To: <45407AA8FD01AB4EA1D23EFE48EA29B9D57B9217DB@USEA-EXCH7.na.uis.unisys.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.231] x-kse-antivirus-interceptor-info: protection disabled Content-Type: multipart/alternative; boundary="_000_A2B75A91EBFC415A967181E939819ACFcheckpointcom_" MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.2 clarification requested X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 19:48:04 -0000 --_000_A2B75A91EBFC415A967181E939819ACFcheckpointcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Oct 1, 2013, at 9:58 PM, "Kain, Michael T" > wrote: I=92m trying to understand the TLS 1.2 restrictions and signature algorithm= s and how they interact. Is there a relation between the signature algorit= hm that is negotiated between client and server and the algorithm which sig= ned the server certificate? Yes. According to sections 2.2 and 2.4 or RFC 4492, the server certificate = for ECDHE_ECDSA and ECDHE_RSA MUST have ECDSA and RSA public keys respectiv= ely, and also MUST be signed by ECDSA and RSA respectively. I'm not sure wh= y that last restriction is needed, but it's there. For non-EC ciphersuites,= there is no restriction, but you still need to negotiate an algorithm that= works with the public key. Does that affect the hash algorithm of TLS 1.2 =96 or is that always SHA256= ? The hash used in the algorithm (for example: to calculate the Finished mess= age) is ciphersuite-specific, but all current ciphersuites that anybody use= s specify SHA-256. For example, if I=92ve got a server configured with a server certificate si= gned with SHA256, can it still establish a connection using the TLS_RSA_WIT= H_AES_256_CBC_SHA? Yes, and then you'll have - a certificate signed with RSA-with-SHA256 - records MAC'd with HMAC-SHA1 - SHA256 in the Finished calculation Does the signature algorithm for a certificate affect which Ciphersuites ca= n be negotiated and used? Only because the ECC RFC says so. It is obviously restricted by the public = key. There's also the DH and ECDH key exchanges (non-ephemeral) that have t= heir own restrictions, but I'm not aware of anyone who uses them. Yoav --_000_A2B75A91EBFC415A967181E939819ACFcheckpointcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2DE447781807794CB76EC159C2A58B9D@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable
On Oct 1, 2013, at 9:58 PM, "Kain, Michael T" <Michael.Kain@unisys.com> wrote:
I=92m trying to understand the TLS 1.2 restrictions and signature algorithm= s and how they interact.  Is there a relation between the signature al= gorithm that is negotiated between client and server and the algorithm whic= h signed the server certificate?

Yes. According to sections 2.2 and 2.4 or RFC 4492, the server certificate = for ECDHE_ECDSA and ECDHE_RSA MUST have ECDSA and RSA public keys respectiv= ely, and also MUST be signed by ECDSA and RSA respectively. I'm not sure wh= y that last restriction is needed, but it's there. For non-EC ciphersuites, there is no restriction, but you = still need to negotiate an algorithm that works with the public key.

Does that affect the hash algorithm of TLS 1.2 =96 or is that always SHA256= ?

The hash used in the algorithm (for example: to calculate the Finished mess= age) is ciphersuite-specific, but all current ciphersuites that anybody use= s specify SHA-256.

For example, if I=92ve got a server configured with a server certificate si= gned with SHA256, can it still establish a connection using the TLS_RSA_WIT= H_AES_256_CBC_SHA?

Yes, and then you'll have
 - a certificate signed with RSA-with-SHA256
 - records MAC'd with HMAC-SHA1
 - SHA256 in the Finished calculation

Does the signature algorithm for a certificate affect which Ciphersuites ca= n be negotiated and used?

Only because the ECC RFC says so. It is obviously restricted by the public = key. There's also the DH and ECDH key exchanges (non-ephemeral) that have t= heir own restrictions, but I'm not aware of anyone who uses them.

Yoav


--_000_A2B75A91EBFC415A967181E939819ACFcheckpointcom_-- From mrex@sap.com Tue Oct 1 13:37:52 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C4411E8211 for ; Tue, 1 Oct 2013 13:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.05 X-Spam-Level: X-Spam-Status: No, score=-7.05 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yP64OJdLNNE for ; Tue, 1 Oct 2013 13:37:42 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7C22C11E81AD for ; Tue, 1 Oct 2013 13:37:41 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r91Kbcft004380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Oct 2013 22:37:38 +0200 (MEST) In-Reply-To: <45407AA8FD01AB4EA1D23EFE48EA29B9D57B9217DB@USEA-EXCH7.na.uis.unisys.com> To: "Kain, Michael T" Date: Tue, 1 Oct 2013 22:37:38 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20131001203738.334971A9CC@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "'tls@ietf.org'" Subject: Re: [TLS] TLS 1.2 clarification requested X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 20:37:52 -0000 Kain, Michael T wrote: > > I'm trying to understand the TLS 1.2 restrictions and signature > algorithms and how they interact. BEWARE! The semantics of the TLS signature algorithms extension as specified in TLSv1.2 (rfc5246): http://tools.ietf.org/html/rfc5246#section-7.4.1.4.1 and the specified interaction with the ServerCertificate chain as described in the last paragraph in page 49 http://tools.ietf.org/html/rfc5246#page-49 is fubar'ed (as in the ...beyond recognition sense). I don't know whether implementations of TLSv1.2 actually do/enforce any of that crap, but Murphy's Law says that the implementation that your customer/consumer wants to interop with, does so -- and that will cause of lot of grey hair in the long run. > > Is there a relation between the signature algorithm > that is negotiated between client and server and the algorithm which signed > the server certificate? The description in rfc5246 sections "7.4.1.4.1 Signature Algorithms" and "7.4.2 Server Certificate" require such a relation, but there is some non-zero probability that a TLSv1.2 implementor either did not notice or intentionally ignores this botched part of rfc5246. > > Does that affect the hash algorithm of TLS 1.2 - or is that always SHA256? Beware ! there are two distinct types of default hash algorithms in TLSv1.2: 1. SHA256 for the PRF plus the handshake message hash that goes into the Finished handshake message computation 2. either MD5 or SHA1 **alone** for "digitally_signed struct" as used in the ServerKeyExchange or CertificateVerify handshake messages. (2) is a huge step backwards in security from all prior versions of TLS and even from SSLv3. Essentially, a client that is proposing TLSv1.2 and not including a TLS signature extension, is subjecting itself to a downgrade attack that is worse than a fallback reconnect to SSLv3. The "default" digital signature algorithm is the most ridiculous breakage in TLSv1.2. Had the TLS WG waited for FIPS 186-3 to complete then there could have been SHA-256 everywhere in TLSv1.2, resulting in less complex and faster code, and more secure implementations. > > For example, if I've got a server configured with a server certificate > signed with SHA256, can it still establish a connection using the > TLS_RSA_WITH_AES_256_CBC_SHA? With implementations of SSLv3 through TLSv1.1, this typically just works. rfc5246 would "officially" require both server and client to fatally abort the handshake, unless the client allowed the use of a server certificate with a sha256WithRSAEncryption signature by including a TLS signature extension to that effect in ClientHello -- which is ridiculous. > > Does the signature algorithm for a certificate affect which Ciphersuites can > be negotiated and used? I can not currently think of a situation where the signature algorithm on the server's certificate would matter. It is the public key in the server's certificate (plus the keyUsage attribute) that determines which key exchange algorithms can be used, and that limits the cipher suites from those proposed by the client in ClientHello from which the server can choose. -Martin From ynir@checkpoint.com Tue Oct 1 14:37:46 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D092F21F9FED for ; Tue, 1 Oct 2013 14:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.999 X-Spam-Level: X-Spam-Status: No, score=-8.999 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OroNAL0jNjBP for ; Tue, 1 Oct 2013 14:37:34 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6350521F9F50 for ; Tue, 1 Oct 2013 14:37:26 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r91LbO6W015162; Wed, 2 Oct 2013 00:37:24 +0300 X-CheckPoint: {524B4094-0-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.30]) by IL-EX10.ad.checkpoint.com ([169.254.2.92]) with mapi id 14.02.0347.000; Wed, 2 Oct 2013 00:37:24 +0300 From: Yoav Nir To: "" Thread-Topic: [TLS] TLS 1.2 clarification requested Thread-Index: Ac6+19Gy7ubypu9bSN6R9OEEKLlUhP//6jQAgAAQwoA= Date: Tue, 1 Oct 2013 21:37:23 +0000 Message-ID: <51559859-218D-47C1-B670-916FDEB5CCD0@checkpoint.com> References: <20131001203738.334971A9CC@ld9781.wdf.sap.corp> In-Reply-To: <20131001203738.334971A9CC@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.231] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="us-ascii" Content-ID: <45A6D7C102050745BBFC0A0AC2E6A37D@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.2 clarification requested X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 21:37:46 -0000 On Oct 1, 2013, at 11:37 PM, Martin Rex wrote: > Kain, Michael T wrote: >>=20 >> I'm trying to understand the TLS 1.2 restrictions and signature >> algorithms and how they interact. >=20 > BEWARE! >=20 > The semantics of the TLS signature algorithms extension as specified > in TLSv1.2 (rfc5246): >=20 > http://tools.ietf.org/html/rfc5246#section-7.4.1.4.1 >=20 > and the specified interaction with the ServerCertificate chain as=20 > described in the last paragraph in page 49 >=20 > http://tools.ietf.org/html/rfc5246#page-49 >=20 > is fubar'ed (as in the ...beyond recognition sense). >=20 > I don't know whether implementations of TLSv1.2 actually do/enforce any > of that crap, but Murphy's Law says that the implementation that your > customer/consumer wants to interop with, does so -- and that will > cause of lot of grey hair in the long run. No. Murphy's law says that that implementation is a perfect implementation = of a misreading of RFC 5246. Except that perfect implementations don't cras= h so much. >> Does that affect the hash algorithm of TLS 1.2 - or is that always SHA25= 6? >=20 > Beware ! there are two distinct types of default hash algorithms > in TLSv1.2: >=20 > 1. SHA256 for the PRF plus the handshake message hash that goes > into the Finished handshake message computation >=20 > 2. either MD5 or SHA1 **alone** for "digitally_signed struct" > as used in the ServerKeyExchange or CertificateVerify > handshake messages. >=20 >=20 > (2) is a huge step backwards in security from all prior versions of > TLS and even from SSLv3. Essentially, a client that is proposing TLSv1.2 > and not including a TLS signature extension, is subjecting itself > to a downgrade attack that is worse than a fallback reconnect to SSLv3. How so? Section 7.4.8 says : RSA keys MAY be used with any permitted hash algorithm, subject to restrictions in the certificate, if any. So if the client has an RSA certificate, the signature can be done with SHA= -256. Yes, the client has to "advertise" this in a ClientHello extension. W= hat of it? > The "default" digital signature algorithm is the most ridiculous > breakage in TLSv1.2. Had the TLS WG waited for FIPS 186-3 to complete > then there could have been SHA-256 everywhere in TLSv1.2, resulting > in less complex and faster code, and more secure implementations. >=20 >=20 >>=20 >> For example, if I've got a server configured with a server certificate >> signed with SHA256, can it still establish a connection using the >> TLS_RSA_WITH_AES_256_CBC_SHA? >=20 > With implementations of SSLv3 through TLSv1.1, this typically just works. >=20 > rfc5246 would "officially" require both server and client to fatally > abort the handshake, unless the client allowed the use of a server > certificate with a sha256WithRSAEncryption signature by including a TLS > signature extension to that effect in ClientHello -- which is ridiculous. >=20 >=20 >>=20 >> Does the signature algorithm for a certificate affect which Ciphersuites= can >> be negotiated and used? >=20 > I can not currently think of a situation where the signature algorithm > on the server's certificate would matter. RFC 4492 said so. I now see that RFC 5246 relaxed that rule, but who reads = all the way to appendix A.7, right? > It is the public key in the server's certificate (plus the keyUsage attri= bute) > that determines which key exchange algorithms can be used, and that limit= s > the cipher suites from those proposed by the client in ClientHello > from which the server can choose. That is the case for TLS 1.2, but for TLS 1.0 and 1.1, using ECDHE requires= that the public key in the cert match the signature algorithm.=20 Yoav From Johannes.Merkle@secunet.com Wed Oct 2 02:43:40 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E173E21F9E9D for ; Wed, 2 Oct 2013 02:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thEO31fThmH5 for ; Wed, 2 Oct 2013 02:43:29 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6740021E8254 for ; Wed, 2 Oct 2013 02:43:03 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 7CB7A1A0081; Wed, 2 Oct 2013 11:43:01 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id p2mK6atnd1YU; Wed, 2 Oct 2013 11:43:00 +0200 (CEST) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 490B51A0080; Wed, 2 Oct 2013 11:43:00 +0200 (CEST) Received: from [10.208.1.57] ([10.208.1.57]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Oct 2013 11:43:00 +0200 Message-ID: <524BEAA3.8020108@secunet.com> Date: Wed, 02 Oct 2013 11:42:59 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Yoav Nir References: <45407AA8FD01AB4EA1D23EFE48EA29B9D57B9217DB@USEA-EXCH7.na.uis.unisys.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Oct 2013 09:43:00.0526 (UTC) FILETIME=[C8602CE0:01CEBF53] Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.2 clarification requested X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 09:43:41 -0000 > Yes. According to sections 2.2 and 2.4 or RFC 4492, the server certificate for ECDHE_ECDSA and ECDHE_RSA MUST have ECDSA and RSA public keys respectively, and also MUST be signed by ECDSA and RSA respectively. I'm not sure why that last restriction is needed, but it's there. For non-EC ciphersuites, there is no restriction, but you still need to negotiate an algorithm that works with the public key. > As you noted in your other post, RFC 5246 relaxes this restriction. And you don't have to go down until appendix A.7, it is clearly stated in Section 4.2 Note that this implies that a certificate containing a key for one signature algorithm MAY be signed using a different signature algorithm (for instance, an RSA key signed with a DSA key). Appendix A.7 only points out that this changes the rules of RFC 4492. Johannes From ynir@checkpoint.com Wed Oct 2 03:44:22 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A66621E8254 for ; Wed, 2 Oct 2013 03:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.633 X-Spam-Level: X-Spam-Status: No, score=-9.633 tagged_above=-999 required=5 tests=[AWL=0.966, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuWCZf7UT1rh for ; Wed, 2 Oct 2013 03:43:59 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD7121F9BA4 for ; Wed, 2 Oct 2013 03:43:43 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r92AhbED006935; Wed, 2 Oct 2013 13:43:37 +0300 X-CheckPoint: {524BF8D9-2-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.92]) by DAG-EX10.ad.checkpoint.com ([169.254.3.173]) with mapi id 14.02.0347.000; Wed, 2 Oct 2013 13:43:37 +0300 From: Yoav Nir To: Johannes Merkle Thread-Topic: [TLS] TLS 1.2 clarification requested Thread-Index: Ac6+19Gy7ubypu9bSN6R9OEEKLlUhP//2+0AgADps4CAABDxgA== Date: Wed, 2 Oct 2013 10:43:37 +0000 Message-ID: <5A2B4148-4DB3-429F-944E-D8EEE513ACE9@checkpoint.com> References: <45407AA8FD01AB4EA1D23EFE48EA29B9D57B9217DB@USEA-EXCH7.na.uis.unisys.com> <524BEAA3.8020108@secunet.com> In-Reply-To: <524BEAA3.8020108@secunet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.116] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="Windows-1252" Content-ID: <0E99272459ABA64092624BCEBC3AFE9E@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.2 clarification requested X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 10:44:22 -0000 On Oct 2, 2013, at 12:42 PM, Johannes Merkle = wrote: >=20 >> Yes. According to sections 2.2 and 2.4 or RFC 4492, the server certifica= te for ECDHE_ECDSA and ECDHE_RSA MUST have ECDSA and RSA public keys respec= tively, and also MUST be signed by ECDSA and RSA respectively. I'm not sure= why that last restriction is needed, but it's there. For non-EC ciphersuit= es, there is no restriction, but you still need to negotiate an algorithm t= hat works with the public key. >>=20 >=20 > As you noted in your other post, RFC 5246 relaxes this restriction. And y= ou don't have to go down until appendix A.7, it > is clearly stated in Section 4.2 >=20 > Note > that this implies that a certificate containing a key for one > signature algorithm MAY be signed using a different signature > algorithm (for instance, an RSA key signed with a DSA key). >=20 > Appendix A.7 only points out that this changes the rules of RFC 4492. >=20 And that also means that such certificates are OK for TLS 1.2, but not for = TLS 1.0 or 1.1. Yoav From jbonneau@gmail.com Wed Sep 25 22:15:45 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5723111E8152; Wed, 25 Sep 2013 22:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wot2NmQZtvj8; Wed, 25 Sep 2013 22:15:44 -0700 (PDT) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF9711E8155; Wed, 25 Sep 2013 22:15:33 -0700 (PDT) Received: by mail-vb0-f47.google.com with SMTP id h10so474920vbh.20 for ; Wed, 25 Sep 2013 22:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RPvvSiwO/t5Sl8IKpsc5lXGCslZuZk5jjYMkni/Ke7Q=; b=yShqUbdLEMPJN8+OdcIlZF9qCrgHExIHKq/350VGmUDEqf8KSSkVkLMts240tXoYjG wF7cB/wOWIMUAli/G6aKFa6Kr7P57zyc2M7DTiu2SAEfavXWzNUK51FK7747ZHqSYr85 rfc+AiylwzuLKQ4DgL2BetdSxhvU+T2ZpAQV+CIlxvs5gRZIy+zcuBvC63JTAa528+VY F+uhPXbxwXYDc4xiSVLWztd4SJrVwy/DoXULIJN547A24GYJO8e2ApCK5VqgA/I+N0NE XJfQd5mLRRbPBnUrY4r0lBfw1N+5wBMY6+y0Zu062aDOpu9WNs2pgI86PUPSfmH+Ggy1 gtkQ== X-Received: by 10.221.32.133 with SMTP id sk5mr11585vcb.27.1380172533507; Wed, 25 Sep 2013 22:15:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.241.198 with HTTP; Wed, 25 Sep 2013 22:15:13 -0700 (PDT) In-Reply-To: References: From: Joseph Bonneau Date: Thu, 26 Sep 2013 01:15:13 -0400 Message-ID: To: Ben Laurie Content-Type: multipart/alternative; boundary=001a1133aa0096b02704e7427518 X-Mailman-Approved-At: Wed, 02 Oct 2013 08:21:22 -0700 Cc: "therightkey@ietf.org" , "tls@ietf.org" Subject: Re: [TLS] [therightkey] Fwd: Improving EV Certificate Security X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 05:15:45 -0000 --001a1133aa0096b02704e7427518 Content-Type: text/plain; charset=UTF-8 I'd like some elaboration on the plan for step 6, creating a whitelist of valid EV certificates without an SCT. How is this going to be achieved? Also, if we could do this, why not do it for all certificates and bootstrap CT that way? Are the parameters of EV special for this (fewer certs, better records, etc.)? An alternate approach to a whitelist is to require SCTs for certs with a "not before" validity period after time T (presumably this requirement kicksn in around time T). With a stolen/compromised EV CA key you could still issue a fraudulent cert and backdate it, so you'd have to more strictly enforce the limits on validity periods for EV certs which I believe are 27 months in the CA/Browser forum guidelines and 39 months in the EV code-signing cert proposal. Of course this isn't attractive in that it means years before you really have protection against fraudulent EV certs. Has this approach been considered? Joe --001a1133aa0096b02704e7427518 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'd like some elaboration on the plan for step 6, crea= ting a whitelist of valid EV certificates without an SCT. How is this going= to be achieved? Also, if we could do this, why not do it for all certifica= tes and bootstrap CT that way? Are the parameters of EV special for this (f= ewer certs, better records, etc.)?

An alternate approach to a whitelist is to require SCTs for = certs with a "not before" validity period after time T (presumabl= y this requirement kicksn in around time T). With a stolen/compromised EV C= A key you could still issue a fraudulent cert and backdate it, so you'd= have to more strictly enforce the limits on validity periods for EV certs = which I believe are 27 months in the CA/Browser forum guidelines and 39 mon= ths in the EV code-signing cert proposal. Of course this isn't attracti= ve in that it means years before you really have protection against fraudul= ent EV certs. Has this approach been considered?

Joe
--001a1133aa0096b02704e7427518-- From ryan-ietf@sleevi.com Wed Sep 25 23:32:03 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7560F11E8159; Wed, 25 Sep 2013 23:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7YiCyX5mww0; Wed, 25 Sep 2013 23:31:58 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 8674621F9A16; Wed, 25 Sep 2013 23:31:58 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 28FDA163B; Wed, 25 Sep 2013 23:31:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=1s/06czCrsZTUnV6oko7w0C/A2o=; b=dDjzN1fOUa9UiMvIj 0sv1eSis+SM/lSS8Vqdtcx6ZHkAd3vA29YUVjqpXXOX/9RqFKJWPW7XmLKNF9Sl9 3a69g3IiF2QR/5WtLd735pxXdKOQCsx503BeJIgfq0uzrxA4RvgcitV4USoaj2yA Tc9gqIRKF61Jhq6GxktnOdc7tU= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPA id E35EF161E; Wed, 25 Sep 2013 23:31:57 -0700 (PDT) Received: from 173.8.157.162 (proxying for 173.8.157.162) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Wed, 25 Sep 2013 23:31:58 -0700 Message-ID: In-Reply-To: References: Date: Wed, 25 Sep 2013 23:31:58 -0700 From: "Ryan Sleevi" To: "Joseph Bonneau" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 02 Oct 2013 08:21:22 -0700 Cc: "therightkey@ietf.org" , "tls@ietf.org" Subject: Re: [TLS] [therightkey] Fwd: Improving EV Certificate Security X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ryan-ietf@sleevi.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 06:32:03 -0000 On Wed, September 25, 2013 10:15 pm, Joseph Bonneau wrote: > I'd like some elaboration on the plan for step 6, creating a whitelist= of > valid EV certificates without an SCT. How is this going to be achieved= ? > Also, if we could do this, why not do it for all certificates and > bootstrap > CT that way? Are the parameters of EV special for this (fewer certs, > better > records, etc.)? Fewer certs, by many orders of magnitude, such that whitelisting is a reasonable approach. > > An alternate approach to a whitelist is to require SCTs for certs with= a > "not before" validity period after time T (presumably this requirement > kicksn in around time T). With a stolen/compromised EV CA key you coul= d > still issue a fraudulent cert and backdate it, so you'd have to more > strictly enforce the limits on validity periods for EV certs which I > believe are 27 months in the CA/Browser forum guidelines and 39 months= in > the EV code-signing cert proposal. Of course this isn't attractive in = that > it means years before you really have protection against fraudulent EV > certs. Has this approach been considered? > > Joe As you note, with a stolen/compromised EV CA key, you can still backdate certs. The whitelist approach balances the tradeoffs and brings the delta for practical checking on the client side down to a reasonable value and with acceptable (and negligible) performance overheads, which decrease over time. From jbonneau@gmail.com Thu Sep 26 07:29:30 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E90B11E810B; Thu, 26 Sep 2013 07:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8+i+IdULL5O; Thu, 26 Sep 2013 07:29:29 -0700 (PDT) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDCF21F98AC; Thu, 26 Sep 2013 07:29:29 -0700 (PDT) Received: by mail-ve0-f174.google.com with SMTP id jy13so938674veb.19 for ; Thu, 26 Sep 2013 07:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wlw4QAIImb7CbS/fk3KMw+HlT2HPBy2qFzkXVheHbr8=; b=ZL3EzLYzE1UqFvv7yQtZ9ep03dcjbeakLGlAZc3C4ve+QZk6Vz0Zq68ePEzeyyJmDf aNjIkm4+yTVk0i5a7mv7rtHdV4gspAcnnmOkzYxYpgoIeCNBClBJZXtsBj/IGB+xpmjr IcVtm5adhTMoX4k9l6KCee4ybguwhCxBNVoJaxgByI/s9ctilZFM3KCSI10KbVzp8X1E K1ElKOFrP4ZRsdedzR147dsDEYqUseb0/YDrZJ0JTAOkD8y/RU3V8qgueU66jl6DAeGd vbRONXF7EaQ1zAlfRLYXEi5LiiAYuQAVqhHYExzu0rVHs3FIUYajfXWE0tUxcqpllla7 kEXg== X-Received: by 10.52.187.138 with SMTP id fs10mr772872vdc.10.1380205768803; Thu, 26 Sep 2013 07:29:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.241.198 with HTTP; Thu, 26 Sep 2013 07:29:08 -0700 (PDT) In-Reply-To: References: From: Joseph Bonneau Date: Thu, 26 Sep 2013 10:29:08 -0400 Message-ID: To: Ben Laurie Content-Type: multipart/alternative; boundary=bcaec548a385911e5004e74a32ac X-Mailman-Approved-At: Wed, 02 Oct 2013 08:21:22 -0700 Cc: "therightkey@ietf.org" , "tls@ietf.org" Subject: Re: [TLS] [therightkey] Fwd: Improving EV Certificate Security X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 14:29:31 -0000 --bcaec548a385911e5004e74a32ac Content-Type: text/plain; charset=UTF-8 > I'd like some elaboration on the plan for step 6, creating a whitelist of > > valid EV certificates without an SCT. How is this going to be achieved? > > Not sure what the question is - as the doc says, the list will be > constructed from the logs... > I think I read it incorrectly as "without an embedded CT from *any* qualify logs" instead of "from all qualifying logs." Now I can see how the whitelist is created, but I'm less clear on what the intention of it is. Is the assumption that some certs will be issued with more than zero but fewer than three SCTs (proposed to the minimum acceptable in the "Qualifying Certificates" section) and you'd like to whitelist such certs during the rollout period? Also, why isn't there be a step 8 in the plan, where the whitelist is deprecated and every EV cert requires SCTs and Chrome is rejecting the EV certs without them? --bcaec548a385911e5004e74a32ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> I'd like some = elaboration on the plan for step 6, creating a whitelist of
> valid EV certificates without an SCT. How is this going to be achieved= ?

Not sure what the question is - as the doc says, the list will be
constructed from the logs...

I think I read it i= ncorrectly as "without an embedded CT from *any* qualify logs" in= stead of "from all qualifying logs." Now I can see how the whitel= ist is created, but I'm less clear on what the intention of it is. Is t= he assumption that some certs will be issued with more than zero but fewer = than three SCTs (proposed to the minimum acceptable in the "Qualifying= Certificates" section) and you'd like to whitelist such certs dur= ing the rollout period?

Also, why i= sn't there be a step 8 in the plan, where the whitelist is deprecated a= nd every EV cert requires SCTs and Chrome is rejecting the EV certs without= them?
--bcaec548a385911e5004e74a32ac-- From jbonneau@gmail.com Thu Sep 26 07:45:10 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70CF011E8103; Thu, 26 Sep 2013 07:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAEGdrtpq054; Thu, 26 Sep 2013 07:45:09 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9D81B11E80DE; Thu, 26 Sep 2013 07:45:07 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id ht10so920541vcb.10 for ; Thu, 26 Sep 2013 07:45:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tbOEH//K3fAbv/psP5xvs6AVXZy+OKiDpyK8WpZmEQY=; b=sbr26cCLfaVm+FaKNh7J/cVmiFlkZOfu5SM2sj4ROZ9Wy+LCInxd2/y+mY9g1cev4f hGshRYhHRodJXv3d8mrd63v1Mh0fgZam7/bfX7Kwmndn6gsIRKNfAXgxcnUHdtFwhs3n mCZ0U6yv0Yx0tnTDvS4bcyEtJ0DgDboD23ae8qNXkplko0w10X7IpgR/HlhinVZAumIR tmWhnU84iX7VoL7tMVtlhiUWvLVwYd0/7kBzfJV/eAZ9dObCARpbqQmVIJWfVEJpAeVT 6RYNzOPEGtjFMH9bkqeq4EWLNo8pxTLl/c8Rfjct/0KfV/sSgYHOSZYefjWOET6i7b3s 6dAg== X-Received: by 10.220.173.134 with SMTP id p6mr524781vcz.36.1380206707065; Thu, 26 Sep 2013 07:45:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.241.198 with HTTP; Thu, 26 Sep 2013 07:44:47 -0700 (PDT) In-Reply-To: References: From: Joseph Bonneau Date: Thu, 26 Sep 2013 10:44:47 -0400 Message-ID: To: Ben Laurie Content-Type: multipart/alternative; boundary=089e0158b1547dcc9e04e74a6a60 X-Mailman-Approved-At: Wed, 02 Oct 2013 08:21:22 -0700 Cc: "therightkey@ietf.org" , "tls@ietf.org" Subject: Re: [TLS] [therightkey] Fwd: Improving EV Certificate Security X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 14:45:10 -0000 --089e0158b1547dcc9e04e74a6a60 Content-Type: text/plain; charset=UTF-8 > >> Not sure what the question is - as the doc says, the list will be > >> constructed from the logs... > > > > > > I think I read it incorrectly as "without an embedded CT from *any* > qualify > > logs" instead of "from all qualifying logs." Now I can see how the > whitelist > > is created, but I'm less clear on what the intention of it is. Is the > > assumption that some certs will be issued with more than zero but fewer > than > > three SCTs (proposed to the minimum acceptable in the "Qualifying > > Certificates" section) and you'd like to whitelist such certs during the > > rollout period? > > Ah. So, all existing certs do not have embedded SCTs. So, we either > wait until all existing certs expire before we can enforce CT, or we > whitelist the unexpired certs. I think I'm back to my original question now :-) How do all the existing certs get into the CT log? (at which point building the whitelist is easy) Is the onus on EV users then to log their old certs or face failing in Chrome? Or do EV-issuing CAs have sufficient records of what they've issued? Or is this something that we're hoping can be (at least mostly) achieved by network observation? --089e0158b1547dcc9e04e74a6a60 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

=
>> Not sure what the question is - as the doc says, the list will be<= br> >> constructed from the logs...
>
>
> I think I read it incorrectly as "without an embedded CT from *an= y* qualify
> logs" instead of "from all qualifying logs." Now I can = see how the whitelist
> is created, but I'm less clear on what the intention of it is. Is = the
> assumption that some certs will be issued with more than zero but fewe= r than
> three SCTs (proposed to the minimum acceptable in the "Qualifying=
> Certificates" section) and you'd like to whitelist such certs= during the
> rollout period?

Ah. So, all existing certs do not have embedded SCTs. So, we either wait until all existing certs expire before we can enforce CT, or we
whitelist the unexpired certs.

I think I= 9;m back to my original question now :-) How do all the existing certs get = into the CT log? (at which point building the whitelist is easy) Is the onu= s on EV users then to log their old certs or face failing in Chrome? Or do = EV-issuing CAs have sufficient records of what they've issued? Or is th= is something that we're hoping can be (at least mostly) achieved by net= work observation?
--089e0158b1547dcc9e04e74a6a60-- From ekasper@google.com Thu Sep 26 08:45:45 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 097B221F9A61 for ; Thu, 26 Sep 2013 08:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogOnL9pLzTbA for ; Thu, 26 Sep 2013 08:45:44 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 787FA21F9A6C for ; Thu, 26 Sep 2013 08:44:28 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id to1so1570032ieb.23 for ; Thu, 26 Sep 2013 08:44:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N3Dbo2riu4z5rzxgHr+AjPbWCW13WjjKfkdeHM73Bck=; b=PDTlPcGRwfjxmyIkdGIEzKxuK7eu9zeocs25//XK50glS5fZV4I+T656DANN4YxoSb pUr9n7RwNDieK4vG9qkKUg+AI6uhGc3bUABGmw1Q9/XUnZjR6jgIJo8SSzKsGcX64kiq cSwH/39qn4vEqv0le0SmyxfImdesBIEaBR0BkQ6ZU9Ye6KPH5AAP9UnBCMV+J0USpN4m B91UfaeDYp7rVXEnRmcUGhgVRURxSWwDxMBBWkYkASqvHsJFNxNZfSxUeEHAw0aPkPLt rBQ9TpuUibYxDSSBnmVMYLoX/2gQAjhUvv+BRynUUBYoVJ9RGsIX9aVkLjaKuA9qoP0v /fOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=N3Dbo2riu4z5rzxgHr+AjPbWCW13WjjKfkdeHM73Bck=; b=YxxAGwIyXdMypfkGmxJrc7e7SK4fGYlmPJe1U68k5pPbXCDUMceGakKq1t4IjoakFY k7rfT1CCROSBcNaGIqXKpacicXIfprRZ/S+oSZWt6nVUx7j69tO/8eLe38Q/j+OkC5Rg 6mid+ljH63e/dSSY92KVd2o6mZVsZzVKq4FIAcJnAE0ZM3H3xMJ5IX9RkXKPP9gSD6a6 bd8BakWM2VVr1ObHfs4B98kcWnX8Oq+8RJS6fI5mHp5gdpwUnjTesqWuooT5CmC0Tw/4 znDAeqneruzifasHa+6/2A1Ipaa+lfVuCkkFINtX4d4u273AwJKNN1KgYPjuBZRaDIwi SD9w== X-Gm-Message-State: ALoCoQmtfOKjWeZFUiQRev2pCNmk0cNMXHgTtuvENtSbFh9Z/lbthVh2ao6XvByaYAze4YPTAI7P4BeITr1QD/3pvaq0iulb9/dovAgbnaMB7UylFHEbhjPi0/T8lp7bmXkoYFjiBxkFuDr159QJRLP7SKKVlwUnzb7SLKMzNCwz7me1mB8TovETfSWHOGAXF2Piy+vM20OT MIME-Version: 1.0 X-Received: by 10.42.90.202 with SMTP id l10mr1820198icm.64.1380210266820; Thu, 26 Sep 2013 08:44:26 -0700 (PDT) Received: by 10.64.235.231 with HTTP; Thu, 26 Sep 2013 08:44:26 -0700 (PDT) In-Reply-To: References: Date: Thu, 26 Sep 2013 17:44:26 +0200 Message-ID: From: Emilia Kasper To: Ben Laurie Content-Type: multipart/alternative; boundary=90e6ba613fd6ab801b04e74b3eae X-Mailman-Approved-At: Wed, 02 Oct 2013 08:21:22 -0700 Cc: "therightkey@ietf.org" , Joseph Bonneau , "tls@ietf.org" Subject: Re: [TLS] [therightkey] Fwd: Improving EV Certificate Security X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 15:45:45 -0000 --90e6ba613fd6ab801b04e74b3eae Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 26, 2013 at 5:35 PM, Ben Laurie wrote: > On 26 September 2013 15:44, Joseph Bonneau wrote: > > > >> >> Not sure what the question is - as the doc says, the list will be > >> >> constructed from the logs... > >> > > >> > > >> > I think I read it incorrectly as "without an embedded CT from *any* > >> > qualify > >> > logs" instead of "from all qualifying logs." Now I can see how the > >> > whitelist > >> > is created, but I'm less clear on what the intention of it is. Is the > >> > assumption that some certs will be issued with more than zero but > fewer > >> > than > >> > three SCTs (proposed to the minimum acceptable in the "Qualifying > >> > Certificates" section) and you'd like to whitelist such certs during > the > >> > rollout period? > >> > >> Ah. So, all existing certs do not have embedded SCTs. So, we either > >> wait until all existing certs expire before we can enforce CT, or we > >> whitelist the unexpired certs. > > > > > > I think I'm back to my original question now :-) How do all the existing > > certs get into the CT log? (at which point building the whitelist is > easy) > > Is the onus on EV users then to log their old certs or face failing in > > Chrome? Or do EV-issuing CAs have sufficient records of what they've > issued? > > My assumption is that this is true. If it's not, then CAs need to tell us > :-) > CAs are required to retain records for audit, and are required to pass audit to obtain EV status in the first place, so I would very much hope it's not an unreasonable assumption :) > > Or is this something that we're hoping can be (at least mostly) achieved > by > > network observation? > > This is also likely. > _______________________________________________ > therightkey mailing list > therightkey@ietf.org > https://www.ietf.org/mailman/listinfo/therightkey > --90e6ba613fd6ab801b04e74b3eae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Sep 26, 2013 at 5:35 PM, Ben Laurie <<= a href=3D"mailto:benl@google.com" target=3D"_blank">benl@google.com>= wrote:
On 26 September 2013 15:= 44, Joseph Bonneau <jbonneau@gmail= .com> wrote:
>
>> >> Not sure what the question is - as the doc says, the list= will be
>> >> constructed from the logs...
>> >
>> >
>> > I think I read it incorrectly as "without an embedded CT= from *any*
>> > qualify
>> > logs" instead of "from all qualifying logs." N= ow I can see how the
>> > whitelist
>> > is created, but I'm less clear on what the intention of i= t is. Is the
>> > assumption that some certs will be issued with more than zero= but fewer
>> > than
>> > three SCTs (proposed to the minimum acceptable in the "Q= ualifying
>> > Certificates" section) and you'd like to whitelist s= uch certs during the
>> > rollout period?
>>
>> Ah. So, all existing certs do not have embedded SCTs. So, we eithe= r
>> wait until all existing certs expire before we can enforce CT, or = we
>> whitelist the unexpired certs.
>
>
> I think I'm back to my original question now :-) How do all the ex= isting
> certs get into the CT log? (at which point building the whitelist is e= asy)
> Is the onus on EV users then to log their old certs or face failing in=
> Chrome? Or do EV-issuing CAs have sufficient records of what they'= ve issued?

My assumption is that this is true. If it's not, then CAs n= eed to tell us :-)

CAs are required to = retain records for audit,=A0and are required to pass audit to obtain EV sta= tus in the first place, so I would very much hope it's not an unreasona= ble assumption :)


> Or is this something that we're hoping can be (at least mostly) ac= hieved by
> network observation?

This is also likely.
_________________________________________= ______
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey

--90e6ba613fd6ab801b04e74b3eae-- From 57756671618275-ietf-tls@sublist.cr.yp.to Wed Oct 2 09:21:23 2013 Return-Path: <57756671618275-ietf-tls@sublist.cr.yp.to> X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51A021F9D12 for ; Wed, 2 Oct 2013 09:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9M7IauoJQtW for ; Wed, 2 Oct 2013 09:21:08 -0700 (PDT) Received: from mace.cs.uic.edu (mace.cs.uic.edu [131.193.32.224]) by ietfa.amsl.com (Postfix) with SMTP id 4468621F8B04 for ; Wed, 2 Oct 2013 09:19:49 -0700 (PDT) Received: (qmail 7417 invoked by uid 1011); 2 Oct 2013 16:19:48 -0000 Received: from unknown (unknown) by unknown with QMTP; 2 Oct 2013 16:19:48 -0000 Received: (qmail 8126 invoked by uid 1001); 2 Oct 2013 16:19:44 -0000 Date: 2 Oct 2013 16:19:44 -0000 Message-ID: <20131002161944.8125.qmail@cr.yp.to> From: "D. J. Bernstein" To: tls@ietf.org Mail-Followup-To: tls@ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> <20130926152757.15842.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDB49B@XMB116CNC.rim.net> <20130928223648.1113.qmail@cr.yp.to> <20130929025714.5578895.47771.4422@certicom.com> <20131001143511.11010.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE21E@XMB116CNC.rim.net> Subject: Re: [TLS] Safe ECC usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 16:21:23 -0000 Dan Brown writes: > Brainpool and RFC 5639 recommends pseudo-random parameters to avoid > unanticipated attacks, and you are arguing against this recommendation > by anticipating from known attacks. No, and no. The Brainpool standard (from which RFC 5639 is derived) says that the unexplained NIST seeds leave "an essential part of the security analysis open" and that this is a "major issue." I completely agree with this. There are two reasonable ways to address this problem. One way, which Brainpool uses, is to generate curves "in a pseudo-random manner using seeds that are generated in a systematic and comprehensive way," subject of course to other requirements. Another way, which I use, is to take the smallest possible curves meeting the other requirements. Both of these approaches are clear improvements over what NIST/NSA did. As Brainpool puts it, choosing fully explained seeds will "enhance trust in the recommended curves." Choosing smallest curves has the same effect. There's no contradiction between these statements. There is zero reason to believe that either of these approaches is more secure than the other. There is, in particular, zero reason to believe that either approach is safer against "unanticipated attacks." You are wrong to attribute any such belief to the Brainpool standard; the document says no such thing. All available evidence is that both approaches are fine; if we've missed an attack then we have no way to guess whether the attack is more likely to apply to one curve or to the other. My reason for not taking the Brainpool approach is that it has a rather heavy cost. We have enough problems deploying secure crypto without incurring unnecessary costs; if we can afford extra costs then I'd rather put those into taking steps that actually matter for security, such as adding defenses against quantum computers. So I prefer the second approach. Conversely, Brainpool does not discuss the second approach, and does not state any reason to avoid the approach. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago From dbrown@certicom.com Wed Oct 2 11:51:30 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5252F21F9D3B for ; Wed, 2 Oct 2013 11:51:30 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3-OeLvDvffP for ; Wed, 2 Oct 2013 11:51:18 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id EB19821F9D44 for ; Wed, 2 Oct 2013 11:47:44 -0700 (PDT) Content-Type: multipart/mixed; boundary="===============0092626920==" MIME-Version: 1.0 Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs212cnc.rim.net with ESMTP/TLS/AES128-SHA; 02 Oct 2013 14:47:41 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT106CNC.rim.net ([fe80::d824:6c98:60dc:3918%16]) with mapi id 14.03.0123.003; Wed, 2 Oct 2013 14:47:40 -0400 From: Dan Brown To: "'djb@cr.yp.to'" , "'tls@ietf.org'" Thread-Topic: [TLS] Safe ECC usage Thread-Index: AQHOv4s0xn3XJXmgAkKRAg2ZE6kwf5nhtYbA Date: Wed, 2 Oct 2013 18:47:39 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF5BDE90F@XMB116CNC.rim.net> References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> <20130926152757.15842.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDB49B@XMB116CNC.rim.net> <20130928223648.1113.qmail@cr.yp.to> <20130929025714.5578895.47771.4422@certicom.com> <20131001143511.11010.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE21E@XMB116CNC.rim.net> <20131002161944.8125.qmail@cr.yp.to> In-Reply-To: <20131002161944.8125.qmail@cr.yp.to> Accept-Language: en-CA, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] MIME-Version: 1.0 Subject: Re: [TLS] Safe ECC usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 18:51:30 -0000 --===============0092626920== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0149_01CEBF7E.57834BD0" ------=_NextPart_000_0149_01CEBF7E.57834BD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > D. J. Bernstein writes > > Dan Brown writes: > > Brainpool and RFC 5639 recommends pseudo-random parameters to avoid > > unanticipated attacks, and you are arguing against this > recommendation > > by anticipating from known attacks. > > No, and no. > > The Brainpool standard (from which RFC 5639 is derived) says that the > unexplained NIST seeds leave "an essential part of the security > analysis open" and that this is a "major issue." I completely agree > with this. > > There are two reasonable ways to address this problem. One way, which > Brainpool uses, is to generate curves "in a pseudo-random manner using > seeds that are generated in a systematic and comprehensive way," > subject of course to other requirements. Another way, which I use, is > to take the smallest possible curves meeting the other requirements. [DB] Yes. Security requirement 5 says "verifiably pseudo-random ..." and then refers to Section 5, where it is applied to the field size p. Earlier it noted that existing field sizes are all "special". As you noted, using a random prime instead of a special one incurs a computational cost. So, I think I was reasonable to infer that Brainpool was implying that special fields were lacking in security. (The implication against special values may then be inferred further.) But now, I notice that the Brainpool document gives another reason to avoid special fields, so your interpretation is more reasonable than mine. > > Both of these approaches are clear improvements over what NIST/NSA did. [DB] Not disputing that. All they had to do was reveal how their seeds were generated. > As Brainpool puts it, choosing fully explained seeds will "enhance > trust in the recommended curves." Choosing smallest curves has the same > effect. There's no contradiction between these statements. > [DB] I am not asking whether anybody trusts which curve. I am asking for formal claims of security, even ones that contain an unknown variable. > There is zero reason to believe that either of these approaches is more > secure than the other. There is, in particular, zero reason to believe > that either approach is safer against "unanticipated attacks." You are > wrong to attribute any such belief to the Brainpool standard; the > document says no such thing. All available evidence is that both > approaches are fine; if we've missed an attack then we have no way to > guess whether the attack is more likely to apply to one curve or to the > other. [DB] No. This is the essence of what I've been trying to say about Curve25519 being special. I will try again. Assume we trust the verifiably pseudo-random generation algorithms. Then we have a proof that Brainpool are invulnerable to the "missed attack" with probability equal to the density of the vulnerable curves. We have no such proof for special curves such as Curve25519, because we do not know the nature of the missed attack. We cannot assume that a missed attack will render a uniformly random set of vulnerable curves. You provided valid arguments in favour of Curve25519 if the missed attacks are similar to known attacks, with which I agree, but that does not go as far as the Brainpool. Therefore, in terms of security, Brainpool >~ Curve25519 >> P256, if we posit missed EC attacks and trust hash functions, else Brainpool == Curve25519 == P256 if not. (I'm using >~ for slightly better, and >> for considerably better.) > > My reason for not taking the Brainpool approach is that it has a rather > heavy cost. We have enough problems deploying secure crypto without > incurring unnecessary costs; if we can afford extra costs then I'd > rather put those into taking steps that actually matter for security, > such as adding defenses against quantum computers. So I prefer the > second approach. Conversely, Brainpool does not discuss the second > approach, and does not state any reason to avoid the approach. > [DB] Agreed, to this end, I just want to quantify the security gains, so the cost-benefit analysis can be better formalized. ------=_NextPart_000_0149_01CEBF7E.57834BD0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUgTCCBnAw ggVYoAMCAQICChfYCekAAwAXxTIwDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAz WUtGMB4XDTEzMDUyODE1NDQwOVoXDTE0MDUxNzAwMjMzM1owgYUxEzARBgoJkiaJk/IsZAEZFgNu ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xETAPBgNVBAsTCENlcnRpY29tMQ4wDAYDVQQLEwVVc2Vy czESMBAGA1UEAxMJRGFuIEJyb3duMSIwIAYJKoZIhvcNAQkBFhNkYnJvd25AY2VydGljb20uY29t MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDRc70RE0/FL9ZbfN64YjA0lkQOLR9ipGebc9nH jB93OfYfR7CVsCUYy3+v9PO1DiUS9MeWWR4nxB9Ztee32d3syDxGg3PGFwSrms/ORAW9pgiS/yKH An9SKRKyqMz9LSn/VQrEgoyPBPT0S/vg521MGH58MwMXyLm1cLBQU5gtCQIDAQABo4IDmDCCA5Qw CwYDVR0PBAQDAgWgMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQME AgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUAlQmTNpWxnzoCUVjxGTtDz2JvLww FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMB8GA1UdIwQYMBaAFLgwF25vZ5X+hYxoO6XhF7M/+CU6 MIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiGgctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu YXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1NQ0EwM1lLRixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIw U2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2Fs P2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRp b25Qb2ludIZIaHR0cDovL21jYTAzeWtmLnJpbS5uZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRp bmF0ZSUyMENBJTIwTUNBMDNZS0YuY3JsMIIBQQYIKwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUH MAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1BSUEs Q049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixE Qz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZp Y2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxodHRwOi8vbWNhMDN5a2YucmltLm5ldC9DZXJ0 RW5yb2xsL01DQTAzWUtGLnJpbS5uZXRfUklNJTIwU3Vib3JkaW5hdGUlMjBDQSUyME1DQTAzWUtG KDMpLmNydDApBgNVHSUEIjAgBgorBgEEAYI3CgMEBggrBgEFBQcDBAYIKwYBBQUHAwIwQQYDVR0R BDowOKAhBgorBgEEAYI3FAIDoBMMEWRhbmlicm93bkByaW0ubmV0gRNkYnJvd25AY2VydGljb20u Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQC6hxWgDv96DUDS3m8XfyVGAv1CKOcWSVOShz/jofFMFzoN o2dhc0Jg9XTTZBVS+ozakEM+87YUENfP3IODRbCiJBsbiXJxS+fVo7L/bqPp47TB+Lg2/tezlNa2 ab4psmc9xjZGU9+A4lBzS5PpRjvHofsIwETpwt/aPxHIbJ5Cf7kBi7B8hR4mIqc7EJMYXeI0xHLg k3NqBYSGC3XtbykuFV0vPFoTYLO7G3pAP2RzGhuxQoaH4fpWvE3rdakjd1MZFqJrarXSvWi6ah6G Alt7+sOTzlGNqoTQqb55VZEOrU2A1VbmAFjiFR1/229A2KaHhnN6cuNe8bhzoBcnuxtyMIIGvzCC BKegAwIBAgIQMhrzkrEUWZRNTS+VEbN74TANBgkqhkiG9w0BAQUFADBPMRUwEwYKCZImiZPyLGQB GRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBN Q0EwMVlLRjAeFw0wNjEwMTMwMTI0NTVaFw0xNjEwMTMwMTMwNDFaME8xFTATBgoJkiaJk/IsZAEZ FgVsb2NhbDEXMBUGCgmSJomT8ixkARkWB3dpbmRvd3MxHTAbBgNVBAMTFFJJTSBSb290IENBIE1D QTAxWUtGMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAxui6zvytVAEtPzv6NhK7OZna iw/jQEyEVskDf5yzcFkLT/+5PztIbv+eFmL1CP2FhvLv8eQZJDKF4Yv+UsjPEN1lX4DDGKKt0NPp yT9pwQzFaiUt0rnERgSabo7EtpS4S+DuL8G9c+lmWwDqb0UWtPMdVfbr3fDwigyz1yh+vVMAHdhg Oe9lPC6nPtiJ9IXTam7V5mJmDT0mNpq/0fJo3JEaNvDKoXBOkKv6IdbtKxKzPInG6VYaCdgJCAT3 mWgr9kxiEQEUJKrvI2fXI0zRYnlL648gvK84pdsT2xZLFtr4OdZAm4RkK8U+cgurlSCr6NVqnfbq 6/3N6MGmyc9SB2Ayhk2VS66757V4nBzeaeD+srpk4IXU3NTM/+YgR1zVS41XwvZaq9Uf59j0TJhN 9xGVZO871eVVr2VfNxr0xOqUpwcxh5JZYkWcmUJFlYiQh0CM2PrfaDRTTqRZQd4F3xUlcXFAXOGh vaXKvikeI6/utnX6vCnDwMUxmenzlv8epNatxDsuIgOWO4pfqgGMyzWo2hudQ97+5ynUqDLX34nr UzszGeIE3KoqYsksxMF3tqIgadt9hNWXaP/EknZpRAmaP0s0V5ZvgiyXw9UrqnWwmRbLQk7HnYc0 hHQBjXoByKSiOyhgSS9yL6a+7AA2rhBPpsSVI9LYBs2cNKlPsZcCAwEAAaOCAZUwggGRMBMGCSsG AQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTW aYJkJBbBzCTb8RR9RxJ83MlN7jCCASkGA1UdHwSCASAwggEcMIIBGKCCARSgggEQhoHEbGRhcDov Ly9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1NQ0EwMVlLRixDTj1DRFAsQ049UHVi bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5k b3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1j UkxEaXN0cmlidXRpb25Qb2ludIZHaHR0cDovL21jYTAxeWtmLndpbmRvd3MubG9jYWwvQ2VydEVu cm9sbC9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwDQYJ KoZIhvcNAQEFBQADggIBAEOeWFu4OVTnx9+jYk92iDra2f1Bc5j1WesEGINl4VCY9WJy6n17b/h2 fDmjj9KfIto3LE2Wej77lSJqv/LSd7wnfTQVZVb1wBe2Zt+LuPAqi6vWSDAQVOfdOMYVu5imznnf +ZNMLduTqXZ/bFQKTWsg2qhBWwaiYfxEY7nVg3+ZfStqwc9R3v/tHH+b9kX3FuKLoVQ6KSrqUyBi fhIRj57eOw6/JjPA+SId/p2yEZ+xmANQ31vE3BHFRm20kZHHqAfdCmTt1S7LDSLHBj3GZXIFUge9 aPKqzAXee2DCYTP3YYcgrP/FbFF2RqGRIhPM+MdjJraMjex+nNT+2KC/EIWsbU9DgFII0wHKpRx8 rlJNN8kmb/H9qGqcNaW9Q/pwUTpX1bXSdbzvYFs3NY7KmYYii4Q0RQCGr96OvDT0/S6/IrnW+vqZ jnPV2MXqEuyQ0L5HXVOnCi769uGYcRkEo5xzEJ/EMvj07vCWnG7h9ykNhLEEMcygVmBdXP9qOqog dyPJB0AzxAYGqCSMT8Ors1M/srZSXUCfSfENH5iBd7bxH7uXmF7kbOEghom7AccC2Clt4DU0tj9s FyIWg5H6zy6NLetm2/kzdD3mGY3u2tWtijVnd2CWY2YszYo1lbDAfEfjGL/9uFpH79Zt9ekRSD5Z bSn1SNr1njjeGpV3jwyuMIIHRjCCBS6gAwIBAgIKFnKQQQAAAAABuDANBgkqhkiG9w0BAQUFADBP MRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQD ExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjAeFw0xMjA1MTcwMDEzMzNaFw0xNDA1MTcwMDIzMzNaMFAx EzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBT dWJvcmRpbmF0ZSBDQSBNQ0EwM1lLRjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfx jFzEuYa/qd6dXu4HILtBdH3+Bgwz3uQakDcxvrf3fyVQBy69KFOS8/h5REe6bit3tp5wsQQv/nFV mmXK/jq9zD72zl3jv63UzZgOWC90846UxTTmmNEyHzo1M54B3LrnE6L2Q6QbEZMAnrJ96uV8pN2X Zsn5j+MvfI5ajFu+6oPbHeYzQjZB3GDju7sELm7cAcr0YYX3xeLTB2rLUUZF6Nyyc0btD57ARYEa 99A+6JslO8VcxtlgRddx17NB6gttNjwmJFT3l3UVcK5O5+UVSWpW1zQbZQBvl0iP7gXcrJW4Dv0p 036iHg9lgDV1qQChi9NCixwm7yYtCHLq9akCAwEAAaOCAyEwggMdMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFLgwF25vZ5X+hYxoO6XhF7M/+CU6MAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEE AwIBAzAjBgkrBgEEAYI3FQIEFgQUZUBVml3ak56Kwnbul6AULvNdck8wGQYJKwYBBAGCNxQCBAwe CgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNVHR8EggEg MIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Ys Q049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRp b25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6Ly9tY2Ew MXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Yu Y3JsMIIBPAYIKwYBBQUHAQEEggEuMIIBKjCBuwYIKwYBBQUHMAKGga5sZGFwOi8vL0NOPVJJTSUy MFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRvd3MsREM9bG9jYWw/Y0FDZXJ0aWZp Y2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwagYIKwYBBQUHMAKG Xmh0dHA6Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvTUNBMDFZS0Yud2luZG93 cy5sb2NhbF9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcnQwDQYJKoZIhvcNAQEFBQADggIB AK/ZTtcAxFAZJo37z0KG3EGIGIScPRus90jBJGQO9+Mrb4QRoMjkCwZP9GbYq2CxCqOBiKOZfkSK PMSupPLRlE70z9tGbsMz13ExQy50WZS9n4XRxglyDRga1fQVwGNF+SMPaBzQapiFi3CkBWNSdz+f aRdkdiqIvG3hxkbk6AXr6xhlu2mvnhJ/dE248lZDmN3FkWDHXEgEd5uHxwd7nWjxXVuzRV0oNgrG E96uTqLHVsdefHplPwyrIlgV4SY1ST1y8nKhZlB4IX8fDIj1Xr3rRssW+8XEKSILvawoU47n34x6 xZrO8nbramu3s3BPDnPBe5d1akBYA/nTKb9l6by6dNzJ7u1r73w7/tC53Hgf+826w6Gw+Z6Xs1d2 6RvukJ+7VCyKTR+rg+jASrfhS7naerxVMoOZwr6GxqqHYbK1gp3ag8Ek1U62/LYLqbvYMn58e23k q1pR6vLfQY4AhteMJipLmkxioYjHMCm9rTCZCnU2e/yvNNGXXq8WEeJpAc7hXbFR8L7VTaawkSxg jtJ2YTLvGH0cM/lEOAn3UGUG1lAhBBBzpLS4oW+ITZ5LsPWx2UiWAHLF79XE+PzvFE1+haf4HzJ0 KNKizMaj6DyVJN/oLOvdlVn32x70hCkr9zPFM6f4wEtQoY+qV3Q13zB7FePumyia5+/xmioObwts MYICrjCCAqoCAQEwXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmlt MSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwCQYFKw4D AhoFAKCCAaYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMDAy MTg0NzM5WjAjBgkqhkiG9w0BCQQxFgQUBeIWJgR8aLcGKvvC7Vrk3kDRMVAwZwYJKoZIhvcNAQkP MVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwbQYJKwYBBAGCNxAEMWAwXjBQMRMw EQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vi b3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwbwYLKoZIhvcNAQkQAgsxYKBeMFAxEzAR BgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBTdWJv cmRpbmF0ZSBDQSBNQ0EwM1lLRgIKF9gJ6QADABfFMjANBgkqhkiG9w0BAQEFAASBgK30W/Yqn/Gl s72j5TFY4J/Kv2pJflnHl23U8YNpBeg1ZwaNzTc5fiPwCQBzwrn2YKMa7sbp/yvQeICUiEmyQhpJ iWc4QJ6gD7JjA8Qdq6HxDrCSXmJfCzKZEdIOWqgQXjo7j78rdMXHIXXEct8EuuZHUs5VHrvCezBF 166Ay3JUAAAAAAAA ------=_NextPart_000_0149_01CEBF7E.57834BD0-- --===============0092626920== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --===============0092626920==-- From schoen@eff.org Wed Oct 2 12:18:25 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1824421F9FC3 for ; Wed, 2 Oct 2013 12:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juDIly0tZd0R for ; Wed, 2 Oct 2013 12:18:14 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [64.147.188.12]) by ietfa.amsl.com (Postfix) with ESMTP id CED9C21E809D for ; Wed, 2 Oct 2013 12:02:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=kkE/T5d3TVWIDzy+vgsBU2Jh3vv+bC7ov42S5zCVV8g=; b=fJvGcGElI7Y2C8J1OhHUEjK1KUlVv6iW5uIIkY7k4sbL5X/r/jE/adqzDqkIw4iKYXRV7sEk3x4F00urvjtn/5vThTNzpHlNUO9UmxCJPQsT5gatGhBd/sjQUVbAhx0L; Received: from localhost ([127.0.0.1]:43360 helo=sescenties) by mail2.eff.org with esmtp (Exim 4.80) (envelope-from ) id 1VRRgW-0006KI-Vn for tls@ietf.org; Wed, 02 Oct 2013 12:02:09 -0700 Date: Wed, 2 Oct 2013 12:02:09 -0700 From: Seth David Schoen To: tls@ietf.org Message-ID: <20131002190209.GN2532@sescenties.(null)> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [TLS] Downgrade prevention with authenticated list of ciphersuites? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 19:18:25 -0000 I'm wondering if there's any existing proposal for a mechanism to prevent ciphersuite downgrade attacks by authenticating the list of ciphersuites offered by a TLS server. One way to do this might be to put the list somewhere in the server's certificate (maybe someone's already specified a way to do so?), like a "subject offered ciphersuites list". The advantage of this is that a network attacker -- I think -- can't downgrade the connection to a less secure ciphersuite* than the most secure one supported by both ends (unless they can also cause misissuance of a certificate). The disadvantage is an extreme decrease in the flexibility of server configuration for a system administrator, because they need to get certs reissued in order to make changes to the ciphersuite list, at least if they want certain kinds of changes to have any effect. And it provides another way for connections to fail due to a misconfiguration. It seems like this policy would have good backward compatibility properties if the extension conveying this information is not marked critical. If a client doesn't understand the list, it ignores it and is just as vulnerable as today. If it does understand the list, it always uses what it regards as the most secure ciphersuite that's supported by both ends. * However, as Daniel Gillmor pointed out to me, they can still cause other kinds of non-ciphersuite-related downgrades (like a TLS protocol version downgrade) that could have security consequences that are as bad or worse. -- Seth Schoen Senior Staff Technologist https://www.eff.org/ Electronic Frontier Foundation https://www.eff.org/join 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x107 From agl@google.com Wed Oct 2 12:34:35 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D616C21F8B4E for ; Wed, 2 Oct 2013 12:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeVJ3c53fpzI for ; Wed, 2 Oct 2013 12:34:28 -0700 (PDT) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9A47521F9767 for ; Wed, 2 Oct 2013 12:23:02 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id jx11so968848veb.21 for ; Wed, 02 Oct 2013 12:23:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hjtezSU+5y9FR9L6P14s0aqwDALN5WDrMxsCOUu6nDw=; b=RadQrtoA/lfnp82S5vGh7kKAe7ZYwRq/vt4p3QWKPQSbHS1R0aJxxZ4bBqoZMfrXRo t+XDzydjnH32kwtLMamm1Y09+Vx/VCKnbfqB8mG3VM0oVJLis68tBLwVBQF2IQae5g8p P7tusgeOffpsWEHor81GaEQcsNFZvl6ZlCJA8GVR2noWCFhJZj6U60JRuG6/QsXFIrHV eCPYZDo1jpWB5rZ+IJvvaqKjQX9pzhK7YewGNCApp5DRPzdowensGwbGllkENPblMAu2 3+AgK3hTQpWoZQ46UEj28ppVzFV6Qn9ZxOC5U16mBfDNj9ZyBV/Turb+o+2Bo+LETwU8 QLpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=hjtezSU+5y9FR9L6P14s0aqwDALN5WDrMxsCOUu6nDw=; b=H5RiOi8E6VbEZXBgIjBPZPFU+D4e6G7NjzgmCZ8ILrVwD4nDg8P5uuJC8qqpj8Srhi zdAvB26WsA+P/HL5xMd/NNqSGRpaVs/AO8g46xH26lVtYGLXiVheLd79IH3v/PIG6HqT 6j+VrRZwT1NSritcbFVHGJ/Ke/wqsLdWNxoV7UTbLbevj9dj5KoEvjPI8so7O9lePzOd BwmrxalU48UY49hsBLPnqGC0wJVMc2vjZ9J585g7TC5ZX9Qb+qAtzFCF6Sm5Mc80PEpu dwSmg2zC6+dreIGecvTouIIjLq008YEqbbn1dLlKtAAuzEukOoiAdSHvS+Ke1vUUMbs6 TQMw== X-Gm-Message-State: ALoCoQkuZw9rShWh1eszMBy3EqcKERdZsrtB+ivz3Z/Qx3yIcARb0eghPYdQosOo0Ay/Fb/f9ci9bAzfYtYhMp8n/ktFlCwlAaSjkZjzgJvxAYqdW6tJ7xwsXq3wAEeTsbliOI/zrGrTrZ5QxXMGdMNuEBu0uZeuWg2ZdHVXsotEwSDffLIrIX5FWm89xRZxCeGNTytHy7JB X-Received: by 10.58.19.233 with SMTP id i9mr51838vee.36.1380741781619; Wed, 02 Oct 2013 12:23:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.100.40 with HTTP; Wed, 2 Oct 2013 12:22:40 -0700 (PDT) In-Reply-To: <524c7192.8360440a.2d86.ffffdc2bSMTPIN_ADDED_BROKEN@mx.google.com> References: <524c7192.8360440a.2d86.ffffdc2bSMTPIN_ADDED_BROKEN@mx.google.com> From: Adam Langley Date: Wed, 2 Oct 2013 15:22:40 -0400 Message-ID: To: Seth David Schoen Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Downgrade prevention with authenticated list of ciphersuites? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 19:34:35 -0000 On Wed, Oct 2, 2013 at 3:02 PM, Seth David Schoen wrote: > I'm wondering if there's any existing proposal for a mechanism to prevent > ciphersuite downgrade attacks by authenticating the list of ciphersuites > offered by a TLS server. One way to do this might be to put the list > somewhere in the server's certificate (maybe someone's already specified > a way to do so?), like a "subject offered ciphersuites list". TLS already authenticates the ciphersuite lists of both sides in the final Finished messages. Are you worried about misconfigured servers, or False Start, or version fallback causing certain cipher suites to disappear? Cheers AGL From schoen@eff.org Wed Oct 2 14:23:39 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8DA21F949F for ; Wed, 2 Oct 2013 14:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+x1bD58F2Xz for ; Wed, 2 Oct 2013 14:23:28 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [64.147.188.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2C521F991F for ; Wed, 2 Oct 2013 14:23:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=mXFUGwMgoSYg7Wp4Y2z4irBCl8T/SNyIxDeSeydVmzU=; b=VB27RCrRfoN4aEDVmBGx0awVO3qeuoCH6Rafn1AKevXf/CEDZAUQhIQbPOnzdunGyUkSWS+0COfvX1LW/Tbo2zxH6NWG5UcwisZx5T9FvUNzZcV8GKLOW89QqFSuiN1o; Received: from localhost ([127.0.0.1]:46656 helo=sescenties) by mail2.eff.org with esmtp (Exim 4.80) (envelope-from ) id 1VRTsu-0002RK-46; Wed, 02 Oct 2013 14:23:04 -0700 Date: Wed, 2 Oct 2013 14:23:03 -0700 From: Seth David Schoen To: Adam Langley Message-ID: <20131002212303.GO2532@sescenties.(null)> References: <524c7192.8360440a.2d86.ffffdc2bSMTPIN_ADDED_BROKEN@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "tls@ietf.org" Subject: Re: [TLS] Downgrade prevention with authenticated list of ciphersuites? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 21:23:39 -0000 Adam Langley writes: > TLS already authenticates the ciphersuite lists of both sides in the > final Finished messages. > > Are you worried about misconfigured servers, or False Start, or > version fallback causing certain cipher suites to disappear? Nope, I just got confused about the nature of the version downgrade and thought there was _also_ an effectively-unauthenticated transmission of the ciphersuite list. I agree that the Finished message makes my suggestion superfluous! -- Seth Schoen Senior Staff Technologist https://www.eff.org/ Electronic Frontier Foundation https://www.eff.org/join 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x107 From 57756671618275-ietf-tls@sublist.cr.yp.to Wed Oct 2 18:05:41 2013 Return-Path: <57756671618275-ietf-tls@sublist.cr.yp.to> X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D2721F8C0C for ; Wed, 2 Oct 2013 18:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDu7Ivlyi07g for ; Wed, 2 Oct 2013 18:05:30 -0700 (PDT) Received: from mace.cs.uic.edu (mace.cs.uic.edu [131.193.32.224]) by ietfa.amsl.com (Postfix) with SMTP id 44B5921F9EE1 for ; Wed, 2 Oct 2013 18:05:08 -0700 (PDT) Received: (qmail 8310 invoked by uid 1011); 3 Oct 2013 01:05:06 -0000 Received: from unknown (unknown) by unknown with QMTP; 3 Oct 2013 01:05:06 -0000 Received: (qmail 17186 invoked by uid 1001); 3 Oct 2013 01:04:55 -0000 Date: 3 Oct 2013 01:04:55 -0000 Message-ID: <20131003010455.17185.qmail@cr.yp.to> From: "D. J. Bernstein" To: tls@ietf.org Mail-Followup-To: tls@ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> <20130926152757.15842.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDB49B@XMB116CNC.rim.net> <20130928223648.1113.qmail@cr.yp.to> <20130929025714.5578895.47771.4422@certicom.com> <20131001143511.11010.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE21E@XMB116CNC.rim.net> <20131002161944.8125.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE90F@XMB116CNC.rim.net> Subject: Re: [TLS] Safe ECC usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 01:05:41 -0000 We're hypothesizing an attack A that isn't publicly known, and considering the following probabilities: Pr[A succeeds against a NIST P-256 user]; Pr[A succeeds against a brainpoolP256r1 user]; Pr[A succeeds against a Curve25519 user]. NSA had considerable power to manipulate the NIST P-256 curve choice and thus, at least potentially, the first probability. Under a wide range of reasonable assumptions on A this would allow NSA to create a very high first probability. There's far less room for Brainpool manipulation, although still some (why SHA-1? why not right to left? why pi instead of e or sqrt(2)? and so on), maybe enough to exploit. There's essentially zero room for Curve25519 manipulation. We have no basis for comparing the probabilities outside the case of manipulation. Perhaps Pr[A succeeds against a brainpoolP256r1 user] < Pr[A succeeds against a Curve25519 user], but there's zero justification for this guess. Perhaps Pr[A succeeds against a brainpoolP256r1 user] > Pr[A succeeds against a Curve25519 user], but there's also zero justification for this guess. This is wild speculation, completely divorced from rational risk management. Dan Brown writes: > a proof that Brainpool are invulnerable to the "missed attack" with > probability equal to the density of the vulnerable curves There is no such proof, and there never will be any such proof. I hope you're not trying to bamboozle the innocent reader with bogus claims of provability! But that's not the big issue here. The big issue is that, even in a fantasy world of proving the (rather implausible) statement Pr[A succeeds against a brainpoolP256r1 user] = Pr[A succeeds against a user of a random curve], we still wouldn't have any basis for comparing the Brainpool and Curve25519 probabilities. You claim that Pr[A succeeds against a user of a random curve] < Pr[A succeeds against a Curve25519 user] but you have zero justification for this claim. One could just as well claim the opposite, namely that Pr[A succeeds against a user of a random curve] > Pr[A succeeds against a Curve25519 user], which would also have zero justification. Maybe big coefficients are more secure than small coefficients, but maybe they're _less_ secure. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago From pgut001@cs.auckland.ac.nz Thu Oct 3 05:25:48 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA23021F9DCA for ; Thu, 3 Oct 2013 05:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPkdWdBlZzNW for ; Thu, 3 Oct 2013 05:25:25 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 1C02E21F9B03 for ; Thu, 3 Oct 2013 05:23:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1380802995; x=1412338995; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=XIRYouOx0qVjM0w4viLIxvOXK77ZFpydJefwoqJLR1s=; b=oOxV6RSOtB8fOrKuD+xaNW4+rI77T/CPYtbf4DNzYOcBVyt2JG/MZ+C7 H1or29K8w4AHnpCHH/f72Y2Vza4RD0TKxMmnlepoJ6UKkf318eJNSaFXD HAVgzQJVcEJeEgcbcDh5axwAOUnwpdGeqykh3FDDhydZtlwzskwz4txO0 o=; X-IronPort-AV: E=Sophos;i="4.90,1026,1371038400"; d="scan'208";a="215727079" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 04 Oct 2013 01:23:12 +1300 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.92]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Fri, 4 Oct 2013 01:23:12 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] Safe ECC usage Thread-Index: Ac7AM1NsVidsxPpMS3Sq7adPe9QRGg== Date: Thu, 3 Oct 2013 12:23:11 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7355681240@uxcn10-6.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Safe ECC usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 12:25:48 -0000 Santosh Chokhani writes:=0A= =0A= >Simply copying RSA template and thus the key usage bits should not yield t= he=0A= >behavior you mention. RSA certificates should set the key encipherment bi= t.=0A= >EC type certificates should not set that bit; the appropriate bit is key= =0A= >agreement.=0A= =0A= My code, in its default configuration, strictly enforces keyUsage. From th= is=0A= I've found that both applications and CAs can set these bits more or less a= t=0A= random, including completely illogical settings like keyAgreement for RSA= =0A= keys. I've also found, through trial-and-error, that many applications=0A= completely ignore them and use the keys in whatever way they feel appropria= te=0A= (the situation for PKCS #12 files in particular is so bad that after fighti= ng=0A= it for awhile I had to turn off checking of keyUsage entirely). So this is= n't=0A= a case of copying an RSA template, it's broken software generating them and= =0A= equally broken software ignoring them.=0A= =0A= Peter.=0A= From dbrown@certicom.com Thu Oct 3 07:45:06 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAE921E8054 for ; Thu, 3 Oct 2013 07:45:06 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnE+FtOWypQi for ; Thu, 3 Oct 2013 07:44:54 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 9608C21E80A7 for ; Thu, 3 Oct 2013 07:37:13 -0700 (PDT) Content-Type: multipart/mixed; boundary="===============1490163058==" MIME-Version: 1.0 Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs212cnc.rim.net with ESMTP/TLS/AES128-SHA; 03 Oct 2013 10:37:07 -0400 Received: from XCT116CNC.rim.net (10.65.161.216) by XCT105CNC.rim.net (10.65.161.205) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 3 Oct 2013 10:37:07 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT116CNC.rim.net ([::1]) with mapi id 14.03.0123.003; Thu, 3 Oct 2013 10:37:06 -0400 From: Dan Brown To: "'djb@cr.yp.to'" , "'tls@ietf.org'" Thread-Topic: [TLS] Safe ECC usage Thread-Index: AQHOv9SSxn3XJXmgAkKRAg2ZE6kwf5ni98AQ Date: Thu, 3 Oct 2013 14:37:06 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF5BDECA6@XMB116CNC.rim.net> References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> <20130926152757.15842.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDB49B@XMB116CNC.rim.net> <20130928223648.1113.qmail@cr.yp.to> <20130929025714.5578895.47771.4422@certicom.com> <20131001143511.11010.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE21E@XMB116CNC.rim.net> <20131002161944.8125.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE90F@XMB116CNC.rim.net> <20131003010455.17185.qmail@cr.yp.to> In-Reply-To: <20131003010455.17185.qmail@cr.yp.to> Accept-Language: en-CA, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] MIME-Version: 1.0 Subject: Re: [TLS] Safe ECC usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 14:45:06 -0000 --===============1490163058== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_014E_01CEC024.7FCC3C90" ------=_NextPart_000_014E_01CEC024.7FCC3C90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit D. J. Bernstein writes: > > We're hypothesizing an attack A that isn't publicly known, and > considering the following probabilities: > > Pr[A succeeds against a NIST P-256 user]; > Pr[A succeeds against a brainpoolP256r1 user]; > Pr[A succeeds against a Curve25519 user]. > > NSA had considerable power to manipulate the NIST P-256 curve choice > and thus, at least potentially, the first probability. Under a wide > range of reasonable assumptions on A this would allow NSA to create a > very high first probability. > > There's far less room for Brainpool manipulation, although still some > (why SHA-1? why not right to left? why pi instead of e or sqrt(2)? and > so on), maybe enough to exploit. There's essentially zero room for > Curve25519 manipulation. Agreed. Good point. Alternatively, it is also reasonable to assume that NSA knows of an attack A but is unwilling to reveal it, and manipulated P256 to avoid A, by methods that they do not wish to reveal. The prudence principle, assume that worst, means your pessimistic assumptions merits addressing more than this alternative optimistic assumption. > > We have no basis for comparing the probabilities outside the case of > manipulation. Perhaps > > Pr[A succeeds against a brainpoolP256r1 user] > < Pr[A succeeds against a Curve25519 user], > > but there's zero justification for this guess. Perhaps > > Pr[A succeeds against a brainpoolP256r1 user] > > Pr[A succeeds against a Curve25519 user], > > but there's also zero justification for this guess. This is wild > speculation, completely divorced from rational risk management. Agreed. I don't think I said this. > > Dan Brown writes: > > a proof that Brainpool are invulnerable to the "missed attack" with > > probability equal to the density of the vulnerable curves > > There is no such proof, and there never will be any such proof. I hope > you're not trying to bamboozle the innocent reader with bogus claims of > provability! > > But that's not the big issue here. The big issue is that, even in a > fantasy world of proving the (rather implausible) statement > > Pr[A succeeds against a brainpoolP256r1 user] > = Pr[A succeeds against a user of a random curve], Well, I thought I prefaced my claim that you quoted above with an "if" clause, something like we assume that we can trust verifiably pseudorandom generation. I had in mind something like random oracle model proof. Since you say there will never be such a proof, I am reconsidering what I thought, and pondering why you say that. Hmm. I don't think you are talking about posterior probabilities, which are available to the parties who know A and to which I am not claiming any kind of proof, argument or anything. That is, I was thinking about prior probabilities, given the fact that we don't know A, and that we are specifically discussing unknown A. If you are saying that random oracle model proofs do not apply to that real world, then you are right that I did not present anything like a standard model proof. I was wrong for implying such a thing. But, you also said there will never be such a proof, so I am rather puzzled. Maybe I am missing a factor in the equality, even in a random oracle proof, because as you noted, even the Brainpool seeds are mildly subject to manipulation. Anyway, you say it's not a big issue, and introduce a fantasy world or proving that claim. Anyway, I am still inclined to interpret the Brainpool phrase "verifiably random" as claiming more that non-manipulability. It seems to suggest some form of justifiable indistinguishabilty to a random curve. This may only be a heuristic argument, but at least it some kind of argument. > > we still wouldn't have any basis for comparing the Brainpool and > Curve25519 probabilities. You claim that > > Pr[A succeeds against a user of a random curve] > < Pr[A succeeds against a Curve25519 user] > > but you have zero justification for this claim. One could just as well > claim the opposite, namely that > > Pr[A succeeds against a user of a random curve] > > Pr[A succeeds against a Curve25519 user], > > which would also have zero justification. Maybe big coefficients are > more secure than small coefficients, but maybe they're _less_ secure. > Agreed. Zero justification. Prudence principle: assume the worst, so choose the < inequality for Curve25519. I think we should continue to assume the worst, even if it is wild speculation, and then address it as best as possible. The Brainpool curves have some kind of justification, albeit maybe not a full-fledged proof. In other words, to me, the Brainpool approach presents some kind of best-we-can-do-effort to resist attacks not yet known to us. I think P256 would do this too, except for the special field, and more importantly, the unexplained seeds. I would be quite surprised if the US gov publicly recommended, via FIPS 186-2, that its agencies use EC curves that could be affected an attack A. I find it very hard to think how the US gov could be sure that other skilled adversaries could not find the attack A. The only thing I can think of, is if a trapdoor key was embedded in P256, but that seems to imply some kind of the weakness in sha1 or the verifiable key generation process, because such a key would have require sufficient entropy for third parties to guess, rendering the hash-generic exhaustive search approach to manipulation infeasible. Anyway, the advantage for Brainpool over Curve25519 is slight, and hypothetical, and may be offset by Curve25519's many other benefits, e.g. efficiency, simple and short implementation. ------=_NextPart_000_014E_01CEC024.7FCC3C90 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUgTCCBnAw ggVYoAMCAQICChfYCekAAwAXxTIwDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAz WUtGMB4XDTEzMDUyODE1NDQwOVoXDTE0MDUxNzAwMjMzM1owgYUxEzARBgoJkiaJk/IsZAEZFgNu ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xETAPBgNVBAsTCENlcnRpY29tMQ4wDAYDVQQLEwVVc2Vy czESMBAGA1UEAxMJRGFuIEJyb3duMSIwIAYJKoZIhvcNAQkBFhNkYnJvd25AY2VydGljb20uY29t MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDRc70RE0/FL9ZbfN64YjA0lkQOLR9ipGebc9nH jB93OfYfR7CVsCUYy3+v9PO1DiUS9MeWWR4nxB9Ztee32d3syDxGg3PGFwSrms/ORAW9pgiS/yKH An9SKRKyqMz9LSn/VQrEgoyPBPT0S/vg521MGH58MwMXyLm1cLBQU5gtCQIDAQABo4IDmDCCA5Qw CwYDVR0PBAQDAgWgMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQME AgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUAlQmTNpWxnzoCUVjxGTtDz2JvLww FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMB8GA1UdIwQYMBaAFLgwF25vZ5X+hYxoO6XhF7M/+CU6 MIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiGgctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu YXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1NQ0EwM1lLRixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIw U2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2Fs P2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRp b25Qb2ludIZIaHR0cDovL21jYTAzeWtmLnJpbS5uZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRp bmF0ZSUyMENBJTIwTUNBMDNZS0YuY3JsMIIBQQYIKwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUH MAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1BSUEs Q049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixE Qz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZp Y2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxodHRwOi8vbWNhMDN5a2YucmltLm5ldC9DZXJ0 RW5yb2xsL01DQTAzWUtGLnJpbS5uZXRfUklNJTIwU3Vib3JkaW5hdGUlMjBDQSUyME1DQTAzWUtG KDMpLmNydDApBgNVHSUEIjAgBgorBgEEAYI3CgMEBggrBgEFBQcDBAYIKwYBBQUHAwIwQQYDVR0R BDowOKAhBgorBgEEAYI3FAIDoBMMEWRhbmlicm93bkByaW0ubmV0gRNkYnJvd25AY2VydGljb20u Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQC6hxWgDv96DUDS3m8XfyVGAv1CKOcWSVOShz/jofFMFzoN o2dhc0Jg9XTTZBVS+ozakEM+87YUENfP3IODRbCiJBsbiXJxS+fVo7L/bqPp47TB+Lg2/tezlNa2 ab4psmc9xjZGU9+A4lBzS5PpRjvHofsIwETpwt/aPxHIbJ5Cf7kBi7B8hR4mIqc7EJMYXeI0xHLg k3NqBYSGC3XtbykuFV0vPFoTYLO7G3pAP2RzGhuxQoaH4fpWvE3rdakjd1MZFqJrarXSvWi6ah6G Alt7+sOTzlGNqoTQqb55VZEOrU2A1VbmAFjiFR1/229A2KaHhnN6cuNe8bhzoBcnuxtyMIIGvzCC BKegAwIBAgIQMhrzkrEUWZRNTS+VEbN74TANBgkqhkiG9w0BAQUFADBPMRUwEwYKCZImiZPyLGQB GRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBN Q0EwMVlLRjAeFw0wNjEwMTMwMTI0NTVaFw0xNjEwMTMwMTMwNDFaME8xFTATBgoJkiaJk/IsZAEZ FgVsb2NhbDEXMBUGCgmSJomT8ixkARkWB3dpbmRvd3MxHTAbBgNVBAMTFFJJTSBSb290IENBIE1D QTAxWUtGMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAxui6zvytVAEtPzv6NhK7OZna iw/jQEyEVskDf5yzcFkLT/+5PztIbv+eFmL1CP2FhvLv8eQZJDKF4Yv+UsjPEN1lX4DDGKKt0NPp yT9pwQzFaiUt0rnERgSabo7EtpS4S+DuL8G9c+lmWwDqb0UWtPMdVfbr3fDwigyz1yh+vVMAHdhg Oe9lPC6nPtiJ9IXTam7V5mJmDT0mNpq/0fJo3JEaNvDKoXBOkKv6IdbtKxKzPInG6VYaCdgJCAT3 mWgr9kxiEQEUJKrvI2fXI0zRYnlL648gvK84pdsT2xZLFtr4OdZAm4RkK8U+cgurlSCr6NVqnfbq 6/3N6MGmyc9SB2Ayhk2VS66757V4nBzeaeD+srpk4IXU3NTM/+YgR1zVS41XwvZaq9Uf59j0TJhN 9xGVZO871eVVr2VfNxr0xOqUpwcxh5JZYkWcmUJFlYiQh0CM2PrfaDRTTqRZQd4F3xUlcXFAXOGh vaXKvikeI6/utnX6vCnDwMUxmenzlv8epNatxDsuIgOWO4pfqgGMyzWo2hudQ97+5ynUqDLX34nr UzszGeIE3KoqYsksxMF3tqIgadt9hNWXaP/EknZpRAmaP0s0V5ZvgiyXw9UrqnWwmRbLQk7HnYc0 hHQBjXoByKSiOyhgSS9yL6a+7AA2rhBPpsSVI9LYBs2cNKlPsZcCAwEAAaOCAZUwggGRMBMGCSsG AQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTW aYJkJBbBzCTb8RR9RxJ83MlN7jCCASkGA1UdHwSCASAwggEcMIIBGKCCARSgggEQhoHEbGRhcDov Ly9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1NQ0EwMVlLRixDTj1DRFAsQ049UHVi bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5k b3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1j UkxEaXN0cmlidXRpb25Qb2ludIZHaHR0cDovL21jYTAxeWtmLndpbmRvd3MubG9jYWwvQ2VydEVu cm9sbC9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwDQYJ KoZIhvcNAQEFBQADggIBAEOeWFu4OVTnx9+jYk92iDra2f1Bc5j1WesEGINl4VCY9WJy6n17b/h2 fDmjj9KfIto3LE2Wej77lSJqv/LSd7wnfTQVZVb1wBe2Zt+LuPAqi6vWSDAQVOfdOMYVu5imznnf +ZNMLduTqXZ/bFQKTWsg2qhBWwaiYfxEY7nVg3+ZfStqwc9R3v/tHH+b9kX3FuKLoVQ6KSrqUyBi fhIRj57eOw6/JjPA+SId/p2yEZ+xmANQ31vE3BHFRm20kZHHqAfdCmTt1S7LDSLHBj3GZXIFUge9 aPKqzAXee2DCYTP3YYcgrP/FbFF2RqGRIhPM+MdjJraMjex+nNT+2KC/EIWsbU9DgFII0wHKpRx8 rlJNN8kmb/H9qGqcNaW9Q/pwUTpX1bXSdbzvYFs3NY7KmYYii4Q0RQCGr96OvDT0/S6/IrnW+vqZ jnPV2MXqEuyQ0L5HXVOnCi769uGYcRkEo5xzEJ/EMvj07vCWnG7h9ykNhLEEMcygVmBdXP9qOqog dyPJB0AzxAYGqCSMT8Ors1M/srZSXUCfSfENH5iBd7bxH7uXmF7kbOEghom7AccC2Clt4DU0tj9s FyIWg5H6zy6NLetm2/kzdD3mGY3u2tWtijVnd2CWY2YszYo1lbDAfEfjGL/9uFpH79Zt9ekRSD5Z bSn1SNr1njjeGpV3jwyuMIIHRjCCBS6gAwIBAgIKFnKQQQAAAAABuDANBgkqhkiG9w0BAQUFADBP MRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQD ExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjAeFw0xMjA1MTcwMDEzMzNaFw0xNDA1MTcwMDIzMzNaMFAx EzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBT dWJvcmRpbmF0ZSBDQSBNQ0EwM1lLRjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfx jFzEuYa/qd6dXu4HILtBdH3+Bgwz3uQakDcxvrf3fyVQBy69KFOS8/h5REe6bit3tp5wsQQv/nFV mmXK/jq9zD72zl3jv63UzZgOWC90846UxTTmmNEyHzo1M54B3LrnE6L2Q6QbEZMAnrJ96uV8pN2X Zsn5j+MvfI5ajFu+6oPbHeYzQjZB3GDju7sELm7cAcr0YYX3xeLTB2rLUUZF6Nyyc0btD57ARYEa 99A+6JslO8VcxtlgRddx17NB6gttNjwmJFT3l3UVcK5O5+UVSWpW1zQbZQBvl0iP7gXcrJW4Dv0p 036iHg9lgDV1qQChi9NCixwm7yYtCHLq9akCAwEAAaOCAyEwggMdMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFLgwF25vZ5X+hYxoO6XhF7M/+CU6MAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEE AwIBAzAjBgkrBgEEAYI3FQIEFgQUZUBVml3ak56Kwnbul6AULvNdck8wGQYJKwYBBAGCNxQCBAwe CgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNVHR8EggEg MIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Ys Q049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRp b25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6Ly9tY2Ew MXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Yu Y3JsMIIBPAYIKwYBBQUHAQEEggEuMIIBKjCBuwYIKwYBBQUHMAKGga5sZGFwOi8vL0NOPVJJTSUy MFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRvd3MsREM9bG9jYWw/Y0FDZXJ0aWZp Y2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwagYIKwYBBQUHMAKG Xmh0dHA6Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvTUNBMDFZS0Yud2luZG93 cy5sb2NhbF9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcnQwDQYJKoZIhvcNAQEFBQADggIB AK/ZTtcAxFAZJo37z0KG3EGIGIScPRus90jBJGQO9+Mrb4QRoMjkCwZP9GbYq2CxCqOBiKOZfkSK PMSupPLRlE70z9tGbsMz13ExQy50WZS9n4XRxglyDRga1fQVwGNF+SMPaBzQapiFi3CkBWNSdz+f aRdkdiqIvG3hxkbk6AXr6xhlu2mvnhJ/dE248lZDmN3FkWDHXEgEd5uHxwd7nWjxXVuzRV0oNgrG E96uTqLHVsdefHplPwyrIlgV4SY1ST1y8nKhZlB4IX8fDIj1Xr3rRssW+8XEKSILvawoU47n34x6 xZrO8nbramu3s3BPDnPBe5d1akBYA/nTKb9l6by6dNzJ7u1r73w7/tC53Hgf+826w6Gw+Z6Xs1d2 6RvukJ+7VCyKTR+rg+jASrfhS7naerxVMoOZwr6GxqqHYbK1gp3ag8Ek1U62/LYLqbvYMn58e23k q1pR6vLfQY4AhteMJipLmkxioYjHMCm9rTCZCnU2e/yvNNGXXq8WEeJpAc7hXbFR8L7VTaawkSxg jtJ2YTLvGH0cM/lEOAn3UGUG1lAhBBBzpLS4oW+ITZ5LsPWx2UiWAHLF79XE+PzvFE1+haf4HzJ0 KNKizMaj6DyVJN/oLOvdlVn32x70hCkr9zPFM6f4wEtQoY+qV3Q13zB7FePumyia5+/xmioObwts MYICrjCCAqoCAQEwXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmlt MSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwCQYFKw4D AhoFAKCCAaYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMDAz MTQzNzAzWjAjBgkqhkiG9w0BCQQxFgQU6s+xK2eKX/MQ3PWMIdvJlj2Gg/8wZwYJKoZIhvcNAQkP MVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwbQYJKwYBBAGCNxAEMWAwXjBQMRMw EQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vi b3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwbwYLKoZIhvcNAQkQAgsxYKBeMFAxEzAR BgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBTdWJv cmRpbmF0ZSBDQSBNQ0EwM1lLRgIKF9gJ6QADABfFMjANBgkqhkiG9w0BAQEFAASBgA5xzvubqADy MUoI60bP2Z1DTVHu+Gcp6dtMJ/MH1aRscwwcOJOlCT2CPaQHiHef/BJr3eLOoFGfTCfzYXdBVs8o o0TilkTDhqTIaeT1wt89SvwYTutZ50dLxBrhaoly3iZlszD8rWmB9heztgFpZzJQOd/ij4HINgsL d2hbHyXyAAAAAAAA ------=_NextPart_000_014E_01CEC024.7FCC3C90-- --===============1490163058== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --===============1490163058==-- From Johannes.Merkle@secunet.com Fri Oct 4 05:29:46 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87C321F9BC1 for ; Fri, 4 Oct 2013 05:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uav8Kro4jtbr for ; Fri, 4 Oct 2013 05:29:35 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 40EF421F8C65 for ; Fri, 4 Oct 2013 05:18:39 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id D39291A0084; Fri, 4 Oct 2013 14:18:37 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id E5KPun0O_qg2; Fri, 4 Oct 2013 14:18:36 +0200 (CEST) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id BA7C31A0083; Fri, 4 Oct 2013 14:18:36 +0200 (CEST) Received: from [10.208.1.57] ([10.208.1.57]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Oct 2013 14:18:37 +0200 Message-ID: <524EB21C.6050606@secunet.com> Date: Fri, 04 Oct 2013 14:18:36 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Dan Brown References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> <20130926152757.15842.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDB49B@XMB116CNC.rim.net> <20130928223648.1113.qmail@cr.yp.to> <20130929025714.5578895.47771.4422@certicom.com> <20131001143511.11010.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE21E@XMB116CNC.rim.net> <20131002161944.8125.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE90F@XMB116CNC.rim.net> In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5BDE90F@XMB116CNC.rim.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2013 12:18:37.0096 (UTC) FILETIME=[DA3B3280:01CEC0FB] Cc: "'djb@cr.yp.to'" , "'tls@ietf.org'" Subject: Re: [TLS] Safe ECC usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 12:29:46 -0000 > random prime instead of a special one incurs a computational cost. So, I > think I was reasonable to infer that Brainpool was implying that special > fields were lacking in security. (The implication against special values > may then be inferred further.) The primes used by NIST curves are so special that there is less room for suspicion of a backdoor in the primes than in the curve. Our main concern with the special primes used by NIST curves is that their special form requires more caution to harden your arithmetic against side-channel attacks. As a matter of fact, Sakai & Sakurai, for instance, have proposed power analysis attacks targeting arithmetic on Pseudo-Mersenne primes. And we don't know, if the NSA has developed improved side-channel attacks against ECC over such fields. As I understand, the Curve25519 papers address side-channel immunity by specifying an eligible arithmetic. No objection to that approach, but for the Brainpool curves we had a different one. Another aspect was that we avoid many patents by not using Pseudo-Mersenne primes. Johannes From rstruik.ext@gmail.com Fri Oct 4 06:09:59 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F6121F9DCE for ; Fri, 4 Oct 2013 06:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rAeGdtSEKUM for ; Fri, 4 Oct 2013 06:09:51 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB0221F92CD for ; Fri, 4 Oct 2013 05:57:53 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id ar20so9041027iec.32 for ; Fri, 04 Oct 2013 05:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=WEruhJNBsodI3digq5mt2LkuZBIUSe3hq6ujfn8XmBo=; b=Wb1dVIQYMhYpDLBio5fnZdaCGYv750wQX/ooeIah3vlLFie2PyPMmIO1ehupoywzUw HpSOX4wBx5MGUZQWfZ7b/oN4K08l0kG9wZRnClO9TJugMN9GsXvwWFP7apWFuk/9jZNk jiTbS+eoZnxRLguYrXr/ToFTtMkYAcgKNgF2r3TPOMbDAAf0VXUhgT6CjQXVhF/yLH97 xp7H8zYzAH5lEJcDBkV6f9pusxuRbX1m0CKuII6Hxf3MGP6N40n7BfOPs/yZ5cmNBox8 WLTJxf64CCKl6lr5G03eTmmo79GCffGl3yTVFFAeXkh5dM/yJ30tAISJ2u/xUkDcRCry yHcQ== X-Received: by 10.43.60.139 with SMTP id ws11mr8581223icb.12.1380891472006; Fri, 04 Oct 2013 05:57:52 -0700 (PDT) Received: from [192.168.1.102] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.230.254.17]) by mx.google.com with ESMTPSA id ri1sm6663699igc.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 04 Oct 2013 05:57:51 -0700 (PDT) Message-ID: <524EBB48.1050807@gmail.com> Date: Fri, 04 Oct 2013 08:57:44 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Johannes Merkle References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> <20130926152757.15842.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDB49B@XMB116CNC.rim.net> <20130928223648.1113.qmail@cr.yp.to> <20130929025714.5578895.47771.4422@certicom.com> <20131001143511.11010.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE21E@XMB116CNC.rim.net> <20131002161944.8125.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE90F@XMB116CNC.rim.net> <524EB21C.6050606@secunet.com> In-Reply-To: <524EB21C.6050606@secunet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'tls@ietf.org'" Subject: [TLS] (offline note) Re: Safe ECC usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 13:09:59 -0000 [offline note] Hi Johannes: Thanks for your note. I presume you refer to the paper: Side Channel Analysis - Simple Power Analysis on Fast Modular Reduction with ECC over Generalized Mersenne Primes (Yasuyuki Sakai, Kouichi Sakurai, IEICE Trans.Fund., 2006) I am glad you refer to side channel resistance and implementation attacks, an often undershed aspect of security discussions (certainly in standardization bodies). The paper suggests the need to weed out conditional branches, as are also a problem in other implementation attacks. Do you think that modular reductions with NISTp curves are generally hard to secure, or just the naive and well-documented approach? I would be curious if you have some data that delves on this with Brainpool curves. {As an example, if one uses Barrett reduction (Alg. 2.14 of Guide to ECC book), one has a conditional branch as well. This being said, this can be massaged away.} As to patents: for basic scalar multiplication, this era should be nearly over, if one discards implementation attacks; if one doesn't, it does not seem to, though. Best regards, Rene On 10/4/2013 8:18 AM, Johannes Merkle wrote: >> random prime instead of a special one incurs a computational cost. So, I >> think I was reasonable to infer that Brainpool was implying that special >> fields were lacking in security. (The implication against special values >> may then be inferred further.) > The primes used by NIST curves are so special that there is less room for suspicion of a backdoor in the primes than in > the curve. > > Our main concern with the special primes used by NIST curves is that their special form requires more caution to harden > your arithmetic against side-channel attacks. As a matter of fact, Sakai & Sakurai, for instance, have proposed power > analysis attacks targeting arithmetic on Pseudo-Mersenne primes. And we don't know, if the NSA has developed improved > side-channel attacks against ECC over such fields. > > As I understand, the Curve25519 papers address side-channel immunity by specifying an eligible arithmetic. No objection > to that approach, but for the Brainpool curves we had a different one. > > Another aspect was that we avoid many patents by not using Pseudo-Mersenne primes. > > > > Johannes > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 From wtc@google.com Sat Oct 5 08:37:04 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F256321F90FD for ; Sat, 5 Oct 2013 08:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nZuW0ul2GYy for ; Sat, 5 Oct 2013 08:37:02 -0700 (PDT) Received: from mail-vb0-x22a.google.com (mail-vb0-x22a.google.com [IPv6:2607:f8b0:400c:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 8709821F84F8 for ; Sat, 5 Oct 2013 08:37:02 -0700 (PDT) Received: by mail-vb0-f42.google.com with SMTP id e12so2930358vbg.1 for ; Sat, 05 Oct 2013 08:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lq2cf76+GZPLcY3hicvKUbdl6zSDNqJ3ehDiOW6oVtM=; b=d5lsqe8BGXk7AAd4h0CS41QiufHcoTRmO6ov2N3CL5ZpNjrSqvcbxy+wMWwbK5k5mF szIZryOKvQtSt/nvswSGs4cen9MZ5kUjaV3j0+dBllWsyMtXAAZZjpCi8G7zDUCXv1GN vddciXSpPSmvyGYf3X+XF2OnQryf3FTYTq+TN/IACDLqpQzBsAI5u0ZAvBiiDSVR1nzz jxGQTMQ+j9otmwgmE0CGBnthRK4FsqiC3DiAK7hNBK8yxZcJ7zXzwCNDTFAD67fPpIuC PeEKeXjg7NmfoJDImzZYwnVdo/Nb5bzP+1v5n3eLbTgir6OhIpGMCHOU2/t2seZQeSlq GwoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lq2cf76+GZPLcY3hicvKUbdl6zSDNqJ3ehDiOW6oVtM=; b=MxX8W5sj2li2esqGVwgS0ry+AaSRdnV0Ba32hLgslr1b1bzURpzYvQAdl0w20U0sEw fk2kQ3qiZ/EU8yMhU4P9pACDkDRdq0fM/6obfZhVYreUYYGIBPIGk/kPgLkWmVHsHORc RQDlscN5HQgFlUM0CbzgAS/ZUHhtHDIz3/nqdBUskh/BPRicK9zHt4+hh+1Ugw4LoS98 NGqad9A0syVLM7+qI2WyYZ5oSn7ldh2ljIdWKcN5BJM1YUR4E18DWA16qPMq7g45vNU3 b6IU+lLpPcXazLEnoFiadwRnDM6FjwJsQZcISoj0+UzV/UboIwRMPJB7pOLUVhyGSWP7 kUKQ== X-Gm-Message-State: ALoCoQkTOmR+X1uvbi5z4Cx58CUFXgDQP4vw/lXtQbwo9iFyQ6HTHIp/SVqaQTT5+2AxRwqP+bR0fA8zUbqRDvoIJ4nKIKew+FyuKtVzgH5Ypdl84OXGcjzX6SeTypEMmKN28JNAx/Rpab/WLO/O+PEQ+6oWAUA9CYHhGHaxW9/IsneAfyisiHeTPwLA6e/exls/ITYAsUQ9 MIME-Version: 1.0 X-Received: by 10.52.34.109 with SMTP id y13mr15037374vdi.8.1380987421886; Sat, 05 Oct 2013 08:37:01 -0700 (PDT) Received: by 10.52.167.105 with HTTP; Sat, 5 Oct 2013 08:37:01 -0700 (PDT) In-Reply-To: References: Date: Sat, 5 Oct 2013 08:37:01 -0700 Message-ID: From: Wan-Teh Chang To: Adam Langley Content-Type: text/plain; charset=ISO-8859-1 Cc: "tls@ietf.org" Subject: Re: [TLS] ChaCha20 + Poly1305 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 15:37:04 -0000 On Tue, Sep 10, 2013 at 8:22 AM, Adam Langley wrote: > I've just posted a draft defining ChaCha20+Poly1305 cipher suites for > TLS: https://datatracker.ietf.org/doc/draft-agl-tls-chacha20poly1305/ Hi Adam, I just reviewed the -01 draft. I have some comments. The most important comment is about the AEAD construction in Section 5. Section 3. ChaCha20: * Define that <<< means a rotate left shift. * The second paragraph says the block counter is four input words. The last paragraph says the block counter is two input words. * The last paragraph says the nonce (input words 12 and 13) is before the block counter (input words 14 and 15), but http://cr.yp.to/chacha/chacha-20080128.pdf says the block counter is followed by the nonce. Assuming little-endian order, I think it seems better for the block counter to be before the nonce. Section 5. AEAD construction: * In the input for Poly1305, the byte count of the ciphertext is before the ciphertext. I think this should be reversed to allow an implementation to start computing Poly1305 before having all the ciphertext. For consistency, also reverse the order of the byte count of additional data and the addtional data. Section 9. IANA considerations: * We should also ask IANA to assign an AEAD algorithm ID to chacha20poly1305 in its registry http://www.iana.org/assignments/aead-parameters/aead-parameters.xhtml. Wan-Teh Chang From 57756671618275-ietf-tls@sublist.cr.yp.to Sat Oct 5 12:30:19 2013 Return-Path: <57756671618275-ietf-tls@sublist.cr.yp.to> X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23B221F90CF for ; Sat, 5 Oct 2013 12:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=-0.780, BAYES_20=-0.74, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLt5rU5l9V6e for ; Sat, 5 Oct 2013 12:30:15 -0700 (PDT) Received: from mace.cs.uic.edu (mace.cs.uic.edu [131.193.32.224]) by ietfa.amsl.com (Postfix) with SMTP id 2BB0721F90AC for ; Sat, 5 Oct 2013 12:30:11 -0700 (PDT) Received: (qmail 12698 invoked by uid 1011); 5 Oct 2013 19:30:09 -0000 Received: from unknown (unknown) by unknown with QMTP; 5 Oct 2013 19:30:09 -0000 Received: (qmail 27062 invoked by uid 1001); 5 Oct 2013 19:29:50 -0000 Date: 5 Oct 2013 19:29:50 -0000 Message-ID: <20131005192950.27059.qmail@cr.yp.to> From: "D. J. Bernstein" To: tls@ietf.org Mail-Followup-To: tls@ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> <20130926152757.15842.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDB49B@XMB116CNC.rim.net> <20130928223648.1113.qmail@cr.yp.to> <20130929025714.5578895.47771.4422@certicom.com> <20131001143511.11010.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE21E@XMB116CNC.rim.net> <20131002161944.8125.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE90F@XMB116CNC.rim.net> <20131003010455.17185.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDECA6@XMB116CNC.rim.net> Subject: Re: [TLS] Safe ECC usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 19:30:19 -0000 Dan Brown writes: > it is also reasonable to assume that NSA knows of an attack A > but is unwilling to reveal it, and manipulated P256 to avoid A Sure. In BigBrotherLand, the eavesdropper Eve is actually a big fan of the innocent users Alice and Bob, and is helping protect them against hidden weaknesses in their communication system. However, our job as _cryptographers_ is to tell Alice and Bob how to protect themselves against the possibility of _bad_ behavior by Eve. That's why all these ECC standards are advertising the "verifiable" randomness of the NIST curves---they're claiming that the curves are protected against bad behavior by NSA's Jerry Solinas. That's also why people are unhappy to learn that the advertising is false. When we see a protocol that turns out to have Eve as a trusted third party with the power to compromise security, we fix the protocol. We don't say "Well, gee, maybe Eve is actually helping our security." > The Brainpool curves have some kind of justification, albeit maybe not > a full-fledged proof. In other words, to me, the Brainpool approach > presents some kind of best-we-can-do-effort to resist attacks not yet > known to us. No, it doesn't. Maybe an unknown attack is _more_ likely to break brainpoolP256r1 than to break Curve25519. You keep using words like "best" and "prudence" and "advantage"; but you have zero justification for any of this. You keep * misrepresenting brainpoolP256r1 as a random curve and * stating the "random is safer" myth in several different ways; do you not realize that this myth was solidly debunked several years ago? Section 11 of http://eprint.iacr.org/2008/390.pdf presents several clear counterexamples; do you dispute those counterexamples? If you think there's some reason that brainpoolP256r1 is more like the examples where randomness helps security, rather than the examples where randomness hurts security, then you should say what that reason is. You can't simply pretend that the counterexamples don't exist. By the way, I also don't see anything in the Brainpool document along the lines that you're claiming. For example, the document never claims that its primes are more secure than "special" primes; it clearly states that it avoids "special" primes "to avoid patented fast arithmetic." ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago From Andrei.Popov@microsoft.com Sat Oct 5 14:54:44 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E77821F9D89 for ; Sat, 5 Oct 2013 14:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbNzwMoOSkKR for ; Sat, 5 Oct 2013 14:54:40 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0149.outbound.protection.outlook.com [207.46.163.149]) by ietfa.amsl.com (Postfix) with ESMTP id 0B54621F9D0A for ; Sat, 5 Oct 2013 14:54:39 -0700 (PDT) Received: from BL2PR03MB194.namprd03.prod.outlook.com (10.255.230.142) by BL2PR03MB195.namprd03.prod.outlook.com (10.255.230.153) with Microsoft SMTP Server (TLS) id 15.0.785.10; Sat, 5 Oct 2013 21:54:38 +0000 Received: from BL2PR03MB194.namprd03.prod.outlook.com ([169.254.14.243]) by BL2PR03MB194.namprd03.prod.outlook.com ([169.254.14.243]) with mapi id 15.00.0785.001; Sat, 5 Oct 2013 21:54:38 +0000 From: Andrei Popov To: "tls@ietf.org" Thread-Topic: Prohibiting RC4 Cipher Suites Thread-Index: Ac7CFG9LxkQu9pDESLu3yn05kvlxTw== Date: Sat, 5 Oct 2013 21:54:37 +0000 Message-ID: <4dd49b8fbd044133aa16f0200de88134@BL2PR03MB194.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::2] x-forefront-prvs: 0990C54589 x-forefront-antispam-report: SFV:NSPM; SFS:(26614003)(189002)(53754006)(479174003)(377454003)(24454002)(199002)(13464003)(51704005)(80976001)(76482001)(50986001)(81686001)(4396001)(49866001)(76576001)(31966008)(54316002)(69226001)(74502001)(56776001)(47446002)(33646001)(19580405001)(83322001)(56816003)(76796001)(47976001)(76786001)(81816001)(47736001)(77096001)(19580395003)(81342001)(81542001)(76176001)(54356001)(15202345003)(74316001)(53806001)(77982001)(59766001)(65816001)(46102001)(79102001)(80022001)(74366001)(74876001)(63696002)(74706001)(15974865002)(83072001)(74662001)(51856001)(15975445006)(85306002)(557034004)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB195; H:BL2PR03MB194.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ee43::2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Subject: [TLS] Prohibiting RC4 Cipher Suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 21:54:44 -0000 I have submitted v01 of the "Prohibiting RC4 Cipher Suites" draft with the = updated attack description: http://www.ietf.org/internet-drafts/draft-popov= -tls-prohibiting-rc4-01.txt Looking forward to further comments, Andrei -----Original Message----- From: Paterson, Kenny [mailto:Kenny.Paterson@rhul.ac.uk] Sent: Wednesday, August 21, 2013 2:13 PM To: Andrei Popov; tls@ietf.org Subject: Re: [TLS] Prohibiting RC4 Cipher Suites Andrei, Your intro says: "Recent cryptanalysis results [ALF] exploit biases in the RC4 keystream to = recover early portions of plaintexts." The attacks can recover repeated plaintext from ANYWHERE in the plaintext s= tream, so they are more flexible in application than your text suggests. Another (better?) link for the attacks by AlFardan et al. is www.isg.rhul.a= c.uk/tls. The "official" USENIX link, which should be long-lasting, is: https://www.usenix.org/conference/usenixsecurity13/security-rc4-tls Best wishes Kenny On 21/08/2013 13:59, "Andrei Popov" wrote: >Hello All, >=20 >RC4 is a widely deployed cipher, which is commonly preferred by TLS >servers: our tests show ~40% of the high-traffic HTTPS sites pick RC4=20 >if IE offers this cipher. A significant percentage of web sites and=20 >e-mail servers have only RC4 enabled, so a client cannot altogether=20 >disable RC4 without breaking interoperability. At the same time,=20 >attacks on RC4 are improving (e.g. >http://www.isg.rhul.ac.uk/tls/), to the point that practical exploits=20 >are possible. >=20 >I have posted a new Internet-Draft =B3Prohibiting RC4 Cipher Suites=B2 >(draft-popov-tls-prohibiting-rc4-00 >) to=20 >deprecate the use of RC4 cipher suites in TLS. >=20 >Looking forward to comments and feedback on the draft, >=20 >Andrei Popov > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From agl@google.com Tue Oct 8 08:32:56 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0E221E81F1 for ; Tue, 8 Oct 2013 08:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbSRk2sxN+VS for ; Tue, 8 Oct 2013 08:32:56 -0700 (PDT) Received: from mail-vb0-x236.google.com (mail-vb0-x236.google.com [IPv6:2607:f8b0:400c:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2F22B21E818D for ; Tue, 8 Oct 2013 08:32:56 -0700 (PDT) Received: by mail-vb0-f54.google.com with SMTP id q14so4229153vbe.41 for ; Tue, 08 Oct 2013 08:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=AwTzQIRmFbKcAm4FiG/PAFNyY/1Llkq3AxApoRRji/k=; b=KYQgytY6E7bB3ys7V8n0CfHX1dMtd5EOXsuXQvs2VDTfVQw3cvevpIi1fA3e4zjK8f agpQ8FdmAMoP4V7GbmsHYl6ZrhaZ8dncs1jeCm9Q61ONthM8f80TCt6EDAn3BHxnIvGK 1MT2r3Yy3GDLF1/Qr/j3j20kNk042AzLSFv2A/eHfC5uZWWxkJKxtyA2lOvIpDzUL354 bFkFIlrG0nVU89NvU05jRROLWItRz6jpypKnMy2WctqD9DhW1rfqeHaZaIkT4ISKKzls KNZPgthPGpjF0wHqo3KH0GnuSu4U4ZtzA+wDGcCg29oE5IENi5jCBEt1mP94XWZweubg cLMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=AwTzQIRmFbKcAm4FiG/PAFNyY/1Llkq3AxApoRRji/k=; b=IfsRcg4zKI7o2ZQZX/TpiYD27q6K2bNZNMR5jquog3wKPJoWBF1xEKpfyZ+F1/EU8T ChOmwd7jJNvQgZvnu2FZrxljWM4ZmIcIeaS42CXJqKc7wIzHn865DZkAADZ9eIO55Bo7 euK3YDZIfzBLhheNt8ZOYobuA/Lsn0arFp5R95KscjlkGvByd9BlMDTh8VbmzFyrWcAb kozIvtvZVyRuf032Wf1J7EgM84WVC5tn0GwGPs7J6GptbNuns4+DLN5fZAvfwDXlTxoY j1EXOQ2d3qHwN7wKwRqFM442SelZ5B3Cqpr0/n09I84v02iWQJCCQ+nk/caOBamwQrk/ vmzg== X-Gm-Message-State: ALoCoQkYTzNI/erhq70GlfTANcTN5adqQszl5OG/5wJcG/INjSD87Colb/lsHBu4d9Fne6+KewSgFi6R9mdj/i5y4GZMF/CE0CK/BuefD6Tdfq6Hq0zins4Qv98n8RpxMCEhG9iddY/t2tmah0B8eVNLelunpsM6mAvsU2NmkwRdr8K2R4/nK1rE18vtNrmViGGgRLBdKt+0 X-Received: by 10.52.65.136 with SMTP id x8mr1236107vds.23.1381246375411; Tue, 08 Oct 2013 08:32:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.100.40 with HTTP; Tue, 8 Oct 2013 08:32:35 -0700 (PDT) In-Reply-To: References: From: Adam Langley Date: Tue, 8 Oct 2013 11:32:35 -0400 Message-ID: To: Wan-Teh Chang Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] ChaCha20 + Poly1305 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 15:32:57 -0000 On Sat, Oct 5, 2013 at 11:37 AM, Wan-Teh Chang wrote: > * Define that <<< means a rotate left shift. Done. > * The second paragraph says the block counter is four input words. The > last paragraph says the block counter is two input words. Fixed, thanks. > > * The last paragraph says the nonce (input words 12 and 13) is before > the block counter (input words 14 and 15), but > http://cr.yp.to/chacha/chacha-20080128.pdf says the block counter is > followed by the nonce. Assuming little-endian order, I think it seems > better for the block counter to be before the nonce. I got confused between Salsa and ChaCha in this case and have corrected the draft to be in line with the ChaCha specification. > Section 5. AEAD construction: > > * In the input for Poly1305, the byte count of the ciphertext is > before the ciphertext. I think this should be reversed to allow an > implementation to start computing Poly1305 before having all the > ciphertext. For consistency, also reverse the order of the byte count > of additional data and the addtional data. Although I don't think it's needed in this case, I agree that it might be useful and have changed the draft and code accordingly. I will publish an updated draft shortly. > Section 9. IANA considerations: > > * We should also ask IANA to assign an AEAD algorithm ID to > chacha20poly1305 in its registry > http://www.iana.org/assignments/aead-parameters/aead-parameters.xhtml. Done. Cheers AGL From agl@google.com Tue Oct 8 10:03:41 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB4821E8253 for ; Tue, 8 Oct 2013 10:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CUeGhosZKNF for ; Tue, 8 Oct 2013 10:03:33 -0700 (PDT) Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id E04B021E823C for ; Tue, 8 Oct 2013 10:03:29 -0700 (PDT) Received: by mail-vb0-f49.google.com with SMTP id w16so4290925vbb.22 for ; Tue, 08 Oct 2013 10:03:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5xFRYNjzM4c2UXt5gcCsGqx0ddRZ5Kt1e/lYkOmPESA=; b=WIt83oMapenuLjYgQtq2oXgf4GPoNo0/LKxMJ63rXPRh2S+rFcrdnPG/I3c1OIAogb ZWzhsQMb5KUQW4OD3h3d+P3R84WT6IbdI4UGzkpyVGR9ih9gDbWN3lPBM3I0x5FRkpqR si6O8q0ByJUPqZCjSLgr+ydHhnrH0DvqkaS1KbY8xn8EekcrKwQMgo2P31rM1f6jOhgy 8qnmwOm5FF4tqUOO44mFJud2T8ussT8A2ZFxvjo1R5z7YVSOCBY13Fj/ySkC3FqnB9hL dbzsLpWhQrbdQrfPP9ZRn2sSr4WvYnID/30TEmXKheuYufHwgokYkdO8zn8feA4zv6uw hLAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5xFRYNjzM4c2UXt5gcCsGqx0ddRZ5Kt1e/lYkOmPESA=; b=SKwoyRi9QNWg4A5LyWIna+QQzGJBYLubdPgU4pte1sGj93P7y/RtgJR2nyYVO/gyAI 29jQRxizZspFr+xcsXlgAfALZvvfvUgeeNroZC4uHov71TmF6HQCJxfeJmpq8jFktsDe ad3id7AZVEPa/8JuaBCaOLkVJnM81H/S7Iyn8TaEWgLEeV9LVUfBUROADTg1kAGfwd/r MgJc5k/8kZ9kG9VVcC7ucxHLvmmK8h6qkxXXAebhvMt0NoKFYNZia9xuuljbiqrirHey 28m9OGCRZRx4cwbMljUdBxZYv2imGBnDxRL9nPEFLDz2+ujfc/37TsjshWdf70F2vjPo gF/A== X-Gm-Message-State: ALoCoQnnKwqzYNtlolWmFXuzQrHHDiJv6Ca6gEt9Mi+LVEx2zPmh58KBoDQCctpSXmg4ZTU587Kizo3tyXzniy+MGzjTyUfwlk6ckQncGuCK5qgjjgjjSdN8ZKjBhsIy7Swx4VJOin/xTD1pUj9AN/17/2wgXe6LNQsBMdLCu/PTrbSyDECxErcCzWP6V8XQF4OE4+6UeHKL X-Received: by 10.52.164.102 with SMTP id yp6mr1543563vdb.14.1381251808337; Tue, 08 Oct 2013 10:03:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.100.40 with HTTP; Tue, 8 Oct 2013 10:03:08 -0700 (PDT) In-Reply-To: References: From: Adam Langley Date: Tue, 8 Oct 2013 13:03:08 -0400 Message-ID: To: Wan-Teh Chang Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] ChaCha20 + Poly1305 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 17:03:45 -0000 On Tue, Oct 8, 2013 at 11:32 AM, Adam Langley wrote: > Although I don't think it's needed in this case, I agree that it might > be useful and have changed the draft and code accordingly. I will > publish an updated draft shortly. The updated draft is at https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-02 Cheers AGL From mrex@sap.com Tue Oct 8 13:51:43 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A264511E80FE for ; Tue, 8 Oct 2013 13:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.449 X-Spam-Level: X-Spam-Status: No, score=-9.449 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6iWaLqSgkxx for ; Tue, 8 Oct 2013 13:51:39 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 600E411E80EA for ; Tue, 8 Oct 2013 13:51:39 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r98KpTUJ023027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Oct 2013 22:51:29 +0200 (MEST) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> To: Peter Gutmann Date: Tue, 8 Oct 2013 22:51:29 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20131008205129.4D7AF1A9E6@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: [TLS] (EC)DSA potential problems (ECC "brittleness") X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 20:51:43 -0000 Peter Gutmann wrote: > Yaron Sheffer writes: > > >I think we've been through all these arguments (on both sides of the issue) > >over the last week, with the exception of "ECC brittleness". Can you please > >clarify what you mean by that? > > So with RSA-authenticated DH all you need to do is use a constant-time modexp > on the server when you sign and pre-encode the PKCS #1 expected result and use > a constant-time memcmp() on the client when you verify and you're OK. If you > did that ten years ago then you're safe against pretty much everything that's > come along since then. > > With ECDLP-based algorithms in contrast there's a whole range of issues you > need to take into account, the worst of which is the distressing propensity of > the DLP algorithms to leak the private key if you get even the tiniest detail > wrong. Not only do you have to get all of these finicky details exactly > right, but every now and then someone points out a new issue that you then > need to retroactively patch into your existing code base. For example if you > used the recommended (until not too long ago) way to generate your k for > (EC)DSA then you'd leak a tiny bit of your private key on each signature > (again, that nasty propensity of DLP algorithms to leak the private key). > That's what I meant by ECC, and DLP in general, brittleness. Which "recommended (until not too long ago) way to generate your k for (EC)DSA" are you referring to specifically? Is or was this part of FIPS 186-x for DSA--or some X9.xx document for ECDSA that do not have (not having coughed up the $$), and is that specific issue sufficient to enable the attack described in this paper: Jean-Charles Faugere, Christopher Goyet and Guenael Renault "Attacking (EC)DSA Given Only an Implicit Hint" http://www-polsys.lip6.fr/~goyetc/doc/ImplicitECDSA_Goyet.pdf (My own understanding of the crypto math is rather poor) What's also irritates me is that every intentional weaknesses or bias in a DRNG could enable this attack. IIRC, EC_Dual_DRNG has both, a bias and a weaknesss. It also makes me feel uneasy about secret RNG designs such as Intels RDRAND--on top of the Problem that RDRAND expands 1.5 GBit/s alleged real randomness into 6 GBit/s weakened output (rather than the reverse, compressing it). The fact that TLS requires a new and independent signature on the (EC)DHE params in ServerKeyExchange on every full handshakes makes it easy to obtain (EC)DSA signatures in large numbers and short time through successful and therefore unsuspicious "full TLS handshakes". Btw. where would one find the information necessary to implement (EC)DSA safe with respect to the state-of-the-art? The references in rfc4492 (ECC for TLS) and rfc6460 (Suite B Profile for TLS) appear somewhat static: http://tools.ietf.org/html/rfc6460#section-7 http://tools.ietf.org/html/rfc4492#section-10 Wouldn't it make sense to first ensure that implementors _know_ what known problems they have to watch out for TODAY (which is not necessarily part of the original algorithm specs), before we ask them to prefer/migrate to such algorithms? -Martin From turners@ieca.com Tue Oct 8 14:41:04 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B333021F9E54 for ; Tue, 8 Oct 2013 14:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.27 X-Spam-Level: X-Spam-Status: No, score=-102.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPXanCPC+FqU for ; Tue, 8 Oct 2013 14:40:53 -0700 (PDT) Received: from gateway11.websitewelcome.com (gateway11.websitewelcome.com [70.85.18.3]) by ietfa.amsl.com (Postfix) with ESMTP id 6712E21F9E53 for ; Tue, 8 Oct 2013 14:40:50 -0700 (PDT) Received: by gateway11.websitewelcome.com (Postfix, from userid 500) id 2129B42C0C764; Tue, 8 Oct 2013 16:40:49 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway11.websitewelcome.com (Postfix) with ESMTP id F3E1942C0C6FC for ; Tue, 8 Oct 2013 16:40:48 -0500 (CDT) Received: from [96.231.225.44] (port=57990 helo=thunderfish.local) by gator3286.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VTf1M-0001GG-Ev; Tue, 08 Oct 2013 16:40:48 -0500 Message-ID: <52547BDF.5000808@ieca.com> Date: Tue, 08 Oct 2013 17:40:47 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Hannes Tschofenig References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.225.44]:57990 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 6 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Cc: "" Subject: Re: [TLS] TLS Cached Info Status X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 21:41:04 -0000 Hannes, Did you ever get any of the telemetry data? If not what is plan b? I'd like to see this draft progress soon, assuming there's wg support for it, or to officially have it declared dead. spt On 5/14/13 7:18 AM, Hannes Tschofenig wrote: > Hi all, > I thought it would be a good idea to let the group know what the status > of the TLS Cached Info draft is (since Rob just asked me a few minutes > ago). > You may recall that we had a discussion about the ability to not only > cache a single OCSP response (as defined with RFC 6066) but also OCSP > responses of intermediate CA certs, which is functionality > http://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extension/ provides. > Rob raised this issue in his review, see > http://www.ietf.org/mail-archive/web/tls/current/msg09352.html. > To me it sounds reasonable to add the requested functionality and the > pros & cons had been discussed on the list. > When I met Ekr at the recent NIST workshop we briefly spoke about the > TLS Cached Info document and how to progress it. He came up with the > idea to use the Firefox telemetry feature to gather some data so that we > can estimage the cache hit/miss ratio. With data we would obviously be > in a much better position to make an informed decision. > I hope that we get that data soon. If we cannot get it then we have to > switch to plan B. > Ciao > Hannes > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From dbrown@certicom.com Wed Oct 9 09:31:22 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A13C521F9B25 for ; Wed, 9 Oct 2013 09:31:21 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWPxJNNn8AmC for ; Wed, 9 Oct 2013 09:31:14 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 63DF211E81C7 for ; Wed, 9 Oct 2013 09:28:58 -0700 (PDT) Content-Type: multipart/mixed; boundary="===============0099617342==" MIME-Version: 1.0 Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 09 Oct 2013 12:28:54 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT106CNC.rim.net ([fe80::d824:6c98:60dc:3918%16]) with mapi id 14.03.0123.003; Wed, 9 Oct 2013 12:28:53 -0400 From: Dan Brown To: "'djb@cr.yp.to'" , "'tls@ietf.org'" Thread-Topic: [TLS] Safe ECC usage Thread-Index: AQHOwgFCxn3XJXmgAkKRAg2ZE6kwf5nsY0Kg Date: Wed, 9 Oct 2013 16:28:53 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF5BE4A9D@XMB116CNC.rim.net> References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> <20130926152757.15842.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDB49B@XMB116CNC.rim.net> <20130928223648.1113.qmail@cr.yp.to> <20130929025714.5578895.47771.4422@certicom.com> <20131001143511.11010.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE21E@XMB116CNC.rim.net> <20131002161944.8125.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE90F@XMB116CNC.rim.net> <20131003010455.17185.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDECA6@XMB116CNC.rim.net> <20131005192950.27059.qmail@cr.yp.to> In-Reply-To: <20131005192950.27059.qmail@cr.yp.to> Accept-Language: en-CA, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] MIME-Version: 1.0 Subject: Re: [TLS] Safe ECC usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 16:31:22 -0000 --===============0099617342== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0148_01CEC4EB.1CCCDE30" ------=_NextPart_000_0148_01CEC4EB.1CCCDE30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit D. J. Bernstein writes > Dan Brown writes: > > it is also reasonable to assume that NSA knows of an attack A but is > > unwilling to reveal it, and manipulated P256 to avoid A > > Sure. In BigBrotherLand, the eavesdropper Eve is actually a big fan of > the innocent users Alice and Bob, and is helping protect them against > hidden weaknesses in their communication system. > > However, our job as _cryptographers_ is to tell Alice and Bob how to > protect themselves against the possibility of _bad_ behavior by Eve. > That's why all these ECC standards are advertising the "verifiable" > randomness of the NIST curves---they're claiming that the curves are > protected against bad behavior by NSA's Jerry Solinas. That's also why Aside, and smaller point: To me, the fact that the NIST Koblitz curves and the curves http://cacr.uwaterloo.ca/techreports/2001/corr2001-68.ps seem just as free from manipulation as Curve25519, seems like mild evidence against a backdoor in P256. Publication of these alternatives would undermine a plan to get one's adversary to use backdoors unwittingly. I think I already made this point on the TLS list. > people are unhappy to learn that the advertising is false. Good point: I did not realize most people were unaware that the seeds had no explanation, yet still concluded verifiably random ruled out every possible mischief. I also agree that "verifiably random" is a misnomer, but did consider it a minor one. Do you have a better suggestion? Also, this is why I am trying to understand what you are advertising about Curve25519. You gave an example that, under reasonable assumptions, with 2^(-30) probability the ECDLP in Curve25519 could be solved in 2^64 computations. I do not see how those assumptions are reasonable, but even so, if 2^30 people use Curve25519, then is that a good risk? Do you feel that the system-wide risk for RSA, or integer DH is comparable? > > When we see a protocol that turns out to have Eve as a trusted third > party with the power to compromise security, we fix the protocol. We > don't say "Well, gee, maybe Eve is actually helping our security." Yes, but I think already implied this when I said should assume the worst, etc. > > > The Brainpool curves have some kind of justification, albeit maybe > not > > a full-fledged proof. In other words, to me, the Brainpool approach > > presents some kind of best-we-can-do-effort to resist attacks not yet > > known to us. > > No, it doesn't. Maybe an unknown attack is _more_ likely to break > brainpoolP256r1 than to break Curve25519. You keep using words like Maybe. Maybes will always exist in crypto. We just try to reduce them, whenever and however we can. > "best" and "prudence" and "advantage"; but you have zero justification > for any of this. You keep > > * misrepresenting brainpoolP256r1 as a random curve and > * stating the "random is safer" myth in several different ways; > > do you not realize that this myth was solidly debunked several years > ago? Section 11 of http://eprint.iacr.org/2008/390.pdf presents several > clear counterexamples; do you dispute those counterexamples? Thanks, I had completely forgotten about that paper, probably because I don't see ether issue as very important. In other words, we're splitting hairs. Anyway, the eprint of Koblitz, Koblitz and Menezes [KKM] lumps brainpool into the class of random curves, similarly to me. Of course, the brainpool curve is a fixed curve. (I don't think ever misrepresented that fact.) If the brainpool and nist seeds were kept secret, then these pseudorandom curves would be hard to distinguish from some class of random curves, or do you dispute that? I don't think that "maybe" attack against brainpool curve that you hypothesize above, is intended to be a such distinguisher (although it could be, since we're talking possibilities now), but rather one that, by some fluke, affects that particular seed used in the brainpool. The KKM paper does not say "myth", it says "conventional wisdom". Yes, I am just applying the conventional wisdom. KKM do not claim to "solidly debunk" that wisdom, and instead say we are left to make our "best guess" about future attacks. Their examples about prime-field curves make "plausible" assumptions about a future attack. Well, one could "plausibly" assume that a future attack affects a random curves uniformly at random, and then conclude that one fixed curve is just as good as any other. But, this seems to me almost like circular reasoning. In other words, I do have some trouble with their example: their assumptions may be artificial. I also dispute the implicit KKM contention that conventional wisdom did not admit any possibility special curves could be safer. Rather I see conventional wisdom already looked at the evidence and made its "best guess" that random curves would be safer, admitting the possibility that it could be otherwise. Also, I don't fully agree with the implicit KKM contention that just because some attacks are unknown, and that various attacks will always be possible, therefore we should totally rely on intuition. I agree that intuition, as in "best guess" is a good start, but a careful algorithm selection should try to formalize this initial intuition, isolate and reduce assumptions, prove what little can be proved and so on. The KKM example about isogenies between curves is very interesting, of course. Maybe I am mistaken, but I think that brainpool curves address that via the c(E) thing. Have you considered the equivalent for Curve25519? It would be interesting to know if the ECDLP in Curve25519 is, via isogenies, equivalent to the ECDLP in many other curves (perhaps only of the same size). They we could focus our debate a little better. > > If you think there's some reason that brainpoolP256r1 is more like the > examples where randomness helps security, rather than the examples > where randomness hurts security, then you should say what that reason > is. You can't simply pretend that the counterexamples don't exist. I was not pretending, but I did make a bad mistake: when I assumed that worst for Curve25519, I forgot to assume the worst for random curves. In other words, I supplied the wrong reason for my position. So, I have being thinking a little more about why I hold this position. Here's what I have so far, all of which is informal. Also, I am restricting this to prime-field elliptic curves. 1. Suppose some extremes: if an attack affects all random curves, excluding Curve25519, then basically ECC would be no more, and Curve25519 would now belong to the class "Special Elliptic Curve Cryptography". How logical would it be for SECC to inherit the previously believed security of ECC? Maybe it SECC would be secure, but clock would have to started anew to build up trust. The opposite extreme is that some attack affects only a special class of curves, as in the MOV and SASS attacks. Then ECC goes on, with not much worry, and we just drop those affected curves. This has happened twice already. 2. So far, there no are 0 (*) attacks against random curves, and 2 against special curves: the MOV and SASS attacks. I view this as quite good evidence in favour of random curves, over special curves. Of course, the next attack could be against random curves. Of course, with only 2 attacks, the evidence is slim. In addition to this evidence of these two attacks, consider these attacks are rather old, and no new ones have been published for many years. Regarding this point (#2), I have a hard time reconciling some of your views: "zero justification": you keep saying this phrase, and applied against random safer than special. Is this referring to fact that there's always a possibility of something completely surprising and unlike past experiences? "overwhelming evidence": you used this phrase, I think in reference to the MOV and SASS attacks, to support the argument that Curve25519 belong to a different special class than the known weak special classes. (I.e. something about the field sizes, the curve sizes and coefficient sizes being irrelevant, because they do not figure much in the MOV and SASS attacks). What I am having trouble with is how the same fact set (MOV+SASS) presents both "zero justification" for arguments that favour brainpool over Curve25519 and "overwhelming evidence" for brainpool incomparable to Curve25519. Could you elaborate? 3. This next reason is very informal, but I think it affected my thoughts. Curve25519 is a newcomer to TLS, compared to the NIST curves and brainpool curves, and as such, warrants scepticism. The burden is on any new algorithm presented to TLS is to identify its advantages, and these claims should be scrutinized by the TLS WG. Curve25519 may have sufficient other advantages over alternatives for adoption in TLS: efficiency, secure implementation, and so on. I suggest that offering Curve25519 as a means to provide algorithm agility, e.g. if RSA, integer DH, and random EC including brainpool collapse, then maybe Curve25519 will be sole survivor. Certainly possible. // On the other hand, after reading Section 11 of KKM, I remembered something else that is a slight shred of evidence that special curves are safer than random curves (although not with respect to the ECDLP): The Cheon-type attacks affect random curves slightly more adversely than certain special curves. That is, some special curves in which n-1 and n+1 are nearly prime resist Cheon-type attacks, but these curves are rare among random curves (or sizes), so could be viewed as special. Although this is a very weak attack, and arguably moot if one assumes one-way KDFs, it exists, unlike the hypothetical attack as in the KKM examples on prime-field elliptic curves. I don't think that this is enough evidence to override the other evidence favouring random curves, though. // If we move far away from prime-field elliptic curves, say to hash functions, then I do not see any evidence that random is safer special. Indeed, if one defined a random hash function by random sequence of bit operations, perhaps formalizing this through straight line programs, then, I would imagine the security would be very bad. In that case, special seems safer than random. (Going yet farther astray, I think there's results in coding theory that random codes can do as well as special codes.) Anyway, to argue random over special in the case ECC, we have to look at the evidence particular to ECC. > > By the way, I also don't see anything in the Brainpool document along > the lines that you're claiming. For example, the document never claims > that its primes are more secure than "special" primes; it clearly > states that it avoids "special" primes "to avoid patented fast > arithmetic." > Yes, I already acknowledged most of that previously in this thread. ------=_NextPart_000_0148_01CEC4EB.1CCCDE30 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUgTCCBnAw ggVYoAMCAQICChfYCekAAwAXxTIwDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAz WUtGMB4XDTEzMDUyODE1NDQwOVoXDTE0MDUxNzAwMjMzM1owgYUxEzARBgoJkiaJk/IsZAEZFgNu ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xETAPBgNVBAsTCENlcnRpY29tMQ4wDAYDVQQLEwVVc2Vy czESMBAGA1UEAxMJRGFuIEJyb3duMSIwIAYJKoZIhvcNAQkBFhNkYnJvd25AY2VydGljb20uY29t MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDRc70RE0/FL9ZbfN64YjA0lkQOLR9ipGebc9nH jB93OfYfR7CVsCUYy3+v9PO1DiUS9MeWWR4nxB9Ztee32d3syDxGg3PGFwSrms/ORAW9pgiS/yKH An9SKRKyqMz9LSn/VQrEgoyPBPT0S/vg521MGH58MwMXyLm1cLBQU5gtCQIDAQABo4IDmDCCA5Qw CwYDVR0PBAQDAgWgMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQME AgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUAlQmTNpWxnzoCUVjxGTtDz2JvLww FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMB8GA1UdIwQYMBaAFLgwF25vZ5X+hYxoO6XhF7M/+CU6 MIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiGgctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu YXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1NQ0EwM1lLRixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIw U2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2Fs P2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRp b25Qb2ludIZIaHR0cDovL21jYTAzeWtmLnJpbS5uZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRp bmF0ZSUyMENBJTIwTUNBMDNZS0YuY3JsMIIBQQYIKwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUH MAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1BSUEs Q049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixE Qz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZp Y2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxodHRwOi8vbWNhMDN5a2YucmltLm5ldC9DZXJ0 RW5yb2xsL01DQTAzWUtGLnJpbS5uZXRfUklNJTIwU3Vib3JkaW5hdGUlMjBDQSUyME1DQTAzWUtG KDMpLmNydDApBgNVHSUEIjAgBgorBgEEAYI3CgMEBggrBgEFBQcDBAYIKwYBBQUHAwIwQQYDVR0R BDowOKAhBgorBgEEAYI3FAIDoBMMEWRhbmlicm93bkByaW0ubmV0gRNkYnJvd25AY2VydGljb20u Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQC6hxWgDv96DUDS3m8XfyVGAv1CKOcWSVOShz/jofFMFzoN o2dhc0Jg9XTTZBVS+ozakEM+87YUENfP3IODRbCiJBsbiXJxS+fVo7L/bqPp47TB+Lg2/tezlNa2 ab4psmc9xjZGU9+A4lBzS5PpRjvHofsIwETpwt/aPxHIbJ5Cf7kBi7B8hR4mIqc7EJMYXeI0xHLg k3NqBYSGC3XtbykuFV0vPFoTYLO7G3pAP2RzGhuxQoaH4fpWvE3rdakjd1MZFqJrarXSvWi6ah6G Alt7+sOTzlGNqoTQqb55VZEOrU2A1VbmAFjiFR1/229A2KaHhnN6cuNe8bhzoBcnuxtyMIIGvzCC BKegAwIBAgIQMhrzkrEUWZRNTS+VEbN74TANBgkqhkiG9w0BAQUFADBPMRUwEwYKCZImiZPyLGQB GRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBN Q0EwMVlLRjAeFw0wNjEwMTMwMTI0NTVaFw0xNjEwMTMwMTMwNDFaME8xFTATBgoJkiaJk/IsZAEZ FgVsb2NhbDEXMBUGCgmSJomT8ixkARkWB3dpbmRvd3MxHTAbBgNVBAMTFFJJTSBSb290IENBIE1D QTAxWUtGMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAxui6zvytVAEtPzv6NhK7OZna iw/jQEyEVskDf5yzcFkLT/+5PztIbv+eFmL1CP2FhvLv8eQZJDKF4Yv+UsjPEN1lX4DDGKKt0NPp yT9pwQzFaiUt0rnERgSabo7EtpS4S+DuL8G9c+lmWwDqb0UWtPMdVfbr3fDwigyz1yh+vVMAHdhg Oe9lPC6nPtiJ9IXTam7V5mJmDT0mNpq/0fJo3JEaNvDKoXBOkKv6IdbtKxKzPInG6VYaCdgJCAT3 mWgr9kxiEQEUJKrvI2fXI0zRYnlL648gvK84pdsT2xZLFtr4OdZAm4RkK8U+cgurlSCr6NVqnfbq 6/3N6MGmyc9SB2Ayhk2VS66757V4nBzeaeD+srpk4IXU3NTM/+YgR1zVS41XwvZaq9Uf59j0TJhN 9xGVZO871eVVr2VfNxr0xOqUpwcxh5JZYkWcmUJFlYiQh0CM2PrfaDRTTqRZQd4F3xUlcXFAXOGh vaXKvikeI6/utnX6vCnDwMUxmenzlv8epNatxDsuIgOWO4pfqgGMyzWo2hudQ97+5ynUqDLX34nr UzszGeIE3KoqYsksxMF3tqIgadt9hNWXaP/EknZpRAmaP0s0V5ZvgiyXw9UrqnWwmRbLQk7HnYc0 hHQBjXoByKSiOyhgSS9yL6a+7AA2rhBPpsSVI9LYBs2cNKlPsZcCAwEAAaOCAZUwggGRMBMGCSsG AQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTW aYJkJBbBzCTb8RR9RxJ83MlN7jCCASkGA1UdHwSCASAwggEcMIIBGKCCARSgggEQhoHEbGRhcDov Ly9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1NQ0EwMVlLRixDTj1DRFAsQ049UHVi bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5k b3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1j UkxEaXN0cmlidXRpb25Qb2ludIZHaHR0cDovL21jYTAxeWtmLndpbmRvd3MubG9jYWwvQ2VydEVu cm9sbC9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwDQYJ KoZIhvcNAQEFBQADggIBAEOeWFu4OVTnx9+jYk92iDra2f1Bc5j1WesEGINl4VCY9WJy6n17b/h2 fDmjj9KfIto3LE2Wej77lSJqv/LSd7wnfTQVZVb1wBe2Zt+LuPAqi6vWSDAQVOfdOMYVu5imznnf +ZNMLduTqXZ/bFQKTWsg2qhBWwaiYfxEY7nVg3+ZfStqwc9R3v/tHH+b9kX3FuKLoVQ6KSrqUyBi fhIRj57eOw6/JjPA+SId/p2yEZ+xmANQ31vE3BHFRm20kZHHqAfdCmTt1S7LDSLHBj3GZXIFUge9 aPKqzAXee2DCYTP3YYcgrP/FbFF2RqGRIhPM+MdjJraMjex+nNT+2KC/EIWsbU9DgFII0wHKpRx8 rlJNN8kmb/H9qGqcNaW9Q/pwUTpX1bXSdbzvYFs3NY7KmYYii4Q0RQCGr96OvDT0/S6/IrnW+vqZ jnPV2MXqEuyQ0L5HXVOnCi769uGYcRkEo5xzEJ/EMvj07vCWnG7h9ykNhLEEMcygVmBdXP9qOqog dyPJB0AzxAYGqCSMT8Ors1M/srZSXUCfSfENH5iBd7bxH7uXmF7kbOEghom7AccC2Clt4DU0tj9s FyIWg5H6zy6NLetm2/kzdD3mGY3u2tWtijVnd2CWY2YszYo1lbDAfEfjGL/9uFpH79Zt9ekRSD5Z bSn1SNr1njjeGpV3jwyuMIIHRjCCBS6gAwIBAgIKFnKQQQAAAAABuDANBgkqhkiG9w0BAQUFADBP MRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQD ExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjAeFw0xMjA1MTcwMDEzMzNaFw0xNDA1MTcwMDIzMzNaMFAx EzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBT dWJvcmRpbmF0ZSBDQSBNQ0EwM1lLRjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfx jFzEuYa/qd6dXu4HILtBdH3+Bgwz3uQakDcxvrf3fyVQBy69KFOS8/h5REe6bit3tp5wsQQv/nFV mmXK/jq9zD72zl3jv63UzZgOWC90846UxTTmmNEyHzo1M54B3LrnE6L2Q6QbEZMAnrJ96uV8pN2X Zsn5j+MvfI5ajFu+6oPbHeYzQjZB3GDju7sELm7cAcr0YYX3xeLTB2rLUUZF6Nyyc0btD57ARYEa 99A+6JslO8VcxtlgRddx17NB6gttNjwmJFT3l3UVcK5O5+UVSWpW1zQbZQBvl0iP7gXcrJW4Dv0p 036iHg9lgDV1qQChi9NCixwm7yYtCHLq9akCAwEAAaOCAyEwggMdMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFLgwF25vZ5X+hYxoO6XhF7M/+CU6MAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEE AwIBAzAjBgkrBgEEAYI3FQIEFgQUZUBVml3ak56Kwnbul6AULvNdck8wGQYJKwYBBAGCNxQCBAwe CgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNVHR8EggEg MIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Ys Q049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRp b25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6Ly9tY2Ew MXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Yu Y3JsMIIBPAYIKwYBBQUHAQEEggEuMIIBKjCBuwYIKwYBBQUHMAKGga5sZGFwOi8vL0NOPVJJTSUy MFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRvd3MsREM9bG9jYWw/Y0FDZXJ0aWZp Y2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwagYIKwYBBQUHMAKG Xmh0dHA6Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvTUNBMDFZS0Yud2luZG93 cy5sb2NhbF9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcnQwDQYJKoZIhvcNAQEFBQADggIB AK/ZTtcAxFAZJo37z0KG3EGIGIScPRus90jBJGQO9+Mrb4QRoMjkCwZP9GbYq2CxCqOBiKOZfkSK PMSupPLRlE70z9tGbsMz13ExQy50WZS9n4XRxglyDRga1fQVwGNF+SMPaBzQapiFi3CkBWNSdz+f aRdkdiqIvG3hxkbk6AXr6xhlu2mvnhJ/dE248lZDmN3FkWDHXEgEd5uHxwd7nWjxXVuzRV0oNgrG E96uTqLHVsdefHplPwyrIlgV4SY1ST1y8nKhZlB4IX8fDIj1Xr3rRssW+8XEKSILvawoU47n34x6 xZrO8nbramu3s3BPDnPBe5d1akBYA/nTKb9l6by6dNzJ7u1r73w7/tC53Hgf+826w6Gw+Z6Xs1d2 6RvukJ+7VCyKTR+rg+jASrfhS7naerxVMoOZwr6GxqqHYbK1gp3ag8Ek1U62/LYLqbvYMn58e23k q1pR6vLfQY4AhteMJipLmkxioYjHMCm9rTCZCnU2e/yvNNGXXq8WEeJpAc7hXbFR8L7VTaawkSxg jtJ2YTLvGH0cM/lEOAn3UGUG1lAhBBBzpLS4oW+ITZ5LsPWx2UiWAHLF79XE+PzvFE1+haf4HzJ0 KNKizMaj6DyVJN/oLOvdlVn32x70hCkr9zPFM6f4wEtQoY+qV3Q13zB7FePumyia5+/xmioObwts MYICrjCCAqoCAQEwXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmlt MSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwCQYFKw4D AhoFAKCCAaYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMDA5 MTYyODUxWjAjBgkqhkiG9w0BCQQxFgQUpSoSdq2fpUobusVHh4fzs09HE7AwZwYJKoZIhvcNAQkP MVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwbQYJKwYBBAGCNxAEMWAwXjBQMRMw EQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vi b3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwbwYLKoZIhvcNAQkQAgsxYKBeMFAxEzAR BgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBTdWJv cmRpbmF0ZSBDQSBNQ0EwM1lLRgIKF9gJ6QADABfFMjANBgkqhkiG9w0BAQEFAASBgF1kCnqet2wd KrAkQqjbTNFfH4gTPCdfm3SumErXChZss/Fivx2wf+qV7WSETdLB/v+Ym60Ai45+22rB1AEzXUeV oZN0qmNcCXPSWQE0WEnEMVe4d0tPMMXQQ9SBcALpIFyocQlKw460jNOnClajUMbFOtrogY5/S7q3 g/U+IDe6AAAAAAAA ------=_NextPart_000_0148_01CEC4EB.1CCCDE30-- --===============0099617342== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --===============0099617342==-- From kmigoe@nsa.gov Wed Oct 9 09:50:58 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A30B21F9DE9 for ; Wed, 9 Oct 2013 09:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.133 X-Spam-Level: X-Spam-Status: No, score=-10.133 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPJsQXvFcrA2 for ; Wed, 9 Oct 2013 09:50:52 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id 4718C21F9D12 for ; Wed, 9 Oct 2013 09:50:52 -0700 (PDT) X-TM-IMSS-Message-ID: <5bbf279e0007377f@nsa.gov> Received: from MSHT-GH1-UEA01.corp.nsa.gov ([10.215.227.18]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 5bbf279e0007377f ; Wed, 9 Oct 2013 12:58:47 -0400 Received: from MSMR-GH1-UEA01.corp.nsa.gov (10.215.225.4) by MSHT-GH1-UEA01.corp.nsa.gov (10.215.227.18) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 9 Oct 2013 12:50:51 -0400 Received: from MSMR-GH1-UEA03.corp.nsa.gov ([10.215.224.3]) by MSMR-GH1-UEA01.corp.nsa.gov ([10.215.225.4]) with mapi id 14.02.0342.003; Wed, 9 Oct 2013 12:50:50 -0400 From: "Igoe, Kevin M." To: "'tls@ietf.org'" Thread-Topic: Synopsis of CFRG discussions on new stream ciphers and MACs for TLS Thread-Index: Ac7FD7VT2T4r3M83SauM1r3DE/e5ww== Date: Wed, 9 Oct 2013 16:50:49 +0000 Message-ID: <3C4AAD4B5304AB44A6BA85173B4675CAB24E246F@MSMR-GH1-UEA03.corp.nsa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.228.46] Content-Type: multipart/alternative; boundary="_000_3C4AAD4B5304AB44A6BA85173B4675CAB24E246FMSMRGH1UEA03cor_" MIME-Version: 1.0 Subject: [TLS] Synopsis of CFRG discussions on new stream ciphers and MACs for TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 16:50:58 -0000 --_000_3C4AAD4B5304AB44A6BA85173B4675CAB24E246FMSMRGH1UEA03cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As requested by the TLS WG during IETF-87, the CFRG discussed the suitability of the candidate stream ciphers and MACs proposed for use in TLS. Three stream ciphers have been discussed: * The original SALSA-20 * ChaCha, a variant of SALSA-20, modifying the prolog and epilog to increase efficiency. * eStream SALSA-20 (hereafter eSALSA) reduces the number of rounds from 20 rounds in SALSA-20 down to 12 rounds in eSalsa. The discussion of these stream ciphers boiled down to the following points: * There seems to be substantial controversy over the efficiency of the various stream cipher candidates, especially when compared to AES counter modes. This needs to be straightened out before an informed decision can be made. On the maturity of the cryptanalysis of the three stream ciphers: * The analysis of SALSA-20 has been very thorough and the degree of confidence in SALSA-20 is very high. * Though ChaCha has received slightly less analysis, the CFRG is confident that the analysis was sufficiently thorough that ChaCha is an acceptable alternative to SALSA-20. * The RG was less comfortable with the maturity of the analysis of eSALSA, but no substantive objections were raised. Cryptanalytically all three are almost certainly sufficient for use in TLS. The RG expressed a preference for ChaCha. We were also asked our opinion on the MACs being considered, UMAC and POLY1305. No cryptanalytic issues were raised, though VMAC was suggested as a more efficient alternative to UMAC. The suitability of these MACs for efficient hardware implementation was questioned. ----------------+-------------------------------------------------- Kevin M. Igoe | "We can't solve problems by using the same kind kmigoe@nsa.gov | of thinking we used when we created them." | - Albert Einstein - ----------------+-------------------------------------------------- --_000_3C4AAD4B5304AB44A6BA85173B4675CAB24E246FMSMRGH1UEA03cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
As requested by the TLS WG during IETF-87, the CFRG discussed the
suitability of the candidate stream ciphers and MACs proposed for
use in TLS.
 
Three stream ciphers have been discussed:
        • The original SALSA-= 20
        • ChaCha, a variant o= f SALSA-20, modifying the prolog and
       epilog to increase efficiency.
        • eStream SALSA-20 (h= ereafter eSALSA) reduces the number
        of rounds from 20 rounds in SALS= A-20 down to 12 rounds in
        eSalsa.
 
The discussion of these stream ciphers boiled down to the
following points:
&nbs= p;       <= span style=3D"font-size:10.5pt;">• There seems to be substantial cont= roversy over the
        efficiency of= the various stream cipher candidates,
       especially when compa= red to AES counter modes.<= span style=3D"font-size:10.5pt;">  This
        needs to be stra= ightened out before an informed decision
       can be made.
On the maturity of the cryptanalysis of the three stream ciphers:
        • The analysis of SAL= SA-20 has been very thorough and the
        degree of confidence in SALSA-20= is very high.
        • Though ChaCha has r= eceived slightly less analysis, the
        CFRG is confident that the analy= sis was sufficiently
        thorough that ChaCha is an accep= table alternative to
        SALSA-20.
        • The RG was less com= fortable with the maturity of the
        analysis of eSALSA, but no subst= antive objections were
        raised.
Cryptanalytically all three are almost certainly sufficient for
use in TLS.  The RG expressed a preference for ChaCha.
 
We were also asked our opinion on the MACs being considered, UMAC
and POLY1305. No cryptanalytic issues were raised, though VMAC was
suggested as a more efficient alternative to UMAC. The
suitability of these MACs for efficient hardware implementation
was questioned.
&nbs= p;
 
----------------+------------------------------------= --------------
Kevin M. Igoe   | "We can't solve problems= by using the same kind
kmigoe@nsa.gov  | of thinking we used when we create= d them."
         &nb= sp;      |      &nbs= p;       - Albert Einstein -
----------------+------------------------------------= --------------
&nbs= p;
&nbs= p;
&nbs= p;
 --_000_3C4AAD4B5304AB44A6BA85173B4675CAB24E246FMSMRGH1UEA03cor_-- From prvs=3994e4542f=uri@ll.mit.edu Wed Oct 9 10:12:31 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8F021E811C for ; Wed, 9 Oct 2013 10:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.201 X-Spam-Level: X-Spam-Status: No, score=-5.201 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9oulQRkDIJ7 for ; Wed, 9 Oct 2013 10:12:26 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECA121E808F for ; Wed, 9 Oct 2013 10:12:25 -0700 (PDT) Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r99HCM5J015362; Wed, 9 Oct 2013 13:12:22 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: "Igoe, Kevin M." , "'tls@ietf.org'" Date: Wed, 9 Oct 2013 13:12:17 -0400 Thread-Topic: [TLS] Synopsis of CFRG discussions on new stream ciphers and MACs for TLS Thread-Index: Ac7FErd22MJxngiOQxat1EJ+pkWVtw== Message-ID: In-Reply-To: <3C4AAD4B5304AB44A6BA85173B4675CAB24E246F@MSMR-GH1-UEA03.corp.nsa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3464169137_10415650" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-10-09_05:2013-10-09, 2013-10-09, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1310090063 Subject: Re: [TLS] Synopsis of CFRG discussions on new stream ciphers and MACs for TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 17:12:31 -0000 --B_3464169137_10415650 Content-type: multipart/alternative; boundary="B_3464169137_10436730" --B_3464169137_10436730 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable My order of preference would be: - Chacha: Best. - Salsa-20: OK, fine. - eSalsa: If nothing else is available. From: , "Kevin M." Date: Wednesday, October 9, 2013 12:50 To: "'tls@ietf.org'" Subject: [TLS] Synopsis of CFRG discussions on new stream ciphers and MACs for TLS > As requested by the TLS WG during IETF-87, the CFRG discussed the > suitability of the candidate stream ciphers and MACs proposed for > use in TLS. > =20 > Three stream ciphers have been discussed: > =80 The original SALSA-20 > =80 ChaCha, a variant of SALSA-20, modifying the prolog and > epilog to increase efficiency. > =80 eStream SALSA-20 (hereafter eSALSA) reduces the number > of rounds from 20 rounds in SALSA-20 down to 12 rounds in > eSalsa. > =20 > The discussion of these stream ciphers boiled down to the > following points: > =80 There seems to be substantial controversy over the > efficiency of the various stream cipher candidates, > especially when compared to AES counter modes. This > needs to be straightened out before aninformed decision > can be made. > On the maturity of the cryptanalysis of the three stream ciphers: > =80 The analysis of SALSA-20 has been very thorough and the > degree of confidence in SALSA-20 is very high. > =80 Though ChaCha has received slightly less analysis, the > CFRG is confident that the analysis was sufficiently > thorough that ChaCha is an acceptable alternative to > SALSA-20. > =80 The RG was less comfortable with the maturity of the > analysis of eSALSA, but no substantive objections were > raised. > Cryptanalytically all three are almost certainly sufficient for > use in TLS. The RG expressed a preference for ChaCha. > =20 > We were also asked our opinion on the MACs being considered, UMAC > and POLY1305. No cryptanalytic issues were raised, though VMAC was > suggested as a more efficient alternative to UMAC. The > suitability of these MACs for efficient hardware implementation > was questioned. > =20 > =20 > ----------------+-------------------------------------------------- > Kevin M. Igoe | "We can't solve problems by using the same kind > kmigoe@nsa.gov | of thinking we used when we created them." > | - Albert Einstein - > ----------------+-------------------------------------------------- > =20 > =20 > =20 --B_3464169137_10436730 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
My order of prefer= ence would be: 
 - Chacha:   Best.
 - Salsa-20: OK, fine.
 - eSalsa:     If= nothing else is available.

= From: <Igoe>, "Kevin M." <k= migoe@nsa.gov>
Date: Wednes= day, October 9, 2013 12:50
To: "<= a href=3D"mailto:'tls@ietf.org">'tls@ietf.org'" <tls@ietf.org>
Subject: [TLS] Synopsis of CFRG discussions on new stream ciphers and MACs for TL= S

As requested by the TLS WG during IETF-87, t= he CFRG discussed the
suitability of the candidate stream ciphers and MACs proposed for
use in TLS.
 
Three stream ciphers have been disc= ussed:
        • The orig= inal SALSA-20
        • C= haCha, a variant of SALSA-20, modifying the prolog and
       epilog to increase efficiency.
&n= bsp;       • eStream SALSA-20 (hereafter= eSALSA) reduces the number
        of rounds from 20 rounds in SALS= A-20 down to 12 rounds in
        eSalsa.
 
The discussion of these stream ciphers boiled down to the
following points:
        • There seems to be substan= tial controversy over the
<= span style=3D"font-size:10.5pt;">       efficiency of the various stream cipher candidates,
   =     especially when compared to AES counter modes.  This
        needs to be straightened out before aninformed decision
  =      can be made.
On the maturity of the = cryptanalysis of the three stream ciphers:
    = ;    • The analysis of SALSA-20 has been very thorough = and the
        degree of confidence in SALSA-20= is very high.
        • = Though ChaCha has received slightly less analysis, the
        CFRG is confident that the analy= sis was sufficiently
        thorough that ChaCha is an accep= table alternative to
        SALSA-20.
  =       • The RG was less comfortable with the = maturity of the
        analysis of eSALSA, but no subst= antive objections were
        raised.
Cryptanalytica= lly all three are almost certainly sufficient for
use in TLS.  The RG expressed a preference for ChaCha.
 = ;
We were also asked our opinion on the MACs being considered, UMA= C
and POLY1305. No cryptanalytic issues were raised, though VMAC was
suggested as a more efficient alternative to UMAC. The
suitability of these MACs for efficient hardware implementation
was questioned.
 
 
----------------+--------------------------------------------------<= /font>
Kevin M. Igoe   | "We can't solve problems by= using the same kind
kmigoe@nsa.gov  | of thinking we used when we created them."
=        &nbs= p;        |     =          - Albert Einstein -<= /font>
----------------+--------------------------------------= ------------
 
 
 
--B_3464169137_10436730-- --B_3464169137_10415650 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUFAYJKoZIhvcNAQcCoIIUBTCCFAECAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghHjMIIEyzCCA7OgAwIBAgIKZmfFegAAAABv3jANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0yMB4XDTEzMDYwNTE3NDg1NVoXDTE0MDYwNTE3NDg1NVow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQD0pxreUKJmz3cYObjwcqXaTyUCzAwXTeB7BABDIopD F0wfCHEAhf3lZCftQRtrN6lcvk2d530ESc00q11bwFjiifpTGVTJoxiumHVgFInWHrECeQy0 B9BWM4XiWY3MXvqFjsQJ8HmqQTGqLk9+0/4/CyEXEnwNqAWNYA2K2uLWuJb/WSiimxfcBc/p rIn+ObsIpkDnACG2jWRkE41GklcmaTexUTQetGRFVfYwrC73+4EQs32IKDVnJ+Rd2/yqwHgr i0kNwR8tu/5qIux4j0YVAwucQF43Mj2LmVhwCqHxHm4mVVJQQLJkS5ZA9wycKyze3Fm7k6h8 11i7laYKWiyvAgMBAAGjggGTMIIBjzAdBgNVHQ4EFgQUxkrbqy+gJYz6KplY/VQJigLNuzMw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYB BQUHAQEEVjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTIwIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAw PQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhcveMof/ inMCAWQCAQUwIgYDVR0lAQH/BBgwFgYIKwYBBQUHAwQGCisGAQQBgjcKAwwwGAYDVR0gBBEw DzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0B AQsFAAOCAQEAUpfpR1Sa9nInr3dVDOMvGcxg7GwHdSoCD9xCTXfPxqAkzI3UdOm6fLPUE7Wd XtaLsoInWIK/gP2uRTONUNbUScH21ia+J0UjZj5t2cbU+akefQkeobYXGAsa1BxIFSjaRQrq oLuZocef2ut8FjFeiU+YmNH4DAMGqtcg54Yq5PTdLVzZKJv8Z6vsJVcWgb/pLNIZ2dByb8K5 48A/rjUeJcBL/Gy0EveUYJAWTQvbCjZwFFdubfjoPDu2qFuhgAhAlER/fzTcq5bapjYnfEHZ /Yx6Tmg5hUl5zNhr6dQY7p3yb+koIiTz7gJCQFc/FZSGxfD4ScPTnCJZXhMPFOUbSDCCBLcw ggOfoAMCAQICARQwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9v dCBDQTAeFw0wOTEyMTQxMjAwMDBaFw0xNTEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8w HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnBMsjYUiH7Deg MwcFYWZM6OknYzRgEO5gNgPE9JJnQgfDB+o1o1VTMBWcJYPXII4CyhLhDvSjfCvTPI4HmRDK Ip5UX5N2BCzwu7BJJMwUJHFaS4RMAC7nvYh6MIEixpl2aWCpkYX74b2CeDDQriGlqXCvxmg2 QhPlNmk4ONpL/80Kx9wKKhV/NThe54sFzZ2pz9YUEX5DE0a52hFvA19EzGhv7fUcucUjKy0z XPQ70LYwOWXLlpxAolKcgwRVsS6/cse8YH9fy8IAsXKAXikgQaFs5EJigLIDKPTKtRaf55yK sORSpoDrO1cvuntA5PnIH/qAFfACvGRTEK1RNLh9AgMBAAGjggGVMIIBkTASBgNVHRMBAf8E CDAGAQH/AgEAMB0GA1UdDgQWBBSOSn2JoWMXHIGINFc3JkVeGYp+JDAfBgNVHSMEGDAWgBRn qnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMCAYYwYQYIKwYBBQUHAQEEVTBTMC0G CCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExSQ0EwIgYIKwYBBQUH MAGGFmh0dHA6Ly9vY3NwLmxsLm1pdC5lZHUwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldGNybD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEG MA0GCyqGSIb3EgIBAwEIMA0GCyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3 EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0G CyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBCwUAA4IBAQCIdwah0P1x/Augwi/nhBq6Ds8QXAqk zSLZrL+DADWjk6HYFNo64x3Bo15c6oaW/GcTpZACt3StPa3OvsgAnKCtk81bQ0WV2MaL/0qm UYyN3bn1NiWrQD8aLAssv9aLY5dUylGOO1r37d9b3X+YtFytg0FRCfl5arYAYhU1SDCHwScD 2o67Is/qYBRGMIYcCcb7PH5UotBSwhO+1WCxIqD+YcRusyD3kEcc4dW6IG36YVhx7aIkw5AU meFH7xl0E1X+0I4Q+cmMNdMiArYx5rYG34AZB+f770fdjWPUUpTT82aphiiImutWyQpmoEWB snsX3nVTRdHCVi+Cf3Cx4YDWMIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMD UEtJMRYwFAYDVQQDEw1NSVRMTCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIz NTk1OVowVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkx DDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMVOKRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKv f9VSQToAsA6q1bACtZUcMv5ZKx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXT XYQIdp1DgjtdADKVLAjXaYpD2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/ hipJ6+sI/ZtrFRmsKGhuwAKobFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpX TZFcM9SOX0f7wmsYi1yFuKFMnQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW 6oMCAwEAAaNgMF4wDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3y EMND7SkwHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0G CSqGSIb3DQEBBQUAA4IBAQA+G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I 1Nf02qDU/GO2H9ETvnvTYhvfgQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8P yYtZtngb6DgeEUv+SwFnzcLO1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/ LbPjNuPdgJfO3d1WrHr1Etaaa0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/Yr oyqWFnH2KkNxRn9+2Ar7g3rnrOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90 ivQAMIIEzjCCA7agAwIBAgIKLRt82QAAAABhCDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMw EQYDVQQDEwpNSVRMTCBDQS0yMB4XDTEzMDIyODE2MTcxNFoXDTE0MDIyODE2MTcxNFowYTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsT BlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCqgQaJR3nurw/TB1Gm3yRezeYoc6BXhdtn9ZToWjJA044X 519aJBKnWyVpLdTgGMmT1uX48QQrKT6WT6QyIqPlpPqZpq9Ex+ZPKOfbk5Jl1Pw5SnceFZQb z1EIMgvz8JX2vhfMrr6DCDk1YIQY+F9ox/iTZTlLwWthnor6FhNLWCz0Rg+d5IPrTWfTzWSn w71hQb6iY8xmrtCJ5njGJUUx1Z6xQ4v26vSvAGLqg9NsAHdaHuQkTCEzDIyRZ9QzfA8+Bti3 sB40yHSTgORE1BQ1wa5+CwyitHq4sSb8NOW41tQ0OnE+QL+rW9anJYkbOzBWHvMbWgo3p1Q8 B8yGuZlnAgMBAAGjggGWMIIBkjAdBgNVHQ4EFgQUdbttDhxCbk/gVL/0gcb3CagQkHQwDgYD VR0PAQH/BAQDAgUgMB8GA1UdIwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUH AQEEVjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIw IwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJ KwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SAC AWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEw DzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0B AQsFAAOCAQEAWHiBeNYY8PIHTsg1fyOX8E3PpnPiKvRyNpYEQ29ZWfgcEZo9OKtyeque14vn +t2jWRp+c7XQvmy0JUZO8Zz3RFFfjezTLfY6LCFWltJoRwGZRyhRC0SWOEsRzcFKrYFB/S5f NYjV69Id9UCNSnlSUTr+NxbVIczfs9TlbYstjamllfrms+XHhzH/xfLQ4bB8HOdxunlgsqBU 3jS7H7hpafBbWhL1Mt5685pAbj1hSAVy4bd1JkJSWi7O6M5Ca4KRp7l0XSZX6Au5h6eoy8IQ aC5xtxVNSUTWSI6ysoH0AzyZUH9nSu3iOM+sMYzKENqijk/pzM7vCDEb89M4S5ffhjGCAfUw ggHxAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0EtMgIKZmfFegAAAABv3jANBglg hkgBZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCCvZ0qYMnmDX3RVhQvZJZyi33k1BnDG4Szd V9g2Qr6kwjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzEw MDkxNzEyMTdaMA0GCSqGSIb3DQEBAQUABIIBAAMwLeJ+6K6k9AuXQB+vmcLgkcRgtv58MQF9 Gkma2wq0h2nNQzGok3og4IKPPYjoynDE6uO2nyddDGiS6loUfrZ90NZG/SPzVF2ly6WBSwIT ZDw3klg+Vm9VMrzzbjUA+fQ9nlRJgAUiWOzKV3Tw1Ne/fukJtfNghkxmv4rQV+POXWN5jhIj BueuD9q0rAreU6F1+tSYBZ8nTQEFjlVHNyI9jwdxuUlU4n+FbDdXv4gxdRsGwl27Ciu+m76S PyHSF7l7czij9kqj63d/6SyaYT9mJruJ45ETkFZr1iNF4/rhnp/pqowRB6qjl6oQQro1MQcy 1MOoT28OnNWuNYMksCs= --B_3464169137_10415650-- From pgut001@cs.auckland.ac.nz Fri Oct 11 05:17:41 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC33321F9CED for ; Fri, 11 Oct 2013 05:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wug5OfZEMevX for ; Fri, 11 Oct 2013 05:17:37 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id C86CF21F9C34 for ; Fri, 11 Oct 2013 05:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1381493857; x=1413029857; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=H/djW1TrZaIaIsg9phiBjSyKo942By89oGfl+Rj4Avk=; b=HWVJx5ro1b4EnTYxpjSRY9FyuH85RIt0yr1u5JoEmQjOah6BTAHH0Bwf Pjgu0wlvheFYwxlZL97AnsXEEdxbMkTTw5D5T2+tz3j4wScu+HFSxbYgz X7m8zZrYo36E2x6HYAKzoT3AeKE7gqsDueG4tnzbWgoqyaNPlvHI5yl91 w=; X-IronPort-AV: E=Sophos;i="4.90,1080,1371038400"; d="scan'208";a="217084577" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 12 Oct 2013 01:17:29 +1300 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.179]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0158.001; Sat, 12 Oct 2013 01:17:29 +1300 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] (EC)DSA potential problems (ECC "brittleness") Thread-Index: Ac7Ge9pHV4fQ9eWiT1ir7fSQHYZRwQ== Date: Fri, 11 Oct 2013 12:17:28 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C735568A5EC@uxcn10-6.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [TLS] (EC)DSA potential problems (ECC "brittleness") X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 12:17:41 -0000 Martin Rex writes:=0A= =0A= >Which "recommended (until not too long ago) way to generate your k for (EC= )=0A= >DSA" are you referring to specifically?=0A= =0A= See Adam Back's conveniently-timed post to the Ramdombit crypto list:=0A= =0A= -- Snip --=0A= =0A= Some may remember Bleichenbacher found a random number generator bias in th= e=0A= original DSA spec, that could leak the key after soem number of signatures= =0A= depending the circumstances.=0A= =0A= Its described in this summary of DSA issues by Vaudenay "Evaluation Report= =0A= on DSA"=0A= =0A= http://www.ipa.go.jp/security/enc/CRYPTREC/fy15/doc/1002_reportDSA.pdf=0A= =0A= Bleichenbacher's attack is described in section 5.=0A= =0A= The conclusion is "Bleichenbacher estimates that the attack would be=0A= practical for a non-negligible fraction of qs with a time complexity of=0A= 2^63, a space complexity of 2^40, and a collection of 2^22 signatures. We= =0A= believe the attack can still be made more efficient."=0A= =0A= NIST reacted by issuing special publication SP 800-xx to address and I=0A= presume that was folded into fips 186-3. Of course NIST is down due to the= =0A= USG political level stupidity (why take the extra work to switch off the we= b=0A= server on the way out I dont know).=0A= =0A= That means 186-1 and 186-2 were vulnerable.=0A= =0A= An even older NSA sabotage spotted by Bleichenbacher?=0A= =0A= Anyway it highlights the significant design fragility in DSA/ECDSA not just= =0A= in the entropy of the secret key, but in the generation of each and every k= =0A= value, which leads to the better (but non-NIST recommended) idea adopted by= =0A= various libraries and applied crypto people to use k=3DH(m,d) so that the= =0A= signture is determinstic in fact, and the same k value will only be used=0A= with the same message (which is harmless as thts just reissuing the bitwise= =0A= same signature).=0A= =0A= -- Snip --=0A= =0A= (my ref. for this was "The Insecurity of the Digital Signature Algorithm wi= th=0A= Partially Known Nonces" by Phong Nguyen and Igor Shparlinski, but Vaudenay'= s=0A= work is a better ref).=0A= =0A= >Is or was this part of FIPS 186-x for DSA--or some X9.xx document for ECDS= A=0A= >that do not have (not having coughed up the $$), and is that specific issu= e=0A= >sufficient to enable the attack described in this paper:=0A= >=0A= > Jean-Charles Faugere, Christopher Goyet and Guenael Renault=0A= > "Attacking (EC)DSA Given Only an Implicit Hint"=0A= >=0A= > http://www-polsys.lip6.fr/~goyetc/doc/ImplicitECDSA_Goyet.pdf=0A= =0A= No, that's yet another one.=0A= =0A= (I did mention that DLP-based PKCs were quite brittle, didn't I? :-).=0A= =0A= >Btw. where would one find the information necessary to implement (EC)DSA s= afe=0A= >with respect to the state-of-the-art?=0A= =0A= I don't think there is one, you need to either be aware of a whole pile of= =0A= research papers (some of which are only drafts, or tech reports, which mean= s=0A= reading a pile of crypto lists), or to read code comments in a well-maintai= ned=0A= crypto library that mentions the workarounds to various problems.=0A= =0A= (Again, my brittleness comment, with RSA you use blinding/const-time modexp= =0A= and do a consistency check on your signatures to check for faults and you'r= e=0A= done, with the DLP's its a continuous arms race).=0A= =0A= Peter.=0A= From 57756671618275-ietf-tls@sublist.cr.yp.to Fri Oct 11 17:31:55 2013 Return-Path: <57756671618275-ietf-tls@sublist.cr.yp.to> X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C1321E8103 for ; Fri, 11 Oct 2013 17:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYbL0ezhFXWi for ; Fri, 11 Oct 2013 17:31:50 -0700 (PDT) Received: from mace.cs.uic.edu (mace.cs.uic.edu [131.193.32.224]) by ietfa.amsl.com (Postfix) with SMTP id 1B87221E8095 for ; Fri, 11 Oct 2013 17:31:49 -0700 (PDT) Received: (qmail 24516 invoked by uid 1011); 12 Oct 2013 00:31:48 -0000 Received: from unknown (unknown) by unknown with QMTP; 12 Oct 2013 00:31:48 -0000 Received: (qmail 670 invoked by uid 1001); 12 Oct 2013 00:30:58 -0000 Date: 12 Oct 2013 00:30:58 -0000 Message-ID: <20131012003058.669.qmail@cr.yp.to> From: "D. J. Bernstein" To: tls@ietf.org Mail-Followup-To: tls@ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> <20130926152757.15842.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDB49B@XMB116CNC.rim.net> <20130928223648.1113.qmail@cr.yp.to> <20130929025714.5578895.47771.4422@certicom.com> <20131001143511.11010.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE21E@XMB116CNC.rim.net> <20131002161944.8125.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE90F@XMB116CNC.rim.net> <20131003010455.17185.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDECA6@XMB116CNC.rim.net> <20131005192950.27059.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BE4A9D@XMB116CNC.rim.net> Subject: Re: [TLS] Safe ECC usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 00:31:55 -0000 Dan Brown writes: > if an attack affects all random curves, excluding > Curve25519, then basically ECC would be no more, Here are six examples of attacks that already affect the security level of the vast majority of elliptic curves: * Shanks's baby-step-giant-step attack. Drastic reduction in the number of arithmetic operations required to break ECDLP. There's no defense against this attack. * The Pohlig--Hellman attack. Further drastic reduction in the number of arithmetic operations required for _most_ curves---but not all; there are occasional special curves that resist the attack. * Twist attacks. Again applicable to _most_ curves---but, again, not all; again there are occasional special curves that resist the attack. * Negating rho. Okay, it's just a 1.4x attack speedup, but I can't see any justification for you to ignore it. There's no defense against this attack. * Pollard's rho attack. Drastic reduction in _memory_ consumption, making elliptic curves much easier to break (in reality, and in sensible cost metrics). There's no defense against this attack. * The van Oorschot--Wiener parallel rho attack. Drastic reduction in _communication_, allowing efficient parallelization, again making elliptic curves much easier to break. There's no defense against this attack. So you're wrong in implying that there haven't already been attacks that affect "random curves". Do we respond by discarding ECC, as you suggest? Of course not. We respond by choosing parameters to resist the attacks: * Choose _extremely_ special curves (we're talking about one curve in a thousand here!) that defend against twist attacks and the Pohlig--Hellman attack. * Choose primes far above 200 bits to defend against the other four attacks. Of course, we also take time to further investigate and build confidence that the security story is stable. All of these attacks have been known for more than ten years (three of them even before ECC was published), as have the two attacks that you mentioned for extremely rare curves. People working on attacks have found interesting improvements for extension fields, higher genus, etc., but seem to have run out of ideas for attacking prime-field ECC. > So far, there no are 0 (*) attacks against random curves, and 2 against > special curves: the MOV and SASS attacks. I view this as quite good > evidence in favour of random curves, over special curves. That's because you're simply ignoring all the contrary evidence. For example, if you insist on using random curves then Pohlig--Hellman will damage your security, probably quite severely. That's why everyone is actually using rare curves that resist the Pohlig--Hellman attack. In other words, rather than taking the uniform distribution over all elliptic curves of whatever size, ECC users are massively biasing the distribution of elliptic curves. The biased distribution discards the vast majority of elliptic curves: at least the curves vulnerable to Pohlig--Hellman, and nowadays also the curves that aren't twist-secure. Every sane risk analysis will conclude that this bias is a good idea. I say that it's a good idea to narrow the distribution even more, in fact down to a single curve, by taking the _smallest_ curve coefficient within the usual massively biased distribution. That's what Curve25519 does. This isn't just a performance win; it also prevents the sort of manipulation that's clearly possible for someone who claims to be "randomly" choosing curves from the wider distribution. Now imagine that there's no manipulation. How does this single-curve distribution compare in security to the larger (massively biased) distribution against some unknown attack? The correct answer is that we have no idea---maybe it's more secure, maybe it's less secure, maybe it's the same. You keep trying to trivialize this question by promoting the myth that more uniformity is safer. You present this as some sort of ill-defined dichotomy between "random" and "special", with "random" clearly being better. You take every break of a small curve class as support for your position, retroactively declaring the curves in the class to be "special", while you ignore the glaring counterexamples such as Pohlig--Hellman. > You gave an example that, under reasonable assumptions, with 2^(-30) > probability the ECDLP in Curve25519 could be solved in 2^64 > computations. No. What I actually wrote was "Suppose NSA knows---and knew in the late 1990s---a cost-2^64 attack that breaks one P1363-compliant 256-bit curve in a billion". I gave examples to illustrate that this "wouldn't be out of line with the spectrum of known ECC attacks". I then explained how this attack would have allowed NSA to _guarantee_ weakness of the NIST P-256 curve, while for an honestly generated curve the situation is obviously quite different. By misstating my assumptions as being specific to Curve25519, you're omitting the critical security impact on NIST P-256, and you're also promoting a misconception that ECC security analysis is curve-specific. > I do not see how those assumptions are reasonable, but even so, if > 2^30 people use Curve25519, then is that a good risk? I have no idea what you think you mean by "a good risk" (and I also have no idea why you're talking about the number of people---the discussion is about weak curves, not weak keys). In the situation that I actually described, there's no reason to think that the risk is different for Curve25519 and for an _honestly_ generated NIST P-256. The problem is that we don't know whether NIST P-256 was honestly generated. > Do you feel that the system-wide risk for RSA, or integer DH is comparable? There are improvements in index calculus all the time. Those have been continually dragging down the security level of RSA, which in turn has been dragging down the performance of RSA, which is exactly why modern RSA is so much slower than ECC. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago From brian@briansmith.org Fri Oct 11 17:51:31 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F2C11E81B7 for ; Fri, 11 Oct 2013 17:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gf++UoO6Q8-Q for ; Fri, 11 Oct 2013 17:51:23 -0700 (PDT) Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by ietfa.amsl.com (Postfix) with ESMTP id 58DA911E81A8 for ; Fri, 11 Oct 2013 17:51:20 -0700 (PDT) Received: by mail-qe0-f52.google.com with SMTP id w7so3702003qeb.25 for ; Fri, 11 Oct 2013 17:51:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=RHEpcAjQWl6Mv9hH3UD76NO5GSnsZPJ2QLBvRWV/S+w=; b=inOzBZa2iPgPzPHMSypvSBma1lYXYRaWMUa5LOmktwBzQ+t30Mh3J1aDDG1V3LGUoJ nSYic1GmHopNNoJLPUFuETim9/T7yYhcCDqU7Hmlob1EqDjvWIUkraKCDPrABY2KnfHP Z9gTSolmZqO7G/vZWCzjdcWcEwIrY0OEfHN/XUz/X+GPAj3G9SzeV6720WjPknmcpvw1 qCbTanEqj8JIR1a0hy2ihYmBe8QATCrpKIqEh8oy0vibP+hV7o85M8gZseGbtI+XUNiz d4MAyGe13f8z/ERP/FwbtJX15jWrkae0uSBXs0JICeTe+TNBptxavZbdtfaTNBk1MP3c hdvQ== X-Gm-Message-State: ALoCoQlDFXFpSInm0CFgjoM5D3XGKe7zh9hrGc3r8WBPsD9OTqtdmyjCKjuTymEgBobTfkLnYOUx MIME-Version: 1.0 X-Received: by 10.224.40.138 with SMTP id k10mr7372115qae.67.1381539079822; Fri, 11 Oct 2013 17:51:19 -0700 (PDT) Received: by 10.224.38.5 with HTTP; Fri, 11 Oct 2013 17:51:19 -0700 (PDT) X-Originating-IP: [63.245.219.50] Date: Fri, 11 Oct 2013 17:51:19 -0700 Message-ID: From: Brian Smith To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Cc: "" Subject: [TLS] Enforcing keyUsage restrictions (was Re: Safe ECC usage) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 00:51:32 -0000 On Thu, Oct 3, 2013 at 5:23 AM, Peter Gutmann wrote: > My code, in its default configuration, strictly enforces keyUsage. From this > I've found that both applications and CAs can set these bits more or less at > random, including completely illogical settings like keyAgreement for RSA > keys. I've also found, through trial-and-error, that many applications > completely ignore them and use the keys in whatever way they feel appropriate > (the situation for PKCS #12 files in particular is so bad that after fighting > it for awhile I had to turn off checking of keyUsage entirely). So this isn't > a case of copying an RSA template, it's broken software generating them and > equally broken software ignoring them. Software based on NSS's libssl has a pretty liberal interpretation of keyUsage, and this is something I'd like to correct in Firefox soon. In particular, I want to encourage CAs to offer ECDSA SSL certificates only with the digitalSignature bit set, and to provide the option to their customers to request RSA certificates with only the digitalSignature bit set. This should provide defense-in-depth from server misconfiguration for websites that want to switch exclusively to ephemeral key exchange. If you have any more specific information you could share regarding your experience with attempting strict(er) KU enforcement, it would be great if you could share it. (Not just Peter, but everybdoy.) Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) From SChokhani@cygnacom.com Fri Oct 11 18:16:04 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654B811E80FE for ; Fri, 11 Oct 2013 18:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wli8REjON2CO for ; Fri, 11 Oct 2013 18:16:00 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE4D11E80E2 for ; Fri, 11 Oct 2013 18:16:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.93,479,1378872000"; d="scan'208";a="785630" Received: from unknown (HELO scygexch10.cygnacom.com) ([10.4.60.26]) by ipedge1.cygnacom.com with ESMTP; 11 Oct 2013 21:15:58 -0400 Received: from SCYGEXCH10.cygnacom.com ([fe80::d8df:b0bd:28be:ad62]) by scygexch10.cygnacom.com ([fe80::d8df:b0bd:28be:ad62%15]) with mapi id 14.02.0247.003; Fri, 11 Oct 2013 21:15:58 -0400 From: Santosh Chokhani To: Brian Smith , Peter Gutmann Thread-Topic: [TLS] Enforcing keyUsage restrictions (was Re: Safe ECC usage) Thread-Index: Ac7G6JkxaJ8RpP5WSUe5BTrzM0zEDg== Date: Sat, 12 Oct 2013 01:15:57 +0000 Message-ID: <4262AC0DB9856847A2D00EF817E8113908E095@scygexch10.cygnacom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.24.99] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [TLS] Enforcing keyUsage restrictions (was Re: Safe ECC usage) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 01:16:04 -0000 DS bit for RSA based TLS server is not appropriate since the Server key is = used by the client to encrypt and never used for digital signature verifica= tion. I thought we set the DS bit in case the server acts as a client. As to the EC, that should depend on the cipher suite used. It could be ECD= H or ECDSA certificate and that should translate to key agreement or DS bit= respectively. -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Brian= Smith Sent: Friday, October 11, 2013 8:51 PM To: Peter Gutmann Cc: Subject: [TLS] Enforcing keyUsage restrictions (was Re: Safe ECC usage) On Thu, Oct 3, 2013 at 5:23 AM, Peter Gutmann w= rote: > My code, in its default configuration, strictly enforces keyUsage. =20 > From this I've found that both applications and CAs can set these bits=20 > more or less at random, including completely illogical settings like=20 > keyAgreement for RSA keys. I've also found, through trial-and-error,=20 > that many applications completely ignore them and use the keys in=20 > whatever way they feel appropriate (the situation for PKCS #12 files=20 > in particular is so bad that after fighting it for awhile I had to=20 > turn off checking of keyUsage entirely). So this isn't a case of=20 > copying an RSA template, it's broken software generating them and equally= broken software ignoring them. Software based on NSS's libssl has a pretty liberal interpretation of keyUs= age, and this is something I'd like to correct in Firefox soon. In particular, I want to encourage CAs to offer ECDSA SSL certificates only= with the digitalSignature bit set, and to provide the option to their cust= omers to request RSA certificates with only the digitalSignature bit set. T= his should provide defense-in-depth from server misconfiguration for websit= es that want to switch exclusively to ephemeral key exchange. If you have any more specific information you could share regarding your ex= perience with attempting strict(er) KU enforcement, it would be great if yo= u could share it. (Not just Peter, but everybdoy.) Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) ________________________= _______________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From code@funwithsoftware.org Fri Oct 11 19:18:18 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDFC021F9AE3 for ; Fri, 11 Oct 2013 19:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id honr0UHFcHVk for ; Fri, 11 Oct 2013 19:18:13 -0700 (PDT) Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by ietfa.amsl.com (Postfix) with ESMTP id EB80921F9AFE for ; Fri, 11 Oct 2013 19:18:12 -0700 (PDT) Received: from mail6.sea5.speakeasy.net (mail6.sea5.speakeasy.net [69.17.117.50]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id CB3CD1EE53DE for ; Fri, 11 Oct 2013 22:18:10 -0400 (EDT) Received: (qmail 21131 invoked from network); 12 Oct 2013 02:18:10 -0000 Received: by simscan 1.4.0 ppid: 25223, pid: 3332, t: 1.5250s scanners: clamav: 0.88.2/m:52/d:10739 spam: 3.0.4 Received: from dsl017-096-185.lax1.dsl.speakeasy.net (HELO [192.168.11.2]) (ppelleti@[69.17.96.185]) (envelope-sender ) by mail6.sea5.speakeasy.net (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 12 Oct 2013 02:18:08 -0000 Message-Id: From: Patrick Pelletier To: tls@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-4--489838866 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 11 Oct 2013 19:18:06 -0700 X-Mailer: Apple Mail (2.936) Subject: [TLS] cipher suite naming X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 02:18:19 -0000 --Apple-Mail-4--489838866 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I was just looking at the IANA cipher suite registry for TLS: http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 and noticed: 0xC0,0xA6 TLS_DHE_PSK_WITH_AES_128_CCM Y [RFC6655] 0xC0,0xA7 TLS_DHE_PSK_WITH_AES_256_CCM Y [RFC6655] 0xC0,0xAA TLS_PSK_DHE_WITH_AES_128_CCM_8 Y [RFC6655] 0xC0,0xAB TLS_PSK_DHE_WITH_AES_256_CCM_8 Y [RFC6655] Why are the _CCM variants called DHE_PSK while the _CCM_8 variants are called PSK_DHE? Shouldn't the _CCM_8 cipher suites be named the same as the _CCM cipher suites, except with _8 at the end? --Patrick --Apple-Mail-4--489838866 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I was just looking at the IANA = cipher suite registry for TLS:


and = noticed:


Why are the _CCM variants called DHE_PSK while the = _CCM_8 variants are called PSK_DHE?  Shouldn't the _CCM_8 cipher = suites be named the same as the _CCM cipher suites, except with _8 at = the = end?

--Patrick

= --Apple-Mail-4--489838866-- From mpg@elzevir.fr Fri Oct 11 20:23:53 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D829811E81CB for ; Fri, 11 Oct 2013 20:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yr64KQZl983B for ; Fri, 11 Oct 2013 20:23:48 -0700 (PDT) Received: from mordell.elzevir.fr (mordell.elzevir.fr [92.243.3.74]) by ietfa.amsl.com (Postfix) with ESMTP id D068511E810E for ; Fri, 11 Oct 2013 20:23:45 -0700 (PDT) Received: from thue.elzevir.fr (thue.elzevir.fr [88.165.216.11]) by mordell.elzevir.fr (Postfix) with ESMTPS id 24972160C7; Sat, 12 Oct 2013 05:23:43 +0200 (CEST) Received: from [192.168.0.124] (unknown [192.168.0.254]) by thue.elzevir.fr (Postfix) with ESMTPSA id 7D941299F7; Sat, 12 Oct 2013 05:23:34 +0200 (CEST) Message-ID: <5258C06B.4010804@elzevir.fr> Date: Sat, 12 Oct 2013 05:22:19 +0200 From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.0 MIME-Version: 1.0 To: Santosh Chokhani , Brian Smith , Peter Gutmann References: <4262AC0DB9856847A2D00EF817E8113908E095@scygexch10.cygnacom.com> In-Reply-To: <4262AC0DB9856847A2D00EF817E8113908E095@scygexch10.cygnacom.com> X-Enigmail-Version: 1.5.2 OpenPGP: id=98EED379; url=https://elzevir.fr/gpg/mpg.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [TLS] Enforcing keyUsage restrictions (was Re: Safe ECC usage) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 03:23:54 -0000 On 12/10/2013 03:15, Santosh Chokhani wrote: > DS bit for RSA based TLS server is not appropriate since the Server key is > used by the client to encrypt and never used for digital signature > verification. > Your seem to have RSA key exchange in mind, while Brian was talking about ECDHE_RSA or DHE_RSA key exchanges, where the server's RSA key is used to sign the parameters in the ServerKeyExchange message. The point was precisely that, if the keyUsage bits were respected, then setting only DS would force to use only forward secret key exchanges with this certificate. Manuel. From pgut001@cs.auckland.ac.nz Fri Oct 11 21:15:55 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713EB11E810F for ; Fri, 11 Oct 2013 21:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uP6quv4RPBGv for ; Fri, 11 Oct 2013 21:15:50 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 8B23E11E810E for ; Fri, 11 Oct 2013 21:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1381551347; x=1413087347; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=V6dgqOX4wp/ncLBN/IGk9ltIhgS/oYDj8DyZ8BEU5Mg=; b=iVjPnaaSu8wP1LcygpEI4PyEkM+XwxFaonoSNTTJY4BP+PQUam5gL2TK tg0Xk6ymD/HxEWmBvnPvyua5p3Xy060xr8bVmLDAp6Cld0MFELHQdgxy2 T0VE4Yz72+RPsovQ2mBAwAXjMJG6B6yCAIiuNeFXZM6cpwtBTLBpGML9J A=; X-IronPort-AV: E=Sophos;i="4.93,479,1378814400"; d="scan'208";a="217132135" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 12 Oct 2013 17:15:45 +1300 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.152]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0158.001; Sat, 12 Oct 2013 17:15:44 +1300 From: Peter Gutmann To: "" Thread-Topic: Enforcing keyUsage restrictions (was Re: [TLS] Safe ECC usage) Thread-Index: Ac7HAbhOe9qFEnASTrW7mk5sjsiEiQ== Date: Sat, 12 Oct 2013 04:15:44 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C735568ACD2@uxcn10-6.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Enforcing keyUsage restrictions (was Re: Safe ECC usage) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 04:15:55 -0000 Brian Smith writes:=0A= =0A= >If you have any more specific information you could share regarding your= =0A= >experience with attempting strict(er) KU enforcement, it would be great if= =0A= >you could share it. (Not just Peter, but everybdoy.)=0A= =0A= What were you after in general? I've just encountered lots of certs with= =0A= keyUsage bits that either prevented them from being used in the manner that= =0A= they were intended for (e.g. DS for an encryption key), or were illogical (= the=0A= aforementioned keyAgreement for an RSA key), or contradictory (kU said one= =0A= thing, eKU said another). Here's one example, from an intermediate CA usin= g=0A= RSA, directly signed by a trusted root CA:=0A= =0A= 624 14: SEQUENCE {=0A= 626 3: OBJECT IDENTIFIER keyUsage (2 5 29 15)=0A= 631 1: BOOLEAN TRUE=0A= 634 4: OCTET STRING, encapsulates {=0A= 636 2: BIT STRING 1 unused bit=0A= : '1111111'B=0A= : }=0A= : }=0A= =0A= Peter.= From mrex@sap.com Fri Oct 11 21:50:24 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C81121F9D74 for ; Fri, 11 Oct 2013 21:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.699 X-Spam-Level: X-Spam-Status: No, score=-9.699 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPYZjmRJaHFG for ; Fri, 11 Oct 2013 21:50:15 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4669421F9BD5 for ; Fri, 11 Oct 2013 21:50:14 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r9C4o16h007181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 12 Oct 2013 06:50:01 +0200 (MEST) In-Reply-To: <5258C06B.4010804@elzevir.fr> To: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= Date: Sat, 12 Oct 2013 06:50:01 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Message-Id: <20131012045001.94DFA1A9F9@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "" Subject: Re: [TLS] Enforcing keyUsage restrictions (was Re: Safe ECC usage) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 04:50:24 -0000 Manuel P=E9gouri=E9-Gonnard wrote: > Santosh Chokhani wrote: > > > > DS bit for RSA based TLS server is not appropriate since the Server key= is > > used by the client to encrypt and never used for digital signature > > verification. > > Your seem to have RSA key exchange in mind, while Brian was talking about > ECDHE_RSA or DHE_RSA key exchanges, where the server's RSA key is used to= sign > the parameters in the ServerKeyExchange message. The point was precisely = that, > if the keyUsage bits were respected, then setting only DS would force to = use > only forward secret key exchanges with this certificate. It might result in more TLS implementations to work around the interop problem and disable keyUsage checks like Peter did. Really, the best that could happen to the NSA is that everyone starts using ECDHE with Nist curves, aka Suite B. It just would not make sense (and amount to a huge waste of tax dollars) if these were _not_ bugged! The defects in (EC)DSA look rather accidental to me, and EC_Dual_DRNG was deliberatly set up to deceive folks on what was _really_ subverted. Considering how it is being used, ECDHE as part of Suite B is the single point of failure that is by far the most convenient, because it will work for large-scale passive eavesdropping. The original "digitally-signed" in SSLv3 and TLSv1.0 for RSA was using a conservative design, since it combined two hash algorithms (SHA1+MD5). In TLSv1.2 this was artificially neutered -- (rsa,md5) is a valid signature algorithm according to the TLSv1.2 spec, but ridiculously weak. If we were to "fix" TLS, then we should use combinations of algorithms more often, rather than less. Such as making it possible to use an RSA premaster secret XORed with a DHE or ECDHE shared secret. -Martin From yaronf.ietf@gmail.com Sat Oct 12 02:15:18 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62AB521E8150 for ; Sat, 12 Oct 2013 02:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZPSVFW176Qp for ; Sat, 12 Oct 2013 02:15:18 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7E18221E8140 for ; Sat, 12 Oct 2013 02:15:16 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id ez12so2115507wid.9 for ; Sat, 12 Oct 2013 02:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=7bjGQzp54Zn5wwprr8ZSKvmJv3GHuJDH1Ki0OKOUq/Y=; b=i8j90omB2F20JgzbvP529KqVAwSnGXZTE8tbYPoglHk8HNBjbPG81DAewK8qq8N292 z5+Csxr3nsx7h1pfQVH27nvZ7LD+uUs5crpjlx5yAP43hQ1Zkdh5q+e9xmANhQklvOXq tuQFRq0NwomrsdPOaJN7E4KT5aS4ximkgBfyPFC4FsGFZ3iMKT1zu742e1FLbK8FB6aV JuKv/rm5kqz4EYVD7tdc7W4RJx/BNrjFgkFxZ6gGE3N5gsS1FiqnR2CUDqUanQXtrJFK URoYnnbBQN3dWGd+bXHRhCbiQSaTsO5Ez022NQwrY7dDVO5WrJbedM36ImKHeVm80sWl XqNw== X-Received: by 10.194.250.6 with SMTP id yy6mr20967029wjc.13.1381569310874; Sat, 12 Oct 2013 02:15:10 -0700 (PDT) Received: from [10.0.0.8] ([109.65.223.20]) by mx.google.com with ESMTPSA id y20sm12758689wib.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 12 Oct 2013 02:15:10 -0700 (PDT) Message-ID: <5259131C.8040201@gmail.com> Date: Sat, 12 Oct 2013 12:15:08 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: mrex@sap.com, =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= References: <20131012045001.94DFA1A9F9@ld9781.wdf.sap.corp> In-Reply-To: <20131012045001.94DFA1A9F9@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [TLS] Safe ECC usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 09:15:18 -0000 Hi Martin, I like conspiracy theories as much as the next one, but the truth is, we simply don't know if NIST P-256 and friends are bugged. OTOH we do know that DHE-1024 is too weak. Luckily, TLS negotiates ECDHE curves. So on the server side you can prefer Brainpool and fall back to P-256. Or you can allow *only* Brainpool (or DJB's latest, or whatever) and switch to DHE or to plain RSA if the client doesn't have your favorite curve. The point is, ECDHE was engineered correctly with built-in crypto agility, so if we move to it we have a way forward. Thanks, Yaron On 10/12/2013 07:50 AM, Martin Rex wrote: >>> [...] > > Really, the best that could happen to the NSA is that everyone starts > using ECDHE with Nist curves, aka Suite B. It just would not make sense > (and amount to a huge waste of tax dollars) if these were _not_ bugged! > > The defects in (EC)DSA look rather accidental to me, and EC_Dual_DRNG was > deliberatly set up to deceive folks on what was _really_ subverted. > Considering how it is being used, ECDHE as part of Suite B is the > single point of failure that is by far the most convenient, because > it will work for large-scale passive eavesdropping. > > [...] > > -Martin From Johannes.Merkle@secunet.com Mon Oct 14 01:39:39 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E2521E815A for ; Mon, 14 Oct 2013 01:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyRDbzZ4wYDw for ; Mon, 14 Oct 2013 01:39:33 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id B6EB921E8149 for ; Mon, 14 Oct 2013 01:39:29 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id D47231A0071 for ; Mon, 14 Oct 2013 10:39:28 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YzKp3kflY0pv for ; Mon, 14 Oct 2013 10:39:27 +0200 (CEST) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id CE5901A006C for ; Mon, 14 Oct 2013 10:39:27 +0200 (CEST) Received: from [172.16.40.201] ([172.16.40.201]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Oct 2013 10:39:27 +0200 Message-ID: <525BADBD.8020007@secunet.com> Date: Mon, 14 Oct 2013 10:39:25 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "" X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Oct 2013 08:39:28.0042 (UTC) FILETIME=[E4EA48A0:01CEC8B8] Subject: [TLS] Using RSA PSS in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 08:39:39 -0000 While the current discussion on this list is about ECC, I would like to raise the question if it were not desirable to allow usage of provably secure RSA-PSS signatures from PKCS#1v2.1 in TLS. Of course, an issue with this idea is that, if we replace DHE_RSA and ECDHE_RSA with DHE_PSS and ECDHE_PSS, we end up with a whole bunch of new cipher suites. An alternative could be a new extension signaling the RSA version used (with PKCS#1v1.5 as default). Any thoughts on that? -- Johannes From hanno@hboeck.de Mon Oct 14 01:49:47 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C60321F9D2E for ; Mon, 14 Oct 2013 01:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGjtgUYJxiPn for ; Mon, 14 Oct 2013 01:49:42 -0700 (PDT) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) by ietfa.amsl.com (Postfix) with ESMTP id 50E1721F9DAA for ; Mon, 14 Oct 2013 01:49:27 -0700 (PDT) Received: from pc (91-64-48-143-dynip.superkabel.de [::ffff:91.64.48.143]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Mon, 14 Oct 2013 10:49:26 +0200 id 00000000000000E9.00000000525BB016.00006D56 Date: Mon, 14 Oct 2013 10:49:12 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: Johannes Merkle Message-ID: <20131014104912.7b19bd93@pc> In-Reply-To: <525BADBD.8020007@secunet.com> References: <525BADBD.8020007@secunet.com> X-Mailer: Claws Mail 3.9.2-dirty (GTK+ 2.24.21; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-27990-1381740566-0001-2" Cc: "" Subject: Re: [TLS] Using RSA PSS in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 08:49:47 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-27990-1381740566-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, 14 Oct 2013 10:39:25 +0200 Johannes Merkle wrote: > While the current discussion on this list is about ECC, I would like > to raise the question if it were not desirable to allow usage of > provably secure RSA-PSS signatures from PKCS#1v2.1 in TLS. >=20 > Of course, an issue with this idea is that, if we replace DHE_RSA and > ECDHE_RSA with DHE_PSS and ECDHE_PSS, we end up with a whole bunch of > new cipher suites. An alternative could be a new extension signaling > the RSA version used (with PKCS#1v1.5 as default). Why would you want to allow RSA in non-PSS-mode at all? And why on earth would you want to make the less secure PKCS#1v1.5 the default? There's simply zero advantage of PKCS#1v1.5 over PSS, except for legacy compatibility. But as PKCS#1v2.1 is now out eleven years, we could just start using it. I'd say: Preferrably with the next TLS version RSA should simply be switched to PSS. --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-27990-1381740566-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJSW7AOAAoJEKWIAHK7tR5CZUYQAK0DMvLUZu0e/UtjM8DqqBhU W4k3ZLOLUVien517OZ5Jn+RvaShWX1tqS5BWP5rMPuQPdYWDAgUAqsd6n8+ohY9r 6M9NxJ+CiffBAc0mJb7VruqwLZPHkHrTbiQQoYJNYuBh1KkngWDRESKTFs66bj9+ iSwEOpIQwyB3Tn7UyruODAS3BLZmlD6XImRkcCDHESb7f+hdCLvI5HhD/4HZ2iYH YyuiKmvWvOLcspFWdqknvnkvbjycVkDEMvDrWlT6eDefeDuXvBTm1pAoqHoRPTwZ Ihm7meHBI/vNp3yf77yzJ5Ns8qKm8PgX6mNfb98IjEznNeHd/eW8K2RCPCvCLUNV at6VstgFFl56JwzdOqD9Qd6DSGWNoRgouK4wovTrmMnLKFEIO/he77BLYkXAzPBo tSeX4n0wDb6gQyKZv/v0dTKdTL7rUGWcbisML5iw5KzmDYRJNWaCE7vn67S2ESBD FBM+QQkJn8ksvmxeLSn+0/maaTSmWeQsnJOEyh3USe37qCR4cufJU9THXd/r9Q41 u8JKtOe0xNRGL9gYhOxfv5l0dWKf+eQCNW49hvj78eUj5xRsXICAeYShq/KeJqjw WQ4SgGUFbvi/OFtfrfko2qS0FwyNr4Z5EVJstJirwc3pw3JxWxh/2s/suMZvo784 +WyOkVckvq7MIrhm6gQ8 =8hoh -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-27990-1381740566-0001-2-- From Johannes.Merkle@secunet.com Mon Oct 14 02:25:48 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE2521E8165 for ; Mon, 14 Oct 2013 02:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqT+bbq6mVqW for ; Mon, 14 Oct 2013 02:25:38 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 13D8121E816F for ; Mon, 14 Oct 2013 02:23:43 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id BEE231A0079; Mon, 14 Oct 2013 11:23:27 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wWHIwyqD9wKj; Mon, 14 Oct 2013 11:23:26 +0200 (CEST) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 7C8D51A0071; Mon, 14 Oct 2013 11:23:26 +0200 (CEST) Received: from [172.16.40.201] ([172.16.40.201]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Oct 2013 11:23:26 +0200 Message-ID: <525BB80D.6010800@secunet.com> Date: Mon, 14 Oct 2013 11:23:25 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: =?UTF-8?B?SGFubm8gQsO2Y2s=?= References: <525BADBD.8020007@secunet.com> <20131014104912.7b19bd93@pc> In-Reply-To: <20131014104912.7b19bd93@pc> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Oct 2013 09:23:26.0755 (UTC) FILETIME=[09B5EF30:01CEC8BF] Cc: "" Subject: Re: [TLS] Using RSA PSS in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 09:25:48 -0000 > Why would you want to allow RSA in non-PSS-mode at all? And why on earth would you want to make the less secure > PKCS#1v1.5 the default? There's simply zero advantage of PKCS#1v1.5 over PSS, except for legacy compatibility. legacy compatibility is exactly the point. Implementations must be prepared to communicate to servers / clients that do not support the new version. (Unfortunately, experience shows that it's not only legacy implementations that do not implement the latest algorithms; there may be even current ones.) And the absence of an extension is the only way to detect lack of support for it, thus, the default MUST be the old RSA version. Otherwise, I agree with your statement that PSS is superior to PKCS#1v1.5 in terms of security. Albeit the security issues with PKCS#1v1.5 signatures are not that bad as in case of encryption. > > I'd say: Preferrably with the next TLS version RSA should simply be switched to PSS. > Although I would welcome a TLS 1.3 deprecating PKCS#1v1.5 in favor of RSA-PSS, I didn't mean to wait for TLS 1.3. Given the slow pace of deployment of new TLS versions that may simply take too long. -- Johannes From Johannes.Merkle@secunet.com Mon Oct 14 02:33:50 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3C421E8196 for ; Mon, 14 Oct 2013 02:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.736 X-Spam-Level: X-Spam-Status: No, score=-2.736 tagged_above=-999 required=5 tests=[AWL=-0.803, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_PART_ALI=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmvzYnLIV33P for ; Mon, 14 Oct 2013 02:33:40 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3A00921F8FF8 for ; Mon, 14 Oct 2013 02:29:24 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id BCE9A1A0075 for ; Mon, 14 Oct 2013 11:29:22 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id uolW1fmcj20w for ; Mon, 14 Oct 2013 11:29:21 +0200 (CEST) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id A95FA1A0071 for ; Mon, 14 Oct 2013 11:29:21 +0200 (CEST) Received: from [172.16.40.201] ([172.16.40.201]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Oct 2013 11:29:21 +0200 Message-ID: <525BB972.40400@secunet.com> Date: Mon, 14 Oct 2013 11:29:22 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: tls@ietf.org References: <525BADBD.8020007@secunet.com> In-Reply-To: <525BADBD.8020007@secunet.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Oct 2013 09:29:21.0945 (UTC) FILETIME=[DD6BA090:01CEC8BF] Subject: Re: [TLS] Using RSA PSS in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 09:33:50 -0000 Johannes Merkle schrieb am 14.10.2013 10:39: > While the current discussion on this list is about ECC, I would like to raise the question if it were not desirable to > allow usage of provably secure RSA-PSS signatures from PKCS#1v2.1 in TLS. > > Of course, an issue with this idea is that, if we replace DHE_RSA and ECDHE_RSA with DHE_PSS and ECDHE_PSS, we end up > with a whole bunch of new cipher suites. An alternative could be a new extension signaling the RSA version used (with > PKCS#1v1.5 as default). > I forgot to mention that PSS introduces additional parameters. RFC 4055 defines RSASSA-PSS-params ::= SEQUENCE { hashAlgorithm [0] HashAlgorithm DEFAULT sha1Identifier, maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1Identifier, saltLength [2] INTEGER DEFAULT 20, trailerField [3] INTEGER DEFAULT 1 } This added flexibility is an even stronger argument for a new extension. -- Johannes From pgut001@cs.auckland.ac.nz Mon Oct 14 04:02:57 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3079E11E8187 for ; Mon, 14 Oct 2013 04:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKeDnnKQVQWe for ; Mon, 14 Oct 2013 04:02:50 -0700 (PDT) Received: from mx1.auckland.ac.nz (mx1.auckland.ac.nz [130.216.125.243]) by ietfa.amsl.com (Postfix) with ESMTP id B5D6C21F9DA1 for ; Mon, 14 Oct 2013 03:59:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1381748344; x=1413284344; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=IJp2gpk5gjcYB0EoJ+Q7eLPYir9xmlXwTgmumIF5t9g=; b=UOO1d9Uct3l3Jp8+OzVe+sUpMgS7XQJS6TWIMV5Tc+1basR2e/bSP3O7 j8W0L3jqtBBWC1ax+gJM627DGSduYRQPTQfk1zBBHgBc9+IrHLDGJcnTc evxmyjCmfG+rcMlwMP/OwjMMvsd3ffuZ3KyjPgHMvuLaPGx2HNq8p023y A=; X-IronPort-AV: E=Sophos;i="4.93,491,1378814400"; d="scan'208";a="278510614" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx1-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 14 Oct 2013 23:58:58 +1300 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.152]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0158.001; Mon, 14 Oct 2013 23:58:58 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] Using RSA PSS in TLS Thread-Index: Ac7Iy0cmtVCFe7PTS3iDqbQTmERuyQ== Date: Mon, 14 Oct 2013 10:58:57 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C735568B823@uxcn10-6.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Using RSA PSS in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 11:02:57 -0000 =3D?UTF-8?B?SGFubm8gQsO2Y2s=3D?=3D writes:=0A= =0A= >legacy compatibility is exactly the point. Implementations must be prepare= d=0A= >to communicate to servers / clients that do not support the new version.= =0A= =0A= Never underestimate that amount of weight that carries. There was an attem= pt,=0A= some years ago, to mandate RSA-PSS for certificates. It met with pretty mu= ch=0A= universal rejection, to the extent that people would probably ignore the=0A= requirement even if it was made a MUST in the spec (at the time it was=0A= described as "X9.42 all over again", a reference to another MUST that every= one=0A= ignored), and as a result was dropped.=0A= =0A= The problem with -PSS is that it doesn't real fix anything in -1.5 (I know= =0A= it's *theoretically* better, but unless you do -1.5 really badly there's no= =0A= practical weakness that would encourage an upgrade). Counting against that= is=0A= the near-insurmountable cost of a changeover (everyone has to redeploy glob= al=0A= crypto infrastructure from scratch).=0A= =0A= Peter.=0A= From SChokhani@cygnacom.com Mon Oct 14 04:13:46 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFD521F8947 for ; Mon, 14 Oct 2013 04:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7y0YGAd6V8QI for ; Mon, 14 Oct 2013 04:13:36 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 40A9021F8C7C for ; Mon, 14 Oct 2013 04:09:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.93,491,1378872000"; d="scan'208";a="797112" Received: from unknown (HELO scygexch10.cygnacom.com) ([10.4.60.26]) by ipedge1.cygnacom.com with ESMTP; 14 Oct 2013 07:09:01 -0400 Received: from SCYGEXCH10.cygnacom.com ([fe80::d8df:b0bd:28be:ad62]) by scygexch10.cygnacom.com ([fe80::d8df:b0bd:28be:ad62%15]) with mapi id 14.02.0247.003; Mon, 14 Oct 2013 07:09:00 -0400 From: Santosh Chokhani To: "" Thread-Topic: [TLS] Using RSA PSS in TLS Thread-Index: Ac7Iy0cmau3rIVDa0kibla0EcHL4eAAAj5uQ Date: Mon, 14 Oct 2013 11:08:59 +0000 Message-ID: <4262AC0DB9856847A2D00EF817E811390957D9@scygexch10.cygnacom.com> References: <9A043F3CF02CD34C8E74AC1594475C735568B823@uxcn10-6.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C735568B823@uxcn10-6.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.24.99] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Using RSA PSS in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 11:13:52 -0000 Since ECDHE_RSA or DHE_RSA says that the Server public key is RSA, the SPKI= in the Server certificate would indicate it is RSA 1.5 or PSS and you do n= ot need additional cipher suites. -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Peter= Gutmann Sent: Monday, October 14, 2013 6:59 AM To: Subject: Re: [TLS] Using RSA PSS in TLS =3D?UTF-8?B?SGFubm8gQsO2Y2s=3D?=3D writes: >legacy compatibility is exactly the point. Implementations must be=20 >prepared to communicate to servers / clients that do not support the new v= ersion. Never underestimate that amount of weight that carries. There was an attem= pt, some years ago, to mandate RSA-PSS for certificates. It met with prett= y much universal rejection, to the extent that people would probably ignore= the requirement even if it was made a MUST in the spec (at the time it was= described as "X9.42 all over again", a reference to another MUST that ever= yone ignored), and as a result was dropped. The problem with -PSS is that it doesn't real fix anything in -1.5 (I know = it's *theoretically* better, but unless you do -1.5 really badly there's no= practical weakness that would encourage an upgrade). Counting against tha= t is the near-insurmountable cost of a changeover (everyone has to redeploy= global crypto infrastructure from scratch). Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From SChokhani@cygnacom.com Mon Oct 14 04:19:45 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1AFE21F8235 for ; Mon, 14 Oct 2013 04:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZG2faGDu9VX for ; Mon, 14 Oct 2013 04:19:39 -0700 (PDT) Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id D1C6E11E8138 for ; Mon, 14 Oct 2013 04:19:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.93,491,1378872000"; d="scan'208";a="797161" Received: from unknown (HELO scygexch10.cygnacom.com) ([10.4.60.26]) by ipedge1.cygnacom.com with ESMTP; 14 Oct 2013 07:19:22 -0400 Received: from SCYGEXCH10.cygnacom.com ([fe80::d8df:b0bd:28be:ad62]) by scygexch10.cygnacom.com ([fe80::d8df:b0bd:28be:ad62%15]) with mapi id 14.02.0247.003; Mon, 14 Oct 2013 07:19:21 -0400 From: Santosh Chokhani To: "" Thread-Topic: [TLS] Using RSA PSS in TLS Thread-Index: Ac7Iy0cmau3rIVDa0kibla0EcHL4eAAAj5uQAABolkA= Date: Mon, 14 Oct 2013 11:19:20 +0000 Message-ID: <4262AC0DB9856847A2D00EF817E811390959B1@scygexch10.cygnacom.com> References: <9A043F3CF02CD34C8E74AC1594475C735568B823@uxcn10-6.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.24.99] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Using RSA PSS in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 11:19:45 -0000 Oops. My bad. I mixed up signature algorithms with SPKI. -----Original Message----- From: Santosh Chokhani=20 Sent: Monday, October 14, 2013 7:09 AM To: Subject: RE: [TLS] Using RSA PSS in TLS Since ECDHE_RSA or DHE_RSA says that the Server public key is RSA, the SPKI= in the Server certificate would indicate it is RSA 1.5 or PSS and you do n= ot need additional cipher suites. -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Peter= Gutmann Sent: Monday, October 14, 2013 6:59 AM To: Subject: Re: [TLS] Using RSA PSS in TLS =3D?UTF-8?B?SGFubm8gQsO2Y2s=3D?=3D writes: >legacy compatibility is exactly the point. Implementations must be=20 >prepared to communicate to servers / clients that do not support the new v= ersion. Never underestimate that amount of weight that carries. There was an attem= pt, some years ago, to mandate RSA-PSS for certificates. It met with prett= y much universal rejection, to the extent that people would probably ignore= the requirement even if it was made a MUST in the spec (at the time it was= described as "X9.42 all over again", a reference to another MUST that ever= yone ignored), and as a result was dropped. The problem with -PSS is that it doesn't real fix anything in -1.5 (I know = it's *theoretically* better, but unless you do -1.5 really badly there's no= practical weakness that would encourage an upgrade). Counting against tha= t is the near-insurmountable cost of a changeover (everyone has to redeploy= global crypto infrastructure from scratch). Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From rob.stradling@comodo.com Mon Oct 14 04:20:03 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2FD11E8185 for ; Mon, 14 Oct 2013 04:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OCdskul-LEE for ; Mon, 14 Oct 2013 04:19:49 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mmmail.mcr.colo.comodoca.net [91.209.196.71]) by ietfa.amsl.com (Postfix) with ESMTP id E399D11E8182 for ; Mon, 14 Oct 2013 04:19:27 -0700 (PDT) Received: (qmail 12232 invoked from network); 14 Oct 2013 11:19:12 -0000 Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 14 Oct 2013 11:19:12 -0000 Received: (qmail 24625 invoked by uid 1000); 14 Oct 2013 11:19:12 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Mon, 14 Oct 2013 12:19:12 +0100 Message-ID: <525BD330.6080100@comodo.com> Date: Mon, 14 Oct 2013 12:19:12 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Santosh Chokhani , "" References: <9A043F3CF02CD34C8E74AC1594475C735568B823@uxcn10-6.UoA.auckland.ac.nz> <4262AC0DB9856847A2D00EF817E811390957D9@scygexch10.cygnacom.com> In-Reply-To: <4262AC0DB9856847A2D00EF817E811390957D9@scygexch10.cygnacom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Using RSA PSS in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 11:20:14 -0000 On 14/10/13 12:08, Santosh Chokhani wrote: > Since ECDHE_RSA or DHE_RSA says that the Server public key is RSA, the SPKI in the Server certificate would indicate it is RSA 1.5 or PSS and you do not need additional cipher suites. But, when the server is deciding which of its 1 or more certs to send, how can it tell whether or not the client supports PSS? > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Peter Gutmann > Sent: Monday, October 14, 2013 6:59 AM > To: > Subject: Re: [TLS] Using RSA PSS in TLS > > =?UTF-8?B?SGFubm8gQsO2Y2s=?= writes: > >> legacy compatibility is exactly the point. Implementations must be >> prepared to communicate to servers / clients that do not support the new version. > > Never underestimate that amount of weight that carries. There was an attempt, some years ago, to mandate RSA-PSS for certificates. It met with pretty much universal rejection, to the extent that people would probably ignore the requirement even if it was made a MUST in the spec (at the time it was described as "X9.42 all over again", a reference to another MUST that everyone ignored), and as a result was dropped. > > The problem with -PSS is that it doesn't real fix anything in -1.5 (I know it's *theoretically* better, but unless you do -1.5 really badly there's no practical weakness that would encourage an upgrade). Counting against that is the near-insurmountable cost of a changeover (everyone has to redeploy global crypto infrastructure from scratch). > > Peter. > _______________________________________________ > 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 > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From SChokhani@cygnacom.com Mon Oct 14 04:22:24 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31CC021F9A5F for ; Mon, 14 Oct 2013 04:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4N9fs8iYotFq for ; Mon, 14 Oct 2013 04:22:20 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5313D11E8132 for ; Mon, 14 Oct 2013 04:21:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.93,491,1378872000"; d="scan'208";a="7080631" Received: from unknown (HELO scygexch10.cygnacom.com) ([10.4.60.26]) by ipedge2.cygnacom.com with ESMTP; 14 Oct 2013 07:21:50 -0400 Received: from SCYGEXCH10.cygnacom.com ([fe80::d8df:b0bd:28be:ad62]) by scygexch10.cygnacom.com ([fe80::d8df:b0bd:28be:ad62%15]) with mapi id 14.02.0247.003; Mon, 14 Oct 2013 07:21:49 -0400 From: Santosh Chokhani To: Rob Stradling , "" Thread-Topic: [TLS] Using RSA PSS in TLS Thread-Index: Ac7Iy0cmau3rIVDa0kibla0EcHL4eAAAj5uQAAjNuQAACFJpYA== Date: Mon, 14 Oct 2013 11:21:48 +0000 Message-ID: <4262AC0DB9856847A2D00EF817E811390959CF@scygexch10.cygnacom.com> References: <9A043F3CF02CD34C8E74AC1594475C735568B823@uxcn10-6.UoA.auckland.ac.nz> <4262AC0DB9856847A2D00EF817E811390957D9@scygexch10.cygnacom.com> <525BD330.6080100@comodo.com> In-Reply-To: <525BD330.6080100@comodo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.24.99] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Using RSA PSS in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 11:22:24 -0000 Rob, I was in error in the first place. So, the original question remains of ho= w to tell each other of PSS. -----Original Message----- From: Rob Stradling [mailto:rob.stradling@comodo.com]=20 Sent: Monday, October 14, 2013 7:19 AM To: Santosh Chokhani; Subject: Re: [TLS] Using RSA PSS in TLS On 14/10/13 12:08, Santosh Chokhani wrote: > Since ECDHE_RSA or DHE_RSA says that the Server public key is RSA, the SP= KI in the Server certificate would indicate it is RSA 1.5 or PSS and you do= not need additional cipher suites. But, when the server is deciding which of its 1 or more certs to send, how = can it tell whether or not the client supports PSS? > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of=20 > Peter Gutmann > Sent: Monday, October 14, 2013 6:59 AM > To: > Subject: Re: [TLS] Using RSA PSS in TLS > > =3D?UTF-8?B?SGFubm8gQsO2Y2s=3D?=3D writes: > >> legacy compatibility is exactly the point. Implementations must be=20 >> prepared to communicate to servers / clients that do not support the new= version. > > Never underestimate that amount of weight that carries. There was an att= empt, some years ago, to mandate RSA-PSS for certificates. It met with pre= tty much universal rejection, to the extent that people would probably igno= re the requirement even if it was made a MUST in the spec (at the time it w= as described as "X9.42 all over again", a reference to another MUST that ev= eryone ignored), and as a result was dropped. > > The problem with -PSS is that it doesn't real fix anything in -1.5 (I kno= w it's *theoretically* better, but unless you do -1.5 really badly there's = no practical weakness that would encourage an upgrade). Counting against t= hat is the near-insurmountable cost of a changeover (everyone has to redepl= oy global crypto infrastructure from scratch). > > Peter. > _______________________________________________ > 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 > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From mrex@sap.com Mon Oct 14 05:12:44 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A736311E817E for ; Mon, 14 Oct 2013 05:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.899 X-Spam-Level: X-Spam-Status: No, score=-9.899 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sD731TEO-v5G for ; Mon, 14 Oct 2013 05:12:39 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 34AD111E8138 for ; Mon, 14 Oct 2013 05:12:35 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r9ECCYLi025617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Oct 2013 14:12:34 +0200 (MEST) In-Reply-To: <525BADBD.8020007@secunet.com> To: Johannes Merkle Date: Mon, 14 Oct 2013 14:12:34 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20131014121234.3936B1A9F9@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "" Subject: Re: [TLS] Using RSA PSS in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 12:12:44 -0000 Johannes Merkle wrote: > > While the current discussion on this list is about ECC, > I would like to raise the question if it were not desirable to > allow usage of provably secure RSA-PSS signatures from PKCS#1v2.1 in TLS. > > Of course, an issue with this idea is that, if we replace DHE_RSA and > ECDHE_RSA with DHE_PSS and ECDHE_PSS, we end up > with a whole bunch of new cipher suites. An alternative could be a > new extension signaling the RSA version used (with > PKCS#1v1.5 as default). > > Any thoughts on that? RSA-PSS would apply only to the DHE_RSA variants, for the vanilla RSA ciphersuites, one would need RSA-OAEP instead, and it seems that using a traditional RSA key/cert for both, signature and encryption is somewhat incompatible with RSA-PSS/RSA-OAEP -- when signaling is through the AlgorithmIdentifier in SPKI of the entity certificate. Having to support two seperate server certificate (different by algorithm) would have a huge impact on - TLS implementations - administrative UIs - server administration procedures - CA procedures What exactly is the real and serious problem that such a HUGE change would be trying to fix? -Martin From Johannes.Merkle@secunet.com Mon Oct 14 05:19:52 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C97221F9BF3 for ; Mon, 14 Oct 2013 05:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.435 X-Spam-Level: X-Spam-Status: No, score=-3.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ph0cjNJz5C54 for ; Mon, 14 Oct 2013 05:19:47 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id ADD2121F9B21 for ; Mon, 14 Oct 2013 05:19:47 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 9E27D1A0080; Mon, 14 Oct 2013 14:19:45 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vsPzl9fcAJJG; Mon, 14 Oct 2013 14:19:44 +0200 (CEST) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 057D91A007E; Mon, 14 Oct 2013 14:19:44 +0200 (CEST) Received: from [10.208.1.57] ([10.208.1.57]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Oct 2013 14:19:43 +0200 Message-ID: <525BE15E.3040008@secunet.com> Date: Mon, 14 Oct 2013 14:19:42 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Santosh Chokhani , "" References: <9A043F3CF02CD34C8E74AC1594475C735568B823@uxcn10-6.UoA.auckland.ac.nz> <4262AC0DB9856847A2D00EF817E811390959B1@scygexch10.cygnacom.com> In-Reply-To: <4262AC0DB9856847A2D00EF817E811390959B1@scygexch10.cygnacom.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Oct 2013 12:19:43.0283 (UTC) FILETIME=[A9D00830:01CEC8D7] Subject: Re: [TLS] Using RSA PSS in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 12:19:52 -0000 Santosh Chokhani schrieb am 14.10.2013 13:19: > Oops. My bad. I mixed up signature algorithms with SPKI. If the certificate contains id-RSASSA-PSS (RFC 4055) in SubjectPublicKeyInfo, the client could tell, but there are several issues with that approach: - The use of id-RSASSA-PSS is optional - The specification of the PSS-parameters in id-RSASSA-PSS is optional (RFC 5756) - Most implementations don't support id-RSASSA-PSS (see http://rsapss.hboeck.de/rsapss-1.0.2.pdf) As far as I understand RFC 5246, the Server Key Exchange message specifies the signature algorithm only by the enum { dhe_dss, dhe_rsa, dh_anon, rsa, dh_dss, dh_rsa, ...}. Johannes -- Johannes From pgut001@cs.auckland.ac.nz Mon Oct 14 05:31:16 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB80411E8127 for ; Mon, 14 Oct 2013 05:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ri7BPuA7wj3v for ; Mon, 14 Oct 2013 05:31:11 -0700 (PDT) Received: from mx1.auckland.ac.nz (mx1.auckland.ac.nz [130.216.125.243]) by ietfa.amsl.com (Postfix) with ESMTP id 7120921F9A19 for ; Mon, 14 Oct 2013 05:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1381753871; x=1413289871; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=0lMf7bFrk5zm2l/chx7/KlJyQykuGAsiTkRcSZsrzEI=; b=oPTgGkiIlMBmwdnXEXGaP+SSjB0GMyucyptA184a3TBoq9U2f5TkNBR/ kpbS1GVeR5N/8+7p6L/il1VuxP6m6osZlY8iSs3CbmFqO/KJNS2xP61j2 BmKL8yY9Id7/ZcHdygQK3SCm/yjRndMLLM1ongyFNDR6c1wm1HgVogtLs Q=; X-IronPort-AV: E=Sophos;i="4.93,492,1378814400"; d="scan'208";a="278528666" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx1-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 15 Oct 2013 01:31:10 +1300 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.152]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.03.0158.001; Tue, 15 Oct 2013 01:31:10 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] Using RSA PSS in TLS Thread-Index: Ac7I2UKPCC12tyPVSVWpIjp0rVDgDQ== Date: Mon, 14 Oct 2013 12:31:09 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C735568B8CB@uxcn10-6.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Using RSA PSS in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 12:31:17 -0000 Martin Rex writes:=0A= =0A= >[...] when signaling is through the AlgorithmIdentifier in SPKI of the ent= ity=0A= >certificate.=0A= =0A= See also my earlier post about PKIX members pretty much universally rejecti= ng=0A= -PSS in certs. You're not going to be able to address this issue by making= it=0A= another WG's problem.=0A= =0A= (How many public-CA-issued -PSS certs have people seen in the wild?).=0A= =0A= Peter.=0A= From Johannes.Merkle@secunet.com Mon Oct 14 05:36:11 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3875621E8162 for ; Mon, 14 Oct 2013 05:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ciYLcFOQKz5 for ; Mon, 14 Oct 2013 05:36:06 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id D55E921E8093 for ; Mon, 14 Oct 2013 05:36:05 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 712251A0071; Mon, 14 Oct 2013 14:36:04 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xa_rLHjHoGQk; Mon, 14 Oct 2013 14:36:03 +0200 (CEST) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 5B7D31A0078; Mon, 14 Oct 2013 14:36:03 +0200 (CEST) Received: from [10.208.1.57] ([10.208.1.57]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Oct 2013 14:36:03 +0200 Message-ID: <525BE533.8040805@secunet.com> Date: Mon, 14 Oct 2013 14:36:03 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mrex@sap.com, "" References: <20131014121234.3936B1A9F9@ld9781.wdf.sap.corp> In-Reply-To: <20131014121234.3936B1A9F9@ld9781.wdf.sap.corp> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Oct 2013 12:36:03.0337 (UTC) FILETIME=[F1F86790:01CEC8D9] Subject: Re: [TLS] Using RSA PSS in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 12:36:11 -0000 > RSA-PSS would apply only to the DHE_RSA variants, for the vanilla > RSA ciphersuites, one would need RSA-OAEP instead, and it seems > that using a traditional RSA key/cert for both, signature and > encryption is somewhat incompatible with RSA-PSS/RSA-OAEP -- when > signaling is through the AlgorithmIdentifier in SPKI of the > entity certificate. As I wrote to Santosh, the PSS AlgorithmIdentifier in SPKI is only optional and hardly supported. TLS-Servers should get a certificate with the usual rsaPublicKey AlgorithmIdentifier in SPKI, which can be used for any RSA operation, including PSS, OAEP and even signature and encryption according to PKCS#1v1.5. > > Having to support two seperate server certificate (different by algorithm) > would have a huge impact on > - TLS implementations > - administrative UIs > - server administration procedures > - CA procedures > > What exactly is the real and serious problem that such a HUGE change > would be trying to fix? > No huge change implied by the change. I admit there is no big issue with old RSA, it it just anticipation of potential future attacks by using a provably secure algorithm. -- Johannes From Johannes.Merkle@secunet.com Mon Oct 14 08:46:21 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5573111E8127 for ; Mon, 14 Oct 2013 08:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naiLS1s03FT9 for ; Mon, 14 Oct 2013 08:46:05 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id C8CD711E813F for ; Mon, 14 Oct 2013 08:46:01 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 432FF1A0076 for ; Mon, 14 Oct 2013 17:45:59 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jdzeN-2j7v4F for ; Mon, 14 Oct 2013 17:45:57 +0200 (CEST) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 4C15C1A0071 for ; Mon, 14 Oct 2013 17:45:57 +0200 (CEST) Received: from [10.208.1.57] ([10.208.1.57]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Oct 2013 17:45:57 +0200 Message-ID: <525C11B5.2050604@secunet.com> Date: Mon, 14 Oct 2013 17:45:57 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "" X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Oct 2013 15:45:57.0682 (UTC) FILETIME=[79877920:01CEC8F4] Subject: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 15:46:21 -0000 jaust in case that someone hasn't noticed it: our draft on using the Brainpool curves in TLS has been published as RFC 7027 http://www.rfc-editor.org/rfc/rfc7027.txt -- Johannes From code@funwithsoftware.org Tue Oct 15 00:33:07 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C8621E80B2 for ; Tue, 15 Oct 2013 00:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nn5qBm04dmwz for ; Tue, 15 Oct 2013 00:33:02 -0700 (PDT) Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by ietfa.amsl.com (Postfix) with ESMTP id 480FA11E8119 for ; Tue, 15 Oct 2013 00:33:01 -0700 (PDT) Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.48]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id F3C101EE4F8E for ; Tue, 15 Oct 2013 03:32:58 -0400 (EDT) Received: (qmail 25221 invoked from network); 15 Oct 2013 07:32:58 -0000 Received: by simscan 1.4.0 ppid: 25713, pid: 17193, t: 3.3579s scanners: clamav: 0.88.2/m:52/d:10739 spam: 3.0.4 Received: from dsl017-096-185.lax1.dsl.speakeasy.net (HELO PatrickMBP.local) (ppelleti@[69.17.96.185]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 15 Oct 2013 07:32:55 -0000 Message-ID: <525CEFA4.2030903@funwithsoftware.org> Date: Tue, 15 Oct 2013 00:32:52 -0700 From: Patrick Pelletier User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "TLS@ietf.org (tls@ietf.org)" References: <525C11B5.2050604@secunet.com> In-Reply-To: <525C11B5.2050604@secunet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 07:33:07 -0000 On 10/14/13 8:45 AM, Johannes Merkle wrote: > jaust in case that someone hasn't noticed it: our draft on using the Brainpool curves in TLS has been published as RFC 7027 > http://www.rfc-editor.org/rfc/rfc7027.txt Is support available in any TLS libraries yet? Do we know which libraries are planning on adding support for Brainpool? --Patrick From pgut001@cs.auckland.ac.nz Tue Oct 15 03:11:30 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D32F21E80B8 for ; Tue, 15 Oct 2013 03:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJ+AhUuRZq9c for ; Tue, 15 Oct 2013 03:11:25 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id D0E7711E81BB for ; Tue, 15 Oct 2013 03:11:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1381831883; x=1413367883; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=y5LfbVuZNXtVaClgkEule2Tmt34MAvHb+sJLcJxxjFg=; b=FXG1koXutv4xO5mj8+AwnpAS9QRKlitInGyfOs6WhgQ4N3vfVZwwgDXX V5IZabGFTRsz9ygHO+vJ6NrVuNp2AcYylLgiK3fotnwXhUQvyWEeluc6J KdWw8wlobOFYWzSz8PjLUHErMg6BpRsBzIWZpmx4YyT+XgQMrxqonAbnM 0=; X-IronPort-AV: E=Sophos;i="4.93,498,1378814400"; d="scan'208";a="217609548" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 15 Oct 2013 23:11:20 +1300 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.152]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0158.001; Tue, 15 Oct 2013 23:11:19 +1300 From: Peter Gutmann To: "" Thread-Topic: [TLS] Using Brainpool curves in TLS Thread-Index: Ac7JjuOeKwdYWaNLTsiJdWJIhODNVQ== Date: Tue, 15 Oct 2013 10:11:18 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C735568C0BF@uxcn10-6.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 10:11:30 -0000 Patrick Pelletier writes:=0A= >On 10/14/13 8:45 AM, Johannes Merkle wrote:=0A= >> jaust in case that someone hasn't noticed it: our draft on using the Bra= inpool curves in TLS has been published as RFC 7027=0A= >> http://www.rfc-editor.org/rfc/rfc7027.txt=0A= >=0A= >Is support available in any TLS libraries yet? Do we know which libraries= =0A= >are planning on adding support for Brainpool?=0A= =0A= Present in my code but commented out due to lack of anything to test agains= t.=0A= =0A= Peter.=0A= =0A= From lists@drh-consultancy.co.uk Tue Oct 15 03:46:34 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6F921F9BAD for ; Tue, 15 Oct 2013 03:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ow8w8JwW9NxH for ; Tue, 15 Oct 2013 03:46:30 -0700 (PDT) Received: from claranet-outbound-smtp05.uk.clara.net (claranet-outbound-smtp05.uk.clara.net [195.8.89.38]) by ietfa.amsl.com (Postfix) with ESMTP id BB07A21F9E96 for ; Tue, 15 Oct 2013 03:46:17 -0700 (PDT) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:13233 helo=[192.168.7.9]) by relay05.mail.eu.clara.net (relay.clara.net [213.253.3.45]:10465) with esmtpa (authdaemon_plain:drh) id 1VW28k-0003re-HB for tls@ietf.org (return-path ); Tue, 15 Oct 2013 10:46:14 +0000 Message-ID: <525D1CF4.9020306@drh-consultancy.co.uk> Date: Tue, 15 Oct 2013 11:46:12 +0100 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: tls@ietf.org References: <525C11B5.2050604@secunet.com> <525CEFA4.2030903@funwithsoftware.org> In-Reply-To: <525CEFA4.2030903@funwithsoftware.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 10:46:34 -0000 On 15/10/2013 08:32, Patrick Pelletier wrote: > On 10/14/13 8:45 AM, Johannes Merkle wrote: >> jaust in case that someone hasn't noticed it: our draft on using the Brainpool >> curves in TLS has been published as RFC 7027 >> http://www.rfc-editor.org/rfc/rfc7027.txt > > Is support available in any TLS libraries yet? Do we know which libraries are > planning on adding support for Brainpool? > Just added support to the OpenSSL development version. Would be interested in any test servers for interop testing. Steve. -- -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From p.j.bakker@offspark.com Tue Oct 15 03:50:44 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5975F11E81D0 for ; Tue, 15 Oct 2013 03:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37KEtdR-P5fR for ; Tue, 15 Oct 2013 03:50:39 -0700 (PDT) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id D8A7A11E81CB for ; Tue, 15 Oct 2013 03:50:36 -0700 (PDT) Received: from a82-161-132-220.adsl.xs4all.nl ([82.161.132.220] helo=Slimpy) by vps2.brainspark.nl with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1VW268-0008WN-Py; Tue, 15 Oct 2013 12:43:33 +0200 From: "Paul Bakker" To: "'Peter Gutmann'" , References: <9A043F3CF02CD34C8E74AC1594475C735568C0BF@uxcn10-6.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C735568C0BF@uxcn10-6.UoA.auckland.ac.nz> Date: Tue, 15 Oct 2013 12:50:25 +0200 Message-ID: <00ce01cec994$5dfe9030$19fbb090$@offspark.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHRSjraq0h77TS63YpXx8MO3MKzOZnwk4qw Content-Language: nl X-SA-Exim-Connect-IP: 82.161.132.220 X-SA-Exim-Mail-From: p.j.bakker@offspark.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 10:50:44 -0000 > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Peter > Gutmann > Sent: dinsdag 15 oktober 2013 12:11 > To: > Subject: Re: [TLS] Using Brainpool curves in TLS > > Patrick Pelletier writes: > >On 10/14/13 8:45 AM, Johannes Merkle wrote: > >> jaust in case that someone hasn't noticed it: our draft on using the > >> Brainpool curves in TLS has been published as RFC 7027 > >> http://www.rfc-editor.org/rfc/rfc7027.txt > > > >Is support available in any TLS libraries yet? Do we know which > >libraries are planning on adding support for Brainpool? > > Present in my code but commented out due to lack of anything to test > against. Chicken and egg problem :) Our private repo has brainpool support included for PolarSSL. We are wrapping up our release right now. 99% certainty: release of Brainpool support within 2 hours. High certainty on correctness due to the way our library is structured and our testing framework. Paul From p.j.bakker@offspark.com Tue Oct 15 03:56:22 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBDD11E81CE for ; Tue, 15 Oct 2013 03:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKR6w1HlstIp for ; Tue, 15 Oct 2013 03:56:17 -0700 (PDT) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 17EA011E81CC for ; Tue, 15 Oct 2013 03:56:13 -0700 (PDT) Received: from a82-161-132-220.adsl.xs4all.nl ([82.161.132.220] helo=Slimpy) by vps2.brainspark.nl with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1VW2BZ-00005q-PC; Tue, 15 Oct 2013 12:49:10 +0200 From: "Paul Bakker" To: "'Dr Stephen Henson'" , "'Peter Gutmann'" References: <525C11B5.2050604@secunet.com> <525CEFA4.2030903@funwithsoftware.org> <525D1CF4.9020306@drh-consultancy.co.uk> In-Reply-To: <525D1CF4.9020306@drh-consultancy.co.uk> Date: Tue, 15 Oct 2013 12:56:02 +0200 Message-ID: <00d101cec995$26d9ef90$748dceb0$@offspark.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHDBObbigI3LWPKEzbQpv5mFKXNvgFN9JsgApDPLc2Z7inCoA== Content-Language: nl X-SA-Exim-Connect-IP: 82.161.132.220 X-SA-Exim-Mail-From: p.j.bakker@offspark.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Cc: tls@ietf.org Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 10:56:22 -0000 For now I've just put up a test server at: 141.138.204.107:4433 Running PolarSSL 1.3.1 with Brainpool curves supported.. Let me know if you run into any issues.. Paul > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Dr > Stephen Henson > Sent: dinsdag 15 oktober 2013 12:46 > To: tls@ietf.org > Subject: Re: [TLS] Using Brainpool curves in TLS > > On 15/10/2013 08:32, Patrick Pelletier wrote: > > On 10/14/13 8:45 AM, Johannes Merkle wrote: > >> jaust in case that someone hasn't noticed it: our draft on using the > >> Brainpool curves in TLS has been published as RFC 7027 > >> http://www.rfc-editor.org/rfc/rfc7027.txt > > > > Is support available in any TLS libraries yet? Do we know which > > libraries are planning on adding support for Brainpool? > > > > Just added support to the OpenSSL development version. Would be > interested in any test servers for interop testing. > > Steve. > -- > -- > Dr Stephen N. Henson. > Core developer of the OpenSSL project: http://www.openssl.org/ > Freelance consultant see: http://www.drh-consultancy.co.uk/ > Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From lists@drh-consultancy.co.uk Tue Oct 15 04:15:17 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E5B11E81D5 for ; Tue, 15 Oct 2013 04:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ph4XTf+78BFf for ; Tue, 15 Oct 2013 04:15:11 -0700 (PDT) Received: from claranet-outbound-smtp05.uk.clara.net (claranet-outbound-smtp05.uk.clara.net [195.8.89.38]) by ietfa.amsl.com (Postfix) with ESMTP id A034E11E81D7 for ; Tue, 15 Oct 2013 04:15:05 -0700 (PDT) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:4856 helo=[192.168.7.9]) by relay05.mail.eu.clara.net (relay.clara.net [213.253.3.45]:10465) with esmtpa (authdaemon_plain:drh) id 1VW2aM-0008KH-JD (return-path ); Tue, 15 Oct 2013 11:14:47 +0000 Message-ID: <525D23A5.3080600@drh-consultancy.co.uk> Date: Tue, 15 Oct 2013 12:14:45 +0100 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Paul Bakker , 'Peter Gutmann' References: <525C11B5.2050604@secunet.com> <525CEFA4.2030903@funwithsoftware.org> <525D1CF4.9020306@drh-consultancy.co.uk> <00d101cec995$26d9ef90$748dceb0$@offspark.com> In-Reply-To: <00d101cec995$26d9ef90$748dceb0$@offspark.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 11:15:17 -0000 On 15/10/2013 11:56, Paul Bakker wrote: > For now I've just put up a test server at: > 141.138.204.107:4433 > > Running PolarSSL 1.3.1 with Brainpool curves supported.. > > Let me know if you run into any issues.. > Tried it with the three Brainpool curves and OpenSSL: no problems. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From p.j.bakker@offspark.com Tue Oct 15 04:16:38 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5444811E81D5 for ; Tue, 15 Oct 2013 04:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftCnSHXwUTGz for ; Tue, 15 Oct 2013 04:16:28 -0700 (PDT) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 6E66821E80C0 for ; Tue, 15 Oct 2013 04:16:23 -0700 (PDT) Received: from a82-161-132-220.adsl.xs4all.nl ([82.161.132.220] helo=Slimpy) by vps2.brainspark.nl with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1VW2V8-0000An-Rt; Tue, 15 Oct 2013 13:09:23 +0200 From: "Paul Bakker" To: "'Dr Stephen Henson'" , "'Peter Gutmann'" References: <525C11B5.2050604@secunet.com> <525CEFA4.2030903@funwithsoftware.org> <525D1CF4.9020306@drh-consultancy.co.uk> <00d101cec995$26d9ef90$748dceb0$@offspark.com> <525D23A5.3080600@drh-consultancy.co.uk> In-Reply-To: <525D23A5.3080600@drh-consultancy.co.uk> Date: Tue, 15 Oct 2013 13:16:13 +0200 Message-ID: <017501cec997$f9edd0c0$edc97240$@offspark.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHDBObbigI3LWPKEzbQpv5mFKXNvgFN9JsgApDPLc0CC7ht0AGPegjTmdFWWxA= Content-Language: nl X-SA-Exim-Connect-IP: 82.161.132.220 X-SA-Exim-Mail-From: p.j.bakker@offspark.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Cc: tls@ietf.org Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 11:16:38 -0000 Cool.. First interop proof for both :) > -----Original Message----- > From: Dr Stephen Henson [mailto:lists@drh-consultancy.co.uk] > Sent: dinsdag 15 oktober 2013 13:15 > To: Paul Bakker; 'Peter Gutmann' > Cc: tls@ietf.org > Subject: Re: [TLS] Using Brainpool curves in TLS > > On 15/10/2013 11:56, Paul Bakker wrote: > > For now I've just put up a test server at: > > 141.138.204.107:4433 > > > > Running PolarSSL 1.3.1 with Brainpool curves supported.. > > > > Let me know if you run into any issues.. > > > > Tried it with the three Brainpool curves and OpenSSL: no problems. > > Steve. > -- > Dr Stephen N. Henson. > Core developer of the OpenSSL project: http://www.openssl.org/ > Freelance consultant see: http://www.drh-consultancy.co.uk/ > Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From pgut001@cs.auckland.ac.nz Tue Oct 15 04:18:25 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B51911E81D6 for ; Tue, 15 Oct 2013 04:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Wi8idmHAvLj for ; Tue, 15 Oct 2013 04:18:20 -0700 (PDT) Received: from mx1.auckland.ac.nz (mx1.auckland.ac.nz [130.216.125.243]) by ietfa.amsl.com (Postfix) with ESMTP id 0D91F11E81D3 for ; Tue, 15 Oct 2013 04:18:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1381835893; x=1413371893; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=rRJww/o1XfHeK7435yGIV5IYqEZPFSlRQ2BeGFkl/us=; b=anZrUDzZqdzhurk29/Z7wMCvdFpfRwb8458nyrEMJSc9ODAn7PWhnWbK EOC/FzEthMbx6ojNSRBaAKooM35MTE8CNPEGvWeXqtmgs7qtP/cwaYNns 1h5rKlqHrJ7vHUlhZ7RLSNZolv4B44ZZwwIzKhqGJavLoysIkYbl/ZrpA 4=; X-IronPort-AV: E=Sophos;i="4.93,498,1378814400"; d="scan'208";a="278880016" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx1-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 16 Oct 2013 00:18:12 +1300 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.152]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0158.001; Wed, 16 Oct 2013 00:18:12 +1300 From: Peter Gutmann To: "" Thread-Topic: tls@ietf.org Thread-Index: Ac7JmDulWbve1A4ISOOYNVATZU4dcg== Date: Tue, 15 Oct 2013 11:18:11 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C735568C18B@uxcn10-6.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [TLS] tls@ietf.org X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 11:18:25 -0000 Paul Bakker writes:=0A= =0A= >For now I've just put up a test server at: 141.138.204.107:4433=0A= >=0A= >Running PolarSSL 1.3.1 with Brainpool curves supported..=0A= =0A= Thanks! What's the procedure for ensuring that we're getting Brainpool cur= ves=0A= rather than fallback to something else, list the Brainpool ones first in th= e=0A= hello, disable all but Brainpool curves, ... ?=0A= =0A= Peter.=0A= From p.j.bakker@offspark.com Tue Oct 15 04:20:29 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879B821F9DE1 for ; Tue, 15 Oct 2013 04:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmkQhKUGyVor for ; Tue, 15 Oct 2013 04:20:24 -0700 (PDT) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 43E2221F9A61 for ; Tue, 15 Oct 2013 04:20:24 -0700 (PDT) Received: from a82-161-132-220.adsl.xs4all.nl ([82.161.132.220] helo=Slimpy) by vps2.brainspark.nl with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1VW2Z3-0000Bt-6e; Tue, 15 Oct 2013 13:13:25 +0200 From: "Paul Bakker" To: "'Peter Gutmann'" , References: <9A043F3CF02CD34C8E74AC1594475C735568C18B@uxcn10-6.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C735568C18B@uxcn10-6.UoA.auckland.ac.nz> Date: Tue, 15 Oct 2013 13:20:17 +0200 Message-ID: <017701cec998$8a5c2670$9f147350$@offspark.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKcPlW3Xzdco8E15JMS+FjTzT8ahZhatC2A Content-Language: nl X-SA-Exim-Connect-IP: 82.161.132.220 X-SA-Exim-Mail-From: p.j.bakker@offspark.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Subject: Re: [TLS] tls@ietf.org X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 11:20:29 -0000 The server enforces server preferences. I did not tweak it for brainpool specifically at the moment. So if you want brainpool: disable all but.. Paul > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Peter > Gutmann > Sent: dinsdag 15 oktober 2013 13:18 > To: > Subject: [TLS] tls@ietf.org > > Paul Bakker writes: > > >For now I've just put up a test server at: 141.138.204.107:4433 > > > >Running PolarSSL 1.3.1 with Brainpool curves supported.. > > Thanks! What's the procedure for ensuring that we're getting Brainpool > curves rather than fallback to something else, list the Brainpool ones first in > the hello, disable all but Brainpool curves, ... ? > > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From lists@drh-consultancy.co.uk Tue Oct 15 04:24:15 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5A021F9FFF for ; Tue, 15 Oct 2013 04:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrNzLPlq3-0r for ; Tue, 15 Oct 2013 04:24:10 -0700 (PDT) Received: from claranet-outbound-smtp06.uk.clara.net (claranet-outbound-smtp06.uk.clara.net [195.8.89.39]) by ietfa.amsl.com (Postfix) with ESMTP id C7AAA21F9AE7 for ; Tue, 15 Oct 2013 04:24:09 -0700 (PDT) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:9128 helo=[192.168.7.9]) by relay06.mail.eu.clara.net (relay.clara.net [213.253.3.46]:10465) with esmtpa (authdaemon_plain:drh) id 1VW2jD-0007WB-MR (return-path ); Tue, 15 Oct 2013 11:23:56 +0000 Message-ID: <525D25CA.4090002@drh-consultancy.co.uk> Date: Tue, 15 Oct 2013 12:23:54 +0100 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Paul Bakker , 'Peter Gutmann' , tls@ietf.org References: <9A043F3CF02CD34C8E74AC1594475C735568C18B@uxcn10-6.UoA.auckland.ac.nz> <017701cec998$8a5c2670$9f147350$@offspark.com> In-Reply-To: <017701cec998$8a5c2670$9f147350$@offspark.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] tls@ietf.org X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 11:24:15 -0000 On 15/10/2013 12:20, Paul Bakker wrote: > The server enforces server preferences. I did not tweak it for brainpool > specifically at the moment. > > So if you want brainpool: disable all but.. > That's what I did for the test: just used the single curve of interest in the supported curves extension. I also double checked the debug output to see that is was used for the ECDH temporary key. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From p.j.bakker@offspark.com Tue Oct 15 05:13:55 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF7021E809C for ; Tue, 15 Oct 2013 05:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id be6w6OyzMRFK for ; Tue, 15 Oct 2013 05:13:51 -0700 (PDT) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 1E41B11E81D5 for ; Tue, 15 Oct 2013 05:13:49 -0700 (PDT) Received: from a82-161-132-220.adsl.xs4all.nl ([82.161.132.220] helo=Slimpy) by vps2.brainspark.nl with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1VW3Oj-0000Lv-Fz; Tue, 15 Oct 2013 14:06:49 +0200 From: "Paul Bakker" To: "'Patrick Pelletier'" References: <525C11B5.2050604@secunet.com> <525CEFA4.2030903@funwithsoftware.org> In-Reply-To: <525CEFA4.2030903@funwithsoftware.org> Date: Tue, 15 Oct 2013 14:13:42 +0200 Message-ID: <01b901cec9a0$004e12b0$00ea3810$@offspark.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHDBObbigI3LWPKEzbQpv5mFKXNvgFN9JsgmgLGVIA= Content-Language: nl X-SA-Exim-Connect-IP: 82.161.132.220 X-SA-Exim-Mail-From: p.j.bakker@offspark.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Cc: tls@ietf.org Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 12:13:56 -0000 Fresh from the oven: https://polarssl.org/tech-updates/releases/polarssl-1.3.1-released So: yes.. ;) > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > Patrick Pelletier > Sent: dinsdag 15 oktober 2013 9:33 > To: TLS@ietf.org (tls@ietf.org) > Subject: Re: [TLS] Using Brainpool curves in TLS > > On 10/14/13 8:45 AM, Johannes Merkle wrote: > > jaust in case that someone hasn't noticed it: our draft on using the > > Brainpool curves in TLS has been published as RFC 7027 > > http://www.rfc-editor.org/rfc/rfc7027.txt > > Is support available in any TLS libraries yet? Do we know which libraries are > planning on adding support for Brainpool? > > --Patrick > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From skyper@thc.org Tue Oct 15 07:42:38 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8125721E80F1 for ; Tue, 15 Oct 2013 07:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.357 X-Spam-Level: * X-Spam-Status: No, score=1.357 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yllTuxvP4DYZ for ; Tue, 15 Oct 2013 07:42:28 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id D4B2D21E80C6 for ; Tue, 15 Oct 2013 07:42:26 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id tp5so1152213ieb.16 for ; Tue, 15 Oct 2013 07:42:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=Cx7jAGDOkECJ4WWkLcSmQPLDQBEtRMDhsPltjKu7ttE=; b=Nr5gSSdCcjo3onRXs360wrgbbv40VUuT9HHUH26Lez2dvoQ/JFxhzkI0hssC2zhonx XWLy51AAzQ4ifHQQ1I8iViDlP+8OjcCxJOAzZ9e01CzdILXcj3VsEn73wVU4gg5TUWZw K4yBRrQflIOPEIoxPKAV+wSiuDtpFCWESVdbk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=Cx7jAGDOkECJ4WWkLcSmQPLDQBEtRMDhsPltjKu7ttE=; b=Pvn/XZjRkrlYGLChPRMpPB0JeUw0ciXjtRS7XbOzCvsG4qBJxzVXjDJEz9orKkM3Ht XY0uI048NYO5NajgpwJMspJ5DO/6fAbFHRhT7hPDJcmIFqQRI/5o0g/FZMCbimY6NZTs b7CliR7CLJvtm3/w9N+gQFMCLvTvS2MrvCKFVfBcBd7XJtUtfHlGCBujRJOacVWz515A t7jat6Vsul1MuLcoo14RtLl8hQdpBHkCKqVJLyCUwXzFJGNpe6c1J3+BpIsPwW17nMDm yaiuSsYNslj+fNFC3EXpRPaV5LQbt3zLgLQ1ykG7MmWDDUh8lv+Ef8mXvDBtX0JTFvlu HTSQ== X-Gm-Message-State: ALoCoQlTcMbfHx0O9Zg1yP4ZyzDwpg7SVT13iRNXM68yqqWF7f10ej5gS34ECzhHS+X3B+r8tInh MIME-Version: 1.0 X-Received: by 10.50.46.67 with SMTP id t3mr17167984igm.46.1381848144240; Tue, 15 Oct 2013 07:42:24 -0700 (PDT) Received: by 10.64.231.100 with HTTP; Tue, 15 Oct 2013 07:42:24 -0700 (PDT) X-Originating-IP: [80.195.189.45] Date: Tue, 15 Oct 2013 15:42:24 +0100 Message-ID: From: Ralf Skyper Kaiser To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a11347edcc5683a04e8c89761 Subject: [TLS] SSL/TLS and HTTPS in a Post-Prism Era X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 14:42:39 -0000 --001a11347edcc5683a04e8c89761 Content-Type: text/plain; charset=ISO-8859-1 Hi, I created an incomplete summary of various reports about Certification Authority breaches. I believe it is the most complete list to date (additions welcome). The summary also contains some (but not all) proposed security solutions and enhancements for the 'CA Trust Problem' and some general security enhancement for the deployment of SSL/TLS. Comments and feedback are welcome. https://thc.org/ssl and a video parody to explain the problem to non-technical people: http://youtu.be/F3BMA3IuvYs Best Regards, Ralf --001a11347edcc5683a04e8c89761 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I created an incomplete summary of various repo= rts about Certification Authority breaches. I believe it is the most comple= te list to date (additions welcome).

The summary also contains some = (but not all) proposed security solutions and enhancements for the 'CA = Trust Problem' and some general security enhancement for the deployment= of SSL/TLS.

Comments and feedback are welcome.


https://thc.org/ssl


and a video parody to explain the= problem to non-technical people:


http://youtu.be/F3BMA3IuvYs


Best Regards,

Ralf

--001a11347edcc5683a04e8c89761-- From internet-drafts@ietf.org Tue Oct 15 08:17:22 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2A511E818B; Tue, 15 Oct 2013 08:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srbvaGOYDxaa; Tue, 15 Oct 2013 08:17:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B3911E812A; Tue, 15 Oct 2013 08:17:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131015151722.2172.37731.idtracker@ietfa.amsl.com> Date: Tue, 15 Oct 2013 08:17:22 -0700 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-applayerprotoneg-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 15:17:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Layer Security Working Group of= the IETF. Title : Transport Layer Security (TLS) Application Layer Protoco= l Negotiation Extension Author(s) : Stephan Friedl Andrei Popov Adam Langley Emile Stephan Filename : draft-ietf-tls-applayerprotoneg-03.txt Pages : 9 Date : 2013-10-15 Abstract: This document describes a Transport Layer Security (TLS) extension for application layer protocol negotiation within the TLS handshake. For instances in which the TLS connection is established over a well known TCP/IP port not associated with the desired application layer protocol, this extension allows the application layer to negotiate which protocol will be used within the TLS session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-applayerprotoneg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-applayerprotoneg-03 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From watsonbladd@gmail.com Tue Oct 15 08:49:56 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C5121F9E0B for ; Tue, 15 Oct 2013 08:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIoafj3IeFs3 for ; Tue, 15 Oct 2013 08:49:55 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id D57A021F9ACA for ; Tue, 15 Oct 2013 08:49:53 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hn9so1816050wib.11 for ; Tue, 15 Oct 2013 08:49:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=r365zaS3dehlwbppq8rA5JUNfFCpetP4mjjqEdnn+js=; b=Ra1bTLFodf8nQCGCZanhARqNqguOk0kzOMAweqT3srUG/e1KqP9Ymmh+UuEvp14p+N Jm5AjB+4/RvSrM+6K7+gSAPeufhyWNyTq9oUEHhUWkMPh+Fg4XZpPuIAj+7j+kmbOeua DINRwLVc+A4diiONDCmpV5IYZwuGxTzUJKXP5/ft6AOnBecAZM2Y49c6ETHheKC1pac0 mlTJBA2tgrjPz+QDtQSK/KZjJ0+QTuzhklt+3VGPGLsobD5m3viVhB3eAOiW+7fQ/C1V 4bESZyG/tajJMB0KdVG0DuXXTMFNxAo5GSScjyoKPAcmMD19bkHkzv41TN/FrtyPnNUp CqiQ== MIME-Version: 1.0 X-Received: by 10.194.122.99 with SMTP id lr3mr34180419wjb.21.1381852192826; Tue, 15 Oct 2013 08:49:52 -0700 (PDT) Received: by 10.194.242.131 with HTTP; Tue, 15 Oct 2013 08:49:52 -0700 (PDT) In-Reply-To: <01b901cec9a0$004e12b0$00ea3810$@offspark.com> References: <525C11B5.2050604@secunet.com> <525CEFA4.2030903@funwithsoftware.org> <01b901cec9a0$004e12b0$00ea3810$@offspark.com> Date: Tue, 15 Oct 2013 08:49:52 -0700 Message-ID: From: Watson Ladd To: Paul Bakker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Patrick Pelletier , tls@ietf.org Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 15:49:56 -0000 On Tue, Oct 15, 2013 at 5:13 AM, Paul Bakker wrot= e: > Fresh from the oven: > https://polarssl.org/tech-updates/releases/polarssl-1.3.1-released > > So: yes.. ;) > >> -----Original Message----- >> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of >> Patrick Pelletier >> Sent: dinsdag 15 oktober 2013 9:33 >> To: TLS@ietf.org (tls@ietf.org) >> Subject: Re: [TLS] Using Brainpool curves in TLS >> >> On 10/14/13 8:45 AM, Johannes Merkle wrote: >> > jaust in case that someone hasn't noticed it: our draft on using the >> > Brainpool curves in TLS has been published as RFC 7027 >> > http://www.rfc-editor.org/rfc/rfc7027.txt >> >> Is support available in any TLS libraries yet? Do we know which librari= es > are >> planning on adding support for Brainpool? What problems does this solve? The Brainpool curves still have unverifiable construction, Weirstrau=C3=9F form (meaning many corner cases in addition and the possibility of sending points not on the curve), primes that are ugly and horribly slow (seriously, randomly picked primes?), come courtesy of our friends in the BND, and don't solve any problems beyond a possible backdoor in NIST curves. What is the rationale behind these curves as opposed to Curve25519? (The curve given by the Montgomery equation y^2=3Dx^3+486662x^2+x over the field F(2^255-19), with canonical basepoint x=3D9). The implementation in PolarSSL has a nonconstant pattern of memory access. Seriously, it isn't 1999 anymore: everyone doing cryptography should be aware of these issues. Sincerely, Watson Ladd >> >> --Patrick >> >> _______________________________________________ >> 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 --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nico@cryptonector.com Tue Oct 15 09:12:46 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D652111E818A for ; Tue, 15 Oct 2013 09:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3YTCSi3ca36 for ; Tue, 15 Oct 2013 09:12:42 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2B511E814D for ; Tue, 15 Oct 2013 09:12:42 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id CB8EE76805C for ; Tue, 15 Oct 2013 09:12:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=TcW445A+7aey43nb904O iNBe4tw=; b=uLJmZjZBGKiJJO+U22KwcGD3ZhYG4r5dpuPiP+uCam/zhzQtwkJw gCSKNM7UmLeSr5VwpLSMdT8GYtktmuWb6HKnmjWsn2rvcJV7VkwmDUmo1bFnAJgZ yVo1nHnWxhiKejzveKr2oTV1nL9AnGQI+0TnG5ZYI5HqbuFl6fwYOus= Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 71E27768059 for ; Tue, 15 Oct 2013 09:12:40 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id y10so6321462wgg.8 for ; Tue, 15 Oct 2013 09:12:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2Welpl25Jma7KcThytdocMv+J7V75/2EbSHz56EN22I=; b=j+AAZgrOp6NAYMG40a8unUtEhPOv03/ZHhEM+UGwIEM5KRB8pDGHDV1lnCcOZ5WSsb B2yUL/wIlQpGLjFghor59D3dACQ0A3tLqp9xfTZUILaKJ9aRPuOapHJZgwe7SRN8s9bG N6xEhz/NPU0plCMKjDfY9uHjZFdiuR1RfaX3y3gQqfviTATTvPMbnJEzQfX6mQY17tJD pk5YhQOWREO/3ofRyrpxgBn8sSA7C4s/ewoRHmtNnOmrSfA6tLoqmqZld/MzKYXfGGC/ 5sF1E9nk7Aw8zhRYKO+rNohW9XrSJM2AWpt3z3bio4ymeuJBxxwXHEHpoTyDe/8bQNgc ihWQ== MIME-Version: 1.0 X-Received: by 10.180.182.82 with SMTP id ec18mr20141090wic.13.1381853559064; Tue, 15 Oct 2013 09:12:39 -0700 (PDT) Received: by 10.216.151.136 with HTTP; Tue, 15 Oct 2013 09:12:39 -0700 (PDT) In-Reply-To: References: <525C11B5.2050604@secunet.com> <525CEFA4.2030903@funwithsoftware.org> <01b901cec9a0$004e12b0$00ea3810$@offspark.com> Date: Tue, 15 Oct 2013 11:12:39 -0500 Message-ID: From: Nico Williams To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Cc: Patrick Pelletier , "tls@ietf.org" Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 16:12:47 -0000 On Tue, Oct 15, 2013 at 10:49 AM, Watson Ladd wrote: > The implementation in PolarSSL has a nonconstant pattern of memory > access. Seriously, it isn't 1999 anymore: everyone doing cryptography > should be aware of these issues. Indeed, constant-time operation is a very big deal. A curve could be perfectly secure in the ECDLP sense and yet be utterly insecure due to side channels. There are no standard curves that we can trust to be secure in both senses; DJB's curves are very likely secure enough in the ECDLP sense (certainly given current *public* research) and they are secure in the other sense; they are also quite fast. http://safecurves.cr.yp.to/ Nico -- From watsonbladd@gmail.com Tue Oct 15 18:40:59 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C7821F9A1C for ; Tue, 15 Oct 2013 18:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqf1V9x2jesy for ; Tue, 15 Oct 2013 18:40:58 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C16FB11E80F8 for ; Tue, 15 Oct 2013 18:40:50 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id h11so1695338wiv.16 for ; Tue, 15 Oct 2013 18:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4BwkIGHhFtkADSeIlkLDWA4GGtLqjbBVBCbx4kDQ3vU=; b=l0t5xqU9HQ9GM6HYwwV2H72Ue5ioxHBwrRIs6r6I8z4B5/E9msge+syb73d9b/WmcY X52R072so57ypsY2WYRuxxrP1wR5ivnHUbF9lxAz64M8g2nRryZHkMaR57Za05XzsEqU A3ZE4OWEGleUIoxoa5HUuU9UFY5bznwES9SeDaMzfO1bRTcH1WyW+lJhQRQiNEUHYwm1 pnEsyWgLk5AD8UcJqNtBfA5gobZTQ09xnvra6wIBKZXZ1AsdZXaDjWqzPD1GtYb6gcCz Cz3o/9qfRSXJpX9ElmNZ0mIllQO+Zr253fe08QFw7HxxwJ5vTQp0GafeJX3mDX4xlwqq YLfQ== MIME-Version: 1.0 X-Received: by 10.180.37.162 with SMTP id z2mr130290wij.58.1381887649681; Tue, 15 Oct 2013 18:40:49 -0700 (PDT) Received: by 10.194.242.131 with HTTP; Tue, 15 Oct 2013 18:40:49 -0700 (PDT) In-Reply-To: References: <525C11B5.2050604@secunet.com> <525CEFA4.2030903@funwithsoftware.org> <01b901cec9a0$004e12b0$00ea3810$@offspark.com> Date: Tue, 15 Oct 2013 18:40:49 -0700 Message-ID: From: Watson Ladd To: Nico Williams Content-Type: text/plain; charset=UTF-8 Cc: Patrick Pelletier , "tls@ietf.org" Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 01:40:59 -0000 On Tue, Oct 15, 2013 at 9:12 AM, Nico Williams wrote: > On Tue, Oct 15, 2013 at 10:49 AM, Watson Ladd wrote: >> The implementation in PolarSSL has a nonconstant pattern of memory >> access. Seriously, it isn't 1999 anymore: everyone doing cryptography >> should be aware of these issues. > > Indeed, constant-time operation is a very big deal. A curve could be > perfectly secure in the ECDLP sense and yet be utterly insecure due to > side channels. There are no standard curves that we can trust to be > secure in both senses; DJB's curves are very likely secure enough in > the ECDLP sense (certainly given current *public* research) and they > are secure in the other sense; they are also quite fast. Note Bena: Being safe against side channels is a property of the implementation, not the curve. DJB's implementations are constant time, and the curves have properties that make it easier to be constant time, but it is trivial to introduce backdoors into implementations of them. > http://safecurves.cr.yp.to/ > > Nico > -- -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nico@cryptonector.com Tue Oct 15 19:25:23 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F47B21F9D04 for ; Tue, 15 Oct 2013 19:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ivy8qOiZAnqr for ; Tue, 15 Oct 2013 19:25:15 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 2F34B11E8209 for ; Tue, 15 Oct 2013 19:25:11 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id CE1991B405F for ; Tue, 15 Oct 2013 19:25:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=4hvM3H8ngWC9+Ydqw7Jc vi7UOnQ=; b=pH1ies1DjY+mrnOlPLYLBtuX7FdWh2Yoj2DQELm1/Wpj7HlgvG2q Wh6scW7fzJDh5RQhDuwAChPbCUmIztSDUFylo4ZZ4pExOADewLBkRtVo34DliEMe zQu2XxJFRnYSSmuevWV8FEzNelsm8l3QFluIDZpZX4gwG4Naq8Y8q48= Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 7577B1B4059 for ; Tue, 15 Oct 2013 19:25:09 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id h11so109355wiv.4 for ; Tue, 15 Oct 2013 19:25:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6lLOxwqO90mmjxY3/zGNH+X1cleFZZ2CN8/NO+RVMq8=; b=nLupx00njjkSQJ51lxLrrSlCHkpjQ2HCV0gikEsHYscsW4dZLHuFhVoSbcAOJmDWHB Ye351EHMu1AITCcM0vlp9RK8/mhGd3DLNsk7ia3MF3MWO9NJFr52ImPeyQsFQ44bA1Es o2yF6J4dZZX5kMBFWiWZSkfPkRQx3iuO/Dp+jgYY92nJPG8bSR6/UeZsel+adnMZ5NO0 vMH/FIFYrubyPH3d5OlL+O+nW64BbROaXA+M/Ke26PETYlvPF2v0jSEpXZtqH94ku3C9 lEX6objDifwaSTbZ/Pz9uuCFkK86Tg02IfVgFTSUoWs8iGYzPgTPwMAkSVRZWldmNAu+ AX6g== MIME-Version: 1.0 X-Received: by 10.180.73.239 with SMTP id o15mr22052328wiv.36.1381890307929; Tue, 15 Oct 2013 19:25:07 -0700 (PDT) Received: by 10.216.151.136 with HTTP; Tue, 15 Oct 2013 19:25:07 -0700 (PDT) In-Reply-To: References: <525C11B5.2050604@secunet.com> <525CEFA4.2030903@funwithsoftware.org> <01b901cec9a0$004e12b0$00ea3810$@offspark.com> Date: Tue, 15 Oct 2013 21:25:07 -0500 Message-ID: From: Nico Williams To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Cc: Patrick Pelletier , "tls@ietf.org" Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 02:25:23 -0000 On Tue, Oct 15, 2013 at 8:40 PM, Watson Ladd wrote: > Note Bena: Being safe against side channels is a property of the > implementation, not the curve. > DJB's implementations are constant time, and the curves have > properties that make it easier to be constant time, That's what I was referring to, yes. > but it is trivial to introduce backdoors into implementations of them. Do you mean that it's easier to backdoor implementations of specific EC curves than, say, RSA? I would think that implementations of... just about anything can be backdoored with relative ease. Nico -- From mrex@sap.com Tue Oct 15 19:52:57 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C968811E8220 for ; Tue, 15 Oct 2013 19:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.957 X-Spam-Level: X-Spam-Status: No, score=-9.957 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scq-V94vEVhs for ; Tue, 15 Oct 2013 19:52:52 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 002CE21F9D30 for ; Tue, 15 Oct 2013 19:52:49 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r9G2qgsl016328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Oct 2013 04:52:43 +0200 (MEST) In-Reply-To: To: Nico Williams Date: Wed, 16 Oct 2013 04:52:42 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20131016025242.CDBAD1A9FF@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: Patrick Pelletier , "tls@ietf.org" Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 02:52:57 -0000 Nico Williams wrote: > > > but it is trivial to introduce backdoors into implementations of them. > > Do you mean that it's easier to backdoor implementations of specific > EC curves than, say, RSA? I would think that implementations of... > just about anything can be backdoored with relative ease. I assume that he might have meant what is also indicated on the referenced Web Site http://safecurves.cr.yp.to/ that it is extremely difficult to implement ECC and _NOT_ hang yourself, It would not surprise me at all if the vast majority of ECC implementations would be found to be vulnerable to serious weaknesses, when carefully analyzed, and that the problems found in the RSA part would be *MUCH* smaller in comparison. -Martin From watsonbladd@gmail.com Tue Oct 15 20:33:48 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F0C11E8105 for ; Tue, 15 Oct 2013 20:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCLpqZTCIocL for ; Tue, 15 Oct 2013 20:33:47 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 4744E11E816B for ; Tue, 15 Oct 2013 20:33:47 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id y10so133070wgg.8 for ; Tue, 15 Oct 2013 20:33:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pIFZVCuo+aII+E24Llw52u+mJVI+kpfFUmfAO2qmiuw=; b=SktErALo8gS00Z62FROyiSt8hlY1w/VZI0V/mXHGhqqCqbMsWutpUwUqqczX3tS7A5 HmQClMUakH2srTrw55CwlsR+i50G5yQjmu3u5R2gIslFQCCBtFSj0ubspJjEZyn9Iznd i5QYLPR7NSuiuXM4+lML5dGIML5gxoGH62Ad3vAXu+4NjU2KQe14EgYUMg//K178673j 1ysoM563/5/VlSiZm7JFMLDDLYMAmqmzXUvqFbtmQ0HKcjh3EF81E45Urxs2i0cIcL7x ZjED6/OaWAze21XtNY+ijdwdHn9tN/lKSULQxArKvRiGhJehkkACpAyWGbFckLHlr52R oSkg== MIME-Version: 1.0 X-Received: by 10.180.210.146 with SMTP id mu18mr22440923wic.10.1381894426566; Tue, 15 Oct 2013 20:33:46 -0700 (PDT) Received: by 10.194.242.131 with HTTP; Tue, 15 Oct 2013 20:33:46 -0700 (PDT) In-Reply-To: <20131016025242.CDBAD1A9FF@ld9781.wdf.sap.corp> References: <20131016025242.CDBAD1A9FF@ld9781.wdf.sap.corp> Date: Tue, 15 Oct 2013 20:33:46 -0700 Message-ID: From: Watson Ladd To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Cc: Patrick Pelletier , "tls@ietf.org" Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 03:33:49 -0000 On Tue, Oct 15, 2013 at 7:52 PM, Martin Rex wrote: > Nico Williams wrote: >> >> > but it is trivial to introduce backdoors into implementations of them. >> >> Do you mean that it's easier to backdoor implementations of specific >> EC curves than, say, RSA? I would think that implementations of... >> just about anything can be backdoored with relative ease. > > I assume that he might have meant what is also indicated on the > referenced Web Site http://safecurves.cr.yp.to/ > that it is extremely difficult to implement ECC and _NOT_ hang yourself, I mean exactly what I said: no more and no less. Implementations must be carefully audited to establish freedom from side-channels, no matter what primitive they implement. > > It would not surprise me at all if the vast majority of ECC > implementations would be found to be vulnerable to serious > weaknesses, when carefully analyzed, and that the problems found > in the RSA part would be *MUCH* smaller in comparison. I really do not know how one is supposed to measure this, or why it matters. A few well-audited implementations designed for maximum clarity should suffice for all most all purposes. > > -Martin -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From mrex@sap.com Tue Oct 15 22:34:22 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C9811E8262 for ; Tue, 15 Oct 2013 22:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fg3kv9-P0VUK for ; Tue, 15 Oct 2013 22:34:17 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id DD36D21F9CBF for ; Tue, 15 Oct 2013 22:34:16 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r9G5Y9lK010881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Oct 2013 07:34:09 +0200 (MEST) In-Reply-To: To: Watson Ladd Date: Wed, 16 Oct 2013 07:34:08 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20131016053408.E7BB01A9FD@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: Patrick Pelletier , "tls@ietf.org" Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 05:34:22 -0000 Watson Ladd wrote: > > I mean exactly what I said: no more and no less. Implementations must > be carefully > audited to establish freedom from side-channels, no matter what > primitive they implement. That is the theory. Now practice is an entirely different matter. If you look through the algorithms in the appendices of FIPS 186-3, you'll find a lot of algorithms that contain conditionals. If the algorithm will have to be used inband for an asymmetric crypto operation, those algorithms leak timing information when processing secret values. If a crypto operation needs an ephemeral random and secret prime, this would apply to the necessary primality tests. If the algorithm described by the underlying specification is not 100% constant time, why would you expect implementations to have this property? -Martin From mpg@elzevir.fr Tue Oct 15 23:37:06 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B10111E8257 for ; Tue, 15 Oct 2013 23:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WH-J4S7TK4De for ; Tue, 15 Oct 2013 23:37:02 -0700 (PDT) Received: from mordell.elzevir.fr (mordell.elzevir.fr [IPv6:2001:4b98:dc0:41:216:3eff:feeb:c406]) by ietfa.amsl.com (Postfix) with ESMTP id C5DA521F96DA for ; Tue, 15 Oct 2013 23:36:58 -0700 (PDT) Received: from thue.elzevir.fr (thue.elzevir.fr [88.165.216.11]) by mordell.elzevir.fr (Postfix) with ESMTPS id 6870916153; Wed, 16 Oct 2013 08:36:54 +0200 (CEST) Received: from [192.168.0.124] (unknown [192.168.0.254]) by thue.elzevir.fr (Postfix) with ESMTPSA id 734BB260A6; Wed, 16 Oct 2013 08:36:53 +0200 (CEST) Message-ID: <525E3404.2090808@elzevir.fr> Date: Wed, 16 Oct 2013 08:36:52 +0200 From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.0 MIME-Version: 1.0 To: Simon Josefsson , tls@ietf.org References: <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> <87zjrl21wp.fsf_-_@latte.josefsson.org> <8738outeup.fsf@latte.josefsson.org> In-Reply-To: <8738outeup.fsf@latte.josefsson.org> X-Enigmail-Version: 1.5.2 OpenPGP: id=98EED379; url=https://elzevir.fr/gpg/mpg.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Curve25519 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 06:37:06 -0000 Hi, On 24/09/2013 17:32, Simon Josefsson wrote: > http://tools.ietf.org/html/draft-josefsson-tls-curve25519-01 > I think a few points should be clarified in the draft. As the introduction correctly states, Curve25519 is a new ECDH function, not just a new curve for use with the usual ECDH construction. Let me sum up the constructions of ECDH in TLS and in Curve25519. TLS ECDH: 1. Private keys: random integer in the range [1, q-1] with q the order of G. 2. Public keys: a point on the curve (defined over F_p). 3. Public key encoding: either (a) the x and y coordinates of the point, or (b) the x coordinate and a bit for determination of the y coordinate, with integers represented as big-endian bytes strings, preceded by a first byte indicating which format was chosen (and holding the possible additional bit). Curve25519 ECDH: 1. Private keys: random 254-bit positive integer with the high-order bit set and the three lowest-order bits cleared. 2. Public keys: any number in the range [0, 2^{256}-1]. 3. Public key encoding: a byte string in little-endian convention. Now I'll discuss the differences and possible issues in more detail. 1. Concerning the private key, I think keeping the paper's definition does not raise any issue. Implementors should just be careful to use a special procedure for this curve. 2. Concerning the public key, the 256-bit integer in the paper represents (modulo p) the x coordinate of a point on the curve E, but this point may not be defined over F_p, but over F_{p^2}. An alternative way of seeing things is that the public key may be either the x coordinate of a point in E(F_p) or of a point in E'(F_p) where E' is the twist curve y^2 = x^3 + 2Ax^2 + 4x. By construction of E, this is not a security issue at all, and rather a fact that simplifies implementations of the Curve25519-ECDH protocol, since there is no need to check the validity of public keys and they are shorter, but it introduces a real difference (in the type of objects, not just their representation) with the usual TLS ECDH function. 3. So, if we want to preserve the nice property than any 32-byte string (ie, any 256-bit integer x) is a valid key (and I think we do), we don't have a y coordinate at our disposal for the normal encoding procedure. Some ideas around this issue: A. Just use the convention y = 0 and one of the existing formats. Pros: simple, just works. Cons: with the basic "uncompressed" format, wastes 32 bytes of bandwidth. B. Always use the "ansiX962_compressed_prime" format. Pros: doesn't waste bandwidth. Cons: forces applications to advertise support this format, which is a problem if they can't support it for other prime curves, unless we introduce an exception to the effect that support for this format with this particular curve is implied as soon as support for the curve is advertised. Does not seem very clean to me. C. Introduce a new point format "compressed_prime_montgomery". Pros: doesn't waste bandwidth, doesn't look hacky. Cons: a new point format only for one curve? OTOH, it is indeed a particular class of curve, since the recommended formulas work only with the x coordinate, and other curves in this class may be added later. Note that A and C may be combined. Any other idea? Manuel. From mrex@sap.com Tue Oct 15 23:42:49 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C3011E824D for ; Tue, 15 Oct 2013 23:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.88 X-Spam-Level: X-Spam-Status: No, score=-9.88 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qohmQq5Sz-2 for ; Tue, 15 Oct 2013 23:42:44 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id A685E11E8244 for ; Tue, 15 Oct 2013 23:42:40 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r9G6gaMN021810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Oct 2013 08:42:36 +0200 (MEST) In-Reply-To: <525E3404.2090808@elzevir.fr> To: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= Date: Wed, 16 Oct 2013 08:42:35 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Message-Id: <20131016064235.D19D71A9FD@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: Simon Josefsson , tls@ietf.org Subject: Re: [TLS] Curve25519 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 06:42:49 -0000 Manuel P=E9gouri=E9-Gonnard wrote: >=20 > Curve25519 ECDH: > 1. Private keys: random 254-bit positive integer with the high-order bit > set and the three lowest-order bits cleared. > 2. Public keys: any number in the range [0, 2^{256}-1]. > 3. Public key encoding: a byte string in little-endian convention. >=20 > Any other idea? Make it work completely _without_ rfc4492 bloat, and similar to DH instead, defining new KeyExchange Methods and seperate ciphersuites for it. -Martin From Johannes.Merkle@secunet.com Wed Oct 16 00:21:34 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A49D11E80F9 for ; Wed, 16 Oct 2013 00:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.49 X-Spam-Level: X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UehAFjkdksx for ; Wed, 16 Oct 2013 00:21:26 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6090121F9928 for ; Wed, 16 Oct 2013 00:21:22 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 55DBC1A0079; Wed, 16 Oct 2013 09:21:21 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id avgNnoauD5sy; Wed, 16 Oct 2013 09:21:20 +0200 (CEST) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id B396A1A0071; Wed, 16 Oct 2013 09:21:18 +0200 (CEST) Received: from [172.16.40.201] ([172.16.40.201]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Oct 2013 09:21:19 +0200 Message-ID: <525E3E6B.1020604@secunet.com> Date: Wed, 16 Oct 2013 09:21:15 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Watson Ladd , Paul Bakker References: <525C11B5.2050604@secunet.com> <525CEFA4.2030903@funwithsoftware.org> <01b901cec9a0$004e12b0$00ea3810$@offspark.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2013 07:21:19.0307 (UTC) FILETIME=[4F0999B0:01CECA40] Cc: Patrick Pelletier , tls@ietf.org Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 07:21:34 -0000 > What problems does this solve? The Brainpool curves still have > unverifiable construction, This is plain wrong. Obviously, you have not read RFC 5639. The construction of the Brainppol curves is completely verifiable, only based on the fundamental constants Pi and e. Johannes From juhovh@iki.fi Wed Oct 16 02:53:03 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF6B11E8177 for ; Wed, 16 Oct 2013 02:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOcHsOYYZeHv for ; Wed, 16 Oct 2013 02:52:57 -0700 (PDT) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by ietfa.amsl.com (Postfix) with ESMTP id 5399A11E8235 for ; Wed, 16 Oct 2013 02:52:50 -0700 (PDT) Received: from [10.177.224.7] (85-76-101-80-nat.elisa-mobile.fi [85.76.101.80]) by gw03.mail.saunalahti.fi (Postfix) with ESMTP id CC202216CB7; Wed, 16 Oct 2013 12:52:37 +0300 (EEST) References: <20131016064235.D19D71A9FD@ld9781.wdf.sap.corp> Mime-Version: 1.0 (1.0) In-Reply-To: <20131016064235.D19D71A9FD@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable Message-Id: <4C4E4556-6ED4-406B-81F6-D3A41BE379BD@iki.fi> X-Mailer: iPhone Mail (11A501) From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= Date: Wed, 16 Oct 2013 12:48:42 +0300 To: "mrex@sap.com" Cc: Simon Josefsson , =?GB2312?Q?Manuel_P=A8=A6gouri=A8=A6-Gonnard?= , "tls@ietf.org" Subject: Re: [TLS] Curve25519 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 09:53:03 -0000 > On 16.10.2013, at 9.42, mrex@sap.com (Martin Rex) wrote: >=20 > Manuel P=A8=A6gouri=A8=A6-Gonnard wrote: >> Any other idea? >=20 > Make it work completely _without_ rfc4492 bloat, > and similar to DH instead, defining new KeyExchange Methods > and seperate ciphersuites for it. I think this would be the best option for Curve25519, just handle it as a sp= ecial case without trying to force it into the overly complex ECC spec. Juho From mpg@elzevir.fr Wed Oct 16 06:05:16 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9282711E82A3 for ; Wed, 16 Oct 2013 06:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmB5qOns+uLg for ; Wed, 16 Oct 2013 06:05:09 -0700 (PDT) Received: from mordell.elzevir.fr (mordell.elzevir.fr [92.243.3.74]) by ietfa.amsl.com (Postfix) with ESMTP id 798F811E8268 for ; Wed, 16 Oct 2013 06:05:08 -0700 (PDT) Received: from thue.elzevir.fr (thue.elzevir.fr [88.165.216.11]) by mordell.elzevir.fr (Postfix) with ESMTPS id 3961B16153; Wed, 16 Oct 2013 15:05:04 +0200 (CEST) Received: from [192.168.0.124] (unknown [192.168.0.254]) by thue.elzevir.fr (Postfix) with ESMTPSA id 95B51260A6; Wed, 16 Oct 2013 15:05:00 +0200 (CEST) Message-ID: <525E8EFC.8010705@elzevir.fr> Date: Wed, 16 Oct 2013 15:05:00 +0200 From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.0 MIME-Version: 1.0 To: mrex@sap.com References: <20131016064235.D19D71A9FD@ld9781.wdf.sap.corp> In-Reply-To: <20131016064235.D19D71A9FD@ld9781.wdf.sap.corp> X-Enigmail-Version: 1.5.2 OpenPGP: id=98EED379; url=https://elzevir.fr/gpg/mpg.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Simon Josefsson , tls@ietf.org Subject: Re: [TLS] Curve25519 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 13:05:17 -0000 On 16/10/2013 08:42, Martin Rex wrote: > Make it work completely _without_ rfc4492 bloat, > and similar to DH instead, defining new KeyExchange Methods > and seperate ciphersuites for it. > If we want to cover all existing key exchanges and ciphersuites, this would mean defining four new key exchanges (ECDH25519-PSK,RSA,ECDSA,anon), and 52 new ciphersuites currently. And then duplicating every ECDHE-based ciphersuite defined in the future. And if at some point, a new Montgomery or Edwards curve is proposed (maybe the recent curve3617), duplicating all that again. That's quite a lot of trouble: what specific problem would it solve? What exactly do you mean by RFC 4492 "bloat", and in which specific way defining new key exchanges would make it lighter? As an implementer, I don't feel like adding new key exchanges for Curve25519 would make my life any easier, as it would come *in addition* to RFC 4492 support. Anyway, I believe that cryptographic parameters agility is a highly desirable property of a protocol like TLS, and RFC 4492 provide that, better than specialised key exchanges supporting only one curve. If that solution had been adopted in early 2006, the only one curve would probably have been a NIST curve (curve25519 was very new at the time, while NIST curves had been around for years), and you wouldn't be very happy now, I guess. I hope my first post didn't give the wrong impression: I don't think the framework from RFC 4492 is a misfit for the Curve25519 ECDH function, the only real point of friction is the encoding of the public keys. The other remarks I made are merely things I'd like to see clarified in the draft, and information that seemed relevant to me to discuss the public key format. Manuel. From tom@ritter.vg Wed Oct 16 06:33:18 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF3E11E81D1 for ; Wed, 16 Oct 2013 06:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ej6mZkiAUVGb for ; Wed, 16 Oct 2013 06:33:17 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id B583111E81D3 for ; Wed, 16 Oct 2013 06:33:15 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id u16so1220612iet.7 for ; Wed, 16 Oct 2013 06:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=iZzkzglO90lbDwBzkKOgQvc5i4umiB6XE27BrI6hfoQ=; b=bagPFbipcPAtPiTCioA2qyMAHZCWfSNy/A3vNZIcPnHuuKSGkag+q+aRMP7a7ZLBBj rencdkDhRRW5+2FqwzvDq5xuTkflzmMAUAGRlJ1SlAt8KcU9D2JrodHpWJ2z0FWKOcmP fHsW7JBXCAGAbI9L26kX3sX6/LQxSWadpt0Fc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=iZzkzglO90lbDwBzkKOgQvc5i4umiB6XE27BrI6hfoQ=; b=dnmDBP+aGKQeXKB2dn0iWHmRzsUP6bJTT+Hgj6HJWnX0zkYFZzpRFEICTPj8i6oDYj g8TAHMFNy/oT+6zRIpF49Ll+cET/N0dH87AW0JE+lLqhT1o+1yfGH8wFt6wVyACvHeFr H0XYk6EnMtpFmJoSgTtqmg+aC5RCzy/Iy7EDwTwnKgHa8XkPPDg/Fu5G2KiI6+NQnKvT +JZaDqExk0vI5a7jJNwPXe4cuzKeV0ZVjccnyxGjKpBEAQelJ0qhpI5gjF95owo2V8zE iGbQPefcTSzLExIW4cQyOjeV2uXJ4XNtTW2TXEp49jKR9jnqCLzLgV47qbF92+dsn35u AWpw== X-Gm-Message-State: ALoCoQkhNSEcw+2fkDiyK8i0xqjo7xN+SMwyJ9Kcu8X2CN6jTkA4iR7pkcxFTLUK7JIk8knXDdac X-Received: by 10.42.148.138 with SMTP id r10mr451386icv.80.1381930394444; Wed, 16 Oct 2013 06:33:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.225.15 with HTTP; Wed, 16 Oct 2013 06:32:53 -0700 (PDT) In-Reply-To: <525E3E6B.1020604@secunet.com> References: <525C11B5.2050604@secunet.com> <525CEFA4.2030903@funwithsoftware.org> <01b901cec9a0$004e12b0$00ea3810$@offspark.com> <525E3E6B.1020604@secunet.com> From: Tom Ritter Date: Wed, 16 Oct 2013 09:32:53 -0400 Message-ID: To: Johannes Merkle Content-Type: text/plain; charset=ISO-8859-1 Cc: Patrick Pelletier , "tls@ietf.org" Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 13:33:18 -0000 On 16 October 2013 03:21, Johannes Merkle wrote: >> What problems does this solve? The Brainpool curves still have >> unverifiable construction, > > This is plain wrong. Obviously, you have not read RFC 5639. The construction of the Brainppol curves is completely > verifiable, only based on the fundamental constants Pi and e. Repeating others arguments: "Several unexplained decisions: Why SHA-1 instead of, e.g., RIPEMD-160 or SHA-256? Why use 160 bits of hash input independently of the curve size? Why pi and e instead of, e.g., sqrt(2) and sqrt(3)? Why handle separate key sizes by more digits of pi and e instead of hash derivation? Why counter mode instead of, e.g., OFB? Why use overlapping counters for A and B (producing the repeated 26DC5C6CE94A4B44F330B5D9)? Why not derive separate seeds for A and B?" http://safecurves.cr.yp.to/rigid.html I'm not sure I agree with them fully, but I also don't have very much context. (My thoughts when reading that is "Why sqrt(2) and sqrt(3) instead of pi and e - what makes those constants more trustworthy?") -tom From mpg@elzevir.fr Wed Oct 16 07:25:33 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5A911E82A8 for ; Wed, 16 Oct 2013 07:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZ+Gij3K4Q8U for ; Wed, 16 Oct 2013 07:25:18 -0700 (PDT) Received: from mordell.elzevir.fr (mordell.elzevir.fr [92.243.3.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8D43911E826F for ; Wed, 16 Oct 2013 07:25:15 -0700 (PDT) Received: from thue.elzevir.fr (thue.elzevir.fr [88.165.216.11]) by mordell.elzevir.fr (Postfix) with ESMTPS id EB4B316153; Wed, 16 Oct 2013 16:25:11 +0200 (CEST) Received: from [192.168.0.124] (unknown [192.168.0.254]) by thue.elzevir.fr (Postfix) with ESMTPSA id 8EF40260A6; Wed, 16 Oct 2013 16:25:10 +0200 (CEST) Message-ID: <525EA1C6.5030909@elzevir.fr> Date: Wed, 16 Oct 2013 16:25:10 +0200 From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.0 MIME-Version: 1.0 To: Tom Ritter , Johannes Merkle References: <525C11B5.2050604@secunet.com> <525CEFA4.2030903@funwithsoftware.org> <01b901cec9a0$004e12b0$00ea3810$@offspark.com> <525E3E6B.1020604@secunet.com> In-Reply-To: X-Enigmail-Version: 1.5.2 OpenPGP: id=98EED379; url=https://elzevir.fr/gpg/mpg.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Patrick Pelletier , "tls@ietf.org" Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 14:25:33 -0000 On 16/10/2013 15:32, Tom Ritter wrote: > I'm not sure I agree with them fully, but I also don't have very much > context. (My thoughts when reading that is "Why sqrt(2) and sqrt(3) > instead of pi and e - what makes those constants more trustworthy?") > I think the point is not that sqrt(2) and sqrt(3) would be better constants that pi, e, or any other constant. It's just that there are a few bits of freedom in the choice of parameters, which makes the curve "not fully rigid". This is obviously not a security concern unless you believe there is a class of weak curves with quite high density, which would IMO be very bad news for ECC in general, not only these particular curves. Which is probably why the authors of the page chose a nice green color and check symbol for both "fully rigid" and "somewhat rigid", as opposed to the frightening red color of the other classe of curves. Manuel. From Johannes.Merkle@secunet.com Wed Oct 16 08:10:44 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF8221F84D9 for ; Wed, 16 Oct 2013 08:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.501 X-Spam-Level: X-Spam-Status: No, score=-3.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnfTXwNyr+58 for ; Wed, 16 Oct 2013 08:10:39 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5E13D11E82AB for ; Wed, 16 Oct 2013 08:10:25 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 2C8001A0078; Wed, 16 Oct 2013 17:10:23 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5f4MGwWJCBdJ; Wed, 16 Oct 2013 17:10:22 +0200 (CEST) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 08F0C1A0076; Wed, 16 Oct 2013 17:10:22 +0200 (CEST) Received: from [172.16.40.201] ([172.16.40.201]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Oct 2013 17:10:21 +0200 Message-ID: <525EAC5D.7080105@secunet.com> Date: Wed, 16 Oct 2013 17:10:21 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Tom Ritter References: <525C11B5.2050604@secunet.com> <525CEFA4.2030903@funwithsoftware.org> <01b901cec9a0$004e12b0$00ea3810$@offspark.com> <525E3E6B.1020604@secunet.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2013 15:10:22.0236 (UTC) FILETIME=[D587C5C0:01CECA81] Cc: Patrick Pelletier , "tls@ietf.org" Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 15:10:44 -0000 >>> What problems does this solve? The Brainpool curves still have >>> unverifiable construction, >> >> This is plain wrong. Obviously, you have not read RFC 5639. The construction of the Brainppol curves is completely >> verifiable, only based on the fundamental constants Pi and e. > > Repeating others arguments: > > "Several unexplained decisions: Why SHA-1 instead of, e.g., RIPEMD-160 > or SHA-256? Why use 160 bits of hash input independently of the curve > size? Why pi and e instead of, e.g., sqrt(2) and sqrt(3)? Why handle > separate key sizes by more digits of pi and e instead of hash > derivation? Why counter mode instead of, e.g., OFB? Why use > overlapping counters for A and B (producing the repeated > 26DC5C6CE94A4B44F330B5D9)? Why not derive separate seeds for A and B?" The fact that the source of the seeds is explained is a huge step towards complete transparency as compared to the NIST curves. Your arguments refer to the procedure for derivation of the parameters from the fundamental constants. There is no canonical choice for such a procedure; the most obvious approach was to take it from ANSI X9.62, which we did. Admittedly, we introduced a slight change: we use the first two PRNG outputs as coefficients a and b, whereas ANSI uses the first PRNG output as r=a^3/b^2 and selects a and b arbitrarily with that relation); but this change is rather small and quite straightforward. IMO there is really not much room left for conspiracy theories. Anyone who is so paranoid (in the positive way which is useful for IT security professionals) to fear that a backdoor may have been built in by tuning the parameter generation procedure should also question all design criteria for any other curve, including Curve25519. There is always room for choices. Johannes From Johannes.Merkle@secunet.com Wed Oct 16 08:15:26 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C9C11E82C6 for ; Wed, 16 Oct 2013 08:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.36 X-Spam-Level: X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bjsod7v8f18O for ; Wed, 16 Oct 2013 08:15:19 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 31C5411E82C2 for ; Wed, 16 Oct 2013 08:15:11 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id EBDAA1A0076; Wed, 16 Oct 2013 17:15:10 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Y3HEQR-HQjeM; Wed, 16 Oct 2013 17:15:09 +0200 (CEST) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id D92F61A0071; Wed, 16 Oct 2013 17:15:09 +0200 (CEST) Received: from [172.16.40.201] ([172.16.40.201]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Oct 2013 17:15:10 +0200 Message-ID: <525EAD7D.7030508@secunet.com> Date: Wed, 16 Oct 2013 17:15:09 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= , Tom Ritter References: <525C11B5.2050604@secunet.com> <525CEFA4.2030903@funwithsoftware.org> <01b901cec9a0$004e12b0$00ea3810$@offspark.com> <525E3E6B.1020604@secunet.com> <525EA1C6.5030909@elzevir.fr> In-Reply-To: <525EA1C6.5030909@elzevir.fr> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2013 15:15:10.0061 (UTC) FILETIME=[811661D0:01CECA82] Cc: Patrick Pelletier , "tls@ietf.org" Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 15:15:26 -0000 >> I'm not sure I agree with them fully, but I also don't have very much >> context. (My thoughts when reading that is "Why sqrt(2) and sqrt(3) >> instead of pi and e - what makes those constants more trustworthy?") sqrt(2) and sqrt(3) are much less fundamental than Pi or e. If you ask mathematicians for the most fundamental constants, you will get 1, Pi, e, i, and maybe 2. I am not sure how to use the imaginary unit i in an algorithm though ;-) From watsonbladd@gmail.com Wed Oct 16 08:22:13 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0783B21F9343 for ; Wed, 16 Oct 2013 08:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hfj6Xd-CuC3 for ; Wed, 16 Oct 2013 08:22:12 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD6421F9CAF for ; Wed, 16 Oct 2013 08:21:34 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id u56so865230wes.5 for ; Wed, 16 Oct 2013 08:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rKlUtzLYy/OMbfqvqR6SwAG1cDvI+G153q1y13zAWvI=; b=R8ARzV2lA0WqhJjYzU6JuddhcRt5lZWLudrybN1/zyb6wWhjyiyNwfxrXIzI73jfVs WQtPpOPQ+iWNS/ydKZfbUYTmTHLIIvK7HiytrzwseJpB0YOfsfXSiSFggyzPtHL/A17T +y+q5blYsY9N5MmEpfC2PPLPLvYTNDA0jXCHGRvKLNtH82+D0QK94BJav8xaOjDZEGQH 9mld0RY2IHhE4V5Kdc91pD1ZzrSwbWKW75xOZPvHtlHno+yezDmOUiVNZm0XDMNHXxoa gA07dMGUiHYYQlWY83//+/JjAN7+idx4dQJhzph1uuqKcaxe0jtyFeHtAaL6r/q8ShlO Iphw== MIME-Version: 1.0 X-Received: by 10.194.172.103 with SMTP id bb7mr1095480wjc.69.1381936893322; Wed, 16 Oct 2013 08:21:33 -0700 (PDT) Received: by 10.194.242.131 with HTTP; Wed, 16 Oct 2013 08:21:33 -0700 (PDT) In-Reply-To: <525EAC5D.7080105@secunet.com> References: <525C11B5.2050604@secunet.com> <525CEFA4.2030903@funwithsoftware.org> <01b901cec9a0$004e12b0$00ea3810$@offspark.com> <525E3E6B.1020604@secunet.com> <525EAC5D.7080105@secunet.com> Date: Wed, 16 Oct 2013 08:21:33 -0700 Message-ID: From: Watson Ladd To: Johannes Merkle Content-Type: text/plain; charset=UTF-8 Cc: Patrick Pelletier , "tls@ietf.org" Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 15:22:13 -0000 On Wed, Oct 16, 2013 at 8:10 AM, Johannes Merkle wrote: >>>> What problems does this solve? The Brainpool curves still have >>>> unverifiable construction, >>> >>> This is plain wrong. Obviously, you have not read RFC 5639. The construction of the Brainppol curves is completely >>> verifiable, only based on the fundamental constants Pi and e. >> >> Repeating others arguments: >> >> "Several unexplained decisions: Why SHA-1 instead of, e.g., RIPEMD-160 >> or SHA-256? Why use 160 bits of hash input independently of the curve >> size? Why pi and e instead of, e.g., sqrt(2) and sqrt(3)? Why handle >> separate key sizes by more digits of pi and e instead of hash >> derivation? Why counter mode instead of, e.g., OFB? Why use >> overlapping counters for A and B (producing the repeated >> 26DC5C6CE94A4B44F330B5D9)? Why not derive separate seeds for A and B?" > > The fact that the source of the seeds is explained is a huge step towards complete transparency as compared to the NIST > curves. Your arguments refer to the procedure for derivation of the parameters from the fundamental constants. There is > no canonical choice for such a procedure; the most obvious approach was to take it from ANSI X9.62, which we did. > Admittedly, we introduced a slight change: we use the first two PRNG outputs as coefficients a and b, whereas ANSI uses > the first PRNG output as r=a^3/b^2 and selects a and b arbitrarily with that relation); but this change is rather small > and quite straightforward. IMO there is really not much room left for conspiracy theories. > > Anyone who is so paranoid (in the positive way which is useful for IT security professionals) to fear that a backdoor > may have been built in by tuning the parameter generation procedure should also question all design criteria for any > other curve, including Curve25519. There is always room for choices. Curve25519 picks the smallest value of A that meets the parameters. Once the prime, shape, and all restrictions are selected, the result is deterministic. Brainpool is close enough that I would say "quite rigid" as opposed to "deterministic construction". Basically, the length of a PARI script to generate the curve should be short. > > Johannes > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From Johannes.Merkle@secunet.com Wed Oct 16 08:46:07 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1DF11E82FD for ; Wed, 16 Oct 2013 08:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.355 X-Spam-Level: X-Spam-Status: No, score=-3.355 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeeEXgGUxJwG for ; Wed, 16 Oct 2013 08:46:02 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id C140C21F8AD5 for ; Wed, 16 Oct 2013 08:45:47 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 8D8B81A0076; Wed, 16 Oct 2013 17:45:44 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UVQpr2nTVen3; Wed, 16 Oct 2013 17:45:42 +0200 (CEST) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id A71DE1A0071; Wed, 16 Oct 2013 17:45:42 +0200 (CEST) Received: from [172.16.40.201] ([172.16.40.201]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Oct 2013 17:45:42 +0200 Message-ID: <525EB4A6.3020601@secunet.com> Date: Wed, 16 Oct 2013 17:45:42 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= , Tom Ritter References: <525C11B5.2050604@secunet.com> <525CEFA4.2030903@funwithsoftware.org> <01b901cec9a0$004e12b0$00ea3810$@offspark.com> <525E3E6B.1020604@secunet.com> <525EA1C6.5030909@elzevir.fr> In-Reply-To: <525EA1C6.5030909@elzevir.fr> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Oct 2013 15:45:42.0831 (UTC) FILETIME=[C580E3F0:01CECA86] Cc: Patrick Pelletier , "tls@ietf.org" Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 15:46:07 -0000 Manuel Pégourié-Gonnard schrieb am 16.10.2013 16:25: > On 16/10/2013 15:32, Tom Ritter wrote: >> I'm not sure I agree with them fully, but I also don't have very much >> context. (My thoughts when reading that is "Why sqrt(2) and sqrt(3) >> instead of pi and e - what makes those constants more trustworthy?") Also, Pi and e as transcendental numbers seem more "unstructured" as any (square or higher-order) root. Just imagine an imaginary hash function taking as a first step the square of the input string taken as integer. Surely, SHA-1 does not work this way but the "unstructuredness" of transcendental numbers seems more robust against any kind of arithmetic processing. > This is obviously not a security concern unless you believe there is a class of > weak curves with quite high density, which would IMO be very bad news for ECC in > general, not only these particular curves. In support of this argument let me summarize my answers to the assessment on http://safecurves.cr.yp.to/rigid.html Q: Why SHA-1 instead of, e.g., RIPEMD-160 or SHA-256? A: Procedure follows ANSI X9.62 Q: Why use 160 bits of hash input independently of the curve size? A: 160 bit is the minimal amount of input entropy needed to allow maximum entropy n the hash value. Q: Why pi and e instead of, e.g., sqrt(2) and sqrt(3)? A: Most mathematicians will acknowledge that pi and e are more fundamental than sqrt(2) and sqrt(3). Furthermore, as transcendental numbers they are more robust w.r.t the "unstructuredness" of their decimal representation. Q: Why handle separate key sizes by more digits of pi and e instead of hash derivation? A: Follows the KISS principle. But, yes, there was a very small degree of freedom. Q: Why counter mode instead of, e.g., OFB? A: Counter mode? We didn't use block ciphers. If you refer to the counter used in computation of hash values, this follows ANSI X9.62. Q: Why use overlapping counters for A and B (producing the repeated 26DC5C6CE94A4B44F330B5D9)? A: I admit that this is unfortunate. And yes, there was a very small degree of freedom. Q: Why not derive separate seeds for A and B? A: Yes, there was a very small degree of freedom. You see, there is not much freedom in the choices made, which implies that implanting a back door would have required a very large class of weak curves or great luck. -- Johannes From Johannes.Merkle@secunet.com Wed Oct 16 08:54:50 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA2B11E8328 for ; Wed, 16 Oct 2013 08:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRf+2vxhj97r for ; Wed, 16 Oct 2013 08:54:41 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDC011E8324 for ; Wed, 16 Oct 2013 08:54:00 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 162D01A0076; Wed, 16 Oct 2013 17:53:59 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nhx5TJN1dvLS; Wed, 16 Oct 2013 17:53:58 +0200 (CEST) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 0AE9A1A0071; Wed, 16 Oct 2013 17:53:58 +0200 (CEST) Received: from [172.16.40.201] ([172.16.40.201]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Oct 2013 17:53:58 +0200 Message-ID: <525EB695.9070607@secunet.com> Date: Wed, 16 Oct 2013 17:53:57 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Watson Ladd References: <525C11B5.2050604@secunet.com> <525CEFA4.2030903@funwithsoftware.org> <01b901cec9a0$004e12b0$00ea3810$@offspark.com> <525E3E6B.1020604@secunet.com> <525EAC5D.7080105@secunet.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Oct 2013 15:53:58.0107 (UTC) FILETIME=[ECB602B0:01CECA87] Cc: Patrick Pelletier , "tls@ietf.org" Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 15:54:50 -0000 > Curve25519 picks the smallest value of A that meets the parameters. Why the smallest, not the largest negative? Why using little /big endian (don't know which was used) instead of the other? Why choosing exactly these conditions (you phrase it "parameters"). Don't get me wrong. I admit that the construction of Curve25519 is extremely rigid, and even more rigid than that of the Brainpool curves. I only point to the fact that there is no perfect rigidity. > is deterministic. Brainpool is close enough that I would say "quite > rigid" as opposed to "deterministic construction". Basically, the I think we can agree on that statement. > length of a PARI script to generate the curve should be short. Good idea, minimal Kolmogorov complexity should be a good formal definition. -- Johannes From nico@cryptonector.com Wed Oct 16 09:29:31 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 856FC11E8313 for ; Wed, 16 Oct 2013 09:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.981 X-Spam-Level: X-Spam-Status: No, score=-1.981 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQWI9O-5C8kg for ; Wed, 16 Oct 2013 09:29:27 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id D436511E8304 for ; Wed, 16 Oct 2013 09:29:26 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 4DF61508072 for ; Wed, 16 Oct 2013 09:29:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=gM0ta3DkWJ67gqm4dhA6 B1KAeUQ=; b=eh4rR4OXiCBy8xTEET/hakLKfRUZ6HTf+MlH1qdrcubNHgDVu8nQ AZ1G1ziqgAWvQDN/l8baOaG9qP27L850KQenWzcmJc/MWMNygfvqG1ZRe0Ecw4a3 nwuXHAIJJSdggVVeWxmMuc3uCvNrfNPUmjTKOdnvjd/QRu3LuF/dZ1Q= Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 26950508084 for ; Wed, 16 Oct 2013 09:29:26 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id e14so1763987iej.11 for ; Wed, 16 Oct 2013 09:29:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WmrdsK+j1JSmYakR6zA45R+oKvvaCgG5Rk4L+irzodw=; b=JhlfzL4JCzMsAQWOy7IJI1+qNfw2dzlqx2CI/6/mIQOVmuwnMjng1k8tJVi1laMi6J dusCICTEXdT0+8FL15lYdPMHR5zuwxdyk1hZUnpXcKOcXSn0KK04tBnRSQhDHjPndAjF JFbiKT5PWnPptauz+SEQ4+PnrnAFtKTJbii7xjk5GpMy9lJyPENjaKLrQb32YKdmNNvj QoGSNt9yc+4fKvnMYN4heHdHAutaOgjkkv6mWb297Ptv3QLYYk+l2Wrzj31i+Ac+G+LH dE1fGPLbKyC8tQu3iqoy8376SGzM4qogCt3/WUEpg8Ls1RGCBqBjO36bnPkSsc/Oh2r9 XB0g== MIME-Version: 1.0 X-Received: by 10.42.82.196 with SMTP id e4mr1607107icl.58.1381940965242; Wed, 16 Oct 2013 09:29:25 -0700 (PDT) Received: by 10.64.128.225 with HTTP; Wed, 16 Oct 2013 09:29:25 -0700 (PDT) In-Reply-To: <525EB695.9070607@secunet.com> References: <525C11B5.2050604@secunet.com> <525CEFA4.2030903@funwithsoftware.org> <01b901cec9a0$004e12b0$00ea3810$@offspark.com> <525E3E6B.1020604@secunet.com> <525EAC5D.7080105@secunet.com> <525EB695.9070607@secunet.com> Date: Wed, 16 Oct 2013 11:29:25 -0500 Message-ID: From: Nico Williams To: Johannes Merkle Content-Type: text/plain; charset=UTF-8 Cc: Patrick Pelletier , "tls@ietf.org" Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 16:29:31 -0000 On Wed, Oct 16, 2013 at 10:53 AM, Johannes Merkle wrote: >> Curve25519 picks the smallest value of A that meets the parameters. > Why the smallest, not the largest negative? Why using little /big endian (don't know which was used) instead of the > other? Why choosing exactly these conditions (you phrase it "parameters"). Endianness has no impact on the mathematics involved. Smallest because there is such a thing (as opposed to largest, which is unbound). It could have been smallest absolute value, allowing one more degree of freedom. Perhaps there's a class of attacks that works with positive As and not with negative As (or vice-versa)? But that seems unlikely. > Don't get me wrong. I admit that the construction of Curve25519 is extremely rigid, and even more rigid than that of the > Brainpool curves. I only point to the fact that there is no perfect rigidity. Agreed. I like DJB's curve constructions because as much as possible is explained verifiably. >> is deterministic. Brainpool is close enough that I would say "quite >> rigid" as opposed to "deterministic construction". Basically, the > > I think we can agree on that statement. Agreed. But the SafeCurves site doesn't focus only on construction rigidity, and it doesn't discount Brainpool on account of rigidity in its construction. SafeCurves also covers other issues. SafeCurves declares Brainpool curves not safe according to the following criteria: - feasibility of efficient constant-time implementation http://safecurves.cr.yp.to/ladder.html - twist security http://safecurves.cr.yp.to/twist.html IIUC this means that when using non-twist secure curves one has to validate that peers' public keys are on the curve being used, which in turn would require exchanging not just public keys but also Schnorr signatures (and, of course, verifying those signatures before using peers' public keys for any other purpose). - completeness http://safecurves.cr.yp.to/complete.html This is an argument that's purely about implementation complexity and performance. I'm not sure how concerned to be about this -- less than about the previous two concerns above, no doubt. - indistinguishability of public key values from random http://safecurves.cr.yp.to/ind.html No EC curve has this. But for some curves one can construct a mapping between any point and some small set of non-points all of which can then be mapped right back into the original. And such a mappings can be made constant-time in the case of the three given safe curves. But no such mappings are known for the other curves (including Brainpool). This is primarily a problem for protocols aiming for privacy protection and for some ZKPPs (e.g., EKE) (but not for, say, J-PAKE, which, incidentally, uses Schnorr signatures to verify public key validity). Nico -- From mike-list@pobox.com Wed Oct 16 10:02:39 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5BB11E8182 for ; Wed, 16 Oct 2013 10:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIeQdSPCua6E for ; Wed, 16 Oct 2013 10:02:34 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id BAEEC11E8125 for ; Wed, 16 Oct 2013 10:02:34 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id B3E49E2B4; Wed, 16 Oct 2013 13:02:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=s11AtXD+Xxue igei+9Qdb2gu2zU=; b=IxT7U8MOxAbMqatzlYEsxKekPxg5iHJhXiKYWrEQO2+2 mT0kyUK0tXtSDvpxnBoahOBkYnJnDTzeaxkT7c+cKobj4EZJSHbo9OgGxmf4qLTk 2p784KncxHjWBw+0B981lljsdnIAdr2Oh2cDTGTQfK+ONpLjdINEL0Hx3W/ybV4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=qUF4x+ A1kkuDGdebSB2U60lZRJEdZKBabAcO95XRD82gN7iR2rGlvP1Igucan0P+8HTL14 LNRQ5pShJV17C0++XJ5TQpiZmxqMI2rBeqjKez6npoSa365eEUZUh3ZDHUyq8DXf gvwxbGpTBIuEGZOVVvwsbOR1ZUQZiYljNtcgg= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id A8910E2B3; Wed, 16 Oct 2013 13:02:32 -0400 (EDT) Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 0DF60E2B0; Wed, 16 Oct 2013 13:02:31 -0400 (EDT) Message-ID: <525EC6A6.70209@pobox.com> Date: Wed, 16 Oct 2013 10:02:30 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Johannes Merkle References: <525C11B5.2050604@secunet.com> <525CEFA4.2030903@funwithsoftware.org> <01b901cec9a0$004e12b0$00ea3810$@offspark.com> <525E3E6B.1020604@secunet.com> <525EA1C6.5030909@elzevir.fr> <525EAD7D.7030508@secunet.com> In-Reply-To: <525EAD7D.7030508@secunet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: BF30EE4A-3684-11E3-96B7-0A540E5B5709-38729857!a-pb-sasl-quonix.pobox.com Cc: TLS Mailing List Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 17:02:39 -0000 Johannes Merkle wrote: > > sqrt(2) and sqrt(3) are much less fundamental than Pi or e. If you > ask mathematicians for the most fundamental constants, you will get > 1, Pi, e, i, and maybe 2. > > I am not sure how to use the imaginary unit i in an algorithm though ;-) Well, they are all related to each other as 1 - e^(i * Pi) = 2 so you can omit one of them. :-) Mike From anders.rundgren@telia.com Wed Oct 16 10:43:30 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA9F11E8191 for ; Wed, 16 Oct 2013 10:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoBXDfyiNQxf for ; Wed, 16 Oct 2013 10:43:25 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id CD1C721F9A5F for ; Wed, 16 Oct 2013 10:43:13 -0700 (PDT) Received: from [192.168.1.99] (78.125.57.162) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 521DAB1700C8972B for tls@ietf.org; Wed, 16 Oct 2013 19:43:11 +0200 Message-ID: <525ED02A.2030705@telia.com> Date: Wed, 16 Oct 2013 19:43:06 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: TLS Mailing List References: <525C11B5.2050604@secunet.com> <525CEFA4.2030903@funwithsoftware.org> <01b901cec9a0$004e12b0$00ea3810$@offspark.com> <525E3E6B.1020604@secunet.com> <525EA1C6.5030909@elzevir.fr> <525EAD7D.7030508@secunet.com> <525EC6A6.70209@pobox.com> In-Reply-To: <525EC6A6.70209@pobox.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 17:43:30 -0000 Brainpool just hit another protocol: http://webpki.org/papers/keygen2/keygen2.junit.run.html#ProvisioningInitializationRequest.BrainpoolOption.1 anders From watsonbladd@gmail.com Wed Oct 16 11:48:50 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7282911E82CE for ; Wed, 16 Oct 2013 11:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TP5DsHF+aimg for ; Wed, 16 Oct 2013 11:48:49 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 877D911E8196 for ; Wed, 16 Oct 2013 11:48:29 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id l12so7460788wiv.5 for ; Wed, 16 Oct 2013 11:48:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XbN7Z4eja9jsdRixm8mC1BC1BYe9+xNhqF1M0F46RTs=; b=F+7M18xf8Y0usW0MVpQ9aFcgSkr7nzbzrwkF73MbETKkSWNBRWatO8u7DK/zKf7ipq E6U7pnZhiau3Xet8hJqiMtevxX7K7B6cfIIeGkfpxPuiIdclpcNuLArEUTptn0TMmXjm yzDt4Mt1CMoSA8WJDv5xiROnMIhuN1tGc6N7op/IB+46t6dfoQaoFv0J2sqmZBYO2KD1 li5GN2IZqma35GipzkMuq/z0YOK9sF3jS+ZOYmR0fI2denTrQ6+0whUctTHrtujBph4E wD9utJpo6TlFDYMBKUDexvMh7BSAIvq2YeSJQz6NAODocXuZCsxWSMlP/39ZmP2SoLvU AXuw== MIME-Version: 1.0 X-Received: by 10.180.76.205 with SMTP id m13mr3578215wiw.10.1381949308726; Wed, 16 Oct 2013 11:48:28 -0700 (PDT) Received: by 10.194.242.131 with HTTP; Wed, 16 Oct 2013 11:48:28 -0700 (PDT) In-Reply-To: <525E3404.2090808@elzevir.fr> References: <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> <87zjrl21wp.fsf_-_@latte.josefsson.org> <8738outeup.fsf@latte.josefsson.org> <525E3404.2090808@elzevir.fr> Date: Wed, 16 Oct 2013 11:48:28 -0700 Message-ID: From: Watson Ladd To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Curve25519 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 18:48:50 -0000 Minor nitpicks about language below. On Tue, Oct 15, 2013 at 11:36 PM, Manuel P=C3=A9gouri=C3=A9-Gonnard wrote: > Hi, > > On 24/09/2013 17:32, Simon Josefsson wrote: >> http://tools.ietf.org/html/draft-josefsson-tls-curve25519-01 >> > I think a few points should be clarified in the draft. As the > introduction correctly states, Curve25519 is a new ECDH function, not > just a new curve for use with the usual ECDH construction. Let me sum up > the constructions of ECDH in TLS and in Curve25519. > > TLS ECDH: > 1. Private keys: random integer in the range [1, q-1] with q the order of= G. > 2. Public keys: a point on the curve (defined over F_p). > 3. Public key encoding: either > (a) the x and y coordinates of the point, or > (b) the x coordinate and a bit for determination of the y coordinate, > with integers represented as big-endian bytes strings, preceded by a > first byte indicating which format was chosen (and holding the possible > additional bit). I don't believe this is correct: RFC4492 permits curves with cofactor greater than one. I don't have a copy of the IEEE standard in front of me, but I believe in this case one has to do a group membership check. So it depends on what the meaning of G is. > > Curve25519 ECDH: > 1. Private keys: random 254-bit positive integer with the high-order bit > set and the three lowest-order bits cleared. > 2. Public keys: any number in the range [0, 2^{256}-1]. > 3. Public key encoding: a byte string in little-endian convention. > > Now I'll discuss the differences and possible issues in more detail. > > 1. Concerning the private key, I think keeping the paper's definition > does not raise any issue. Implementors should just be careful to use a > special procedure for this curve. What is actually happening is that exponentiation by the private key is annihilating the small order torsion subgroup on both the curve and the twist because the private key is divisible by 8, and the curve and twist have large prime-order subgroups with cofactor 8 and 4 respectively. This is a big difference from the usual method, in which one only sends members. > > 2. Concerning the public key, the 256-bit integer in the paper > represents (modulo p) the x coordinate of a point on the curve E, but > this point may not be defined over F_p, but over F_{p^2}. An alternative > way of seeing things is that the public key may be either the x > coordinate of a point in E(F_p) or of a point in E'(F_p) where E' is the > twist curve y^2 =3D x^3 + 2Ax^2 + 4x. > > By construction of E, this is not a security issue at all, and rather a > fact that simplifies implementations of the Curve25519-ECDH protocol, > since there is no need to check the validity of public keys and they are > shorter, but it introduces a real difference (in the type of objects, > not just their representation) with the usual TLS ECDH function. > > 3. So, if we want to preserve the nice property than any 32-byte string > (ie, any 256-bit integer x) is a valid key (and I think we do), we don't > have a y coordinate at our disposal for the normal encoding procedure. > Some ideas around this issue: > > A. Just use the convention y =3D 0 and one of the existing formats. > Pros: simple, just works. > Cons: with the basic "uncompressed" format, wastes 32 bytes of bandwidth. Also, a dirty hack. > > B. Always use the "ansiX962_compressed_prime" format. > Pros: doesn't waste bandwidth. > Cons: forces applications to advertise support this format, which is a > problem if they can't support it for other prime curves, unless we > introduce an exception to the effect that support for this format with > this particular curve is implied as soon as support for the curve is > advertised. Does not seem very clean to me. The other issue is that this isn't the ansiX962 format for deep technical reasons. You would need to use a birational morphism to Weirstrau=C3=9F form, which is a pointless PITA, or just tell pleasing lies, which annoys those of us trying to analyze things, and is a potential source of bugs. > > C. Introduce a new point format "compressed_prime_montgomery". > Pros: doesn't waste bandwidth, doesn't look hacky. > Cons: a new point format only for one curve? OTOH, it is indeed a > particular class of curve, since the recommended formulas work only with > the x coordinate, and other curves in this class may be added later. > > Note that A and C may be combined. Probably the best idea, especially given that definition of addition is completely different. > > Any other idea? > > Manuel. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From dbrown@certicom.com Wed Oct 16 12:37:25 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDC5911E8260 for ; Wed, 16 Oct 2013 12:37:25 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxKbiTrHfRZR for ; Wed, 16 Oct 2013 12:37:20 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 16C5511E8181 for ; Wed, 16 Oct 2013 12:36:53 -0700 (PDT) Content-Type: multipart/mixed; boundary="===============1319045333==" MIME-Version: 1.0 Received: from xct103cnc.rim.net ([10.65.161.203]) by mhs213cnc.rim.net with ESMTP/TLS/AES128-SHA; 16 Oct 2013 15:36:50 -0400 Received: from XCT104CNC.rim.net (10.65.161.204) by XCT103CNC.rim.net (10.65.161.203) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 16 Oct 2013 15:36:49 -0400 Received: from XMB117CNC.rim.net ([fe80::24f3:cc30:b596:7ca0]) by XCT104CNC.rim.net ([::1]) with mapi id 14.03.0123.003; Wed, 16 Oct 2013 15:36:49 -0400 From: Dan Brown To: "'djb@cr.yp.to'" , "'tls@ietf.org'" Thread-Topic: [TLS] Safe ECC usage Thread-Index: AQHOxuJRxn3XJXmgAkKRAg2ZE6kwf5n3qq2g Date: Wed, 16 Oct 2013 19:36:48 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF5BEBAA5@XMB117CNC.rim.net> References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> <20130926152757.15842.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDB49B@XMB116CNC.rim.net> <20130928223648.1113.qmail@cr.yp.to> <20130929025714.5578895.47771.4422@certicom.com> <20131001143511.11010.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE21E@XMB116CNC.rim.net> <20131002161944.8125.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE90F@XMB116CNC.rim.net> <20131003010455.17185.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDECA6@XMB116CNC.rim.net> <20131005192950.27059.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BE4A9D@XMB116CNC.rim.net> <20131012003058.669.qmail@cr.yp.to> In-Reply-To: <20131012003058.669.qmail@cr.yp.to> Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] MIME-Version: 1.0 Subject: Re: [TLS] Safe ECC usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 19:37:26 -0000 --===============1319045333== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_013A_01CECA85.8702ECA0" ------=_NextPart_000_013A_01CECA85.8702ECA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit D. J. Bernstein writes: > Dan Brown writes: > > if an attack affects all random curves, excluding Curve25519, then > > basically ECC would be no more, > > Here are six examples of attacks that already affect the security level > of the vast majority of elliptic curves: > > * Shanks's baby-step-giant-step attack. Drastic reduction in the > number of arithmetic operations required to break ECDLP. There's > no > defense against this attack. > > * The Pohlig--Hellman attack. Further drastic reduction in the > number > of arithmetic operations required for _most_ curves---but not all; > there are occasional special curves that resist the attack. > > * Twist attacks. Again applicable to _most_ curves---but, again, not > all; again there are occasional special curves that resist the > attack. > > * Negating rho. Okay, it's just a 1.4x attack speedup, but I can't > see any justification for you to ignore it. There's no defense > against this attack. > > * Pollard's rho attack. Drastic reduction in _memory_ consumption, > making elliptic curves much easier to break (in reality, and in > sensible cost metrics). There's no defense against this attack. > > * The van Oorschot--Wiener parallel rho attack. Drastic reduction in > _communication_, allowing efficient parallelization, again making > elliptic curves much easier to break. There's no defense against > this attack. > > So you're wrong in implying that there haven't already been attacks > that affect "random curves". Do we respond by discarding ECC, as you Yes, those are pretty good examples favouring special over random, but they are not pertinent to my analysis. The S, PH, P, and vOW attacks above affect any group over which one does DH/DL crypto. They are not ECC-specific. Resisting these attacks and doing DH/DL crypto requires ensuring the parameters resist the attacks. So, any DH/DL system needs to use a group whose order has a prime factor of bit size at least twice the desired security level. If I was an opponent of DH/DL, let's say RSA or NTRU, I might use these to argue against DH/DL. One reason, despite such arguments, to still use DH/DL is forward secrecy. I don't know if NTRU provides forwards secrecy as efficiently as DH/DL. I made a mistake in my previous email about the class of curves to which I restricted: I forgot to specify that I meant random EC curves that meet these generic conditions. When I say "curve" in the context of ECC, I assume this condition. Maybe you have a more mathematically correct perspective, and read random curve to include these vulnerable to PH. The twist attack is just as easily addressed by checking the point before applying one's private key to it. (Unless I misunderstand.) Yes, implementation fault resistance is important, but it is secondary to algorithm security, because an insecure algorithm cannot be fixed any kind of implementation technique. In this case, my personal opinion is that the most reasonable guesses at the difference in algorithm security here are so slight, then implementation fault resistance benefits of Curve25519 have much merit. In other words, I wouldn't object to that argument. The negation attack is considerably weaker than the MOV and SASS attacks, and in any case it seems to be the price to pay for any form of ECC. So, it cannot be used to choose between curves. To summarize, once one sets up the basic DH/DL requirements, and tries to make a choice of ECC for this purpose, then the attack count is still 0 random, and 2 special (or 1 if you prefer to merge MOVFR and SASS into a transfer attack). Based on this score, if I had to guess what the next attack would be, then I would guess special. An attack on random would be a breakthrough. Therefore, trying to choose a random curve is a best guess approach. > suggest? > Of course not. We respond by choosing parameters to resist the attacks: > > * Choose _extremely_ special curves (we're talking about one curve > in > a thousand here!) that defend against twist attacks and the > Pohlig--Hellman attack. > > * Choose primes far above 200 bits to defend against the other four > attacks. > > Of course, we also take time to further investigate and build > confidence that the security story is stable. All of these attacks have > been known for more than ten years (three of them even before ECC was > published), as have the two attacks that you mentioned for extremely > rare curves. > People working on attacks have found interesting improvements for > extension fields, higher genus, etc., but seem to have run out of ideas > for attacking prime-field ECC. > > > So far, there no are 0 (*) attacks against random curves, and 2 > > against special curves: the MOV and SASS attacks. I view this as > > quite good evidence in favour of random curves, over special curves. > > That's because you're simply ignoring all the contrary evidence. For > example, if you insist on using random curves then Pohlig--Hellman will > damage your security, probably quite severely. That's why everyone is > actually using rare curves that resist the Pohlig--Hellman attack. I already answered this above, but in brief: PH must resisted by all forms of DH/DL crypto, so is not a basis to choose between EC curves. And yes again, I did forgot to mention in my definition of random curves the condition that the group order be divisible by a large prime. This is a fact that I take for granted. > > In other words, rather than taking the uniform distribution over all > elliptic curves of whatever size, ECC users are massively biasing the > distribution of elliptic curves. The biased distribution discards the > vast majority of elliptic curves: at least the curves vulnerable to > Pohlig--Hellman, and nowadays also the curves that aren't twist-secure. > Every sane risk analysis will conclude that this bias is a good idea. Not that it matters, but my psychiatrist let me go home. > > I say that it's a good idea to narrow the distribution even more, in > fact down to a single curve, by taking the _smallest_ curve coefficient > within the usual massively biased distribution. That's what Curve25519 > does. This isn't just a performance win; it also prevents the sort of > manipulation that's clearly possible for someone who claims to be > "randomly" choosing curves from the wider distribution. > > Now imagine that there's no manipulation. How does this single-curve > distribution compare in security to the larger (massively biased) > distribution against some unknown attack? The correct answer is that we > have no idea---maybe it's more secure, maybe it's less secure, maybe > it's the same. Uncertainty, "no idea", about unknown attacks is a given, but we should still try to resist them, even if that means making assumptions and guessing. Provably secure algorithm try to do this. Previously unknown attacks are known pop up, occasionally. But, we also give weight to the effort that people have exerted in trying to find attacks, to infer the unlikelihood of new attacks being discovered. > > You keep trying to trivialize this question by promoting the myth that > more uniformity is safer. You present this as some sort of ill-defined > dichotomy between "random" and "special", with "random" clearly being > better. You take every break of a small curve class as support for your > position, retroactively declaring the curves in the class to be > "special", while you ignore the glaring counterexamples such as Pohlig- > -Hellman. As I said above, I take PH resistance for granted in any DH/DL, and a built into the ECC. > > > You gave an example that, under reasonable assumptions, with 2^(-30) > > probability the ECDLP in Curve25519 could be solved in 2^64 > > computations. > > No. What I actually wrote was "Suppose NSA knows---and knew in the late > 1990s---a cost-2^64 attack that breaks one P1363-compliant 256-bit > curve in a billion". I gave examples to illustrate that this "wouldn't > be out of line with the spectrum of known ECC attacks". I then > explained how this attack would have allowed NSA to _guarantee_ > weakness of the NIST > P-256 curve, while for an honestly generated curve the situation is > obviously quite different. Why was I wrong? Is it because Curve25519 is not P1363-compliant? > > By misstating my assumptions as being specific to Curve25519, you're > omitting the critical security impact on NIST P-256, and you're also > promoting a misconception that ECC security analysis is curve-specific. > Yes, your supposition applies to any fixed curve, including Brainpool and Curve25519. Yes, it is not curve-specific. > > I do not see how those assumptions are reasonable, but even so, if > > 2^30 people use Curve25519, then is that a good risk? > > I have no idea what you think you mean by "a good risk" (and I also Good meaning sufficiently small compared to the benefit. > have no idea why you're talking about the number of people---the > discussion is about weak curves, not weak keys). In the situation that If an algorithm is weak, then all its users lose. My heuristic is that the ensuing loss is proportional to the number of (human) users. Such heuristics might be useful to define what a good risk is. Granted for most risks we have make a lot of guessing, but it still has merit to try. > I actually described, there's no reason to think that the risk is > different for > Curve25519 and for an _honestly_ generated NIST P-256. The problem is See all my arguments above. > that we don't know whether NIST P-256 was honestly generated. Agreed that is a problem. I am still surprised that you think it so reasonable a supposition. I forgot now, what attacks you quoted to support that position. Was it PH? > > > Do you feel that the system-wide risk for RSA, or integer DH is > comparable? > > There are improvements in index calculus all the time. Those have been > continually dragging down the security level of RSA, which in turn has > been dragging down the performance of RSA, which is exactly why modern > RSA is so much slower than ECC. > Yes, that's well-known, but is it reasonable to suppose that, with probability 2^(-30) some lurking adversary knows an attack a 2^64 cost attack against each possible RSA key? I don't see any evidence to support that reasonability of the weakness in the whole RSA algorithm. (Weak low-density classes of RSA keys, maybe but that's different.) ------=_NextPart_000_013A_01CECA85.8702ECA0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUgTCCBnAw ggVYoAMCAQICChfYCekAAwAXxTIwDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAz WUtGMB4XDTEzMDUyODE1NDQwOVoXDTE0MDUxNzAwMjMzM1owgYUxEzARBgoJkiaJk/IsZAEZFgNu ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xETAPBgNVBAsTCENlcnRpY29tMQ4wDAYDVQQLEwVVc2Vy czESMBAGA1UEAxMJRGFuIEJyb3duMSIwIAYJKoZIhvcNAQkBFhNkYnJvd25AY2VydGljb20uY29t MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDRc70RE0/FL9ZbfN64YjA0lkQOLR9ipGebc9nH jB93OfYfR7CVsCUYy3+v9PO1DiUS9MeWWR4nxB9Ztee32d3syDxGg3PGFwSrms/ORAW9pgiS/yKH An9SKRKyqMz9LSn/VQrEgoyPBPT0S/vg521MGH58MwMXyLm1cLBQU5gtCQIDAQABo4IDmDCCA5Qw CwYDVR0PBAQDAgWgMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQME AgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUAlQmTNpWxnzoCUVjxGTtDz2JvLww FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMB8GA1UdIwQYMBaAFLgwF25vZ5X+hYxoO6XhF7M/+CU6 MIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiGgctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu YXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1NQ0EwM1lLRixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIw U2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2Fs P2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRp b25Qb2ludIZIaHR0cDovL21jYTAzeWtmLnJpbS5uZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRp bmF0ZSUyMENBJTIwTUNBMDNZS0YuY3JsMIIBQQYIKwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUH MAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1BSUEs Q049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixE Qz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZp Y2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxodHRwOi8vbWNhMDN5a2YucmltLm5ldC9DZXJ0 RW5yb2xsL01DQTAzWUtGLnJpbS5uZXRfUklNJTIwU3Vib3JkaW5hdGUlMjBDQSUyME1DQTAzWUtG KDMpLmNydDApBgNVHSUEIjAgBgorBgEEAYI3CgMEBggrBgEFBQcDBAYIKwYBBQUHAwIwQQYDVR0R BDowOKAhBgorBgEEAYI3FAIDoBMMEWRhbmlicm93bkByaW0ubmV0gRNkYnJvd25AY2VydGljb20u Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQC6hxWgDv96DUDS3m8XfyVGAv1CKOcWSVOShz/jofFMFzoN o2dhc0Jg9XTTZBVS+ozakEM+87YUENfP3IODRbCiJBsbiXJxS+fVo7L/bqPp47TB+Lg2/tezlNa2 ab4psmc9xjZGU9+A4lBzS5PpRjvHofsIwETpwt/aPxHIbJ5Cf7kBi7B8hR4mIqc7EJMYXeI0xHLg k3NqBYSGC3XtbykuFV0vPFoTYLO7G3pAP2RzGhuxQoaH4fpWvE3rdakjd1MZFqJrarXSvWi6ah6G Alt7+sOTzlGNqoTQqb55VZEOrU2A1VbmAFjiFR1/229A2KaHhnN6cuNe8bhzoBcnuxtyMIIGvzCC BKegAwIBAgIQMhrzkrEUWZRNTS+VEbN74TANBgkqhkiG9w0BAQUFADBPMRUwEwYKCZImiZPyLGQB GRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBN Q0EwMVlLRjAeFw0wNjEwMTMwMTI0NTVaFw0xNjEwMTMwMTMwNDFaME8xFTATBgoJkiaJk/IsZAEZ FgVsb2NhbDEXMBUGCgmSJomT8ixkARkWB3dpbmRvd3MxHTAbBgNVBAMTFFJJTSBSb290IENBIE1D QTAxWUtGMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAxui6zvytVAEtPzv6NhK7OZna iw/jQEyEVskDf5yzcFkLT/+5PztIbv+eFmL1CP2FhvLv8eQZJDKF4Yv+UsjPEN1lX4DDGKKt0NPp yT9pwQzFaiUt0rnERgSabo7EtpS4S+DuL8G9c+lmWwDqb0UWtPMdVfbr3fDwigyz1yh+vVMAHdhg Oe9lPC6nPtiJ9IXTam7V5mJmDT0mNpq/0fJo3JEaNvDKoXBOkKv6IdbtKxKzPInG6VYaCdgJCAT3 mWgr9kxiEQEUJKrvI2fXI0zRYnlL648gvK84pdsT2xZLFtr4OdZAm4RkK8U+cgurlSCr6NVqnfbq 6/3N6MGmyc9SB2Ayhk2VS66757V4nBzeaeD+srpk4IXU3NTM/+YgR1zVS41XwvZaq9Uf59j0TJhN 9xGVZO871eVVr2VfNxr0xOqUpwcxh5JZYkWcmUJFlYiQh0CM2PrfaDRTTqRZQd4F3xUlcXFAXOGh vaXKvikeI6/utnX6vCnDwMUxmenzlv8epNatxDsuIgOWO4pfqgGMyzWo2hudQ97+5ynUqDLX34nr UzszGeIE3KoqYsksxMF3tqIgadt9hNWXaP/EknZpRAmaP0s0V5ZvgiyXw9UrqnWwmRbLQk7HnYc0 hHQBjXoByKSiOyhgSS9yL6a+7AA2rhBPpsSVI9LYBs2cNKlPsZcCAwEAAaOCAZUwggGRMBMGCSsG AQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTW aYJkJBbBzCTb8RR9RxJ83MlN7jCCASkGA1UdHwSCASAwggEcMIIBGKCCARSgggEQhoHEbGRhcDov Ly9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1NQ0EwMVlLRixDTj1DRFAsQ049UHVi bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5k b3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1j UkxEaXN0cmlidXRpb25Qb2ludIZHaHR0cDovL21jYTAxeWtmLndpbmRvd3MubG9jYWwvQ2VydEVu cm9sbC9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwDQYJ KoZIhvcNAQEFBQADggIBAEOeWFu4OVTnx9+jYk92iDra2f1Bc5j1WesEGINl4VCY9WJy6n17b/h2 fDmjj9KfIto3LE2Wej77lSJqv/LSd7wnfTQVZVb1wBe2Zt+LuPAqi6vWSDAQVOfdOMYVu5imznnf +ZNMLduTqXZ/bFQKTWsg2qhBWwaiYfxEY7nVg3+ZfStqwc9R3v/tHH+b9kX3FuKLoVQ6KSrqUyBi fhIRj57eOw6/JjPA+SId/p2yEZ+xmANQ31vE3BHFRm20kZHHqAfdCmTt1S7LDSLHBj3GZXIFUge9 aPKqzAXee2DCYTP3YYcgrP/FbFF2RqGRIhPM+MdjJraMjex+nNT+2KC/EIWsbU9DgFII0wHKpRx8 rlJNN8kmb/H9qGqcNaW9Q/pwUTpX1bXSdbzvYFs3NY7KmYYii4Q0RQCGr96OvDT0/S6/IrnW+vqZ jnPV2MXqEuyQ0L5HXVOnCi769uGYcRkEo5xzEJ/EMvj07vCWnG7h9ykNhLEEMcygVmBdXP9qOqog dyPJB0AzxAYGqCSMT8Ors1M/srZSXUCfSfENH5iBd7bxH7uXmF7kbOEghom7AccC2Clt4DU0tj9s FyIWg5H6zy6NLetm2/kzdD3mGY3u2tWtijVnd2CWY2YszYo1lbDAfEfjGL/9uFpH79Zt9ekRSD5Z bSn1SNr1njjeGpV3jwyuMIIHRjCCBS6gAwIBAgIKFnKQQQAAAAABuDANBgkqhkiG9w0BAQUFADBP MRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQD ExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjAeFw0xMjA1MTcwMDEzMzNaFw0xNDA1MTcwMDIzMzNaMFAx EzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBT dWJvcmRpbmF0ZSBDQSBNQ0EwM1lLRjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfx jFzEuYa/qd6dXu4HILtBdH3+Bgwz3uQakDcxvrf3fyVQBy69KFOS8/h5REe6bit3tp5wsQQv/nFV mmXK/jq9zD72zl3jv63UzZgOWC90846UxTTmmNEyHzo1M54B3LrnE6L2Q6QbEZMAnrJ96uV8pN2X Zsn5j+MvfI5ajFu+6oPbHeYzQjZB3GDju7sELm7cAcr0YYX3xeLTB2rLUUZF6Nyyc0btD57ARYEa 99A+6JslO8VcxtlgRddx17NB6gttNjwmJFT3l3UVcK5O5+UVSWpW1zQbZQBvl0iP7gXcrJW4Dv0p 036iHg9lgDV1qQChi9NCixwm7yYtCHLq9akCAwEAAaOCAyEwggMdMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFLgwF25vZ5X+hYxoO6XhF7M/+CU6MAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEE AwIBAzAjBgkrBgEEAYI3FQIEFgQUZUBVml3ak56Kwnbul6AULvNdck8wGQYJKwYBBAGCNxQCBAwe CgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNVHR8EggEg MIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Ys Q049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRp b25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6Ly9tY2Ew MXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Yu Y3JsMIIBPAYIKwYBBQUHAQEEggEuMIIBKjCBuwYIKwYBBQUHMAKGga5sZGFwOi8vL0NOPVJJTSUy MFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRvd3MsREM9bG9jYWw/Y0FDZXJ0aWZp Y2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwagYIKwYBBQUHMAKG Xmh0dHA6Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvTUNBMDFZS0Yud2luZG93 cy5sb2NhbF9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcnQwDQYJKoZIhvcNAQEFBQADggIB AK/ZTtcAxFAZJo37z0KG3EGIGIScPRus90jBJGQO9+Mrb4QRoMjkCwZP9GbYq2CxCqOBiKOZfkSK PMSupPLRlE70z9tGbsMz13ExQy50WZS9n4XRxglyDRga1fQVwGNF+SMPaBzQapiFi3CkBWNSdz+f aRdkdiqIvG3hxkbk6AXr6xhlu2mvnhJ/dE248lZDmN3FkWDHXEgEd5uHxwd7nWjxXVuzRV0oNgrG E96uTqLHVsdefHplPwyrIlgV4SY1ST1y8nKhZlB4IX8fDIj1Xr3rRssW+8XEKSILvawoU47n34x6 xZrO8nbramu3s3BPDnPBe5d1akBYA/nTKb9l6by6dNzJ7u1r73w7/tC53Hgf+826w6Gw+Z6Xs1d2 6RvukJ+7VCyKTR+rg+jASrfhS7naerxVMoOZwr6GxqqHYbK1gp3ag8Ek1U62/LYLqbvYMn58e23k q1pR6vLfQY4AhteMJipLmkxioYjHMCm9rTCZCnU2e/yvNNGXXq8WEeJpAc7hXbFR8L7VTaawkSxg jtJ2YTLvGH0cM/lEOAn3UGUG1lAhBBBzpLS4oW+ITZ5LsPWx2UiWAHLF79XE+PzvFE1+haf4HzJ0 KNKizMaj6DyVJN/oLOvdlVn32x70hCkr9zPFM6f4wEtQoY+qV3Q13zB7FePumyia5+/xmioObwts MYICrjCCAqoCAQEwXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmlt MSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwCQYFKw4D AhoFAKCCAaYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMDE2 MTkzNjQ4WjAjBgkqhkiG9w0BCQQxFgQUqZfuXigO6QrM3hBTgHw67RH8Z5wwZwYJKoZIhvcNAQkP MVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwbQYJKwYBBAGCNxAEMWAwXjBQMRMw EQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vi b3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwbwYLKoZIhvcNAQkQAgsxYKBeMFAxEzAR BgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBTdWJv cmRpbmF0ZSBDQSBNQ0EwM1lLRgIKF9gJ6QADABfFMjANBgkqhkiG9w0BAQEFAASBgAk5u5IFzbQg cRnRQxVqgAcizbD4LOLQ2CWGLBB411ADcvgKSJrMF07DeA6EG/nkpeBIdxxVn8A6uR7jbb9/XvJh f1yf8TZBEBQ7xEiaTrOTZll11h4xLiyIB1EJSLeV9xCFkVjygX7torGTGo2FxPUJbLgI+LO8enXg /m4E6Y/SAAAAAAAA ------=_NextPart_000_013A_01CECA85.8702ECA0-- --===============1319045333== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --===============1319045333==-- From mpg@elzevir.fr Wed Oct 16 12:56:24 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F84B21F9AE3 for ; Wed, 16 Oct 2013 12:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrNvLPjc+wFe for ; Wed, 16 Oct 2013 12:56:10 -0700 (PDT) Received: from mordell.elzevir.fr (mordell.elzevir.fr [IPv6:2001:4b98:dc0:41:216:3eff:feeb:c406]) by ietfa.amsl.com (Postfix) with ESMTP id 36B9421F9926 for ; Wed, 16 Oct 2013 12:56:04 -0700 (PDT) Received: from thue.elzevir.fr (thue.elzevir.fr [88.165.216.11]) by mordell.elzevir.fr (Postfix) with ESMTPS id 66E5216153; Wed, 16 Oct 2013 21:55:58 +0200 (CEST) Received: from [192.168.0.124] (unknown [192.168.0.254]) by thue.elzevir.fr (Postfix) with ESMTPSA id 7D2471F9DA; Wed, 16 Oct 2013 21:55:57 +0200 (CEST) Message-ID: <525EEF4C.2070203@elzevir.fr> Date: Wed, 16 Oct 2013 21:55:56 +0200 From: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.0 MIME-Version: 1.0 To: Watson Ladd References: <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> <87zjrl21wp.fsf_-_@latte.josefsson.org> <8738outeup.fsf@latte.josefsson.org> <525E3404.2090808@elzevir.fr> In-Reply-To: X-Enigmail-Version: 1.5.2 OpenPGP: id=98EED379; url=https://elzevir.fr/gpg/mpg.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Simon Josefsson , "tls@ietf.org" Subject: Re: [TLS] Curve25519 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 19:56:24 -0000 On 16/10/2013 20:48, Watson Ladd wrote: > On Tue, Oct 15, 2013 at 11:36 PM, Manuel Pégourié-Gonnard > wrote: >> TLS ECDH: >> 1. Private keys: random integer in the range [1, q-1] with q the order of G. >> 2. Public keys: a point on the curve (defined over F_p). >> 3. Public key encoding: either >> (a) the x and y coordinates of the point, or >> (b) the x coordinate and a bit for determination of the y coordinate, >> with integers represented as big-endian bytes strings, preceded by a >> first byte indicating which format was chosen (and holding the possible >> additional bit). >> > I don't believe this is correct: RFC4492 permits curves with cofactor > greater than one. I don't have a copy of the IEEE standard in front > of me, but I believe in this case one has to do a group membership > check. So it depends on what the meaning of G is. > Yes, sure, when receiving the peer's public key, one must always check it is actually a point on the expected curve (which is done automatically in the process of computing y if the compressed format is used) and, if the group generated by G has cofactor greater than one, that the peer's public key belongs to this subgroup. I don't really see how it contradicts my statements, but anyway. >> 1. Concerning the private key, I think keeping the paper's definition >> does not raise any issue. Implementors should just be careful to use a >> special procedure for this curve. >> > What is actually happening is that exponentiation by the private key > is annihilating the small order torsion subgroup on both the curve and > the twist because the private key is divisible by 8, and the curve and > twist have large prime-order subgroups with cofactor 8 and 4 > respectively. 100% agreed. I'm just not sure if this precision about the "why" is essential in the I-D, or if we should just leave it in the paper, and just mention in the I-D that implementers MUST be careful to generate private keys in the mandated special way for Curve25519. > This is a big difference from the usual method, in which one only > sends members. Well, to be really nitpicky, if the peer follows the procedure, she will only send members, just as with the usual method. The difference is, *if* the peer doesn't send members of the subgroup generated by G (ie by 9 in the Curve25519 case), with the usual method we must check and reject invalid public keys, and with the Curve22519 we just don't care since the choice of the private exponent takes care of that for us, as you accurately described. >> A. Just use the convention y = 0 and one of the existing formats. >> Pros: simple, just works. >> Cons: with the basic "uncompressed" format, wastes 32 bytes of bandwidth. > Also, a dirty hack. I don't deny it :) >> B. Always use the "ansiX962_compressed_prime" format. >> Pros: doesn't waste bandwidth. >> Cons: forces applications to advertise support this format, which is a >> problem if they can't support it for other prime curves, unless we >> introduce an exception to the effect that support for this format with >> this particular curve is implied as soon as support for the curve is >> advertised. Does not seem very clean to me. >> > The other issue is that this isn't the ansiX962 format for deep > technical reasons. You would need to use a birational morphism to > Weirstrauß form, which is a pointless PITA, or just tell pleasing > lies, which annoys those of us trying to analyze things, and is a > potential source of bugs. Agreed. What I was suggested was indeed to abuse this format and give it a different meaning just for this curve. Which may be qualified as a dirty hack too, obviously. >> C. Introduce a new point format "compressed_prime_montgomery". >> Pros: doesn't waste bandwidth, doesn't look hacky. >> Cons: a new point format only for one curve? OTOH, it is indeed a >> particular class of curve, since the recommended formulas work only with >> the x coordinate, and other curves in this class may be added later. >> > Probably the best idea, especially given that definition of addition > is completely different. It's certainly the less hackish way. Thinking about it, I'm inclined to say we don't need to define a new ECPointFormat entry, the I-D should just mandate that support for (resp. use of) curve25519 implies support for (resp. use of) the associated (unamed) point format. This avoids possible consistency issues like a client advertising support for the curve but not for the associated point format. Similarly, the usual point formats have a leading byte indicating the format used, that should IMO be dropped for curve25519. So this would lead to the definition that, for this curve, instead of containing "the byte string representation of a field element following the conversion routine in Section 4.3.3 of ANSI X9.62", the point member of the ECPoint structure contains an opaque[32] representing the x-coordinate of the point. Which would only leave the issue of the byte order of this string. Here it has no security implications, and I'd be inclined to mandate big-endian order (a divergence from the Curve25519 paper), with the rationale that is it more consistent with other encodings and that implementations already have routines for outpouting bignums in this order. OTOH, this would mean that people using the existing/reference implementations of the Curve25519 function would need to reverse its output/inputs. Either way I don't have strong feelings about this. Manuel. From simon@josefsson.org Wed Oct 16 13:17:52 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C5E11E814B for ; Wed, 16 Oct 2013 13:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+5OaQAECSY5 for ; Wed, 16 Oct 2013 13:17:51 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id 7C23411E813A for ; Wed, 16 Oct 2013 13:17:51 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id r9GKGfhn006919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 16 Oct 2013 22:16:42 +0200 Date: Wed, 16 Oct 2013 22:16:40 +0200 From: Simon Josefsson To: Manuel =?ISO-8859-1?B?UOlnb3VyaektR29ubmFyZA==?= Message-ID: <20131016221640.0452568e@latte.josefsson.org> In-Reply-To: <525EEF4C.2070203@elzevir.fr> References: <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> <87zjrl21wp.fsf_-_@latte.josefsson.org> <8738outeup.fsf@latte.josefsson.org> <525E3404.2090808@elzevir.fr> <525EEF4C.2070203@elzevir.fr> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se X-Virus-Status: Clean Cc: "tls@ietf.org" Subject: Re: [TLS] Curve25519 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 20:17:52 -0000 You wrote: > Thinking about it, I'm inclined to say we don't need to define a new > ECPointFormat entry, the I-D should just mandate that support for > (resp. use of) curve25519 implies support for (resp. use of) the > associated (unamed) point format. This avoids possible consistency > issues like a client advertising support for the curve but not for > the associated point format. > > Similarly, the usual point formats have a leading byte indicating the > format used, that should IMO be dropped for curve25519. > > So this would lead to the definition that, for this curve, instead of > containing "the byte string representation of a field element > following the conversion routine in Section 4.3.3 of ANSI X9.62", the > point member of the ECPoint structure contains an opaque[32] > representing the x-coordinate of the point. This sounds like a feasible approach to me. Maybe we need to put this solution in writing, and maybe put some of the other options in writing as well, to allow people to make an informed decision of where to go. I think this thread has been quite informative, and I'm hoping we can reach some early consensus and update the draft with that. /Simon From watsonbladd@gmail.com Wed Oct 16 18:05:38 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1EC11E819B for ; Wed, 16 Oct 2013 18:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsfic+2Idh5W for ; Wed, 16 Oct 2013 18:05:37 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 203FE21F9A05 for ; Wed, 16 Oct 2013 18:05:36 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id eh20so1207194lab.18 for ; Wed, 16 Oct 2013 18:05:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YzC1NHAQGxMKvOT4/ou5E7IIFUsGuhOebu3jRqlawSo=; b=yVWvzTz6+zwG4nQx+24VVMqCwIHdXvCuM/B9k7TPpr0Quh0bVzySW/sp8GEMWTC2oO /C9V3vYnYBh7vI+vJxeo4zcrwnmSlx4xWmgf1TnOchWb4MLfgZtKzPapkVIOV4FoP4j/ phOJDSPofcKTbwrqeDFa76hTQgA4E2LUBnLxIPdZ2782S23GoBJenD5p9aNN4XjAh0e8 AobLYrOSUWgxSrJ7QOiXEVITxyI8fSZiQ/uoCCEUDliatCAooQpWZAregHQsrPmeypS2 ViThRTeGjqb52T8zTSnBOva4ZIOj3/NRkSUeagFIsbyPO/iN6zHmuYkOw+ha2VZ62Gne K+pg== MIME-Version: 1.0 X-Received: by 10.112.130.138 with SMTP id oe10mr4916211lbb.1.1381971932763; Wed, 16 Oct 2013 18:05:32 -0700 (PDT) Received: by 10.152.1.66 with HTTP; Wed, 16 Oct 2013 18:05:32 -0700 (PDT) In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5BEBAA5@XMB117CNC.rim.net> References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> <20130926152757.15842.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDB49B@XMB116CNC.rim.net> <20130928223648.1113.qmail@cr.yp.to> <20130929025714.5578895.47771.4422@certicom.com> <20131001143511.11010.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE21E@XMB116CNC.rim.net> <20131002161944.8125.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE90F@XMB116CNC.rim.net> <20131003010455.17185.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDECA6@XMB116CNC.rim.net> <20131005192950.27059.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BE4A9D@XMB116CNC.rim.net> <20131012003058.669.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BEBAA5@XMB117CNC.rim.net> Date: Wed, 16 Oct 2013 18:05:32 -0700 Message-ID: From: Watson Ladd To: Dan Brown Content-Type: text/plain; charset=UTF-8 Cc: "djb@cr.yp.to" , "tls@ietf.org" Subject: Re: [TLS] Safe ECC usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 01:05:38 -0000 On Wed, Oct 16, 2013 at 12:36 PM, Dan Brown wrote: > Based on this score, if I had to guess what the next attack would be, then I > would guess special. An attack on random would be a breakthrough. > Therefore, trying to choose a random curve is a best guess approach. > >> I say that it's a good idea to narrow the distribution even more, in >> fact down to a single curve, by taking the _smallest_ curve coefficient >> within the usual massively biased distribution. That's what Curve25519 >> does. This isn't just a performance win; it also prevents the sort of >> manipulation that's clearly possible for someone who claims to be >> "randomly" choosing curves from the wider distribution. >> >> Now imagine that there's no manipulation. How does this single-curve >> distribution compare in security to the larger (massively biased) >> distribution against some unknown attack? The correct answer is that we >> have no idea---maybe it's more secure, maybe it's less secure, maybe >> it's the same. > > Uncertainty, "no idea", about unknown attacks is a given, but we should > still try to resist them, even if that means making assumptions and > guessing. Provably secure algorithm try to do this. Previously unknown > attacks are known pop up, occasionally. But, we also give weight to the > effort that people have exerted in trying to find attacks, to infer the > unlikelihood of new attacks being discovered. > So you agree that E(random curve falls to unknown attack)=E(Curve25519 falls to random attacks). (This is is obvious unless cosmic conspiracy happens, and if it isn't, think about it). But now the question is whether the author of the random curve really picked it at random, vs specified a curve. And then the fact that DJB specified at most 17 bits or so is very important: a new attack would have to work on 2^{-17} of all curves to work on Curve25519. Sincerely, Watson Ladd -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From Johannes.Merkle@secunet.com Thu Oct 17 02:00:08 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E3511E810F for ; Thu, 17 Oct 2013 02:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.507 X-Spam-Level: X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YlbRQ-VP8py for ; Thu, 17 Oct 2013 02:00:04 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2CB11E8171 for ; Thu, 17 Oct 2013 02:00:02 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 15E811A0076; Thu, 17 Oct 2013 11:00:01 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SAwyoEVIg8wL; Thu, 17 Oct 2013 10:59:59 +0200 (CEST) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 878321A0071; Thu, 17 Oct 2013 10:59:59 +0200 (CEST) Received: from [172.16.40.201] ([172.16.40.201]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Oct 2013 11:00:00 +0200 Message-ID: <525FA70F.8030208@secunet.com> Date: Thu, 17 Oct 2013 10:59:59 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Nico Williams References: <525C11B5.2050604@secunet.com> <525CEFA4.2030903@funwithsoftware.org> <01b901cec9a0$004e12b0$00ea3810$@offspark.com> <525E3E6B.1020604@secunet.com> <525EAC5D.7080105@secunet.com> <525EB695.9070607@secunet.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2013 09:00:00.0279 (UTC) FILETIME=[429FFA70:01CECB17] Cc: Patrick Pelletier , "tls@ietf.org" Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 09:00:08 -0000 > But the SafeCurves site doesn't focus only on construction rigidity, > and it doesn't discount Brainpool on account of rigidity in its > construction. SafeCurves also covers other issues. SafeCurves > declares Brainpool curves not safe according to the following > criteria: > > - feasibility of efficient constant-time implementation > http://safecurves.cr.yp.to/ladder.html > > - twist security > http://safecurves.cr.yp.to/twist.html These properties are clearly beneficial to secure implementations against side-channels and active attacks. But you can still achieve this resistance with other curves. The approach of Brainpool was different; we gave clear hints to the necessity of implementation security but left the details completely to the implementors. > > IIUC this means that when using non-twist secure curves one has to > validate that peers' public keys are on the curve being used, which in > turn would require exchanging not just public keys but also Schnorr > signatures (and, of course, verifying those signatures before using > peers' public keys for any other purpose). > Although I am familiar with Schnorr signatures, I don't understand how they should be used for point validation. Typically, you need to check that the public key satisfies the curve equation. For IKE, there was an RFC published on how to do this during key agreement. If you receive a compressed key, it suffices to uncompress the key; if successful, the resulting point is on the curve. Johannes From dbrown@certicom.com Thu Oct 17 08:46:32 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26BB11E8269 for ; Thu, 17 Oct 2013 08:46:32 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_16=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HS1dYyMdwl+V for ; Thu, 17 Oct 2013 08:46:27 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id C5DD011E825D for ; Thu, 17 Oct 2013 08:46:18 -0700 (PDT) Content-Type: multipart/mixed; boundary="===============0531799655==" MIME-Version: 1.0 Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 17 Oct 2013 11:46:14 -0400 Received: from XMB117CNC.rim.net ([fe80::24f3:cc30:b596:7ca0]) by XCT102CNC.rim.net ([fe80::2066:5d4f:8c45:af55%17]) with mapi id 14.03.0123.003; Thu, 17 Oct 2013 11:46:13 -0400 From: Dan Brown To: "'watsonbladd@gmail.com'" Thread-Topic: [TLS] Safe ECC usage Thread-Index: AQHOxuJRxn3XJXmgAkKRAg2ZE6kwf5n3qq2ggAC0kACAAKQ6QA== Date: Thu, 17 Oct 2013 15:46:13 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF5BEC2EC@XMB117CNC.rim.net> References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> <20130926152757.15842.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDB49B@XMB116CNC.rim.net> <20130928223648.1113.qmail@cr.yp.to> <20130929025714.5578895.47771.4422@certicom.com> <20131001143511.11010.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE21E@XMB116CNC.rim.net> <20131002161944.8125.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE90F@XMB116CNC.rim.net> <20131003010455.17185.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDECA6@XMB116CNC.rim.net> <20131005192950.27059.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BE4A9D@XMB116CNC.rim.net> <20131012003058.669.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BEBAA5@XMB117CNC.rim.net> In-Reply-To: Accept-Language: en-CA, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] MIME-Version: 1.0 Cc: "'djb@cr.yp.to'" , "'tls@ietf.org'" Subject: Re: [TLS] Safe ECC usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 15:46:33 -0000 --===============0531799655== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01CECB2E.7A360DA0" ------=_NextPart_000_0000_01CECB2E.7A360DA0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Watson Ladd wrote > Dan Brown wrote > > > Based on this score, if I had to guess what the next attack would be, > > then I would guess special. An attack on random would be a > breakthrough. > > Therefore, trying to choose a random curve is a best guess approach. > > > ... > > > > Uncertainty, "no idea", about unknown attacks is a given, but we > > should still try to resist them, even if that means making > assumptions > > and guessing. Provably secure algorithm try to do this. Previously > unknown > > attacks are known pop up, occasionally. But, we also give weight to > the > > effort that people have exerted in trying to find attacks, to infer > > the unlikelihood of new attacks being discovered. > > > So you agree that E(random curve falls to unknown attack)=E(Curve25519 > falls to random attacks). (This is is obvious unless cosmic conspiracy > happens, and if it isn't, think about it). But now the question is Sure, but confining ourselves to "random attacks' is way too optimistic. Future, and unknown, attacks will not necessarily be random. Also, that is not at all what I was talking about in the text you quoted. In fact, earlier in this thread, I mentioned this random attack argument as being almost circular, assuming one what one aims to establish, and that this was similar to what Koblitz, Koblitz and Menezes argued. Well, maybe you mean something other than "random attacks"? > whether the author of the random curve really picked it at random, vs > specified a curve. And then the fact that DJB specified at most 17 bits > or so is very important: a new attack would have to work on 2^{-17} of > all curves to work on Curve25519. Just curious: where's the 17 from? Why couldn't a new attack just work on one curve, namely Curve25519? If I understand correctly, DJB has argued that the ECC theory and experience would be evidence for a claim similar, but perhaps not as strong, as your claim. Sure, a new attack could work against just one brainpool curve too. But for brainpool, there a three prongs against such a single curve attack: the ECC theory and experience, the use of SHA1 of in brainpool definitions, the use of Pi and e in the brainpool curves. That would definitely be a "cosmic conspiracy". The MOV and SASS worked on small fractions of curves. If I recall correctly, in both cases there had already been proposals to use special curves (for efficiency and other convenience reasons) affected by these attacks, before the attacks were discovered. The risk of this happening again for Curve25519 is much smaller, because of the many intervening years of research into ECC. That's why I view Curve25519 as safe, but in the context of resisting unknown attacks, the evidence supports brainpool, or an honestly-generated P-256 as slightly safer. ... The most compelling argument, at least to me, against my position is the Pohlig--Hellman attack, which DJB already raised a couple times. I've exclude this attack from my evidence, because it is generic to DH/DL, and Curve25519, Brainpool and P256 all address PH attacks in the same way, with a low-pass filter. Arguably, we could have boosted the group size, and resisted PH with a high-pass filter, resulting in DH/DL that belong to a larger class of groups. That would have been less efficient, but also not very compelling for security because is there is evidence of low-density generic DH/DL attacks, i.e. special groups, that need to be avoided. Thus the decision to resist PH by using a low-pass filter (e.g. searching random orders until one nearly prime was found) does not seem to introduce a risk. In the case of PH-protected ECC, the weak argument to avoid special curves is to avoid another MOV or SASS. ------=_NextPart_000_0000_01CECB2E.7A360DA0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUgTCCBnAw ggVYoAMCAQICChfYCekAAwAXxTIwDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAz WUtGMB4XDTEzMDUyODE1NDQwOVoXDTE0MDUxNzAwMjMzM1owgYUxEzARBgoJkiaJk/IsZAEZFgNu ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xETAPBgNVBAsTCENlcnRpY29tMQ4wDAYDVQQLEwVVc2Vy czESMBAGA1UEAxMJRGFuIEJyb3duMSIwIAYJKoZIhvcNAQkBFhNkYnJvd25AY2VydGljb20uY29t MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDRc70RE0/FL9ZbfN64YjA0lkQOLR9ipGebc9nH jB93OfYfR7CVsCUYy3+v9PO1DiUS9MeWWR4nxB9Ztee32d3syDxGg3PGFwSrms/ORAW9pgiS/yKH An9SKRKyqMz9LSn/VQrEgoyPBPT0S/vg521MGH58MwMXyLm1cLBQU5gtCQIDAQABo4IDmDCCA5Qw CwYDVR0PBAQDAgWgMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQME AgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUAlQmTNpWxnzoCUVjxGTtDz2JvLww FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMB8GA1UdIwQYMBaAFLgwF25vZ5X+hYxoO6XhF7M/+CU6 MIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiGgctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu YXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1NQ0EwM1lLRixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIw U2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2Fs P2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRp b25Qb2ludIZIaHR0cDovL21jYTAzeWtmLnJpbS5uZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRp bmF0ZSUyMENBJTIwTUNBMDNZS0YuY3JsMIIBQQYIKwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUH MAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1BSUEs Q049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixE Qz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZp Y2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxodHRwOi8vbWNhMDN5a2YucmltLm5ldC9DZXJ0 RW5yb2xsL01DQTAzWUtGLnJpbS5uZXRfUklNJTIwU3Vib3JkaW5hdGUlMjBDQSUyME1DQTAzWUtG KDMpLmNydDApBgNVHSUEIjAgBgorBgEEAYI3CgMEBggrBgEFBQcDBAYIKwYBBQUHAwIwQQYDVR0R BDowOKAhBgorBgEEAYI3FAIDoBMMEWRhbmlicm93bkByaW0ubmV0gRNkYnJvd25AY2VydGljb20u Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQC6hxWgDv96DUDS3m8XfyVGAv1CKOcWSVOShz/jofFMFzoN o2dhc0Jg9XTTZBVS+ozakEM+87YUENfP3IODRbCiJBsbiXJxS+fVo7L/bqPp47TB+Lg2/tezlNa2 ab4psmc9xjZGU9+A4lBzS5PpRjvHofsIwETpwt/aPxHIbJ5Cf7kBi7B8hR4mIqc7EJMYXeI0xHLg k3NqBYSGC3XtbykuFV0vPFoTYLO7G3pAP2RzGhuxQoaH4fpWvE3rdakjd1MZFqJrarXSvWi6ah6G Alt7+sOTzlGNqoTQqb55VZEOrU2A1VbmAFjiFR1/229A2KaHhnN6cuNe8bhzoBcnuxtyMIIGvzCC BKegAwIBAgIQMhrzkrEUWZRNTS+VEbN74TANBgkqhkiG9w0BAQUFADBPMRUwEwYKCZImiZPyLGQB GRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBN Q0EwMVlLRjAeFw0wNjEwMTMwMTI0NTVaFw0xNjEwMTMwMTMwNDFaME8xFTATBgoJkiaJk/IsZAEZ FgVsb2NhbDEXMBUGCgmSJomT8ixkARkWB3dpbmRvd3MxHTAbBgNVBAMTFFJJTSBSb290IENBIE1D QTAxWUtGMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAxui6zvytVAEtPzv6NhK7OZna iw/jQEyEVskDf5yzcFkLT/+5PztIbv+eFmL1CP2FhvLv8eQZJDKF4Yv+UsjPEN1lX4DDGKKt0NPp yT9pwQzFaiUt0rnERgSabo7EtpS4S+DuL8G9c+lmWwDqb0UWtPMdVfbr3fDwigyz1yh+vVMAHdhg Oe9lPC6nPtiJ9IXTam7V5mJmDT0mNpq/0fJo3JEaNvDKoXBOkKv6IdbtKxKzPInG6VYaCdgJCAT3 mWgr9kxiEQEUJKrvI2fXI0zRYnlL648gvK84pdsT2xZLFtr4OdZAm4RkK8U+cgurlSCr6NVqnfbq 6/3N6MGmyc9SB2Ayhk2VS66757V4nBzeaeD+srpk4IXU3NTM/+YgR1zVS41XwvZaq9Uf59j0TJhN 9xGVZO871eVVr2VfNxr0xOqUpwcxh5JZYkWcmUJFlYiQh0CM2PrfaDRTTqRZQd4F3xUlcXFAXOGh vaXKvikeI6/utnX6vCnDwMUxmenzlv8epNatxDsuIgOWO4pfqgGMyzWo2hudQ97+5ynUqDLX34nr UzszGeIE3KoqYsksxMF3tqIgadt9hNWXaP/EknZpRAmaP0s0V5ZvgiyXw9UrqnWwmRbLQk7HnYc0 hHQBjXoByKSiOyhgSS9yL6a+7AA2rhBPpsSVI9LYBs2cNKlPsZcCAwEAAaOCAZUwggGRMBMGCSsG AQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTW aYJkJBbBzCTb8RR9RxJ83MlN7jCCASkGA1UdHwSCASAwggEcMIIBGKCCARSgggEQhoHEbGRhcDov Ly9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1NQ0EwMVlLRixDTj1DRFAsQ049UHVi bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5k b3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1j UkxEaXN0cmlidXRpb25Qb2ludIZHaHR0cDovL21jYTAxeWtmLndpbmRvd3MubG9jYWwvQ2VydEVu cm9sbC9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwDQYJ KoZIhvcNAQEFBQADggIBAEOeWFu4OVTnx9+jYk92iDra2f1Bc5j1WesEGINl4VCY9WJy6n17b/h2 fDmjj9KfIto3LE2Wej77lSJqv/LSd7wnfTQVZVb1wBe2Zt+LuPAqi6vWSDAQVOfdOMYVu5imznnf +ZNMLduTqXZ/bFQKTWsg2qhBWwaiYfxEY7nVg3+ZfStqwc9R3v/tHH+b9kX3FuKLoVQ6KSrqUyBi fhIRj57eOw6/JjPA+SId/p2yEZ+xmANQ31vE3BHFRm20kZHHqAfdCmTt1S7LDSLHBj3GZXIFUge9 aPKqzAXee2DCYTP3YYcgrP/FbFF2RqGRIhPM+MdjJraMjex+nNT+2KC/EIWsbU9DgFII0wHKpRx8 rlJNN8kmb/H9qGqcNaW9Q/pwUTpX1bXSdbzvYFs3NY7KmYYii4Q0RQCGr96OvDT0/S6/IrnW+vqZ jnPV2MXqEuyQ0L5HXVOnCi769uGYcRkEo5xzEJ/EMvj07vCWnG7h9ykNhLEEMcygVmBdXP9qOqog dyPJB0AzxAYGqCSMT8Ors1M/srZSXUCfSfENH5iBd7bxH7uXmF7kbOEghom7AccC2Clt4DU0tj9s FyIWg5H6zy6NLetm2/kzdD3mGY3u2tWtijVnd2CWY2YszYo1lbDAfEfjGL/9uFpH79Zt9ekRSD5Z bSn1SNr1njjeGpV3jwyuMIIHRjCCBS6gAwIBAgIKFnKQQQAAAAABuDANBgkqhkiG9w0BAQUFADBP MRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQD ExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjAeFw0xMjA1MTcwMDEzMzNaFw0xNDA1MTcwMDIzMzNaMFAx EzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBT dWJvcmRpbmF0ZSBDQSBNQ0EwM1lLRjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfx jFzEuYa/qd6dXu4HILtBdH3+Bgwz3uQakDcxvrf3fyVQBy69KFOS8/h5REe6bit3tp5wsQQv/nFV mmXK/jq9zD72zl3jv63UzZgOWC90846UxTTmmNEyHzo1M54B3LrnE6L2Q6QbEZMAnrJ96uV8pN2X Zsn5j+MvfI5ajFu+6oPbHeYzQjZB3GDju7sELm7cAcr0YYX3xeLTB2rLUUZF6Nyyc0btD57ARYEa 99A+6JslO8VcxtlgRddx17NB6gttNjwmJFT3l3UVcK5O5+UVSWpW1zQbZQBvl0iP7gXcrJW4Dv0p 036iHg9lgDV1qQChi9NCixwm7yYtCHLq9akCAwEAAaOCAyEwggMdMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFLgwF25vZ5X+hYxoO6XhF7M/+CU6MAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEE AwIBAzAjBgkrBgEEAYI3FQIEFgQUZUBVml3ak56Kwnbul6AULvNdck8wGQYJKwYBBAGCNxQCBAwe CgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNVHR8EggEg MIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Ys Q049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRp b25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6Ly9tY2Ew MXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Yu Y3JsMIIBPAYIKwYBBQUHAQEEggEuMIIBKjCBuwYIKwYBBQUHMAKGga5sZGFwOi8vL0NOPVJJTSUy MFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRvd3MsREM9bG9jYWw/Y0FDZXJ0aWZp Y2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwagYIKwYBBQUHMAKG Xmh0dHA6Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvTUNBMDFZS0Yud2luZG93 cy5sb2NhbF9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcnQwDQYJKoZIhvcNAQEFBQADggIB AK/ZTtcAxFAZJo37z0KG3EGIGIScPRus90jBJGQO9+Mrb4QRoMjkCwZP9GbYq2CxCqOBiKOZfkSK PMSupPLRlE70z9tGbsMz13ExQy50WZS9n4XRxglyDRga1fQVwGNF+SMPaBzQapiFi3CkBWNSdz+f aRdkdiqIvG3hxkbk6AXr6xhlu2mvnhJ/dE248lZDmN3FkWDHXEgEd5uHxwd7nWjxXVuzRV0oNgrG E96uTqLHVsdefHplPwyrIlgV4SY1ST1y8nKhZlB4IX8fDIj1Xr3rRssW+8XEKSILvawoU47n34x6 xZrO8nbramu3s3BPDnPBe5d1akBYA/nTKb9l6by6dNzJ7u1r73w7/tC53Hgf+826w6Gw+Z6Xs1d2 6RvukJ+7VCyKTR+rg+jASrfhS7naerxVMoOZwr6GxqqHYbK1gp3ag8Ek1U62/LYLqbvYMn58e23k q1pR6vLfQY4AhteMJipLmkxioYjHMCm9rTCZCnU2e/yvNNGXXq8WEeJpAc7hXbFR8L7VTaawkSxg jtJ2YTLvGH0cM/lEOAn3UGUG1lAhBBBzpLS4oW+ITZ5LsPWx2UiWAHLF79XE+PzvFE1+haf4HzJ0 KNKizMaj6DyVJN/oLOvdlVn32x70hCkr9zPFM6f4wEtQoY+qV3Q13zB7FePumyia5+/xmioObwts MYICrjCCAqoCAQEwXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmlt MSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwCQYFKw4D AhoFAKCCAaYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMDE3 MTU0NjExWjAjBgkqhkiG9w0BCQQxFgQUZ6l5lts96PSIarFkqUyY/L6E4cEwZwYJKoZIhvcNAQkP MVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwbQYJKwYBBAGCNxAEMWAwXjBQMRMw EQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vi b3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwbwYLKoZIhvcNAQkQAgsxYKBeMFAxEzAR BgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBTdWJv cmRpbmF0ZSBDQSBNQ0EwM1lLRgIKF9gJ6QADABfFMjANBgkqhkiG9w0BAQEFAASBgAVfVX793nAk /xOt8Gp5HGdX4Gw0SWXqBG3f/H0YSI0P1+yJV/2XBUIzszjdTUZzo1QrHBxWvNX58Zpu7pKpx4et 40Je8XktyBhrdjKQSUA+1Ytzuu5+e97LMOGwOr+iu4RphYMAFxsZPDo8om+y4CWj7D9bTuQg2vRp 7BMGjFl/AAAAAAAA ------=_NextPart_000_0000_01CECB2E.7A360DA0-- --===============0531799655== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --===============0531799655==-- From nico@cryptonector.com Thu Oct 17 08:55:53 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2EB621F9CA4 for ; Thu, 17 Oct 2013 08:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.981 X-Spam-Level: X-Spam-Status: No, score=-1.981 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8Bz2LgL+gfG for ; Thu, 17 Oct 2013 08:55:33 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 33ADA11E827E for ; Thu, 17 Oct 2013 08:55:13 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id C91DF200B99A8 for ; Thu, 17 Oct 2013 08:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=9P27bP4ab2JoyRRn5KsA TSOXIo0=; b=i86EgFaF3WVSqHJPsIxp2l2Y2SjVQO5h3yb1+dBZRuod7Qqv7cLT kwrKpzyWVIsTXkROjHWZUnOGMVjVKwh/3CL4DpmgfssRQiZ/o7h9Eb3WDGVXhOn9 ZmWfT/rwZq25XvtkyZftB2r8t+PV0BZnLQr97tapBlgei/CMOYfEEwc= Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPSA id 69F25200B99A4 for ; Thu, 17 Oct 2013 08:55:12 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id cb5so8648936wib.13 for ; Thu, 17 Oct 2013 08:55:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ckZz12LhkjD1/iGAkafoUyH9A2a2+5UFsKk7dPQMcxs=; b=Z2Re5Um93Ma0snY60DcE4MnTlrG7xJDD2by4+ocrmdFubjeW8ragBWGuqleGaMfB4v AgEGOIqjxOCIqeliRje5K4Y1t8cikpucN/ymc73rFzhOwtddeMV7Z7J8pAajOb0iKILk la78BFzVOzP00xWVl9sTEhGwZvsEExoxk4VEEB0927o/ve/k+LEJlhC1j9Rsr7IA6Gmd LAA8sozwx4pflmWpEVq3+eo+g4tyY1076SoyAefmfOAndnB2TgpuGlz7ocstL2yRt0Gi 3xDJjNu7pKizX+IUiVOUg6s6g4OUKKLoCvT7nrPXyuDav+ey5KdI4wz8dhGyVTmkGtyI jfTg== MIME-Version: 1.0 X-Received: by 10.194.174.36 with SMTP id bp4mr7817634wjc.7.1382025310419; Thu, 17 Oct 2013 08:55:10 -0700 (PDT) Received: by 10.216.151.136 with HTTP; Thu, 17 Oct 2013 08:55:10 -0700 (PDT) In-Reply-To: <525FA70F.8030208@secunet.com> References: <525C11B5.2050604@secunet.com> <525CEFA4.2030903@funwithsoftware.org> <01b901cec9a0$004e12b0$00ea3810$@offspark.com> <525E3E6B.1020604@secunet.com> <525EAC5D.7080105@secunet.com> <525EB695.9070607@secunet.com> <525FA70F.8030208@secunet.com> Date: Thu, 17 Oct 2013 10:55:10 -0500 Message-ID: From: Nico Williams To: Johannes Merkle Content-Type: text/plain; charset=UTF-8 Cc: Patrick Pelletier , "tls@ietf.org" Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 15:55:53 -0000 On Thu, Oct 17, 2013 at 3:59 AM, Johannes Merkle wrote: >> But the SafeCurves site doesn't focus only on construction rigidity, >> and it doesn't discount Brainpool on account of rigidity in its >> construction. SafeCurves also covers other issues. SafeCurves >> declares Brainpool curves not safe according to the following >> criteria: >> >> - feasibility of efficient constant-time implementation >> http://safecurves.cr.yp.to/ladder.html >> >> - twist security >> http://safecurves.cr.yp.to/twist.html > > These properties are clearly beneficial to secure implementations against side-channels and active attacks. But you can > still achieve this resistance with other curves. The approach of Brainpool was different; we gave clear hints to the > necessity of implementation security but left the details completely to the implementors. I would say that providing hints as to how to implement in constant time >> providing hints that implementations should be constant-time. Everyone knows the latter. Not everyone knows how to achieve that. >> >> IIUC this means that when using non-twist secure curves one has to >> validate that peers' public keys are on the curve being used, which in >> turn would require exchanging not just public keys but also Schnorr >> signatures (and, of course, verifying those signatures before using >> peers' public keys for any other purpose). >> > > Although I am familiar with Schnorr signatures, I don't understand how they should be used for point validation. > > Typically, you need to check that the public key satisfies the curve equation. For IKE, there was an RFC published on > how to do this during key agreement. > > If you receive a compressed key, it suffices to uncompress the key; if successful, the resulting point is on the curve. Yeah, that was a thinko; please excuse me. Validating that the point is on the curve was the point. The fact that some curve has twist security means that for DH there's no need to validate that public keys are points on the curve -- i.e., all other things being equal, such a curve is faster than a curve that doesn't have this feature. Faster is important. Nico -- From hannes.tschofenig@gmx.net Thu Oct 17 09:14:06 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADFEC21F9D11 for ; Thu, 17 Oct 2013 09:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYXKqL+tSO0t for ; Thu, 17 Oct 2013 09:14:02 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1B61E21F9D0A for ; Thu, 17 Oct 2013 09:14:01 -0700 (PDT) Received: from [172.16.254.200] ([80.92.116.76]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MB2G8-1VPAi93xYK-00A0IP for ; Thu, 17 Oct 2013 18:13:58 +0200 Message-ID: <52600CE4.6090300@gmx.net> Date: Thu, 17 Oct 2013 18:14:28 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Sean Turner References: <52547BDF.5000808@ieca.com> In-Reply-To: <52547BDF.5000808@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:MOZ+upSJtJtIcfyBWbpGThdJfup/nT3Cv3Jrxk3/fU5Q9oU77Eq H4IGOKEXUM/C1NnH/y5FvuHBaCyrn8mGRCDOA7MWDZo2a9jA5h3jkLAPYKfpizI230RC9mP G5p9GEmJfRUv/VqB6zSIKMpnzJyk62LwNTvizxzpC+9bUuG71mJbPtO5vqEqN3tGREUf0YB WL5qsPbpZNY6lRXSuGwZg== Cc: "" Subject: Re: [TLS] TLS Cached Info Status X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 16:14:06 -0000 Hi Sean, here is my plan B: we go ahead with the publication of the document without the proposed functionality since we have not gotten the data to judge whether it is a useful extension or not. We can still try to gather the data and if it indeed turns out that the functionality is useful then there is always the possibility to add an extension; the draft defines a 'lightweight' way to provide new caching extensions. I am going to refresh the document. Ciao Hannes On 10/08/2013 11:40 PM, Sean Turner wrote: > Hannes, > > Did you ever get any of the telemetry data? If not what is plan b? > > I'd like to see this draft progress soon, assuming there's wg support > for it, or to officially have it declared dead. > > spt > > On 5/14/13 7:18 AM, Hannes Tschofenig wrote: >> Hi all, >> I thought it would be a good idea to let the group know what the status >> of the TLS Cached Info draft is (since Rob just asked me a few minutes >> ago). >> You may recall that we had a discussion about the ability to not only >> cache a single OCSP response (as defined with RFC 6066) but also OCSP >> responses of intermediate CA certs, which is functionality >> http://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extension/ >> provides. >> Rob raised this issue in his review, see >> http://www.ietf.org/mail-archive/web/tls/current/msg09352.html. >> To me it sounds reasonable to add the requested functionality and the >> pros & cons had been discussed on the list. >> When I met Ekr at the recent NIST workshop we briefly spoke about the >> TLS Cached Info document and how to progress it. He came up with the >> idea to use the Firefox telemetry feature to gather some data so that we >> can estimage the cache hit/miss ratio. With data we would obviously be >> in a much better position to make an informed decision. >> I hope that we get that data soon. If we cannot get it then we have to >> switch to plan B. >> Ciao >> Hannes >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> From mpg@elzevir.fr Thu Oct 17 09:25:47 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02BDE11E8278 for ; Thu, 17 Oct 2013 09:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Mw4JZinEyGu for ; Thu, 17 Oct 2013 09:25:38 -0700 (PDT) Received: from mordell.elzevir.fr (mordell.elzevir.fr [92.243.3.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6978911E8274 for ; Thu, 17 Oct 2013 09:25:21 -0700 (PDT) Received: from thue.elzevir.fr (unknown [IPv6:2a01:e35:8a5d:80b0:be5f:f4ff:fe2c:95bc]) by mordell.elzevir.fr (Postfix) with ESMTPS id 5FAE01612E; Thu, 17 Oct 2013 18:25:19 +0200 (CEST) Received: from [192.168.0.124] (unknown [192.168.0.254]) by thue.elzevir.fr (Postfix) with ESMTPSA id 8A522299F1; Thu, 17 Oct 2013 18:25:16 +0200 (CEST) Message-ID: <52600F6B.3020404@elzevir.fr> Date: Thu, 17 Oct 2013 18:25:15 +0200 From: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.0 MIME-Version: 1.0 To: Nico Williams , Johannes Merkle References: <525C11B5.2050604@secunet.com> <525CEFA4.2030903@funwithsoftware.org> <01b901cec9a0$004e12b0$00ea3810$@offspark.com> <525E3E6B.1020604@secunet.com> <525EAC5D.7080105@secunet.com> <525EB695.9070607@secunet.com> <525FA70F.8030208@secunet.com> In-Reply-To: X-Enigmail-Version: 1.5.2 OpenPGP: id=98EED379; url=https://elzevir.fr/gpg/mpg.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Patrick Pelletier , "tls@ietf.org" Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 16:25:47 -0000 On 17/10/2013 17:55, Nico Williams wrote: > The fact that some curve has twist > security means that for DH there's no need to validate that public > keys are points on the curve Not if your peer sends you (x, y). Your statement is true only in ECDH schemes where the peers sends only x (and you don't attempt to find y). Manuel. From internet-drafts@ietf.org Thu Oct 17 09:28:27 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F1011E8288; Thu, 17 Oct 2013 09:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0-6QQtglXun; Thu, 17 Oct 2013 09:28:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D7D11E827C; Thu, 17 Oct 2013 09:28:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131017162826.32595.35989.idtracker@ietfa.amsl.com> Date: Thu, 17 Oct 2013 09:28:26 -0700 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-cached-info-15.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 16:28:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Layer Security Working Group of= the IETF. Title : Transport Layer Security (TLS) Cached Information Extens= ion Author(s) : Stefan Santesson Hannes Tschofenig Filename : draft-ietf-tls-cached-info-15.txt Pages : 10 Date : 2013-10-17 Abstract: Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted Certification Authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate path (including all intermediary certificates up to the trust anchor public key). This document defines an extension that omits the exchange of already available information. The TLS client informs a server of cached information, for example from a previous TLS handshake, allowing the server to omit the already available information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-cached-info-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-cached-info-15 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hannes.tschofenig@gmx.net Thu Oct 17 09:32:36 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7EE211E828A for ; Thu, 17 Oct 2013 09:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYwqbb3nIj73 for ; Thu, 17 Oct 2013 09:32:32 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8AF11E8290 for ; Thu, 17 Oct 2013 09:32:22 -0700 (PDT) Received: from [172.16.254.200] ([80.92.116.76]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LzHZ7-1VkXjR3usL-014SJ4 for ; Thu, 17 Oct 2013 18:32:21 +0200 Message-ID: <52601133.2000404@gmx.net> Date: Thu, 17 Oct 2013 18:32:51 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "TLS@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:fWv5U+KZUgc0JcOn1AEJiKiGFCChk3AJb5mcA7Iy+rahLJWPlY4 uDtSQh37qL48PfqVe7Rb4qy22t5s53Pdudom6nvWLrGQxIPpV94Ig2l+LTFB54atF4ffr3B UlyzgmBVh+pmpg4QNZ36mEcvsOnguVXl/4zDzO/DfNt3/zfcTNSbBnh5nu07XN4fttYRFbp meZCujNkLFd6ZzQmDtDkA== Subject: [TLS] draft-ietf-tls-cached-info-15 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 16:32:37 -0000 Hi all, as suggested in my previous mail I have refreshed the document and it does not contain the OCSP/multiple OCSP response caching functionality. Here is the document: http://tools.ietf.org/html/draft-ietf-tls-cached-info-15 Ciao Hannes From Johannes.Merkle@secunet.com Thu Oct 17 09:32:54 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDBE111E827C for ; Thu, 17 Oct 2013 09:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BV9FTl9jGWPE for ; Thu, 17 Oct 2013 09:32:49 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 09D3111E8273 for ; Thu, 17 Oct 2013 09:32:32 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 2609D1A0071; Thu, 17 Oct 2013 18:32:31 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Tw9qTi-0TdKU; Thu, 17 Oct 2013 18:32:29 +0200 (CEST) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id D11161A006F; Thu, 17 Oct 2013 18:32:29 +0200 (CEST) Received: from [172.16.40.201] ([172.16.40.201]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Oct 2013 18:32:29 +0200 Message-ID: <5260111D.6030907@secunet.com> Date: Thu, 17 Oct 2013 18:32:29 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Dan Brown References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> <20130926152757.15842.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDB49B@XMB116CNC.rim.net> <20130928223648.1113.qmail@cr.yp.to> <20130929025714.5578895.47771.4422@certicom.com> <20131001143511.11010.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE21E@XMB116CNC.rim.net> <20131002161944.8125.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE90F@XMB116CNC.rim.net> <20131003010455.17185.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDECA6@XMB116CNC.rim.net> <20131005192950.27059.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BE4A9D@XMB116CNC.rim.net> <20131012003058.669.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BEBAA5@XMB117CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF5BEC2EC@XMB117CNC.rim.net> In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5BEC2EC@XMB117CNC.rim.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2013 16:32:29.0714 (UTC) FILETIME=[78F2FF20:01CECB56] Cc: "'djb@cr.yp.to'" , "'tls@ietf.org'" Subject: Re: [TLS] Safe ECC usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 16:32:54 -0000 Dan Brown schrieb am 17.10.2013 17:46: > Why couldn't a new attack just work on one curve, namely Curve25519? If I > understand correctly, DJB has argued that the ECC theory and experience would > be evidence for a claim similar, but perhaps not as strong, as your claim. > There is really no use in speculating about future attacks as long as there are not some clear indications about their presence and potential. An example of the latter case is the anticipation (or is is merely a feeling in the guts?) by some researchers of an attack potential for certain curves having small class group orders, and even the validity of this educated guess is controversially disputed. Nobody knows which curves unforeseen attacks (I mean to exclude the latter example by this term) will affect. IMO any speculation about this (including the present discussion) is metaphysics. BTW, my understanding of DJB posts was that he only meant to contradict your hypothesis on certain curves being more likely being affected by future attacks than others, but as far as I understood, he never made any claim about the impact to be expected by future attacks. -- Johannes From nico@cryptonector.com Thu Oct 17 09:39:01 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE7B11E82A4 for ; Thu, 17 Oct 2013 09:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-jsjkbVgslB for ; Thu, 17 Oct 2013 09:38:56 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 84DA911E829C for ; Thu, 17 Oct 2013 09:38:56 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id 24E1C1E07C for ; Thu, 17 Oct 2013 09:38:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=AdK/jnUQL3BgWuQCLvpS WpXVNWo=; b=J2dZs15x+M7B5mTQSWcn+I1/Du5/KVkBOdSmoJIUxgM6aK9xehGJ SVj31DDYs3mQyE16WKUHaVG+ZHedC6G6ntpHMbUokFH4JVLMy4KbuyRaJk6hSOTv 04+YuoBslCNEfWhWIKhZkB+WhuGHAxJemjIjRRwLj2uvhoOFAE3DHak= Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id 9D5D01E071 for ; Thu, 17 Oct 2013 09:38:55 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id w62so2569712wes.35 for ; Thu, 17 Oct 2013 09:38:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=a6cX49TGEKt6GvFTSyanN96WkMv6ZgLopzw9rJFU9Hs=; b=nISvGURvpTu6lsvQGd2xcmBHA/fIHCFWfzbTkptE+b5Xpc0n+hvxKJ6nYk1LLMw8hY sseUvzL6YnhoK6u2ekHDXM44C8kc1g2fh7z3Zpc5MGUQ2FIwuaG/ivYGp/LH466Sk2gH 3xD9ZHDvho3AvvZE/0Nx6aT06dkkh6hIZmdNKgzB4IdaRVk0IutIaX9keCfphzy37/zc E5pDhTxK+RHYeQJVpItcjR77+cBeh1ybEn1Ul66Fw0dwncJ30byNmMeFMPmq9s4l1RF7 1NM92hS0TvDEgKGqjVoIkv0KeFPX7vNq/aFdVo3Xfm/hSqcYhUSsCsTa2Sr/eMcpuIvN POIA== MIME-Version: 1.0 X-Received: by 10.180.198.79 with SMTP id ja15mr7683382wic.36.1382027933955; Thu, 17 Oct 2013 09:38:53 -0700 (PDT) Received: by 10.216.151.136 with HTTP; Thu, 17 Oct 2013 09:38:53 -0700 (PDT) In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5BEC2EC@XMB117CNC.rim.net> References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> <20130926152757.15842.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDB49B@XMB116CNC.rim.net> <20130928223648.1113.qmail@cr.yp.to> <20130929025714.5578895.47771.4422@certicom.com> <20131001143511.11010.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE21E@XMB116CNC.rim.net> <20131002161944.8125.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE90F@XMB116CNC.rim.net> <20131003010455.17185.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDECA6@XMB116CNC.rim.net> <20131005192950.27059.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BE4A9D@XMB116CNC.rim.net> <20131012003058.669.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BEBAA5@XMB117CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF5BEC2EC@XMB117CNC.rim.net> Date: Thu, 17 Oct 2013 11:38:53 -0500 Message-ID: From: Nico Williams To: Dan Brown Content-Type: text/plain; charset=UTF-8 Cc: "djb@cr.yp.to" , "tls@ietf.org" Subject: Re: [TLS] Safe ECC usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 16:39:01 -0000 On Thu, Oct 17, 2013 at 10:46 AM, Dan Brown wrote: > Why couldn't a new attack just work on one curve, namely Curve25519? If I > understand correctly, DJB has argued that the ECC theory and experience would > be evidence for a claim similar, but perhaps not as strong, as your claim. Let's say that there are single-curve attacks. We don't know how many curves have such attacks, nor how hard it is to find such attacks for specific curves, or specific curves with such attacks. Perhaps DJB does know, but either he got spectacularly lucky (if such attack/curve pairs are rare) or such attack/curve pairs are very common. The latter would imply that all ECC is busted, in which case we needn't worry about whether Curve25519 is weak because we have bigger problems, so we must ignore this possibility when comparing curves to one another. That leaves the former, and now we need some estimate of frequency of such attack/curve pairs in order to decide if any one curve is weak. We don't have such an estimate, but surely whatever that frequency is, it's the same for all cryptographers. That means that for any one standard curve, the likelihood of it being weak this way is about the same if the possible attacks for each curve were not known at the time they were discovered. Now we just need to know whether the curves in question were selected with or without such knowledge, but we can't know this [yet], so instead we must estimate the likelihood that the authors selected a weak curve on purpose. An estimate of weak curve distribution/frequency would allow us to estimate the likelihood that a curve was selected because it was weak. If some curve required specifying N bits of information, then it must have been picked from a range of 1..2^2N or so curves (the 2^2N upper bound is an estimate), *roughly*. The larger the N, the larger the freedom the author has/had in selecting a weak curve. Whatever the frequency of weak curves, the smaller the N, the more luck an author needs to pick a weak curve. That, I think, is the argument for why DJB curves' selection criteria are more rigid (i.e., less subject to manipulation) than Brainpool curves. Now, if one out of every 5 curves are weak, then clearly there's a great chance that DJB curves are weak. If, for small Ns, one out of every 5 curves are weak, while for large Ns one out of every trillion curves are weak, then Brainpool curves are stronger than DJB curves. I.e., the distribution of weak curves matters. We know nothing about the distribution of such weak curves -- the associated attacks are not known, they are merely conjectured for the sake of argument after all. It seems unlikely that there's a class of attacks on curves where the distribution of weak curves tails off as curve complexity (size of constants) increases. But we can't really know anything about this conjectured class of attacks each limited to one or few curves. I'm not sure what we should assume, but all else being equal my conclusion is that we should prefer curves whose selection criteria left very little freedom to those doing the selection. This might include Brainpool-like (i.e., with large constants) curves, but I'd want the selection to work as follows: one small group of people publicly select a hash function, another disjoint set of people independently, publicly (videotaped), and concurrently select a short, simple, and *meaningful* English language string ("hello world"), then pick the largest constants smaller than bounds computed from that hash applied to that string. In the meantime DJB curves were clearly selected with very little freedom to select for rare weak curves, therefore I believe we can trust them. Nico -- From nico@cryptonector.com Thu Oct 17 09:40:49 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5137211E8295 for ; Thu, 17 Oct 2013 09:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRlQKYghZdjs for ; Thu, 17 Oct 2013 09:40:42 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC6411E81BE for ; Thu, 17 Oct 2013 09:40:42 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id EAE7F2005D90B for ; Thu, 17 Oct 2013 09:40:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=J6h60fYCjXs1GlChzQmyhe1lfBY=; b=V0OimawPHNp l4AUTcr+bWgvW4VkprfCMb6/jvxolA4gLTpYJNRobKKGhei7tWoBIyquz9ZwoFkg ITB6lBVQif3JEfzSeFNApeJLO1oJ5dslxRQra536OLqiz4iRW9DdJC0xK9WZABGy ceE2sKxCZ/rY5JvkFhpUh8ili7N1Dhyw= Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPSA id 8FEA52005D90A for ; Thu, 17 Oct 2013 09:40:41 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id n12so2578851wgh.5 for ; Thu, 17 Oct 2013 09:40:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=cx79hANOnpe2kj+bB/JKkcuIec3/KsBUVXw5yB2iSXw=; b=M5ViLnNSx6CnYXDIafjBtmHFQHSKn6gTJFc0HYwktBwxO+lBu5TAnkt7vY6+FImM8I LbU4YzAOC688/F3TtnXJVh6YiOmZ6fSfzxJE/72azTIhVNwV7tn+cns4sUKhH9Voc74t LI9idd6ex2MbG9pPiwjn/xRTQtJqD4/KX22VSl34q/tp+Rb2umNaWAGiN1kCJUMcVOGG i9etGNSitMd1AqVTxXo7VwoecSQDOCh6YW33jjUEtnXeC2aqGp8aJ9k+mubrNv5Jly8q t2oWG2tsoJXjRR7YYLhWRTfpFbO5VZvgjXiw4fH610O9RjjdvcdcSxA5ogds63gtEsIg Op5A== MIME-Version: 1.0 X-Received: by 10.180.198.79 with SMTP id ja15mr7689623wic.36.1382028040041; Thu, 17 Oct 2013 09:40:40 -0700 (PDT) Received: by 10.216.151.136 with HTTP; Thu, 17 Oct 2013 09:40:39 -0700 (PDT) In-Reply-To: <52600F6B.3020404@elzevir.fr> References: <525C11B5.2050604@secunet.com> <525CEFA4.2030903@funwithsoftware.org> <01b901cec9a0$004e12b0$00ea3810$@offspark.com> <525E3E6B.1020604@secunet.com> <525EAC5D.7080105@secunet.com> <525EB695.9070607@secunet.com> <525FA70F.8030208@secunet.com> <52600F6B.3020404@elzevir.fr> Date: Thu, 17 Oct 2013 11:40:39 -0500 Message-ID: From: Nico Williams To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Patrick Pelletier , "tls@ietf.org" Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 16:40:49 -0000 On Thu, Oct 17, 2013 at 11:25 AM, Manuel P=C3=A9gouri=C3=A9-Gonnard wrote: > On 17/10/2013 17:55, Nico Williams wrote: >> The fact that some curve has twist >> security means that for DH there's no need to validate that public >> keys are points on the curve > > Not if your peer sends you (x, y). Your statement is true only in ECDH sc= hemes > where the peers sends only x (and you don't attempt to find y). Fair enough, but as the subject was Brainpool vs. Curve25519... From mrex@sap.com Thu Oct 17 11:30:33 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216B911E82A9 for ; Thu, 17 Oct 2013 11:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.038 X-Spam-Level: X-Spam-Status: No, score=-10.038 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ze7fSNWqdrhz for ; Thu, 17 Oct 2013 11:30:28 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 88F8F11E81A2 for ; Thu, 17 Oct 2013 11:30:18 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r9HIUF8l017742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Oct 2013 20:30:15 +0200 (MEST) In-Reply-To: <20131016221640.0452568e@latte.josefsson.org> To: Simon Josefsson Date: Thu, 17 Oct 2013 20:30:15 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20131017183015.47A401AA07@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= , "tls@ietf.org" Subject: Re: [TLS] Curve25519 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 18:30:34 -0000 Simon Josefsson wrote: > You wrote: > > > Thinking about it, I'm inclined to say we don't need to define a new > > ECPointFormat entry, the I-D should just mandate that support for > > (resp. use of) curve25519 implies support for (resp. use of) the > > associated (unamed) point format. This avoids possible consistency > > issues like a client advertising support for the curve but not for > > the associated point format. > > > > Similarly, the usual point formats have a leading byte indicating the > > format used, that should IMO be dropped for curve25519. > > > > So this would lead to the definition that, for this curve, instead of > > containing "the byte string representation of a field element > > following the conversion routine in Section 4.3.3 of ANSI X9.62", the > > point member of the ECPoint structure contains an opaque[32] > > representing the x-coordinate of the point. This should probably be a variable length vector so that the format can be reused beyond curve25519 for similar curves with longer keys (is curve3617 such a thing?) > > This sounds like a feasible approach to me. Maybe we need to put this > solution in writing, and maybe put some of the other options in writing > as well, to allow people to make an informed decision of where to go. I > think this thread has been quite informative, and I'm hoping we can > reach some early consensus and update the draft with that. Extending plus subsetting rfc4492, so that PDUs and code points for ECDH cipher suites can be shared between curve25519 and other ECC curves, seems appropriate and acceptable. But I would highly appreciate if the generic bloat, brittleness and timing-sensitive ECC math of regular rfc4492 can be avoided as much as possible. So a new, simplified/specialized ECPoint format that is mandatory for use with curve25519 and relatives, would help a lot. -Martin From nico@cryptonector.com Thu Oct 17 13:21:25 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFD6921F92C2 for ; Thu, 17 Oct 2013 13:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.981 X-Spam-Level: X-Spam-Status: No, score=-1.981 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTMSqSyuVYFA for ; Thu, 17 Oct 2013 13:21:20 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 72CD321F9223 for ; Thu, 17 Oct 2013 13:21:20 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id B491C2005D10B for ; Thu, 17 Oct 2013 13:21:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=/Fbk4wcYEMy4o0Z+uOE5 EQYU0QU=; b=SZatvHoBx0DjzNIDMu0Xnhg6fLNp8DdG+mF8a3E8Tl6xP6/zxnEY FUabYcv4e0cNhPOim5iwJ+x5JkPDHCD9fB9vH3IJ8DgpSJGrLRXRi7Pfus8sx8wq 0lCjczBRALgPyJ32W8Zel8xM+DhMDFef76su/mwllAZZ7b/CRDSMWRk= Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id 699FC2005D109 for ; Thu, 17 Oct 2013 13:21:19 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id cb5so22740wib.7 for ; Thu, 17 Oct 2013 13:21:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B9vZ1ETFgDxzafbX/XxxiOfk3Ljj60+XAT5KZd6uTY0=; b=ZF4pnLja2RNVlBjW9GeUjJ8NMHwuFTAv6NJZiFJZgZ9Rv6rKz/mUaOaF+6pwCwjbNu kaaWGC+PT8jFOt4XtZhbV99Ks8t+4YFsJnek9aarJqHuNT6Cvavo8YIWvKidB8O+Gfwh WvqNFGOthWuHvjzJQd6I7ZN2zxMSrZwvPQ1ghTRja94AdHmMYpyeL2uOSLNaHMQ+zvaQ 7B9krRgOoY3r1m4MwhydxP9lu2dnA9G0oo5hD1ZO4PrKrAeenhmIiyrflI83vbzUC0xt OG118+STLSAg641jeZZJp0j/w/TYvW8hdWdA+xkYhkpaRCvVDWJf+TqTr++P8zQdZVTX emdg== MIME-Version: 1.0 X-Received: by 10.180.39.212 with SMTP id r20mr31134470wik.13.1382041277596; Thu, 17 Oct 2013 13:21:17 -0700 (PDT) Received: by 10.216.151.136 with HTTP; Thu, 17 Oct 2013 13:21:17 -0700 (PDT) In-Reply-To: <20131017183015.47A401AA07@ld9781.wdf.sap.corp> References: <20131016221640.0452568e@latte.josefsson.org> <20131017183015.47A401AA07@ld9781.wdf.sap.corp> Date: Thu, 17 Oct 2013 15:21:17 -0500 Message-ID: From: Nico Williams To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Cc: Simon Josefsson , =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= , "tls@ietf.org" Subject: Re: [TLS] Curve25519 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 20:21:25 -0000 On Thu, Oct 17, 2013 at 1:30 PM, Martin Rex wrote: > This should probably be a variable length vector so that the > format can be reused beyond curve25519 for similar curves with > longer keys (is curve3617 such a thing?) Yes (and yes, at least it exists as a curve specification in safecurves.cr.yp.to; dunno if code exists). (Ditto Curve1174.) > Extending plus subsetting rfc4492, so that PDUs and code points > for ECDH cipher suites can be shared between curve25519 and other > ECC curves, seems appropriate and acceptable. Yes. > But I would highly appreciate if the generic bloat, brittleness and > timing-sensitive ECC math of regular rfc4492 can be avoided as much > as possible. So a new, simplified/specialized ECPoint format that > is mandatory for use with curve25519 and relatives, would help a lot. Agreed. Nico -- From mpg@elzevir.fr Fri Oct 18 00:22:32 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF58621F958A for ; Fri, 18 Oct 2013 00:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36ZyCAfYMA62 for ; Fri, 18 Oct 2013 00:22:27 -0700 (PDT) Received: from mordell.elzevir.fr (mordell.elzevir.fr [IPv6:2001:4b98:dc0:41:216:3eff:feeb:c406]) by ietfa.amsl.com (Postfix) with ESMTP id D4D8921F9D92 for ; Fri, 18 Oct 2013 00:22:15 -0700 (PDT) Received: from thue.elzevir.fr (thue.elzevir.fr [88.165.216.11]) by mordell.elzevir.fr (Postfix) with ESMTPS id 7727D161DA; Fri, 18 Oct 2013 09:22:13 +0200 (CEST) Received: from [192.168.0.124] (unknown [192.168.0.254]) by thue.elzevir.fr (Postfix) with ESMTPSA id 314AE25FFC; Fri, 18 Oct 2013 09:22:12 +0200 (CEST) Message-ID: <5260E1A1.9090602@elzevir.fr> Date: Fri, 18 Oct 2013 09:22:09 +0200 From: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.0 MIME-Version: 1.0 To: Nico Williams References: <525C11B5.2050604@secunet.com> <525CEFA4.2030903@funwithsoftware.org> <01b901cec9a0$004e12b0$00ea3810$@offspark.com> <525E3E6B.1020604@secunet.com> <525EAC5D.7080105@secunet.com> <525EB695.9070607@secunet.com> <525FA70F.8030208@secunet.com> <52600F6B.3020404@elzevir.fr> In-Reply-To: X-Enigmail-Version: 1.5.2 OpenPGP: id=98EED379; url=https://elzevir.fr/gpg/mpg.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Patrick Pelletier , "tls@ietf.org" Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 07:22:33 -0000 On 17/10/2013 18:40, Nico Williams wrote: > On Thu, Oct 17, 2013 at 11:25 AM, Manuel Pégourié-Gonnard > wrote: >> On 17/10/2013 17:55, Nico Williams wrote: >>> The fact that some curve has twist >>> security means that for DH there's no need to validate that public >>> keys are points on the curve >> >> Not if your peer sends you (x, y). Your statement is true only in ECDH schemes >> where the peers sends only x (and you don't attempt to find y). > > Fair enough, but as the subject was Brainpool vs. Curve25519... If I may reformulate my point: twist-security is relevant only for curves suitable for use with schemes where only the x coordinate is transmitted, and no attempt to reconstruct y is needed on the receiving side. Which means, curves for which formulas exist for point multiplication using only the x coordinate. To the best of my knowledge (read: after looking up the explicit formulas database) no such formulas exist for short Weierstrass curves. Let's try with pseudo-code: If (has efficient x-only formulas) may transmit only x, and if doing so: if (is twist-secure) no need to validate x else need to validate x else need to transmit or reconstruct y, so: if (y transmitted entirely) need to validate (x,y) explicitly else (x,y) implicitly validated while reconstructing y As you can see, twist-security is irrelevant in the second branch, to which short-Weierstrass curves (which can't be transformed to Montgomery form, such as Brainpool curves) belong unless some magical x-only formulas are discovered. So you may argue that Curve25519 has performance-without-sacrificing-security advantages for DH over Brainpool curves and I certainly won't contradict you on that point, but citing twist security as relevant here would be putting the cart before the horse IMO. Manuel. PS: just kidding (almost?), but one could argue that brainpoolP384r1, as used in TLS for ECDH now, is *less* secure because of twist-security, if people start thinking that they don't need to validate public keys for this curve... From hannes.tschofenig@gmx.net Fri Oct 18 02:05:58 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6478B21F9D7C for ; Fri, 18 Oct 2013 02:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aonxa-zdBp20 for ; Fri, 18 Oct 2013 02:05:53 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA3221F995A for ; Fri, 18 Oct 2013 02:05:48 -0700 (PDT) Received: from [172.16.254.200] ([80.92.116.76]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MATlG-1VR0Nt08CY-00Bfz9 for ; Fri, 18 Oct 2013 11:05:47 +0200 Message-ID: <5260FA09.6040205@gmx.net> Date: Fri, 18 Oct 2013 11:06:17 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Hauke Mehrtens , tls@ietf.org References: <52498FF1.1090701@hauke-m.de> In-Reply-To: <52498FF1.1090701@hauke-m.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:HRSREQMpvMmRF4V398Hs/ZotjKgZ3GI+sHSFjpTRAxQyIihJ5Oz uAl6ZLu3cbDM+rWQYvTyUfwMxcZWKvSgKJnJDeZL4tZ6KbO2fgXtIOhy52GlNH5lA4tNN5x xKNbHK+NM995+bHl2QPMPjeCOsSwSlHC8e2UplAassBaK9rA58vcpe9waISTkS28Vss+XkC o1BBOAn0dpkP2NBCgHEYg== Subject: Re: [TLS] draft-ietf-tls-oob-pubkey-09: client auth, but no client key X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 09:05:58 -0000 Hi Hauke, with the draft-ietf-tls-oob-pubkey specification the TLS client has a way to indicate what certificate types it supports. As such, the TLS server knows what certificates it can ask for before sending the certificate request message. Hence, the situation that the client receives a certificate request but doesn't actually have a certificate cannot really happen (unless in a failure situation). In that case I believe the suitable error response by the TLS client would be the one you described from RFC 5246. Maybe it is worthwhile to point this out in the document to have this error case clearly described? On 09/30/2013 04:51 PM, Hauke Mehrtens wrote: > RFC 5246 7.4.6 "Client Certificate" says: > > If no suitable certificate is available, > the client MUST send a certificate message containing no > certificates. That is, the certificate_list structure has a > length of zero. > > How should a client act when raw public keys are used and the server > requests client authentication, but there is no public key or no > suitable public key? > > Not adding client_certificate_type to the ClientHello is not enough, > because this could also indicate that the client supports client > authentication with X.509 certificates. > > I would send an empty client certificate handshake message and no > certificate verify message and the server should decide, like it is > specified for X.509 certificates in RFC 5246 7.4.6. By 'empty' you mean that the certificate_list structure has a length of zero (similarly as it is defined in RFC 5246)? Ciao Hannes > > Hauke > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From hannes.tschofenig@gmx.net Fri Oct 18 02:06:27 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B2C21F9A50 for ; Fri, 18 Oct 2013 02:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHoRPhkW06nk for ; Fri, 18 Oct 2013 02:06:21 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 14FF821F9D5D for ; Fri, 18 Oct 2013 02:06:04 -0700 (PDT) Received: from [172.16.254.200] ([80.92.116.76]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lm2lZ-1W6Qgt1M93-00ZeFB for ; Fri, 18 Oct 2013 11:06:02 +0200 Message-ID: <5260FA18.4030504@gmx.net> Date: Fri, 18 Oct 2013 11:06:32 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Alexey Melnikov , ietf@ietf.org References: <20130802072350.14846.84073.idtracker@ietfa.amsl.com> <5203B8BC.9080108@isode.com> In-Reply-To: <5203B8BC.9080108@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:zlqU1QMwfDH5sQ4L0MkElKMEbFXzBjEhVTwb9iZMrYdn4eDyYDK bJDf6h9b/81Mus5IW+4CHBKh8QVHhKe1ouv3k2KONwUG6X0JyN0AHXMXVuyOU/y68RW0xfh EitGBQwDW8kdsAxM6f+gHn9FHXFq4P1yk8zoaPbkEA74LzAnx1nYEke2D8bk4A5b/vcVJ5k 0oueSA1psyv2YfygPaAsw== Cc: tls@ietf.org Subject: Re: [TLS] Last Call: (Out-of-Band Public Key Validation for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 09:06:27 -0000 Hi Alexey, the first example indeed has a copy-and-paste error. I fixed it. Ciao Hannes On 08/08/2013 05:26 PM, Alexey Melnikov wrote: > On 02/08/2013 08:23, The IESG wrote: >> The IESG has received a request from the Transport Layer Security WG >> (tls) to consider the following document: >> - 'Out-of-Band Public Key Validation for Transport Layer Security (TLS)' >> as Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2013-08-16. Exceptionally, comments may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> >> This document specifies a new certificate type and two TLS >> extensions, one for the client and one for the server, for exchanging >> raw public keys in Transport Layer Security (TLS) and Datagram >> Transport Layer Security (DTLS) for use with out-of-band public key >> validation. > Hi, > I just read the document and support its publication. > > I think I found one minor issue: > > Section 4.1 says: > > In order to indicate the support of out-of-band raw public keys, > clients MUST include the 'client_certificate_type' and > 'server_certificate_type' extensions in an extended client hello > message. The hello extension mechanism is described in TLS 1.2 > [RFC5246]. > > In Section 5 (the first example): > > client_hello, > server_certificate_type=(RawPublicKey) -> // [1] > > So it looks like the example doesn't comply with the MUST requirement in > the Section 4.1 ("client_certificate_type" is missing) or the > requirement stated in Section 4.1 is incorrect. I suspect you meant > "'client_certificate_type' and/or 'server_certificate_type'" in Section > 4.1. > > Best Regards, > Alexey > > > > From hannes.tschofenig@gmx.net Fri Oct 18 05:03:29 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8504221F9F88 for ; Fri, 18 Oct 2013 05:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwLICHRqj+gH for ; Fri, 18 Oct 2013 05:03:24 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3CE11E8102 for ; Fri, 18 Oct 2013 05:03:23 -0700 (PDT) Received: from [172.16.254.200] ([80.92.116.76]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MS1g6-1V9X7Y0MP4-00TCJI for ; Fri, 18 Oct 2013 14:03:22 +0200 Message-ID: <526123A7.5050305@gmx.net> Date: Fri, 18 Oct 2013 14:03:51 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Dirk Balfanz , IETF TLS WG References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:+0aS8ccBGz9T7VJTX7zOiqJxyKC798vUTFMgKNBTmeBCRhMm/5N 4rPXsUWn0OQ6mMxQz/xyoKFh18vJKzbcWSiwk+JMQvPOzpQ0wM7rIyxE2eKzH00YVXSH6pG 1+vgsLMwLgcQJF0+SS33YUZKnI2gU5Ff0sRbfPnmB42zuGTTBRTJ6PT+N/aT4b5Si58v0xA lAh/LvZ6hgWyoFeOAh5fQ== Subject: Re: [TLS] channel id and oob X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 12:03:29 -0000 Hi Dirk, thanks for looking at the two specifications. A few remarks below: On 08/02/2013 12:10 PM, Dirk Balfanz wrote: > Hi guys, > > I was asked to write a quick analysis of draft-ietf-tls-oob-pubkey, and > whether it can be applied to the use cases we have in mind for Channel ID. > > My conclusion is that it can not, or that the necessary modifications to > the OOB draft would be too substantial to be considered during Last Call. > > First, the similarities: both proposals allow the client to prove > possession of a key pair. The fact that this proof-of-possession is > forthcoming is negotiated using the TLS extension mechanism (during > ClientHello/ServerHello). > > Now for the differences: > > * We don't want the client public key to be sent in the clear. It's a > client identifier, and shouldn't be known to anyone but the client > and the server. This is an aspect the group agreed to solve via a separate extension, if I remember it correctly since it has wider applicability than just for these documents. Recalling Ekr's presentation about TLS 1.3 from the last IETF meeting he mentioned that this would be one of the features of the new version. Whether it is useful to define an extension that can be used with TLS 1.1/1.2 is a decision the ADs and chairs need to make. > > * We don't want the proof-of-keypair-possession to be part of the > session state, I am not entirely sure what you mean by "proof-of-keypair-possession to be part of the session state". for two reasons: > o It blows up the session state, with ramifications on the size of > the fleet of servers that cache this information. > Remember that > in our use case, we don't intend this to be used for the > occasional client that wants to use non-password authentication > with the server; it's designed to be used by _every_ client > talking to big service providers like Google. Raw public keys > are of course smaller than full certificates, but they still > represent a significant increase in the size of session state. The document does not require servers to store the received raw public key. > o We don't want someone who is not actually wielding the private > key of the keypair to make it appear to the server as if they > were in control of that private key. Session resumption, > however, gives you that power: Let's assume that the private key > of the keypair sits in a hardware-protected secure element, and > is therefore out of reach of malware. Master secrets and other > session information, however, is very likely kept in RAM and > therefore available to thieves. If such a thief extracts the > session data from the client and resumes the session, the server > will treat the thief as the holder of the original private key. > If the proof-of-keypair possession is explicitly declared not > part of the session, then a client has to re-prove possession of > the keypair even during abbreviated handshakes. Thus, a thief of > session secrets (but not of the private key) won't be able to > convince a server that it is in control of that private key. You don't have to use session resumption if you do not want. I also consider the threat a bit unrealistic. If you assume that the end device is compromised then what prevents the malware from obtaining the private key before it gets into the hardware-protected secure element. I believe in your scenario you are not talking about a long-term ephemeral key pair but rather something that is dynamically created on the end device or dynamically provisioned. > > The oob-draft keeps the raw key in the session state, thus > inheriting this problem with session state and session resumption. We actually don't say anything about keeping the key in session state nor about session resumption. I consider those aspects implementation and configuration issues. > > * Channel ID keys are different from key material sent in the > Certificate message, and the certificate message shouldn't be > overloaded with this new semantics: Key material presented in the > Certificate message (even if it's a raw key) presumably carries some > semantics for the application: "this is a certain user", "this is an > enterprise-issued machine", etc., while the Channel-ID keys are > always self-generated and their semantics include (among other > things) "this is the key that will be nuked when the user presses > the 'reset my browsing state' button". It makes for tricky > implementations when those two different semantics get mapped to the > same protocol message. More importantly, applications may want to do > both: authenticate a user with a client cert, and then set a > channel-bound cookie as a result of the authentication. You can't do > that if you only have one proof-of-possession available in the > handshake. With the raw public key we actually do not say what identity the key refers to. You are correct that there is an issue if we want to provide two layers of authentication within TLS and I am not sure whether that is even in scope of your document either since it is not discussed. > > As mentioned above, I don't really see how this issues could possibly be > addressed within the draft-ietf-tls-oob-pubkey draft, especially since > it's in last-call. Just the first point above alone seemed to be > something that folks didn't want to touch until TLS 1.3. > > Thoughts? What we could do is the following: a) Brainstorm whether we see the two layers of authentication as a valid use case. I don't think we both do but maybe someone else does. b) We work on a specification that provides the confidentiality protection of information exchanged by the client. This could be useful in a number of cases, even work that is currently ongoing in the TLS working group right now. c) We clarify the issues regarding the session state. I did not occur to me that this would be something to write about in the document but maybe it is worthwhile to have a discussion about it. Ciao Hannes > > Dirk. > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From dbrown@certicom.com Fri Oct 18 07:21:58 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB1011E82B3 for ; Fri, 18 Oct 2013 07:21:58 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpiydFmrJS38 for ; Fri, 18 Oct 2013 07:21:53 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB4B11E82AE for ; Fri, 18 Oct 2013 07:21:50 -0700 (PDT) Content-Type: multipart/mixed; boundary="===============1213953503==" MIME-Version: 1.0 Received: from xct103cnc.rim.net ([10.65.161.203]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 18 Oct 2013 10:21:44 -0400 Received: from XCT111CNC.rim.net (10.65.161.211) by XCT103CNC.rim.net (10.65.161.203) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 18 Oct 2013 10:21:43 -0400 Received: from XMB117CNC.rim.net ([fe80::24f3:cc30:b596:7ca0]) by XCT111CNC.rim.net ([::1]) with mapi id 14.03.0123.003; Fri, 18 Oct 2013 10:21:43 -0400 From: Dan Brown To: "'nico@cryptonector.com'" Thread-Topic: [TLS] Safe ECC usage Thread-Index: AQHOxuJRxn3XJXmgAkKRAg2ZE6kwf5n3qq2ggAC0kACAAKQ6QIAAYI2AgAEXd7A= Date: Fri, 18 Oct 2013 14:21:43 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF5BEDA76@XMB117CNC.rim.net> References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> <20130926152757.15842.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDB49B@XMB116CNC.rim.net> <20130928223648.1113.qmail@cr.yp.to> <20130929025714.5578895.47771.4422@certicom.com> <20131001143511.11010.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE21E@XMB116CNC.rim.net> <20131002161944.8125.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE90F@XMB116CNC.rim.net> <20131003010455.17185.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDECA6@XMB116CNC.rim.net> <20131005192950.27059.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BE4A9D@XMB116CNC.rim.net> <20131012003058.669.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BEBAA5@XMB117CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF5BEC2EC@XMB117CNC.rim.net> In-Reply-To: Accept-Language: en-CA, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] MIME-Version: 1.0 Cc: "'djb@cr.yp.to'" , "'tls@ietf.org'" Subject: Re: [TLS] Safe ECC usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 14:21:58 -0000 --===============1213953503== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_001C_01CECBEB.D74D17F0" ------=_NextPart_000_001C_01CECBEB.D74D17F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Nico Williams wrote: > Dan Brown wrote: > > Why couldn't a new attack just work on one curve, namely Curve25519? > > If I understand correctly, DJB has argued that the ECC theory and > > experience would be evidence for a claim similar, but perhaps not as > strong, as your claim. > > Let's say that there are single-curve attacks. We don't know how many > curves have such attacks, nor how hard it is to find such attacks for > specific curves, or specific curves with such attacks. Perhaps DJB > does know, but either he got spectacularly lucky (if such attack/curve Well, you've assumed here, just like others, that attacks are random. If you assume that attacks are random, then you are right that manipulation is the main threat. I've argued a few times that assuming random attacks is too optimistic, and also close to circular reasoning, and not supported by the evidence. Remember, Curve25519, though free from the potential of malicious manipulation, is chosen, in part, for its special efficiency properties. These special properties may also given an attacker special advantages. DJB has already argued, based on the existing attacks -- not random attacks -- that this is unlikely. And I agreed. Consider the ECC history. After resisting all generic attacks, we have the following Miyaji proposed special trace 1 curves. A few years later, these were broken by the SASS attack. Various proposed supersingular curves. Later, they were broken by the MOVFR attacks. But ever since then, it has been fairly quiet on the prime-field side of ECC. > pairs are rare) or such attack/curve pairs are very common. The latter > would imply that all ECC is busted, in which case we needn't worry > about whether Curve25519 is weak because we have bigger problems, so we > must ignore this possibility when comparing curves to one another. Furthermore, if we admit this possibility, i.e. to justify that the ECDLP over P256, then we should not just ignore it, but consider alternatives to ECC. As I understand it, DJB has put forward his reasonable supposition of what the bigger problem is. Maybe you should review it. > That leaves the former, and now we need some estimate of frequency of > such attack/curve pairs in order to decide if any one curve is weak. > Of course, it's very hard to make such estimates. Even so, there is merit in making such estimates. They have to been based on evidence. There two types of evidence here: 1. The lack of new attacks, despite efforts and incentives. 2. The existing attacks, e.g. MOVFR and SASS. Intuition might entirely dismiss inferring estimates from this evidence set, as wild speculation. More formally, intuition would be saying the inference drawn from the set have low confidence. ------=_NextPart_000_001C_01CECBEB.D74D17F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUgTCCBnAw ggVYoAMCAQICChfYCekAAwAXxTIwDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAz WUtGMB4XDTEzMDUyODE1NDQwOVoXDTE0MDUxNzAwMjMzM1owgYUxEzARBgoJkiaJk/IsZAEZFgNu ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xETAPBgNVBAsTCENlcnRpY29tMQ4wDAYDVQQLEwVVc2Vy czESMBAGA1UEAxMJRGFuIEJyb3duMSIwIAYJKoZIhvcNAQkBFhNkYnJvd25AY2VydGljb20uY29t MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDRc70RE0/FL9ZbfN64YjA0lkQOLR9ipGebc9nH jB93OfYfR7CVsCUYy3+v9PO1DiUS9MeWWR4nxB9Ztee32d3syDxGg3PGFwSrms/ORAW9pgiS/yKH An9SKRKyqMz9LSn/VQrEgoyPBPT0S/vg521MGH58MwMXyLm1cLBQU5gtCQIDAQABo4IDmDCCA5Qw CwYDVR0PBAQDAgWgMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQME AgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUAlQmTNpWxnzoCUVjxGTtDz2JvLww FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMB8GA1UdIwQYMBaAFLgwF25vZ5X+hYxoO6XhF7M/+CU6 MIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiGgctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu YXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1NQ0EwM1lLRixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIw U2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2Fs P2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRp b25Qb2ludIZIaHR0cDovL21jYTAzeWtmLnJpbS5uZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRp bmF0ZSUyMENBJTIwTUNBMDNZS0YuY3JsMIIBQQYIKwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUH MAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1BSUEs Q049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixE Qz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZp Y2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxodHRwOi8vbWNhMDN5a2YucmltLm5ldC9DZXJ0 RW5yb2xsL01DQTAzWUtGLnJpbS5uZXRfUklNJTIwU3Vib3JkaW5hdGUlMjBDQSUyME1DQTAzWUtG KDMpLmNydDApBgNVHSUEIjAgBgorBgEEAYI3CgMEBggrBgEFBQcDBAYIKwYBBQUHAwIwQQYDVR0R BDowOKAhBgorBgEEAYI3FAIDoBMMEWRhbmlicm93bkByaW0ubmV0gRNkYnJvd25AY2VydGljb20u Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQC6hxWgDv96DUDS3m8XfyVGAv1CKOcWSVOShz/jofFMFzoN o2dhc0Jg9XTTZBVS+ozakEM+87YUENfP3IODRbCiJBsbiXJxS+fVo7L/bqPp47TB+Lg2/tezlNa2 ab4psmc9xjZGU9+A4lBzS5PpRjvHofsIwETpwt/aPxHIbJ5Cf7kBi7B8hR4mIqc7EJMYXeI0xHLg k3NqBYSGC3XtbykuFV0vPFoTYLO7G3pAP2RzGhuxQoaH4fpWvE3rdakjd1MZFqJrarXSvWi6ah6G Alt7+sOTzlGNqoTQqb55VZEOrU2A1VbmAFjiFR1/229A2KaHhnN6cuNe8bhzoBcnuxtyMIIGvzCC BKegAwIBAgIQMhrzkrEUWZRNTS+VEbN74TANBgkqhkiG9w0BAQUFADBPMRUwEwYKCZImiZPyLGQB GRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBN Q0EwMVlLRjAeFw0wNjEwMTMwMTI0NTVaFw0xNjEwMTMwMTMwNDFaME8xFTATBgoJkiaJk/IsZAEZ FgVsb2NhbDEXMBUGCgmSJomT8ixkARkWB3dpbmRvd3MxHTAbBgNVBAMTFFJJTSBSb290IENBIE1D QTAxWUtGMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAxui6zvytVAEtPzv6NhK7OZna iw/jQEyEVskDf5yzcFkLT/+5PztIbv+eFmL1CP2FhvLv8eQZJDKF4Yv+UsjPEN1lX4DDGKKt0NPp yT9pwQzFaiUt0rnERgSabo7EtpS4S+DuL8G9c+lmWwDqb0UWtPMdVfbr3fDwigyz1yh+vVMAHdhg Oe9lPC6nPtiJ9IXTam7V5mJmDT0mNpq/0fJo3JEaNvDKoXBOkKv6IdbtKxKzPInG6VYaCdgJCAT3 mWgr9kxiEQEUJKrvI2fXI0zRYnlL648gvK84pdsT2xZLFtr4OdZAm4RkK8U+cgurlSCr6NVqnfbq 6/3N6MGmyc9SB2Ayhk2VS66757V4nBzeaeD+srpk4IXU3NTM/+YgR1zVS41XwvZaq9Uf59j0TJhN 9xGVZO871eVVr2VfNxr0xOqUpwcxh5JZYkWcmUJFlYiQh0CM2PrfaDRTTqRZQd4F3xUlcXFAXOGh vaXKvikeI6/utnX6vCnDwMUxmenzlv8epNatxDsuIgOWO4pfqgGMyzWo2hudQ97+5ynUqDLX34nr UzszGeIE3KoqYsksxMF3tqIgadt9hNWXaP/EknZpRAmaP0s0V5ZvgiyXw9UrqnWwmRbLQk7HnYc0 hHQBjXoByKSiOyhgSS9yL6a+7AA2rhBPpsSVI9LYBs2cNKlPsZcCAwEAAaOCAZUwggGRMBMGCSsG AQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTW aYJkJBbBzCTb8RR9RxJ83MlN7jCCASkGA1UdHwSCASAwggEcMIIBGKCCARSgggEQhoHEbGRhcDov Ly9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1NQ0EwMVlLRixDTj1DRFAsQ049UHVi bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5k b3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1j UkxEaXN0cmlidXRpb25Qb2ludIZHaHR0cDovL21jYTAxeWtmLndpbmRvd3MubG9jYWwvQ2VydEVu cm9sbC9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwDQYJ KoZIhvcNAQEFBQADggIBAEOeWFu4OVTnx9+jYk92iDra2f1Bc5j1WesEGINl4VCY9WJy6n17b/h2 fDmjj9KfIto3LE2Wej77lSJqv/LSd7wnfTQVZVb1wBe2Zt+LuPAqi6vWSDAQVOfdOMYVu5imznnf +ZNMLduTqXZ/bFQKTWsg2qhBWwaiYfxEY7nVg3+ZfStqwc9R3v/tHH+b9kX3FuKLoVQ6KSrqUyBi fhIRj57eOw6/JjPA+SId/p2yEZ+xmANQ31vE3BHFRm20kZHHqAfdCmTt1S7LDSLHBj3GZXIFUge9 aPKqzAXee2DCYTP3YYcgrP/FbFF2RqGRIhPM+MdjJraMjex+nNT+2KC/EIWsbU9DgFII0wHKpRx8 rlJNN8kmb/H9qGqcNaW9Q/pwUTpX1bXSdbzvYFs3NY7KmYYii4Q0RQCGr96OvDT0/S6/IrnW+vqZ jnPV2MXqEuyQ0L5HXVOnCi769uGYcRkEo5xzEJ/EMvj07vCWnG7h9ykNhLEEMcygVmBdXP9qOqog dyPJB0AzxAYGqCSMT8Ors1M/srZSXUCfSfENH5iBd7bxH7uXmF7kbOEghom7AccC2Clt4DU0tj9s FyIWg5H6zy6NLetm2/kzdD3mGY3u2tWtijVnd2CWY2YszYo1lbDAfEfjGL/9uFpH79Zt9ekRSD5Z bSn1SNr1njjeGpV3jwyuMIIHRjCCBS6gAwIBAgIKFnKQQQAAAAABuDANBgkqhkiG9w0BAQUFADBP MRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQD ExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjAeFw0xMjA1MTcwMDEzMzNaFw0xNDA1MTcwMDIzMzNaMFAx EzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBT dWJvcmRpbmF0ZSBDQSBNQ0EwM1lLRjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfx jFzEuYa/qd6dXu4HILtBdH3+Bgwz3uQakDcxvrf3fyVQBy69KFOS8/h5REe6bit3tp5wsQQv/nFV mmXK/jq9zD72zl3jv63UzZgOWC90846UxTTmmNEyHzo1M54B3LrnE6L2Q6QbEZMAnrJ96uV8pN2X Zsn5j+MvfI5ajFu+6oPbHeYzQjZB3GDju7sELm7cAcr0YYX3xeLTB2rLUUZF6Nyyc0btD57ARYEa 99A+6JslO8VcxtlgRddx17NB6gttNjwmJFT3l3UVcK5O5+UVSWpW1zQbZQBvl0iP7gXcrJW4Dv0p 036iHg9lgDV1qQChi9NCixwm7yYtCHLq9akCAwEAAaOCAyEwggMdMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFLgwF25vZ5X+hYxoO6XhF7M/+CU6MAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEE AwIBAzAjBgkrBgEEAYI3FQIEFgQUZUBVml3ak56Kwnbul6AULvNdck8wGQYJKwYBBAGCNxQCBAwe CgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNVHR8EggEg MIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Ys Q049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRp b25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6Ly9tY2Ew MXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Yu Y3JsMIIBPAYIKwYBBQUHAQEEggEuMIIBKjCBuwYIKwYBBQUHMAKGga5sZGFwOi8vL0NOPVJJTSUy MFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRvd3MsREM9bG9jYWw/Y0FDZXJ0aWZp Y2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwagYIKwYBBQUHMAKG Xmh0dHA6Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvTUNBMDFZS0Yud2luZG93 cy5sb2NhbF9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcnQwDQYJKoZIhvcNAQEFBQADggIB AK/ZTtcAxFAZJo37z0KG3EGIGIScPRus90jBJGQO9+Mrb4QRoMjkCwZP9GbYq2CxCqOBiKOZfkSK PMSupPLRlE70z9tGbsMz13ExQy50WZS9n4XRxglyDRga1fQVwGNF+SMPaBzQapiFi3CkBWNSdz+f aRdkdiqIvG3hxkbk6AXr6xhlu2mvnhJ/dE248lZDmN3FkWDHXEgEd5uHxwd7nWjxXVuzRV0oNgrG E96uTqLHVsdefHplPwyrIlgV4SY1ST1y8nKhZlB4IX8fDIj1Xr3rRssW+8XEKSILvawoU47n34x6 xZrO8nbramu3s3BPDnPBe5d1akBYA/nTKb9l6by6dNzJ7u1r73w7/tC53Hgf+826w6Gw+Z6Xs1d2 6RvukJ+7VCyKTR+rg+jASrfhS7naerxVMoOZwr6GxqqHYbK1gp3ag8Ek1U62/LYLqbvYMn58e23k q1pR6vLfQY4AhteMJipLmkxioYjHMCm9rTCZCnU2e/yvNNGXXq8WEeJpAc7hXbFR8L7VTaawkSxg jtJ2YTLvGH0cM/lEOAn3UGUG1lAhBBBzpLS4oW+ITZ5LsPWx2UiWAHLF79XE+PzvFE1+haf4HzJ0 KNKizMaj6DyVJN/oLOvdlVn32x70hCkr9zPFM6f4wEtQoY+qV3Q13zB7FePumyia5+/xmioObwts MYICrjCCAqoCAQEwXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmlt MSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwCQYFKw4D AhoFAKCCAaYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMDE4 MTQyMTQzWjAjBgkqhkiG9w0BCQQxFgQUqpSbgHMCKYvCXb6gPs5i9rtUW0MwZwYJKoZIhvcNAQkP MVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwbQYJKwYBBAGCNxAEMWAwXjBQMRMw EQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vi b3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwbwYLKoZIhvcNAQkQAgsxYKBeMFAxEzAR BgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBTdWJv cmRpbmF0ZSBDQSBNQ0EwM1lLRgIKF9gJ6QADABfFMjANBgkqhkiG9w0BAQEFAASBgI+XGNV2jAb4 Z0zlMApNfXTtPAO49s9f4L3mRH+xzikPLk9l7ZBPl+RNM0RGYVONF8F8+oVdxNUrPDiwzBB8VNKg ba5VcV/zOLP0XjWOnG74ErIpM7VE7KP7CfY4AP29YDU7ykfM8y/RYqosS1ax+NR6x/YH7Kd4dOdg YZabhIiwAAAAAAAA ------=_NextPart_000_001C_01CECBEB.D74D17F0-- --===============1213953503== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --===============1213953503==-- From watsonbladd@gmail.com Fri Oct 18 08:35:33 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB13F11E81D1 for ; Fri, 18 Oct 2013 08:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01XpMtnT1mal for ; Fri, 18 Oct 2013 08:35:33 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D523411E80F9 for ; Fri, 18 Oct 2013 08:35:32 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id u57so3983276wes.32 for ; Fri, 18 Oct 2013 08:35:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=juckV00ETibMsGXboOFEhDnjafrOe4xvfZ4kL9+5Cls=; b=gwVOvpkIxlAgdDBvmt9aAUcQWOGZn/bzWbIlIEW5EBf3AdYPbEQcHlCw6fk87xyEk9 JdoiGN2WamKMablXq6oJR5u/6za8rWL18FhjRGYXtnpCUZsB1PY0MruHFxVskpIVdBUt vHbHJ1TmkeJSjWuVv2/YfDjUjO9gp1sQKKWkGBh/5SL/nBFVeoiIcHtDVva3RpFHvct8 gFsWQNQSltTZECdDOc/xWdiWAIQsznuJZ8zqMxYKEM/l36TR3X8eugU5riCJahov1N5u fg3RNvcaHFbOZ9Qtu1Hb+HlPV7KVZXVPl6en3OAIsicyWKyQtqjKxfA5LwiTDdtWm65Y e9Bw== MIME-Version: 1.0 X-Received: by 10.194.9.70 with SMTP id x6mr3124655wja.22.1382110531982; Fri, 18 Oct 2013 08:35:31 -0700 (PDT) Received: by 10.194.242.131 with HTTP; Fri, 18 Oct 2013 08:35:31 -0700 (PDT) In-Reply-To: <5260E1A1.9090602@elzevir.fr> References: <525C11B5.2050604@secunet.com> <525CEFA4.2030903@funwithsoftware.org> <01b901cec9a0$004e12b0$00ea3810$@offspark.com> <525E3E6B.1020604@secunet.com> <525EAC5D.7080105@secunet.com> <525EB695.9070607@secunet.com> <525FA70F.8030208@secunet.com> <52600F6B.3020404@elzevir.fr> <5260E1A1.9090602@elzevir.fr> Date: Fri, 18 Oct 2013 08:35:31 -0700 Message-ID: From: Watson Ladd To: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Patrick Pelletier , "tls@ietf.org" Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 15:35:33 -0000 On Fri, Oct 18, 2013 at 12:22 AM, Manuel P=C3=A9gouri=C3=A9-Gonnard wrote: > On 17/10/2013 18:40, Nico Williams wrote: >> On Thu, Oct 17, 2013 at 11:25 AM, Manuel P=C3=A9gouri=C3=A9-Gonnard >> wrote: >>> On 17/10/2013 17:55, Nico Williams wrote: >>>> The fact that some curve has twist >>>> security means that for DH there's no need to validate that public >>>> keys are points on the curve >>> >>> Not if your peer sends you (x, y). Your statement is true only in ECDH = schemes >>> where the peers sends only x (and you don't attempt to find y). >> >> Fair enough, but as the subject was Brainpool vs. Curve25519... > > If I may reformulate my point: twist-security is relevant only for curves > suitable for use with schemes where only the x coordinate is transmitted,= and no > attempt to reconstruct y is needed on the receiving side. Which means, cu= rves > for which formulas exist for point multiplication using only the x coordi= nate. > To the best of my knowledge (read: after looking up the explicit formulas > database) no such formulas exist for short Weierstrass curves. Let's try = with > pseudo-code: This isn't true: See Brier-Joye ladders. They aren't used because of efficency problems, but they solve the incompleteness issues. > > If (has efficient x-only formulas) > may transmit only x, and if doing so: > if (is twist-secure) > no need to validate x > else > need to validate x > else > need to transmit or reconstruct y, so: > if (y transmitted entirely) > need to validate (x,y) explicitly > else > (x,y) implicitly validated while reconstructing y > > As you can see, twist-security is irrelevant in the second branch, to whi= ch > short-Weierstrass curves (which can't be transformed to Montgomery form, = such as > Brainpool curves) belong unless some magical x-only formulas are discover= ed. > > So you may argue that Curve25519 has performance-without-sacrificing-secu= rity > advantages for DH over Brainpool curves and I certainly won't contradict = you on > that point, but citing twist security as relevant here would be putting t= he cart > before the horse IMO. > > Manuel. > > PS: just kidding (almost?), but one could argue that brainpoolP384r1, as = used in > TLS for ECDH now, is *less* secure because of twist-security, if people s= tart > thinking that they don't need to validate public keys for this curve... Invalid curve attacks mean validation on short Weierstra=C3=9F curves is always required. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nico@cryptonector.com Fri Oct 18 09:01:39 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD0811E8232 for ; Fri, 18 Oct 2013 09:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfOx3HnKAI+5 for ; Fri, 18 Oct 2013 09:01:28 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id AEDDA11E8263 for ; Fri, 18 Oct 2013 09:01:16 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 1F1B4674091 for ; Fri, 18 Oct 2013 09:01:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=1k9JR9TGmQIVMjWbG6gi 4dCVQxA=; b=NePvPNELmmiRcREntLh0l8Uc31YT9fv7lKD4M0zCC+esaLCwahss ufMOsvfQqmkoZjtGEIeqwzRblTR+8FQJCTpqPyT/TuoQnoPMg1MxBCeBoPhBR62r GdRI/t5e1K3KJjRYmXl1GGIFGutTFHvVPxOYIdSpJyv1kXINgAfhiVQ= Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id E0DF76740A9 for ; Fri, 18 Oct 2013 09:00:19 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id f12so3964653wgh.19 for ; Fri, 18 Oct 2013 09:00:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8zwpPJcT/EojP6IKV+un+etn3BDl1nZEV7TKCCe9sBw=; b=aqYfqzL8uU0qul3nCR1Q9RD+hRFbFs37eajdDUtcBkQ8wZCOJF/GhpqxZ7Lp9mypVP xkA4LfBhGcMlE85kxkubcZFcm5SGxaiS9LQr3DCLmwNB2JehfavvuT2lm2GcadF5+iIv 7Qe7+6F8n+6RN53QqI7hvZI7Sm6udQ6uKlbjnM+oHu6FYK0paw6dEv6f/o69DfXHANaP 3XbTMTfSN5IOMbIcM3VFbLr3T3K9/z7Y1NRW9i4Uckf5fFyMEfC1Y+IT93B8tLe4Fl3B OxXvbpUUZF9txMDUATgwSaZ93bNZc5NlR+eoYILt1f/uiilbp01jlpYSEZsVs8XWBO6r uehw== MIME-Version: 1.0 X-Received: by 10.194.20.170 with SMTP id o10mr3276620wje.4.1382112017089; Fri, 18 Oct 2013 09:00:17 -0700 (PDT) Received: by 10.216.151.136 with HTTP; Fri, 18 Oct 2013 09:00:16 -0700 (PDT) In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5BEDA76@XMB117CNC.rim.net> References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> <20130926152757.15842.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDB49B@XMB116CNC.rim.net> <20130928223648.1113.qmail@cr.yp.to> <20130929025714.5578895.47771.4422@certicom.com> <20131001143511.11010.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE21E@XMB116CNC.rim.net> <20131002161944.8125.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE90F@XMB116CNC.rim.net> <20131003010455.17185.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDECA6@XMB116CNC.rim.net> <20131005192950.27059.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BE4A9D@XMB116CNC.rim.net> <20131012003058.669.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BEBAA5@XMB117CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF5BEC2EC@XMB117CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF5BEDA76@XMB117CNC.rim.net> Date: Fri, 18 Oct 2013 11:00:16 -0500 Message-ID: From: Nico Williams To: Dan Brown Content-Type: text/plain; charset=UTF-8 Cc: "djb@cr.yp.to" , "tls@ietf.org" Subject: Re: [TLS] Safe ECC usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 16:01:39 -0000 On Fri, Oct 18, 2013 at 9:21 AM, Dan Brown wrote: > Nico Williams wrote: >> Dan Brown wrote: >> > Why couldn't a new attack just work on one curve, namely Curve25519? >> > If I understand correctly, DJB has argued that the ECC theory and >> > experience would be evidence for a claim similar, but perhaps not as >> strong, as your claim. >> >> Let's say that there are single-curve attacks. We don't know how many >> curves have such attacks, nor how hard it is to find such attacks for >> specific curves, or specific curves with such attacks. Perhaps DJB >> does know, but either he got spectacularly lucky (if such attack/curve > > Well, you've assumed here, just like others, that attacks are random. If you > assume that attacks are random, then you are right that manipulation is the > main threat. I assumed all of: random attacks ("[w]ed don't know how many") and attacks where one knows how to create a curve so it will be vulnerable ("[w]e don't know ... how hard it is to find ... specific curves with such attacks"). > I've argued a few times that assuming random attacks is too optimistic, and > also close to circular reasoning, and not supported by the evidence. Random attacks are the reason to want rigid curve selection processes. That leaves the other possibility, that the curve author knows how to create curves that will be vulnerable to some class of attacks without a random search. Here we can use curve selection criteria that involve parameter selections that no one person/entity can control -- verifiably. Surely that was your point, no? That curve25519 might be "special" (as in specially weak) in some way that you (and I) don't know. > Remember, Curve25519, though free from the potential of malicious > manipulation, is chosen, in part, for its special efficiency properties. > > These special properties may also given an attacker special advantages. DJB > has already argued, based on the existing attacks -- not random attacks -- > that this is unlikely. And I agreed. > > Consider the ECC history. After resisting all generic attacks, we have the > following > > Miyaji proposed special trace 1 curves. A few years later, these were broken > by the SASS attack. > > Various proposed supersingular curves. Later, they were broken by the MOVFR > attacks. > > But ever since then, it has been fairly quiet on the prime-field side of ECC. We can look at things other than the constants in curve25519 (and curve 1174, and curve3617) -- the class(es) of curve(s) that it (they) fits.. separately from the curve selection criteria. How do we mitigate unknown weaknesses in each curve class? The only thing I know is: algorithm agility. As for selection criteria, I think I'd prefer a verifiably random selection process over the smallest freedom approach, but where there's doubt about the random selection process' verifiability I prefer the latter over the former. The problem is that as time passes it becomes more difficult to verify that a long-ago random selection process was not manipulated -- we have to trust records of history in order to believe that it wasn't. >> pairs are rare) or such attack/curve pairs are very common. The latter >> would imply that all ECC is busted, in which case we needn't worry >> about whether Curve25519 is weak because we have bigger problems, so we >> must ignore this possibility when comparing curves to one another. > > Furthermore, if we admit this possibility, i.e. to justify that the ECDLP over > P256, then we should not just ignore it, but consider alternatives to ECC. I didn't mean that we should flat out ignore that possibility. I was very specific: "... so we must ignore this possibility WHEN COMPARING CURVES TO ONE ANOTHER". I said nothing about comparing ECC to non-ECC. Once more, the only way I know of to mitigate against unknown attacks is algorithm agility. For ephemeral DH algorithm agility is relatively simple: require to implement N different DH algorithms, make it easy to turn off any of them if they get broken. For other ECC uses algorithm agility is much harder: it involves re-keying. We could require that principals have N public keys (in PKI cases, that all N certs have the same names and so on, issued by the same issuer), so that it's possible to drop any one that gets broken later. But even this, I think, may be too much to ask for. So at some point we have to pick something. At some point, in spite of uncertainty, we have to select some algorithm as the one we're going to rely on the most for authentication. Which would you rather use? >> That leaves the former, and now we need some estimate of frequency of >> such attack/curve pairs in order to decide if any one curve is weak. > > Of course, it's very hard to make such estimates. Even so, there is merit in > making such estimates. They have to been based on evidence. There two types > of evidence here: > > 1. The lack of new attacks, despite efforts and incentives. > > 2. The existing attacks, e.g. MOVFR and SASS. > > Intuition might entirely dismiss inferring estimates from this evidence set, > as wild speculation. More formally, intuition would be saying the inference > drawn from the set have low confidence. So do nothing? Ignore the whole field? I'm not sure where you're going with this. What specific advice are you giving us? Nico -- From mpg@elzevir.fr Fri Oct 18 09:30:56 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7FF21F9CF5 for ; Fri, 18 Oct 2013 09:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3UG5WYoooLu for ; Fri, 18 Oct 2013 09:30:55 -0700 (PDT) Received: from mordell.elzevir.fr (mordell.elzevir.fr [IPv6:2001:4b98:dc0:41:216:3eff:feeb:c406]) by ietfa.amsl.com (Postfix) with ESMTP id 0606711E8263 for ; Fri, 18 Oct 2013 09:30:51 -0700 (PDT) Received: from thue.elzevir.fr (unknown [IPv6:2a01:e35:8a5d:80b0:be5f:f4ff:fe2c:95bc]) by mordell.elzevir.fr (Postfix) with ESMTPS id 7B60B161DA; Fri, 18 Oct 2013 18:30:49 +0200 (CEST) Received: from [192.168.0.124] (unknown [192.168.0.254]) by thue.elzevir.fr (Postfix) with ESMTPSA id 1F77F29991; Fri, 18 Oct 2013 18:30:47 +0200 (CEST) Message-ID: <52616236.1080707@elzevir.fr> Date: Fri, 18 Oct 2013 18:30:46 +0200 From: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.0 MIME-Version: 1.0 To: Watson Ladd References: <525C11B5.2050604@secunet.com> <525CEFA4.2030903@funwithsoftware.org> <01b901cec9a0$004e12b0$00ea3810$@offspark.com> <525E3E6B.1020604@secunet.com> <525EAC5D.7080105@secunet.com> <525EB695.9070607@secunet.com> <525FA70F.8030208@secunet.com> <52600F6B.3020404@elzevir.fr> <5260E1A1.9090602@elzevir.fr> In-Reply-To: X-Enigmail-Version: 1.5.2 OpenPGP: id=98EED379; url=https://elzevir.fr/gpg/mpg.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Patrick Pelletier , "tls@ietf.org" Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 16:30:56 -0000 On 18/10/2013 17:35, Watson Ladd wrote: > On Fri, Oct 18, 2013 at 12:22 AM, Manuel Pégourié-Gonnard >> If I may reformulate my point: twist-security is relevant only for curves >> suitable for use with schemes where only the x coordinate is transmitted, and no >> attempt to reconstruct y is needed on the receiving side. Which means, curves >> for which formulas exist for point multiplication using only the x coordinate. >> To the best of my knowledge (read: after looking up the explicit formulas >> database) no such formulas exist for short Weierstrass curves. Let's try with >> pseudo-code: > This isn't true: See Brier-Joye ladders. They aren't used because of > efficency problems, but they > solve the incompleteness issues. I stand corrected, I wasn't previously aware of these formulas and missed them when I checked the EFD page. Thanks for bringing them to my attention. >> If (has efficient x-only formulas) Anyway, since I took care to add "efficient" here, this doesn't change the evaluation of this condition... >> PS: just kidding (almost?), but one could argue that brainpoolP384r1, as used in >> TLS for ECDH now, is *less* secure because of twist-security, if people start >> thinking that they don't need to validate public keys for this curve... > Invalid curve attacks mean validation on short Weierstraß curves is > always required. Which was precisely my point: people should *not* start thinking validation isn't required (regardless of whether the curve is twist-secure or not), when they are receiving an (x,y) pair. I'm sorry if that wasn't clear enough from my messages, I really thought it was. Manuel. From msj@nthpermutation.com Fri Oct 18 09:35:55 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3663D11E831B for ; Fri, 18 Oct 2013 09:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_BAYES_5x8=0.8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pG8qU-7twKxg for ; Fri, 18 Oct 2013 09:35:50 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id CD08121F89A5 for ; Fri, 18 Oct 2013 09:35:49 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id l13so2821733qcy.18 for ; Fri, 18 Oct 2013 09:35:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BQ5H+KhAzMo+s2jSHHwObPIij67t/8seJjXcKYcvG64=; b=hfUF0O4oLy/CHNVrfNfps7s7pCRVeVzJrthE1WgtzlykgQxebaqN5KPJ83kDfG2U6Z w7ROfl6ESSXQZV6kOYaWU2WH2c6KUv0a00G81E/FAPYoAG666hdDzj/De+UVmBscuXjv ubbKganlj+glp5f90pQaOZP1Y6G11flICUfnTMDBfrj6k+b8Gq+ov8OJSrRELnPR4hCS EhnvFqx2whS2/lfqM0wxObtZ+QcjP7YG9gqOhuUcXayYrSbktWnZtuvBH4lyeLiW9zFU j6kGtOxiLDF16nD4M+uQOFySrHSNtk5EhUL4Qm4vkdRJezFalcQbstuYH4fvt9ZCi4rV nSjw== X-Gm-Message-State: ALoCoQkimbx48YM0wR5BtJTU91oZPJjFIldXH3IbidDpz0D67DNWMZglOm3wPgN8oNjdx/3ZQ+CT X-Received: by 10.49.47.84 with SMTP id b20mr5088522qen.83.1382114148409; Fri, 18 Oct 2013 09:35:48 -0700 (PDT) Received: from [10.90.197.74] (soi.silverspringnet.com. [74.121.22.10]) by mx.google.com with ESMTPSA id x1sm7005134qai.6.2013.10.18.09.35.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Oct 2013 09:35:47 -0700 (PDT) Message-ID: <52616365.1080108@nthpermutation.com> Date: Fri, 18 Oct 2013 12:35:49 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: tls@ietf.org References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> <20130926152757.15842.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDB49B@XMB116CNC.rim.net> <20130928223648.1113.qmail@cr.yp.to> <20130929025714.5578895.47771.4422@certicom.com> <20131001143511.11010.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE21E@XMB116CNC.rim.net> <20131002161944.8125.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE90F@XMB116CNC.rim.net> <20131003010455.17185.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDECA6@XMB116CNC.rim.net> <20131005192950.27059.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BE4A9D@XMB116CNC.rim.net> <20131012003058.669.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BEBAA5@XMB117CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF5BEC2EC@XMB117CNC.rim.net> In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5BEC2EC@XMB117CNC.rim.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Safe ECC usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 16:35:55 -0000 I've been watching the curve conspiracy discussion stuff for a bit. I don't actually know what the reality is. So I decided to try and find the earliest mention of one of the seeds. I half expected I was going to find the seed string had been pulled from the random number tables in the CRC handbook. I googled for "C49D3608 86E70493 6A6678E1 139D26B7 819F7E90" - the seed for P256 and found: ftp://ftp.iks-jena.de/mitarb/lutz/standards/ansi/X9/x962-11-17-97.pdf This document has the seed for P256 and P192 (which also matches) but not P384 or P521. Only sample curves up to 256 bits were provided. The existence of this document, created in 1997 would tend to suggest that at least a few curves were created in X9 and not by NIST given the document precedes the FIPS 186-2 publication by a couple of years. Of course, X9 could have just gotten the curves from NIST as a submission - but why weren't P384 and P521 provided at that point? I don't have access to the X9 archives - maybe someone out there has a set of X9 correspondence around 1997 or so that we could take a look at? I would expect the curves to be some form of specific contribution. Mike From dbrown@certicom.com Fri Oct 18 11:42:26 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66AC11E8243 for ; Fri, 18 Oct 2013 11:42:26 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8Gs31KRIhDN for ; Fri, 18 Oct 2013 11:42:21 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 64A8911E81B8 for ; Fri, 18 Oct 2013 11:42:21 -0700 (PDT) Content-Type: multipart/mixed; boundary="===============1062121819==" MIME-Version: 1.0 Received: from xct101cnc.rim.net ([10.65.161.201]) by mhs210cnc.rim.net with ESMTP/TLS/AES128-SHA; 18 Oct 2013 14:42:17 -0400 Received: from XMB117CNC.rim.net ([fe80::24f3:cc30:b596:7ca0]) by XCT101CNC.rim.net ([fe80::9c22:d9c:c906:c488%16]) with mapi id 14.03.0123.003; Fri, 18 Oct 2013 14:42:16 -0400 From: Dan Brown To: "'nico@cryptonector.com'" Thread-Topic: [TLS] Safe ECC usage Thread-Index: AQHOxuJRxn3XJXmgAkKRAg2ZE6kwf5n3qq2ggAC0kACAAKQ6QIAAYI2AgAEXd7CAAHAUAP//2cVA Date: Fri, 18 Oct 2013 18:42:16 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF5BEDD49@XMB117CNC.rim.net> References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> <20130926152757.15842.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDB49B@XMB116CNC.rim.net> <20130928223648.1113.qmail@cr.yp.to> <20130929025714.5578895.47771.4422@certicom.com> <20131001143511.11010.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE21E@XMB116CNC.rim.net> <20131002161944.8125.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE90F@XMB116CNC.rim.net> <20131003010455.17185.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDECA6@XMB116CNC.rim.net> <20131005192950.27059.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BE4A9D@XMB116CNC.rim.net> <20131012003058.669.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BEBAA5@XMB117CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF5BEC2EC@XMB117CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF5BEDA76@XMB117CNC.rim.net> In-Reply-To: Accept-Language: en-CA, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] MIME-Version: 1.0 Cc: "'djb@cr.yp.to'" , "'tls@ietf.org'" Subject: Re: [TLS] Safe ECC usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 18:42:27 -0000 --===============1062121819== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0020_01CECC10.3CE92B20" ------=_NextPart_000_0020_01CECC10.3CE92B20 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Nico Williams wrote: > Dan Brown wrote: > > Nico Williams wrote: > > Random attacks are the reason to want rigid curve selection processes. Yes, good point and sentence. Special attacks are the reason to want random curve selection. > > That leaves the other possibility, that the curve author knows how to > create curves that will be vulnerable to some class of attacks without > a random search. Here we can use curve selection criteria that involve > parameter selections that no one person/entity can control -- > verifiably. > > Surely that was your point, no? That curve25519 might be "special" > (as in specially weak) in some way that you (and I) don't know. My point was not about malicious curve selection, but its pre-requisite: existence of a weak class of curves. > > > Remember, Curve25519, though free from the potential of malicious > > manipulation, is chosen, in part, for its special efficiency > properties. > > > > These special properties may also given an attacker special > > advantages. DJB has already argued, based on the existing attacks - > - not random attacks -- > > that this is unlikely. And I agreed. > > > > Consider the ECC history. After resisting all generic attacks, we > > have the following > > > > Miyaji proposed special trace 1 curves. A few years later, these > were > > broken by the SASS attack. > > > > Various proposed supersingular curves. Later, they were broken by > the > > MOVFR attacks. > > > > But ever since then, it has been fairly quiet on the prime-field side > of ECC. > > We can look at things other than the constants in curve25519 (and curve > 1174, and curve3617) -- the class(es) of curve(s) that it (they) fits.. > separately from the curve selection criteria. How do we mitigate > unknown weaknesses in each curve class? The only thing I know is: > algorithm agility. In addition to algorithm agility, random curve selection mitigates unknown weaknesses, e.g. Brainpool or P256 (but only if you trust its creator). Hmm, maybe, I am missing your point about "curve class". I believe that, elsewhere in this thread, I said algorithm agility would be a very good reason for including Curve25519, in addition to Brainpool. Algorithm agility, though, does not help much, in general, against untold attacks (mainly helping against newly announced attacks). In particular, we don't want to TLS to become laissez-faire roll any algorithm you want, i.e. the ultimate in algorithm agility? At some point, TLS considers the evidence and picks a few good algorithms, right? The choice governing this selection of each algorithm is not primarily algorithm agility. For example, AES was chosen for inclusion in TLS, not because of algorithm agility but because of the extensive analysis it underwent. TLS did not, and still does not, adopt every single newly proposed algorithm in the name of algorithm agility. So, something other than algorithm agility seems to be protecting TLS. Also, separately from but similary to algorithm agility, algorithm X is not usually adopted in TLS just on the grounds that we know of no attack, else each new proposal would be adopted. So, it is inconsistent to consider only about known attacks. TLS has to consider what evidence there is against unknown attacks. I contend that it is on this basis, that is reasonable scrutinize crypto algorithms, be it P256 or Curve25519. > As for selection criteria, I think I'd prefer a verifiably random > selection process over the smallest freedom approach, but where there's > doubt about the random selection process' verifiability I prefer the > latter over the former. The problem is that as time passes it becomes > more difficult to verify that a long-ago random selection process was > not manipulated -- we have to trust records of history in order to > believe that it wasn't. > > >> pairs are rare) or such attack/curve pairs are very common. The > >> latter would imply that all ECC is busted, in which case we needn't > >> worry about whether Curve25519 is weak because we have bigger > >> problems, so we must ignore this possibility when comparing curves > to one another. > > > > Furthermore, if we admit this possibility, i.e. to justify that the > > ECDLP over P256, then we should not just ignore it, but consider > alternatives to ECC. > > I didn't mean that we should flat out ignore that possibility. I was > very specific: "... so we must ignore this possibility WHEN COMPARING > CURVES TO ONE ANOTHER". I said nothing about comparing ECC to non-ECC. > Once more, the only way I know of to mitigate against unknown attacks > is algorithm agility. Sorry for the confusion. In this thread, I've been arguing two INDEPENDENT points: - random curves have slightly more assurance than special - if the threat against P256 is serious, then we had better seriously consider non-ECC The evidence set for the two points is similar, which may cause me to look like an arguing for one point, when I am trying to argue the other. Put another way, what's the point in comparing curves to each other, if we believe there's a bigger problem of ECC being busted. Put another way, it's as if we have something like C = max(A,B) + |A-B|, then C is always better than A or B, unless A and B are the same. > For ephemeral DH algorithm agility is relatively simple: require to > implement N different DH algorithms, make it easy to turn off any of > them if they get broken. > > For other ECC uses algorithm agility is much harder: it involves re- > keying. We could require that principals have N public keys (in PKI > cases, that all N certs have the same names and so on, issued by the > same issuer), so that it's possible to drop any one that gets broken > later. But even this, I think, may be too much to ask for. > > So at some point we have to pick something. At some point, in spite of > uncertainty, we have to select some algorithm as the one we're going to > rely on the most for authentication. Which would you rather use? Hmm, as an end user, I might go for the safest possible that can run on my device. > > >> That leaves the former, and now we need some estimate of frequency > of > >> such attack/curve pairs in order to decide if any one curve is weak. > > > > Of course, it's very hard to make such estimates. Even so, there is > > merit in making such estimates. They have to been based on evidence. > > There two types of evidence here: > > > > 1. The lack of new attacks, despite efforts and incentives. > > > > 2. The existing attacks, e.g. MOVFR and SASS. > > > > Intuition might entirely dismiss inferring estimates from this > > evidence set, as wild speculation. More formally, intuition would be > > saying the inference drawn from the set have low confidence. > > So do nothing? Ignore the whole field? I'm not sure where you're > going with this. What specific advice are you giving us? > Oh, sorry, I was very unclear, hinging on the word "might" to express what others might intuit. I was thinking about a totally different point. My own intuition: I think ECC is safe, and that in the very unlikely case of any untold attacks, they will be at most similar in impact to MOVFR and SASS. My advice: definitely don't worry about Brainpool. Don't worry about P256, unless you view its creator as an adversary and you are somehow required to use ECC, almost against your will, instead of some alternative like RSA or integer DH. Consider Curve25519 mainly if you really want efficiency, or don't trust the reliability of your implementation, and maybe also have dim view on the security of ECC alternatives. TLS can safely adopt all these EC choices. At some point, though, TLS may not want to allow too many choices. ------=_NextPart_000_0020_01CECC10.3CE92B20 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUgTCCBnAw ggVYoAMCAQICChfYCekAAwAXxTIwDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAz WUtGMB4XDTEzMDUyODE1NDQwOVoXDTE0MDUxNzAwMjMzM1owgYUxEzARBgoJkiaJk/IsZAEZFgNu ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xETAPBgNVBAsTCENlcnRpY29tMQ4wDAYDVQQLEwVVc2Vy czESMBAGA1UEAxMJRGFuIEJyb3duMSIwIAYJKoZIhvcNAQkBFhNkYnJvd25AY2VydGljb20uY29t MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDRc70RE0/FL9ZbfN64YjA0lkQOLR9ipGebc9nH jB93OfYfR7CVsCUYy3+v9PO1DiUS9MeWWR4nxB9Ztee32d3syDxGg3PGFwSrms/ORAW9pgiS/yKH An9SKRKyqMz9LSn/VQrEgoyPBPT0S/vg521MGH58MwMXyLm1cLBQU5gtCQIDAQABo4IDmDCCA5Qw CwYDVR0PBAQDAgWgMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQME AgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUAlQmTNpWxnzoCUVjxGTtDz2JvLww FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMB8GA1UdIwQYMBaAFLgwF25vZ5X+hYxoO6XhF7M/+CU6 MIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiGgctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu YXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1NQ0EwM1lLRixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIw U2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2Fs P2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRp b25Qb2ludIZIaHR0cDovL21jYTAzeWtmLnJpbS5uZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRp bmF0ZSUyMENBJTIwTUNBMDNZS0YuY3JsMIIBQQYIKwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUH MAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1BSUEs Q049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixE Qz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZp Y2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxodHRwOi8vbWNhMDN5a2YucmltLm5ldC9DZXJ0 RW5yb2xsL01DQTAzWUtGLnJpbS5uZXRfUklNJTIwU3Vib3JkaW5hdGUlMjBDQSUyME1DQTAzWUtG KDMpLmNydDApBgNVHSUEIjAgBgorBgEEAYI3CgMEBggrBgEFBQcDBAYIKwYBBQUHAwIwQQYDVR0R BDowOKAhBgorBgEEAYI3FAIDoBMMEWRhbmlicm93bkByaW0ubmV0gRNkYnJvd25AY2VydGljb20u Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQC6hxWgDv96DUDS3m8XfyVGAv1CKOcWSVOShz/jofFMFzoN o2dhc0Jg9XTTZBVS+ozakEM+87YUENfP3IODRbCiJBsbiXJxS+fVo7L/bqPp47TB+Lg2/tezlNa2 ab4psmc9xjZGU9+A4lBzS5PpRjvHofsIwETpwt/aPxHIbJ5Cf7kBi7B8hR4mIqc7EJMYXeI0xHLg k3NqBYSGC3XtbykuFV0vPFoTYLO7G3pAP2RzGhuxQoaH4fpWvE3rdakjd1MZFqJrarXSvWi6ah6G Alt7+sOTzlGNqoTQqb55VZEOrU2A1VbmAFjiFR1/229A2KaHhnN6cuNe8bhzoBcnuxtyMIIGvzCC BKegAwIBAgIQMhrzkrEUWZRNTS+VEbN74TANBgkqhkiG9w0BAQUFADBPMRUwEwYKCZImiZPyLGQB GRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBN Q0EwMVlLRjAeFw0wNjEwMTMwMTI0NTVaFw0xNjEwMTMwMTMwNDFaME8xFTATBgoJkiaJk/IsZAEZ FgVsb2NhbDEXMBUGCgmSJomT8ixkARkWB3dpbmRvd3MxHTAbBgNVBAMTFFJJTSBSb290IENBIE1D QTAxWUtGMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAxui6zvytVAEtPzv6NhK7OZna iw/jQEyEVskDf5yzcFkLT/+5PztIbv+eFmL1CP2FhvLv8eQZJDKF4Yv+UsjPEN1lX4DDGKKt0NPp yT9pwQzFaiUt0rnERgSabo7EtpS4S+DuL8G9c+lmWwDqb0UWtPMdVfbr3fDwigyz1yh+vVMAHdhg Oe9lPC6nPtiJ9IXTam7V5mJmDT0mNpq/0fJo3JEaNvDKoXBOkKv6IdbtKxKzPInG6VYaCdgJCAT3 mWgr9kxiEQEUJKrvI2fXI0zRYnlL648gvK84pdsT2xZLFtr4OdZAm4RkK8U+cgurlSCr6NVqnfbq 6/3N6MGmyc9SB2Ayhk2VS66757V4nBzeaeD+srpk4IXU3NTM/+YgR1zVS41XwvZaq9Uf59j0TJhN 9xGVZO871eVVr2VfNxr0xOqUpwcxh5JZYkWcmUJFlYiQh0CM2PrfaDRTTqRZQd4F3xUlcXFAXOGh vaXKvikeI6/utnX6vCnDwMUxmenzlv8epNatxDsuIgOWO4pfqgGMyzWo2hudQ97+5ynUqDLX34nr UzszGeIE3KoqYsksxMF3tqIgadt9hNWXaP/EknZpRAmaP0s0V5ZvgiyXw9UrqnWwmRbLQk7HnYc0 hHQBjXoByKSiOyhgSS9yL6a+7AA2rhBPpsSVI9LYBs2cNKlPsZcCAwEAAaOCAZUwggGRMBMGCSsG AQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTW aYJkJBbBzCTb8RR9RxJ83MlN7jCCASkGA1UdHwSCASAwggEcMIIBGKCCARSgggEQhoHEbGRhcDov Ly9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1NQ0EwMVlLRixDTj1DRFAsQ049UHVi bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5k b3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1j UkxEaXN0cmlidXRpb25Qb2ludIZHaHR0cDovL21jYTAxeWtmLndpbmRvd3MubG9jYWwvQ2VydEVu cm9sbC9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwDQYJ KoZIhvcNAQEFBQADggIBAEOeWFu4OVTnx9+jYk92iDra2f1Bc5j1WesEGINl4VCY9WJy6n17b/h2 fDmjj9KfIto3LE2Wej77lSJqv/LSd7wnfTQVZVb1wBe2Zt+LuPAqi6vWSDAQVOfdOMYVu5imznnf +ZNMLduTqXZ/bFQKTWsg2qhBWwaiYfxEY7nVg3+ZfStqwc9R3v/tHH+b9kX3FuKLoVQ6KSrqUyBi fhIRj57eOw6/JjPA+SId/p2yEZ+xmANQ31vE3BHFRm20kZHHqAfdCmTt1S7LDSLHBj3GZXIFUge9 aPKqzAXee2DCYTP3YYcgrP/FbFF2RqGRIhPM+MdjJraMjex+nNT+2KC/EIWsbU9DgFII0wHKpRx8 rlJNN8kmb/H9qGqcNaW9Q/pwUTpX1bXSdbzvYFs3NY7KmYYii4Q0RQCGr96OvDT0/S6/IrnW+vqZ jnPV2MXqEuyQ0L5HXVOnCi769uGYcRkEo5xzEJ/EMvj07vCWnG7h9ykNhLEEMcygVmBdXP9qOqog dyPJB0AzxAYGqCSMT8Ors1M/srZSXUCfSfENH5iBd7bxH7uXmF7kbOEghom7AccC2Clt4DU0tj9s FyIWg5H6zy6NLetm2/kzdD3mGY3u2tWtijVnd2CWY2YszYo1lbDAfEfjGL/9uFpH79Zt9ekRSD5Z bSn1SNr1njjeGpV3jwyuMIIHRjCCBS6gAwIBAgIKFnKQQQAAAAABuDANBgkqhkiG9w0BAQUFADBP MRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQD ExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjAeFw0xMjA1MTcwMDEzMzNaFw0xNDA1MTcwMDIzMzNaMFAx EzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBT dWJvcmRpbmF0ZSBDQSBNQ0EwM1lLRjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfx jFzEuYa/qd6dXu4HILtBdH3+Bgwz3uQakDcxvrf3fyVQBy69KFOS8/h5REe6bit3tp5wsQQv/nFV mmXK/jq9zD72zl3jv63UzZgOWC90846UxTTmmNEyHzo1M54B3LrnE6L2Q6QbEZMAnrJ96uV8pN2X Zsn5j+MvfI5ajFu+6oPbHeYzQjZB3GDju7sELm7cAcr0YYX3xeLTB2rLUUZF6Nyyc0btD57ARYEa 99A+6JslO8VcxtlgRddx17NB6gttNjwmJFT3l3UVcK5O5+UVSWpW1zQbZQBvl0iP7gXcrJW4Dv0p 036iHg9lgDV1qQChi9NCixwm7yYtCHLq9akCAwEAAaOCAyEwggMdMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFLgwF25vZ5X+hYxoO6XhF7M/+CU6MAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEE AwIBAzAjBgkrBgEEAYI3FQIEFgQUZUBVml3ak56Kwnbul6AULvNdck8wGQYJKwYBBAGCNxQCBAwe CgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNVHR8EggEg MIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Ys Q049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRp b25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6Ly9tY2Ew MXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Yu Y3JsMIIBPAYIKwYBBQUHAQEEggEuMIIBKjCBuwYIKwYBBQUHMAKGga5sZGFwOi8vL0NOPVJJTSUy MFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRvd3MsREM9bG9jYWw/Y0FDZXJ0aWZp Y2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwagYIKwYBBQUHMAKG Xmh0dHA6Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvTUNBMDFZS0Yud2luZG93 cy5sb2NhbF9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcnQwDQYJKoZIhvcNAQEFBQADggIB AK/ZTtcAxFAZJo37z0KG3EGIGIScPRus90jBJGQO9+Mrb4QRoMjkCwZP9GbYq2CxCqOBiKOZfkSK PMSupPLRlE70z9tGbsMz13ExQy50WZS9n4XRxglyDRga1fQVwGNF+SMPaBzQapiFi3CkBWNSdz+f aRdkdiqIvG3hxkbk6AXr6xhlu2mvnhJ/dE248lZDmN3FkWDHXEgEd5uHxwd7nWjxXVuzRV0oNgrG E96uTqLHVsdefHplPwyrIlgV4SY1ST1y8nKhZlB4IX8fDIj1Xr3rRssW+8XEKSILvawoU47n34x6 xZrO8nbramu3s3BPDnPBe5d1akBYA/nTKb9l6by6dNzJ7u1r73w7/tC53Hgf+826w6Gw+Z6Xs1d2 6RvukJ+7VCyKTR+rg+jASrfhS7naerxVMoOZwr6GxqqHYbK1gp3ag8Ek1U62/LYLqbvYMn58e23k q1pR6vLfQY4AhteMJipLmkxioYjHMCm9rTCZCnU2e/yvNNGXXq8WEeJpAc7hXbFR8L7VTaawkSxg jtJ2YTLvGH0cM/lEOAn3UGUG1lAhBBBzpLS4oW+ITZ5LsPWx2UiWAHLF79XE+PzvFE1+haf4HzJ0 KNKizMaj6DyVJN/oLOvdlVn32x70hCkr9zPFM6f4wEtQoY+qV3Q13zB7FePumyia5+/xmioObwts MYICrjCCAqoCAQEwXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmlt MSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwCQYFKw4D AhoFAKCCAaYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMDE4 MTg0MjE1WjAjBgkqhkiG9w0BCQQxFgQUQm8lRtGOB4Bo3gJ/AIobcXti0CYwZwYJKoZIhvcNAQkP MVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwbQYJKwYBBAGCNxAEMWAwXjBQMRMw EQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vi b3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwbwYLKoZIhvcNAQkQAgsxYKBeMFAxEzAR BgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBTdWJv cmRpbmF0ZSBDQSBNQ0EwM1lLRgIKF9gJ6QADABfFMjANBgkqhkiG9w0BAQEFAASBgK3ntiFKV2jK CG1mWlrtZyrhIye7iYnUxjFsBpDf8531gn06blyFbk5kEAY3OAsq+BPwQBNyl1IxKTrYZqnhXVpk 1eeFzpMPAsWZKEg4YK1v5aaecJ8+R6dng7PIOUaj+dk+Xy/pijiR8n0xOddvI5hLxlF6/7PZQGO0 Lwr1YzUaAAAAAAAA ------=_NextPart_000_0020_01CECC10.3CE92B20-- --===============1062121819== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. --===============1062121819==-- From nico@cryptonector.com Fri Oct 18 13:28:25 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D1811E81E8 for ; Fri, 18 Oct 2013 13:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58bwqyHC0G45 for ; Fri, 18 Oct 2013 13:28:20 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2AC11E8191 for ; Fri, 18 Oct 2013 13:28:19 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id BF8ACB8058 for ; Fri, 18 Oct 2013 13:28:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=QQhrrCq2aBbUZ3q1MxCX OwC2Fds=; b=PkiPdUNYwGOO/FgmqZwedlqWgIlrxlFRYAoA/PQGGkL5huDpYaTK gQ3q412gY9J27yMtwl0ZTEXC+DWidWwpjV2HoCnGneO9k+n020Yss6eT1TBUudCA R7w2szO/31xFiPiRwxKbIcR63rdrhH2Z5WlY+tJTZRuljpW1ib/rnCM= Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 5065AB800A for ; Fri, 18 Oct 2013 13:28:18 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id u57so4327706wes.29 for ; Fri, 18 Oct 2013 13:28:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qS8crz5vVs1HJxRf8w3I/uzuQySp3MH1ICNK+ULYUzM=; b=XskK3tTdcTvrkfbhpqzHK0ChVrWop9YnvigoTXqiybjja3Ll16dWtFM/ebD4o+Kf1M /hLjOPA4ATkEIPnx7eyQkQ+TbXRCUlJhKK8bYU6ELyyLVW5Yd6InCAAbf6b8+/zG/NFb hwmilFNLseWx7lbEWwmvqrKlM8OMK1SR2oUHTD42xOJ2sIZEgKUnPaN/QG8/e3Tdhdk9 8QWnXn0bIquxl1Rr3h6dzit6FJFTnDbPr/Us9PELc3wiD4t7SuAMSZT8+/vs57diu2wA rZDwbQ3BdTtVNB4THLMxzLhGDZAkpt6EzfQ/yQjoQQQ8yOtr6em1xLhjECKE8OjBjCgJ uoag== MIME-Version: 1.0 X-Received: by 10.194.81.135 with SMTP id a7mr3320147wjy.56.1382128096464; Fri, 18 Oct 2013 13:28:16 -0700 (PDT) Received: by 10.216.151.136 with HTTP; Fri, 18 Oct 2013 13:28:16 -0700 (PDT) In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5BEDD49@XMB117CNC.rim.net> References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> <20130926152757.15842.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDB49B@XMB116CNC.rim.net> <20130928223648.1113.qmail@cr.yp.to> <20130929025714.5578895.47771.4422@certicom.com> <20131001143511.11010.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE21E@XMB116CNC.rim.net> <20131002161944.8125.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDE90F@XMB116CNC.rim.net> <20131003010455.17185.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDECA6@XMB116CNC.rim.net> <20131005192950.27059.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BE4A9D@XMB116CNC.rim.net> <20131012003058.669.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BEBAA5@XMB117CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF5BEC2EC@XMB117CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF5BEDA76@XMB117CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF5BEDD49@XMB117CNC.rim.net> Date: Fri, 18 Oct 2013 15:28:16 -0500 Message-ID: From: Nico Williams To: Dan Brown Content-Type: text/plain; charset=UTF-8 Cc: "djb@cr.yp.to" , "tls@ietf.org" Subject: Re: [TLS] Safe ECC usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 20:28:25 -0000 On Fri, Oct 18, 2013 at 1:42 PM, Dan Brown wrote: > Nico Williams wrote: >> Dan Brown wrote: >> > Nico Williams wrote: >> >> Random attacks are the reason to want rigid curve selection processes. > > Yes, good point and sentence. > > Special attacks are the reason to want random curve selection. But then you need to construct a random curve selection process that everyone will be able to believe [years later!] was not manipulated. That's very difficult. Even if we eliminate the unreasonably paranoid from "everyone". And then what if the selected curves don't perform well? Pick the next closest well-performing curve? How would such a procedure affect the trustworthiness of the selection process? At least with DJB's curves I only need to worry that DJB (et. al.) has knowledge about cryptanalysis on said curves that he (they) are not sharing, that DJB is mounting an attack on us. You worry about special attacks that are not known to the public nor DJB, but to me that's the same as "random", and all I care about is that the curve authors not have known about them a priori, because then we can reason (with no data, granted, so it's all hand waving) about the density of such attacks in the neighborhood of the curves in question. >> We can look at things other than the constants in curve25519 (and curve >> 1174, and curve3617) -- the class(es) of curve(s) that it (they) fits.. >> separately from the curve selection criteria. How do we mitigate >> unknown weaknesses in each curve class? The only thing I know is: >> algorithm agility. > > In addition to algorithm agility, random curve selection mitigates unknown > weaknesses, e.g. Brainpool or P256 (but only if you trust its creator). But since Dual_EC, we don't trust P256's creators. That's a key reason for this entire discussion. > Hmm, maybe, I am missing your point about "curve class". s/class/family/. > I believe that, elsewhere in this thread, I said algorithm agility would be a > very good reason for including Curve25519, in addition to Brainpool. OK, good. > Algorithm agility, though, does not help much, in general, against untold > attacks (mainly helping against newly announced attacks). Unless you also have enough diversity of algorithms to begin with. That's why a number of algorithms would have to be required to implement (quite a few, actually, considering your doubts anyways, and assuming we can't get good consensus on just two; you might have doubts about just two different algorithms). > In particular, we don't want to TLS to become laissez-faire roll any algorithm > you want, i.e. the ultimate in algorithm agility? At some point, TLS > considers the evidence and picks a few good algorithms, right? The choice > governing this selection of each algorithm is not primarily algorithm agility. But it should be -- it should be about ability to survive cryptanalytic advances. We've experienced this w.r.t. chained IV CBC cipher modes in SSHv2, for example, where having deployed counter modes saved our collective bacon once. > For example, AES was chosen for inclusion in TLS, not because of algorithm > agility but because of the extensive analysis it underwent. TLS did not, and > still does not, adopt every single newly proposed algorithm in the name of > algorithm agility. So, something other than algorithm agility seems to be > protecting TLS. I understand this. And given the time we've had to cryptanalyze AES maybe we feel really good about it, so maybe we don't need so many symmetric ciphers. But your arguments, assuming they carry the day, argue for having several key exchange and signature algorithms -- I don't see how else to interpret what you're saying. > Also, separately from but similary to algorithm agility, algorithm X is not > usually adopted in TLS just on the grounds that we know of no attack, else > each new proposal would be adopted. So, it is inconsistent to consider only > about known attacks. TLS has to consider what evidence there is against > unknown attacks. There's only so much we can do about unknown attacks. Algorithm agility + lots of algorithms (each from a different family). > - random curves have slightly more assurance than special > - if the threat against P256 is serious, then we had better seriously consider > non-ECC You lost me with the second point. As to the first, the problem is that assurance for random selection is difficult -- aside from that I'd agree. > The evidence set for the two points is similar, which may cause me to look > like an arguing for one point, when I am trying to argue the other. > > Put another way, what's the point in comparing curves to each other, if we > believe there's a bigger problem of ECC being busted. Yes, we need non-ECC algorithms too, well, at least for as long as they are practical (i.e., RSA with 16KB keys are not). But anyways, we also need ECC because of its performance benefits. At least until quantum computers become sufficiently powerful that we have to drop this entire field of cryptography anyways. >> So at some point we have to pick something. At some point, in spite of >> uncertainty, we have to select some algorithm as the one we're going to >> rely on the most for authentication. Which would you rather use? > > Hmm, as an end user, I might go for the safest possible that can run on my > device. Well, OK, but we have a large diversity of devices and device capabilities. If we're going to wind down this thread with a conclusion, we should get more specific. > My own intuition: I think ECC is safe, and that in the very unlikely case of > any untold attacks, they will be at most similar in impact to MOVFR and SASS. OK, thanks. My own intuition is that DJB's curves are safe from as-yet unknown attacks. It's just intuition. > My advice: definitely don't worry about Brainpool. Don't worry about P256, > unless you view its creator as an adversary and you are somehow required to > use ECC, almost against your will, instead of some alternative like RSA or > integer DH. Consider Curve25519 mainly if you really want efficiency, or > don't trust the reliability of your implementation, and maybe also have dim > view on the security of ECC alternatives. DJB argues cogently that the NIST curves are not safe enough. I'm OK with Brainpool, but there are still significant advantages to DJB's curves. > TLS can safely adopt all these EC choices. > > At some point, though, TLS may not want to allow too many choices. Well, I think we're way past that point as to non-required to implement algorithms. The problem there is the cartesian product explosion of cipher suite IDs. As for required to implement algorithms, we're not. Nico -- From frantz@pwpconsult.com Sat Oct 19 00:02:05 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE9F11E8170 for ; Sat, 19 Oct 2013 00:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+EydLdvBKn3 for ; Sat, 19 Oct 2013 00:01:59 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5BB11E8164 for ; Sat, 19 Oct 2013 00:01:59 -0700 (PDT) Received: from [173.75.83.95] (helo=Williams-MacBook-Pro.local) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VXQXr-0005P6-TB; Sat, 19 Oct 2013 03:01:56 -0400 Date: Sat, 19 Oct 2013 00:01:55 -0700 From: Bill Frantz To: Nico Williams X-Priority: 3 In-Reply-To: Message-ID: 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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec791b834a56d7a00047ec2732b351683983350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.95 Cc: djb@cr.yp.to, tls@ietf.org Subject: Re: [TLS] Safe ECC usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 07:02:05 -0000 On 10/18/13 at 9:00 AM, nico@cryptonector.com (Nico Williams) wrote: >For ephemeral DH algorithm agility is relatively simple: require to >implement N different DH algorithms, make it easy to turn off any of >them if they get broken. > >For other ECC uses algorithm agility is much harder: it involves >re-keying. We could require that principals have N public keys (in >PKI cases, that all N certs have the same names and so on, issued by >the same issuer), so that it's possible to drop any one that gets >broken later. But even this, I think, may be too much to ask for. > >So at some point we have to pick something. At some point, in spite >of uncertainty, we have to select some algorithm as the one we're >going to rely on the most for authentication. Which would you rather >use? One possible solution is to use more than one algorithm. Having=20 two signatures, both of which must validate, is robust even if=20 one algorithm is compromised. Using two DH key agreements and=20 XORing the results protects against one of them be compromised. etc. This approach has costs. Some applications may be willing to pay=20 them and others not. But TLS has a lot of options and users can choose. Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | Re: Hardware Management Modes: | Periwinkle (408)356-8506 | If there's a mode, there's a | 16345=20 Englewood Ave www.pwpconsult.com | failure mode. - Jerry Leichter | Los Gatos,=20 CA 95032 From internet-drafts@ietf.org Sat Oct 19 00:33:24 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60EE511E8179; Sat, 19 Oct 2013 00:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnLGGO-0yV+K; Sat, 19 Oct 2013 00:33:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4339211E8181; Sat, 19 Oct 2013 00:33:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131019073320.9578.88742.idtracker@ietfa.amsl.com> Date: Sat, 19 Oct 2013 00:33:20 -0700 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-oob-pubkey-10.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 07:33:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Layer Security Working Group of= the IETF. Title : Using Raw Public Keys in Transport Layer Security (TLS) = and Datagram Transport Layer Security (DTLS) Author(s) : Paul Wouters Hannes Tschofenig John Gilmore Samuel Weiler Tero Kivinen Filename : draft-ietf-tls-oob-pubkey-10.txt Pages : 16 Date : 2013-10-19 Abstract: This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) for use with out-of-band public key validation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-oob-pubkey There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-oob-pubkey-10 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hannes.tschofenig@gmx.net Sat Oct 19 00:39:03 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0FEA21F9FB3 for ; Sat, 19 Oct 2013 00:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaYxzHRJh80H for ; Sat, 19 Oct 2013 00:38:50 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 5607B21F9DC9 for ; Sat, 19 Oct 2013 00:38:47 -0700 (PDT) Received: from [172.16.254.200] ([80.92.116.76]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LlGoc-1W7JdQ0JoU-00b53Z for ; Sat, 19 Oct 2013 09:38:46 +0200 Message-ID: <52623723.8090202@gmx.net> Date: Sat, 19 Oct 2013 09:39:15 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:1/Ne8bIl/lO27R+HqTU9zJEnQaREXnrCHrff+ORjMltD3GaENV9 mD3yzv9vQpqC7eeyse1G5P0ldoxXSimr77Qk0O8HPD2GBosYc0gLijootNqV8/vgtOSXcOS gTlNbMtID/EVS/CxGJSY2jeLymclBiuzOxppV1waZP1i/Jrb6SYKOMNOHVrnn7O7SBotyQz d+3PMWfAa5rNRNyK5VFUA== Subject: [TLS] draft-ietf-tls-oob-pubkey-10 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 07:39:04 -0000 Hi all, I have just uploaded version -10 of draft-ietf-tls-oob-pubkey: http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-10 With this update I have incorporated feedback received from various directorates. There were a couple of good suggestions to improve readability. While the diff shows a fair number of changes in the document they are mostly caused by re-arranging text within sections. Ciao Hannes From pgut001@cs.auckland.ac.nz Sat Oct 19 03:51:30 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61FE11E819F for ; Sat, 19 Oct 2013 03:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWBSZhkGkKsK for ; Sat, 19 Oct 2013 03:51:21 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 258F611E8164 for ; Sat, 19 Oct 2013 03:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1382179879; x=1413715879; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=DS5RTuw78EKKAK4Rn2vJLM/yORdH74pEtEw5fbUD4fg=; b=AwY/a+7evHrmOdu9vELcvLa8SMVVRYnJoIsBUroIKGazK3qmJzKbGbGh G4h5U+DYR7hx3Rsa2y3JSb0CFPYdb9zhdU3uLMW9bNMIFjkY7S/5vtjh2 rjFW4h9vOp7Fx9CK4oR/LjiIE7hUmmAqi8V0Nod9NHm89XZjD5PSD0J6m c=; X-IronPort-AV: E=Sophos;i="4.93,528,1378814400"; d="scan'208";a="218317725" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 19 Oct 2013 23:51:04 +1300 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.152]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.03.0158.001; Sat, 19 Oct 2013 23:51:04 +1300 From: Peter Gutmann To: "" , Paul Bakker Thread-Topic: [TLS] Using Brainpool curves in TLS Thread-Index: Ac7MuRrcCntznbKaQWC508EekXIjdw== Date: Sat, 19 Oct 2013 10:51:03 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C735568E7D4@uxcn10-6.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Using Brainpool curves in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2013 10:51:30 -0000 Paul Bakker writes:=0A= > For now I've just put up a test server at:=0A= > 141.138.204.107:4433=0A= >=0A= > Running PolarSSL 1.3.1 with Brainpool curves supported..=0A= =0A= Works fine with cryptlib.=0A= =0A= Just out of interest, how many other implementations noticed the major and= =0A= minor security issue when connecting to this server? Curious to see how mu= ch=0A= checking gets done...=0A= =0A= Peter.=0A= From balfanz@google.com Mon Oct 21 16:13:05 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFD011E867B for ; Mon, 21 Oct 2013 16:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.311 X-Spam-Level: X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0zycYg4XFZl for ; Mon, 21 Oct 2013 16:13:03 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 808BC11E86F3 for ; Mon, 21 Oct 2013 16:12:58 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id to1so461855ieb.23 for ; Mon, 21 Oct 2013 16:12:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4DhMS2g+YZafkX3eCGMIfkjW+6l4pjWmMpZOheM5wkQ=; b=DfSQBq1adbWts+H3NHQRby2tYrfytAyh64y5NYiK4N5BDsth5tVp26fVtJAFZ42qCG DWHCibSugmPpa+kAQpEg7wMO9/WFGoKbwjFVUJONnyX/89nH715wXdT71EoBMDCrDeH2 vlC/ItWfsKyKTgBEQ6lE/V+XaI61ALveCyaQzFdTlldO1cPtXCNrrXHePDeYd1w4OSl7 nhiQQ+3d7xgrnnvvR2GtB9U5ui/I4oql6PQmAgke/vU3K80inHRX1/9LhWAhqDPadh0q qu0zDDODscip+TCNNvNnvD8eXTSJ3Dl+k8R13yBF6OR4akrvW3e96rBr6QRQ9lrGNzfa tuGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4DhMS2g+YZafkX3eCGMIfkjW+6l4pjWmMpZOheM5wkQ=; b=aiph9MehbRcUnoy/Y8s2pN/BbzQVO5mgKdkMkrAr5tCsPZImVVdA2YCNyPyQzHbI51 R5WkHK+yiqf5+Ja6MSoPOrEXO3fniakGymyhrXc+z2eWcl2MdY9YRpj9XyJuGT2dSvar wSbIji4hbgdp/HJttT0wnHQ6JD1Q01LUc1GuIZYPuVoS1Yyx4zN1CfmYSlBotQk1zT0Y DZer0mjWxeEk3skRaKvSyQ8G4BWwRapQnM9mrsJg3UIwdV2fMzjxAi34aPfHbKPq2kS1 VP2kxKQ+93Tnfa7rHXJUle+t+y6edH5z4Qnl5n25EAHa2ublu5k+lFNMqcpGeK42DbvW 5aqQ== X-Gm-Message-State: ALoCoQkrXunmbMeYN8/QhTimoIt0qdAcobGWTW8ASgLjuTc+oWtaX0LGvKq4W6YRLSxAp6o+yHb/GqV/oevz2ksVD05GQq9dxlAtwtXl1DxPyD3eVak+f/JcZ8Hxhd0SMswHXuffQJ698/3qLIkqNtWhObFMIaMQoK4VhvA8cHnXw7t3pkbH0dEnoeLn+K5f7kJsqJhw5cXf MIME-Version: 1.0 X-Received: by 10.43.158.10 with SMTP id ls10mr395422icc.20.1382397177840; Mon, 21 Oct 2013 16:12:57 -0700 (PDT) Received: by 10.64.61.166 with HTTP; Mon, 21 Oct 2013 16:12:57 -0700 (PDT) In-Reply-To: <526123A7.5050305@gmx.net> References: <526123A7.5050305@gmx.net> Date: Mon, 21 Oct 2013 16:12:57 -0700 Message-ID: From: Dirk Balfanz To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a11c1ead6b9843304e9486c30 Cc: IETF TLS WG Subject: Re: [TLS] channel id and oob X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 23:13:05 -0000 --001a11c1ead6b9843304e9486c30 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 18, 2013 at 5:03 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi Dirk, > > thanks for looking at the two specifications. A few remarks below: > > > On 08/02/2013 12:10 PM, Dirk Balfanz wrote: > >> Hi guys, >> >> I was asked to write a quick analysis of draft-ietf-tls-oob-pubkey, and >> whether it can be applied to the use cases we have in mind for Channel ID. >> >> My conclusion is that it can not, or that the necessary modifications to >> the OOB draft would be too substantial to be considered during Last Call. >> >> First, the similarities: both proposals allow the client to prove >> possession of a key pair. The fact that this proof-of-possession is >> forthcoming is negotiated using the TLS extension mechanism (during >> ClientHello/ServerHello). >> >> Now for the differences: >> >> * We don't want the client public key to be sent in the clear. It's a >> >> client identifier, and shouldn't be known to anyone but the client >> and the server. >> > > This is an aspect the group agreed to solve via a separate extension, if I > remember it correctly since it has wider applicability than just for these > documents. > > Recalling Ekr's presentation about TLS 1.3 from the last IETF meeting he > mentioned that this would be one of the features of the new version. Right. Which is why my take-away was that ChannelID won't be seriously considered until TLS 1.3. > Whether it is useful to define an extension that can be used with TLS > 1.1/1.2 is a decision the ADs and chairs need to make. > > > >> * We don't want the proof-of-keypair-possession to be part of the >> session state, >> > > > I am not entirely sure what you mean by "proof-of-keypair-possession to be > part of the session state". > When your TLS terminators resume a session with a client - what do those terminators tell their backends about the session? If the client proved possession of a private key/certificate during the original handshake, so terminators not tell their backends about that key on a resumed session? For ChannelID, we explicitly _don't_ want them to do that. > > for two reasons: > >> o It blows up the session state, with ramifications on the size of >> >> the fleet of servers that cache this information. >> Remember that >> in our use case, we don't intend this to be used for the >> occasional client that wants to use non-password authentication >> with the server; it's designed to be used by _every_ client >> talking to big service providers like Google. Raw public keys >> are of course smaller than full certificates, but they still >> represent a significant increase in the size of session state. >> > > > The document does not require servers to store the received raw public key. > > > o We don't want someone who is not actually wielding the private >> >> key of the keypair to make it appear to the server as if they >> were in control of that private key. Session resumption, >> however, gives you that power: Let's assume that the private key >> of the keypair sits in a hardware-protected secure element, and >> is therefore out of reach of malware. Master secrets and other >> session information, however, is very likely kept in RAM and >> therefore available to thieves. If such a thief extracts the >> session data from the client and resumes the session, the server >> will treat the thief as the holder of the original private key. >> If the proof-of-keypair possession is explicitly declared not >> part of the session, then a client has to re-prove possession of >> the keypair even during abbreviated handshakes. Thus, a thief of >> session secrets (but not of the private key) won't be able to >> convince a server that it is in control of that private key. >> > > You don't have to use session resumption if you do not want. > But I do want to use session resumption! It's saves bits during the handshake. :-) > I also consider the threat a bit unrealistic. If you assume that the end > device is compromised then what prevents the malware from obtaining the > private key before it gets into the hardware-protected secure element. The key could have been created inside the secure element to begin with. > I believe in your scenario you are not talking about a long-term ephemeral > key pair but rather something that is dynamically created on the end device > or dynamically provisioned. > > >> The oob-draft keeps the raw key in the session state, thus >> inheriting this problem with session state and session resumption. >> > > We actually don't say anything about keeping the key in session state nor > about session resumption. I consider those aspects implementation and > configuration issues. > That's interesting. I was looking for the part in the TLS spec that says "thou shall make client certs part of the session state", and indeed couldn't find it. But in practice, of course that is what people are doing, right? If your TLS terminators didn't make a client cert part of the session state, how could you ever resume a session with them and still be considered authenticated with that client cert? > > > >> * Channel ID keys are different from key material sent in the >> >> Certificate message, and the certificate message shouldn't be >> overloaded with this new semantics: Key material presented in the >> Certificate message (even if it's a raw key) presumably carries some >> semantics for the application: "this is a certain user", "this is an >> enterprise-issued machine", etc., while the Channel-ID keys are >> always self-generated and their semantics include (among other >> things) "this is the key that will be nuked when the user presses >> the 'reset my browsing state' button". It makes for tricky >> implementations when those two different semantics get mapped to the >> same protocol message. More importantly, applications may want to do >> both: authenticate a user with a client cert, and then set a >> channel-bound cookie as a result of the authentication. You can't do >> that if you only have one proof-of-possession available in the >> handshake. >> > > With the raw public key we actually do not say what identity the key > refers to. > Right - of course not; that kind of stuff doesn't belong in the spec. But in practice these keys are used for something, and if I want to keep doing that something, while at the same time do something else (provide key material to which upper-layer credentials such as cookies can be bound), then using the same message for those two somethings won't work. > You are correct that there is an issue if we want to provide two layers of > authentication within TLS and I am not sure whether that is even in scope > of your document either since it is not discussed. > > > > >> As mentioned above, I don't really see how this issues could possibly be >> addressed within the draft-ietf-tls-oob-pubkey draft, especially since >> it's in last-call. Just the first point above alone seemed to be >> something that folks didn't want to touch until TLS 1.3. >> >> Thoughts? >> > > What we could do is the following: > > > a) Brainstorm whether we see the two layers of authentication as a valid > use case. I don't think we both do but maybe someone else does. > Let me address this by starting at the application layer: Let's say we want a feature in which browsers authenticate themselves to servers. This should happen transparently so that users aren't bothered by it, but it shouldn't be so transparent that the user can't change the key material if/when they want to. So we build this feature into the browser, including all the UI, and now we're looking for a message in the TLS layer to put that proof of key possession. The ClientCertificate message immediately comes to mind. So we'll build our network stack so that the keys (that can be reset by the user, but will be generated and selected transparently) will be used by the ClientCertificate message. Now someone else wants a different application-layer feature: they want CAs to be able to issue user certificates, users to be able to install them, explicitly select among them when connecting to a server. Again, the ClientCertificate message seems like a natural vessel for the proof-of-key possession that comes with this feature. So now, when we build the network stack, it looks like the keys used in the ClientCertificate message should be those installed by user when the receive a certificate from a CA, etc. It's not so much that I want to do ChannelID and TLS Client Auth _at the same time_, it's that the ClientCertificate message, and the logic around it, becomes quite messy if it needs to serve these two different user cases - perhaps not at the TLS layer itself (maybe that one is just given a key pair), but someone somewhere will have to decide which keys we're using - the self-generated transparent ones or the CA-certified ones. The same is true at the server side. You guys may remember that the first iteration of this ("TLS-OBC") in fact re-used the ClientCertificate message. When we realized that we were about to turn on essentially TLS Client Auth for a substantial fraction of the clients out there, we had to go inside the network stack on the server and put some logic in there that said: "if the ClientCertificate message carries one of those transparent keys that the user can reset whenever they want, do one thing; and if it carries one of those keys that are certified by a CA, do something else", which started to become quite messy. We think it's easier to have two different messages for these. > > b) We work on a specification that provides the confidentiality protection > of information exchanged by the client. This could be useful in a number of > cases, even work that is currently ongoing in the TLS working group right > now. > I think there have been a couple of attempts in this direction, and the consensus seems to be that we'll do this in TLS 1.3. > c) We clarify the issues regarding the session state. I did not occur to > me that this would be something to write about in the document but maybe it > is worthwhile to have a discussion about it. > Yeah, I'm a bit confused about this. I was a bit surprised to not find more explicit mention of what it means to resume a session in the TLS spec. Clearly, a resumed session (from the server's point of view) means "the guy on the other end knows the same master secret as I do". But in practice it also means "the guy on the other side wields the private key corresponding to this certain public key", if that's what was proven during the initial handshake. If that's something that implementations simply assume without it being called out in the spec, maybe that's something that we should think about some more. Dirk. > > > Ciao > Hannes > > >> Dirk. >> >> >> >> ______________________________**_________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/**listinfo/tls >> >> > --001a11c1ead6b9843304e9486c30 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Oct 18, 2013 at 5:03 AM, Hannes Tschofenig <hannes= .tschofenig@gmx.net> wrote:
Hi Dirk,

thanks for looking at the two specifications. A few remarks below:


On 08/02/2013 12:10 PM, Dirk Balfanz wrote:
Hi guys,

I was asked to write a quick analysis of draft-ietf-tls-oob-pubkey, and
whether it can be applied to the use cases we have in mind for Channel ID.<= br>
My conclusion is that it can not, or that the necessary modifications to the OOB draft would be too substantial to be considered during Last Call.
First, the similarities: both proposals allow the client to prove
possession of a key pair. The fact that this proof-of-possession is
forthcoming is negotiated using the TLS extension mechanism (during
ClientHello/ServerHello).

Now for the differences:

=A0 * We don't want the client public key to be sent in the clear. It&#= 39;s a

=A0 =A0 client identifier, and shouldn't be known to anyone but the cli= ent
=A0 =A0 and the server.

This is an aspect the group agreed to solve via a separate extension, if I = remember it correctly since it has wider applicability than just for these = documents.

Recalling Ekr's presentation about TLS 1.3 from the last IETF meeting h= e mentioned that this would be one of the features of the new version.

Right. Which is why my take-away was that Chann= elID won't be seriously considered until TLS 1.3.
=A0
Whether it is useful to define an extension= that can be used with TLS 1.1/1.2 is a decision the ADs and chairs need to= make.



=A0 * We don't want the proof-of-keypair-possession to be part of the =A0 =A0 session state,


I am not entirely sure what you mean by "proof-of-keypair-possession t= o be part of the session state".

W= hen your TLS terminators resume a session with a client - what do those ter= minators tell their backends about the session? If the client proved posses= sion of a private key/certificate during the original handshake, so termina= tors not tell their backends about that key on a resumed session? For Chann= elID, we explicitly _don't_ want them to do that.=A0
=A0

=A0for two reasons:
=A0 =A0 =A0 o It blows up the session state, with ramifications on the size= of

=A0 =A0 =A0 =A0 the fleet of servers that cache this information.
Remember that
=A0 =A0 =A0 =A0 in our use case, we don't intend this to be used for th= e
=A0 =A0 =A0 =A0 occasional client that wants to use non-password authentica= tion
=A0 =A0 =A0 =A0 with the server; it's designed to be used by _every_ cl= ient
=A0 =A0 =A0 =A0 talking to big service providers like Google. Raw public ke= ys
=A0 =A0 =A0 =A0 are of course smaller than full certificates, but they stil= l
=A0 =A0 =A0 =A0 represent a significant increase in the size of session sta= te.


The document does not require servers to store the received raw public key.=


=A0 =A0 =A0 o We don't want someone who is not actually wielding the pr= ivate

=A0 =A0 =A0 =A0 key of the keypair to make it appear to the server as if th= ey
=A0 =A0 =A0 =A0 were in control of that private key. Session resumption, =A0 =A0 =A0 =A0 however, gives you that power: Let's assume that the pr= ivate key
=A0 =A0 =A0 =A0 of the keypair sits in a hardware-protected secure element,= and
=A0 =A0 =A0 =A0 is therefore out of reach of malware. Master secrets and ot= her
=A0 =A0 =A0 =A0 session information, however, is very likely kept in RAM an= d
=A0 =A0 =A0 =A0 therefore available to thieves. If such a thief extracts th= e
=A0 =A0 =A0 =A0 session data from the client and resumes the session, the s= erver
=A0 =A0 =A0 =A0 will treat the thief as the holder of the original private = key.
=A0 =A0 =A0 =A0 If the proof-of-keypair possession is explicitly declared n= ot
=A0 =A0 =A0 =A0 part of the session, then a client has to re-prove possessi= on of
=A0 =A0 =A0 =A0 the keypair even during abbreviated handshakes. Thus, a thi= ef of
=A0 =A0 =A0 =A0 session secrets (but not of the private key) won't be a= ble to
=A0 =A0 =A0 =A0 convince a server that it is in control of that private key= .

You don't have to use session resumption if you do not want.

But I do want to use session resumption! It's= saves bits during the handshake. :-)
=A0
I also consider the threat a bit unrealistic. If you assume that the end de= vice is compromised then what prevents the malware from obtaining the priva= te key before it gets into the hardware-protected secure element.

The key could have been created inside the secure eleme= nt to begin with.=A0
=A0
I believe in your scenario you are not talking about a long-term ephemeral= key pair but rather something that is dynamically created on the end devic= e or dynamically provisioned.


=A0 =A0 The oob-draft keeps the raw key in the session state, thus
=A0 =A0 inheriting this problem with session state and session resumption.<= br>

We actually don't say anything about keeping the key in session state n= or about session resumption. I consider those aspects implementation and co= nfiguration issues.

That's interest= ing. I was looking for the part in the TLS spec that says "thou shall = make client certs part of the session state", and indeed couldn't = find it. But in practice, of course that is what people are doing, right? I= f your TLS terminators didn't make a client cert part of the session st= ate, how could you ever resume a session with them and still be considered = authenticated with that client cert?

=A0



=A0 * Channel ID keys are different from key material sent in the

=A0 =A0 Certificate message, and the certificate message shouldn't be =A0 =A0 overloaded with this new semantics: Key material presented in the =A0 =A0 Certificate message (even if it's a raw key) presumably carries= some
=A0 =A0 semantics for the application: "this is a certain user", = "this is an
=A0 =A0 enterprise-issued machine", etc., while the Channel-ID keys ar= e
=A0 =A0 always self-generated and their semantics include (among other
=A0 =A0 things) "this is the key that will be nuked when the user pres= ses
=A0 =A0 the 'reset my browsing state' button". It makes for tr= icky
=A0 =A0 implementations when those two different semantics get mapped to th= e
=A0 =A0 same protocol message. More importantly, applications may want to d= o
=A0 =A0 both: authenticate a user with a client cert, and then set a
=A0 =A0 channel-bound cookie as a result of the authentication. You can'= ;t do
=A0 =A0 that if you only have one proof-of-possession available in the
=A0 =A0 handshake.

With the raw public key we actually do not say what identity the key refers= to.

Right - of course not; that kind o= f stuff doesn't belong in the spec. But in practice these keys are used= for something, and if I want to keep doing that something, while at the sa= me time do something else (provide key material to which upper-layer creden= tials such as cookies can be bound), then using the same message for those = two somethings won't work.
=A0
You are correct that there is an issue if we= want to provide two layers of authentication within TLS and I am not sure = whether that is even in scope of your document either since it is not discu= ssed.




As mentioned above, I don't really see how this issues could possibly b= e
addressed within the draft-ietf-tls-oob-pubkey draft, especially since
it's in last-call. Just the first point above alone seemed to be
something that folks didn't want to touch until TLS 1.3.

Thoughts?

What we could do is the following:


a) Brainstorm whether we see the two layers of authentication as a valid us= e case. I don't think we both do but maybe someone else does.

Let me address this by starting at the applicati= on layer: Let's say we want a feature in which browsers authenticate th= emselves to servers. This should happen transparently so that users aren= 9;t bothered by it, but it shouldn't be so transparent that the user ca= n't change the key material if/when they want to. So we build this feat= ure into the browser, including all the UI, and now we're looking for a= message in the TLS layer to put that proof of key possession. The ClientCe= rtificate message immediately comes to mind. So we'll build our network= stack so that the keys (that can be reset by the user, but will be generat= ed and selected transparently) will be used by the ClientCertificate messag= e.

Now someone else wants a different application-layer fe= ature: they want CAs to be able to issue user certificates, users to be abl= e to install them, explicitly select among them when connecting to a server= . Again, the ClientCertificate message seems like a natural vessel for the = proof-of-key possession that comes with this feature. So now, when we build= the network stack, it looks like the keys used in the ClientCertificate me= ssage should be those installed by user when the receive a certificate from= a CA, etc.

It's not so much that I want to do ChannelID and TL= S Client Auth _at the same time_, it's that the ClientCertificate messa= ge, and the logic around it, becomes quite messy if it needs to serve these= two different user cases - perhaps not at the TLS layer itself (maybe that= one is just given a key pair), but someone somewhere will have to decide w= hich keys we're using - the self-generated transparent ones or the CA-c= ertified ones.=A0

The same is true at the server side. You guys may remem= ber that the first iteration of this ("TLS-OBC") in fact re-used = the ClientCertificate message. When we realized that we were about to turn = on essentially TLS Client Auth for a substantial fraction of the clients ou= t there, we had to go inside the network stack on the server and put some l= ogic in there that said: "if the ClientCertificate message carries one= of those transparent keys that the user can reset whenever they want, do o= ne thing; and if it carries one of those keys that are certified by a CA, d= o something else", which started to become quite messy. We think it= 9;s easier to have two different messages for these.
=A0

b) We work on a specification that provides the confidentiality protection = of information exchanged by the client. This could be useful in a number of= cases, even work that is currently ongoing in the TLS working group right = now.

I think there have been a couple of attemp= ts in this direction, and the consensus seems to be that we'll do this = in TLS 1.3.
=A0
c) We clarify the issues regarding the session state. I did not occur to me= that this would be something to write about in the document but maybe it i= s worthwhile to have a discussion about it.

Yeah, I'm a bit confused about this. I was a bit surprised to not = find more explicit mention of what it means to resume a session in the TLS = spec. Clearly, a resumed session (from the server's point of view) mean= s "the guy on the other end knows the same master secret as I do"= . But in practice it also means "the guy on the other side wields the = private key corresponding to this certain public key", if that's w= hat was proven during the initial handshake. If that's something that i= mplementations simply assume without it being called out in the spec, maybe= that's something that we should think about some more.

Dirk.
=A0


Ciao
Hannes


Dirk.



_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls



--001a11c1ead6b9843304e9486c30-- From SRS0=g+Yl=T7=acm.org=bmoeller@srs.kundenserver.de Mon Oct 21 16:27:30 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9C811E82BB for ; Mon, 21 Oct 2013 16:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.626 X-Spam-Level: X-Spam-Status: No, score=-1.626 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6T4oDnmWXoid for ; Mon, 21 Oct 2013 16:27:24 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9DA11E827C for ; Mon, 21 Oct 2013 16:27:17 -0700 (PDT) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0M4PCy-1VvPPL3DNk-00yhvj; Tue, 22 Oct 2013 01:27:16 +0200 Received: by mail-ie0-f179.google.com with SMTP id aq17so368432iec.24 for ; Mon, 21 Oct 2013 16:27:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rnXRGiLFcMQ3GJjrjUirZp7fK06tkJoRio1T7SXNPr0=; b=WHdcgbZhjWiw38iyMr0Wu21bE+qiYN7PIJNToI49e40iJhDdu4lEeWThb45rIGNK/B ht8M3t/DDZtreh52Yc0E/xcT6TXvA8l4wydAZwLRf8uwCxrFXLeaLi1Zoh5O5D/wHUP+ Xb8chPyNxX4eCkZaRpMBsyQDY8j5WtgUiABXMvNWFNfFfiLLnEulhzf0HfOSAnpcTNX2 tAgbucZb/Lp1snofFS+tY1MnfQIv4rlth1WWQDZGMpGwxh+h3WtI6EEalvZz3+GMa9Ka nh9wg24Xi2gK5qgEwgRM968WFzSIPMdYJoCEjze8eQ+AgHZI+tnZGkNIs4kW01Sz7EYQ 1tPg== MIME-Version: 1.0 X-Received: by 10.50.109.132 with SMTP id hs4mr11301575igb.34.1382398034452; Mon, 21 Oct 2013 16:27:14 -0700 (PDT) Received: by 10.43.64.138 with HTTP; Mon, 21 Oct 2013 16:27:14 -0700 (PDT) In-Reply-To: References: <526123A7.5050305@gmx.net> Date: Mon, 21 Oct 2013 19:27:14 -0400 Message-ID: From: Bodo Moeller To: Dirk Balfanz Content-Type: multipart/alternative; boundary=089e013a1d90c82ff104e9489fbc X-Provags-ID: V02:K0:6KnPXFmrVWrFA48bhGwHPKn2wDleDYXR/UmoEmHM/3T AsCvCjU5lZmINiVDZ4AuajKVXhzUK22weoX0gsGtPOodmDfQUe qfFrmJxEmJr6xolxo9nDobf0hRQqmch+eEmzLT67KSFUutu5bd 6QAvJXkow7KwviqpFnelPrZoEXupezUv8twCwpjdU4URFXBYtX hEGt4RH39SCBq5TlX8DMr8UWIbpSXsO6QLEmST/SH2WrcO4fQk UGwNbvpJBOgSq4/Oxd2NAUoB050biM07ups5zt0wDY7W9XJyoF NycqYLXubb7/ACgF0nKGA5GAceIJErxqUm38xHDPK0E+b0HXnK R9E2u02vfjgrYlqmmrLzNHiB3WYzuE9srHLpRCxpiEdn/2T5eF YYm12rrmydvWoADcH9GC92yvQ7JWghDFJ8xE73NqaOtcPPFrHg u9Wm5 Cc: IETF TLS WG Subject: Re: [TLS] channel id and oob X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 23:28:16 -0000 --089e013a1d90c82ff104e9489fbc Content-Type: text/plain; charset=ISO-8859-1 > We actually don't say anything about keeping the key in session state nor >> about session resumption. I consider those aspects implementation and >> configuration issues. >> > > That's interesting. I was looking for the part in the TLS spec that says > "thou shall make client certs part of the session state", and indeed > couldn't find it. But in practice, of course that is what people are doing, > right? If your TLS terminators didn't make a client cert part of the > session state, how could you ever resume a session with them and still be > considered authenticated with that client cert? > In very basic usage of client certificates, a server might be configured to only ever allow authenticated clients with certificates from a particular CA to start sessions -- e.g., letting them access intranet content without having to know which particular client each access is coming from. In simple cases like that, there's no need to keep certificate details around in session state. --089e013a1d90c82ff104e9489fbc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

=
=
We actually don't say anything about keeping the key in session state n= or about session resumption. I consider those aspects implementation and co= nfiguration issues.

That's in= teresting. I was looking for the part in the TLS spec that says "thou = shall make client certs part of the session state", and indeed couldn&= #39;t find it. But in practice, of course that is what people are doing, ri= ght? If your TLS terminators didn't make a client cert part of the sess= ion state, how could you ever resume a session with them and still be consi= dered authenticated with that client cert?

In very basic usage of c= lient certificates, a server might be configured to only ever allow authent= icated clients with certificates from a particular CA to start sessions -- = e.g., letting them access intranet content without having to know which par= ticular client each access is coming from. =A0In simple cases like that, th= ere's no need to keep certificate details around in session state.



--089e013a1d90c82ff104e9489fbc-- From mrex@sap.com Mon Oct 21 17:28:55 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2CE711E87A3 for ; Mon, 21 Oct 2013 17:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.059 X-Spam-Level: X-Spam-Status: No, score=-10.059 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptGm8o5DjHBU for ; Mon, 21 Oct 2013 17:28:50 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 498FD11E85CE for ; Mon, 21 Oct 2013 17:28:40 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r9M0Sb7d025753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 22 Oct 2013 02:28:37 +0200 (MEST) In-Reply-To: To: Dirk Balfanz Date: Tue, 22 Oct 2013 02:28:36 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20131022002836.9CBCA1AA15@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: IETF TLS WG Subject: Re: [TLS] channel id and oob X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 00:28:55 -0000 Dirk Balfanz wrote: > > When your TLS terminators resume a session with a client - what do those > terminators tell their backends about the session? If the client proved > possession of a private key/certificate during the original handshake, so > terminators not tell their backends about that key on a resumed session? Reverse Proxies will normally forward the authenticated client cert PLUS any chain certificates that were received and successfully verified during the full handshake to the backend. Clients will normally also cache the Server certificate plus the entire chain in the client side session cache. Every reasonably portable and generic TLS protocol implementation is likely going to include that information in its SSL session cache. Applications may not necesserily know nor care whether the TLS handshake was a full handshake or abbreviated handshake (aka session resume). > > That's interesting. I was looking for the part in the TLS spec that says > "thou shall make client certs part of the session state", and indeed > couldn't find it. But in practice, of course that is what people are doing, > right? If your TLS terminators didn't make a client cert part of the > session state, how could you ever resume a session with them and still be > considered authenticated with that client cert? Session caching simply would not make any sense without caching most of the attributes that were successfully established or successfully negotiated during the full TLS handshake. I do not see a difference between the client caching the server's certificate chain and the server caching the client's certificate chain. > > Yeah, I'm a bit confused about this. I was a bit surprised to not find more > explicit mention of what it means to resume a session in the TLS spec. TLS is underspecified in a lot of places. You may remember the result of renegotiation being underspecified. A security problem that remained unnoticed for ~13 years. > > Clearly, a resumed session (from the server's point of view) means "the guy > on the other end knows the same master secret as I do". But in practice it > also means "the guy on the other side wields the private key corresponding > to this certain public key", if that's what was proven during the initial > handshake. Each peer only knows that the peer was able to perform a proof-of-posession during the full TLS handshake. It would be unwise to make any assumptions about the posession of a private key for any point in time, much less any later points in time, independent of whether the original TLS connection has been running for a few hours, or whether this is about a newly established TLS connection that has just been resumed from the TLS session cache, with the original TLS handshake a few hours in the past. The certificate path validation (in particular when revocation checking from remote information sources is performed) may be in the same ballpark that the full handshake crypto operations, so typically, there is not going to be a certificate path validation on session resume. -Martin From watsonbladd@gmail.com Mon Oct 21 18:11:19 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB30A11E81A4 for ; Mon, 21 Oct 2013 18:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GK2h7XAy5zK0 for ; Mon, 21 Oct 2013 18:11:19 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id A468011E82DE for ; Mon, 21 Oct 2013 18:11:14 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id b13so5317259wgh.4 for ; Mon, 21 Oct 2013 18:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=DQTHfppB3Ewlqhd0z+Hf86V56G448LP9VSvfVkCNsAE=; b=Fn+n3skg6qstHqw0ZVEyG02CwOLWo6x5halWGt1RRxk8v9zGQpkkk7Dy1T4wsE/6Ag WyLo7K6BX53xyaDUKGmXDROfN0j+3LlGTwgXNv0/ybjNnkTPeeajM4OJnADsgFMOxfu2 cjZCI5J2EUQBEE9OcUuH1s6pgno9KySEhkHAM8ZI7qwJuJCrtbw0YpNQFctpV07MUP/K H8Cbt5jLKAYSRFfG25m6DyuBJbaWMPm+Iyax90DVw4AYYPyNR8WFa8H+Ntry+G0FckC3 Ly6OrZKAwCO/ptstMV4dLnH9Vs3x1wRYSCuIz/3/vpgBOn1WhQdfFXriVBsVZae8Eq0S x/OQ== MIME-Version: 1.0 X-Received: by 10.180.72.237 with SMTP id g13mr12342387wiv.0.1382404273592; Mon, 21 Oct 2013 18:11:13 -0700 (PDT) Received: by 10.194.242.131 with HTTP; Mon, 21 Oct 2013 18:11:13 -0700 (PDT) Date: Mon, 21 Oct 2013 18:11:13 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: [TLS] Channel ID and server load: comment on draft-balfanz-tls-channelid-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 01:11:20 -0000 Channel ID requires 2 modular exponentiations every handshake on the server, even when sessions are resumed. The claimed argument for this necessity is that resumption tickets could get stolen from the client. Why could Channel ID identifiers not get stolen when the resumption tickets are? Is there a reasonable threat model in which a client so compromised as to lose resumption tickets has a meaningful benefit from Channel ID? Why P256 and ECDSA? These choices prevent batch verification on the server, increasing the workload significantly. They do not have major security advantages, or performance advantages over Ed25519. When browsers implement Channel ID, what separations between different websites are required? Cross-site request forgery has long been the bane of web authentication technologies: does Channel ID provide additional benefits here? Sincerely, Watson Ladd From agl@google.com Tue Oct 22 08:14:58 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C081611E84A4 for ; Tue, 22 Oct 2013 08:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dkTClbwlVka for ; Tue, 22 Oct 2013 08:14:57 -0700 (PDT) Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 964BF11E84D1 for ; Tue, 22 Oct 2013 08:14:56 -0700 (PDT) Received: by mail-vb0-f49.google.com with SMTP id w16so4985625vbb.8 for ; Tue, 22 Oct 2013 08:14:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZTjvIICRK3v+acIO1/+OW/AC+y0zC+utObm3fiiFFno=; b=I5SxuKr2WkHDFQsc5Pl2jQqkApnSnfoLLdc83bmNWdOvVM7hzRcBuazyO910fWHYys zaku0udVEIpMxc951JfSazHRYkg+/tKPwT64mwfYfRw1c4isCBcRboFT3lD7EflKDqv9 JiAL+TclZS0WW5O1KFlOQKB5a+F3ZcDDmkP6RV/MAmozKW2BnLxS2boqRx0mYU46hPYn TJaDA+klaYfMlj4ynEGJ6zHThkx9H6pdtZb194/YHxErJwP5qxuavlCKAf8MY3vAURQ0 U/ObWIS3lJlOWdg7Zeb6KB/GaaewmbRRV1+ivZlnwv6RgilyU6QLqggSCVjocZgTsELN ZAtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZTjvIICRK3v+acIO1/+OW/AC+y0zC+utObm3fiiFFno=; b=IlL5cCdnD857jcbTEsQRpb2IrfGh4e/nqn+CFBQtVknhcVFpYGnCKwxwmm2ZC7PbBs AEQxW/TP1o4T1Mcc2S/8/05pr6l2cALZrn1I+7dIvKysvFnr/qMF3Ye9E0xnpW5ZEAmM +JNiQa98Fqb68OYmYt+CC6IWiuuW0zppbFCuKJF6FhxpnWIXiZJTcwkQXCdsz5YCaK+z aR03sd5WuXkpoPm4xNyJhT85lkEsbsrRy56mLt5MZRKqMTmRpyhr3fd0XblyfTwPNeJM 5wtN/Qc695gb9HvetS0Hhj4BdA6D1F9HD7HBGBY+VRuCHF1Fb8Tnf1lDbCytCNFjlXKn Agbw== X-Gm-Message-State: ALoCoQm3I07XXeGMEp6+FveRPw0O9k4eksoJbRB9Gf2rWsHi80chT/0sso7CHElMvUK+fr91x5vSRiAE4lgCMn2U5axFoNbhMTHy1TAkcrpifcjEizE3vsTakiOX0jhHs2O+6Y1cvG/c7lLpUfPLKwj3DYjuP8DYhtpAonaJZupTq9YLNS9BqQ7WBKU76Rm4IwxMKpvlRbGt X-Received: by 10.52.164.102 with SMTP id yp6mr13348861vdb.14.1382454887583; Tue, 22 Oct 2013 08:14:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.100.40 with HTTP; Tue, 22 Oct 2013 08:14:27 -0700 (PDT) In-Reply-To: References: From: Adam Langley Date: Tue, 22 Oct 2013 11:14:27 -0400 Message-ID: To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Channel ID and server load: comment on draft-balfanz-tls-channelid-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 15:14:58 -0000 On Mon, Oct 21, 2013 at 9:11 PM, Watson Ladd wrote: > Why could Channel ID identifiers not get stolen when the resumption > tickets are? Is there a reasonable threat model in which a client so > compromised as to lose resumption tickets has a meaningful benefit > from Channel ID? Because ChannelIDs have a public and private part, the private part can be much better protected. For example, by moving it out of the browser process completely, even on standard machines, and even under hardware-protection, where such capability exists. > Why P256 and ECDSA? These choices prevent batch verification on the > server, increasing the workload significantly. They do not have major > security advantages, or performance advantages over Ed25519. Why can't one batch verify ECDSA signatures? The major issue with batch verification is latency: in order to build a batch one has to wait for enough ChannelID connections (64 for the batch speeds advertised for Ed25519) to be in the handshake stage. But for HTTPS, latency is very important and we can't delay connections for that long in normal processing. That's not to say that batch processing is useless in all situations, but it not always applicable. The goal of wanting to put the private key into hardware protection also motivated the choice of signing primitive since we get what we're given with hardware. I did come close to adding signature primitive negotiation to ChannelID recently but, due to bugs in old F5 firmwares, we cannot currently afford any extra bytes in the ClientHello until we have workarounds in place. It may still appear in the future. > When browsers implement Channel ID, what separations between different > websites are required? Cross-site request forgery has long been the > bane of web authentication technologies: does Channel ID provide > additional benefits here? Dirk deals with the higher levels of the stack, so I'll pass on that question. Cheers AGL From watsonbladd@gmail.com Tue Oct 22 10:52:24 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A6211E8210 for ; Tue, 22 Oct 2013 10:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWbE3UdMSUbl for ; Tue, 22 Oct 2013 10:52:23 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id E32EC11E84D8 for ; Tue, 22 Oct 2013 10:52:11 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q58so8660964wes.3 for ; Tue, 22 Oct 2013 10:52:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ydstNfc/JzS9T2vcP5cp/TpLEr3vQrQ9wqkwkVaDB50=; b=UzMQ0cA6j34Nu2+E3Z2TB3H1QiNSzSMXSzYHU7rYR+4GBtynroWFyInS0ZdeWZ8bnh sJhrpjILwi3INnwuuzv856FPZ4KYO+BwNg3uZTkt6J9EHp8lg/4i8R0/kv4YhHEkuoUY h9Ohi+yLI0zvj3KVQzFZXYsUpf+7fD8PGfkyesAgx2I3tnmUPUxcvwKnr1ey0y8Q0yF0 RF0Xb7dS4DZeHvVFpFLhYzgBVfln5kpCTczZE+nZ+3D6vn7R819qxjjZHRjk67JZc9xI 2r3yPI4zDDthg57VR+hnOJydP1AGM/HM5aarPfn15Uzj+f5ABblX63/lD0gHSzsj43Rn bDqw== MIME-Version: 1.0 X-Received: by 10.194.143.100 with SMTP id sd4mr3003593wjb.69.1382464331164; Tue, 22 Oct 2013 10:52:11 -0700 (PDT) Received: by 10.194.242.131 with HTTP; Tue, 22 Oct 2013 10:52:11 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Oct 2013 10:52:11 -0700 Message-ID: From: Watson Ladd To: Adam Langley Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Channel ID and server load: comment on draft-balfanz-tls-channelid-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 17:52:24 -0000 On Tue, Oct 22, 2013 at 8:14 AM, Adam Langley wrote: > On Mon, Oct 21, 2013 at 9:11 PM, Watson Ladd wrote: >> Why could Channel ID identifiers not get stolen when the resumption >> tickets are? Is there a reasonable threat model in which a client so >> compromised as to lose resumption tickets has a meaningful benefit >> from Channel ID? > > Because ChannelIDs have a public and private part, the private part > can be much better protected. For example, by moving it out of the > browser process completely, even on standard machines, and even under > hardware-protection, where such capability exists. Completely spurious: hardware (or a separate process) does not know whether it is being asked to provide the ChannelID for a request that is genuine or one that the attacker provided after subverting the browser process. There also is a replay attack: a signature of a static string provides no liveness, contrary to assumptions made here. As a result disclosure of a ChannelID for a web server provides the ability to falsely authenticate a connection. > >> Why P256 and ECDSA? These choices prevent batch verification on the >> server, increasing the workload significantly. They do not have major >> security advantages, or performance advantages over Ed25519. > > Why can't one batch verify ECDSA signatures? Because of a stupid missing bit, you don't know which of two points lead to the r value. If you did know this bit, you could make the verification equation an identity in the curve and apply the Bos-Coster trick Ed25519 does. I've not come up with a way around this issue. Guess and check isn't worth it: it ends up costing more than verifying one at a time. > > The major issue with batch verification is latency: in order to build > a batch one has to wait for enough ChannelID connections (64 for the > batch speeds advertised for Ed25519) to be in the handshake stage. But > for HTTPS, latency is very important and we can't delay connections > for that long in normal processing. > > That's not to say that batch processing is useless in all situations, > but it not always applicable. Fair enough: I assume P256 is performant enough for the applications being imagined, but given the constant kvetching about performance, I'm not sure everyone shares that. (Then again, they kvetch while using interpreted languages...) The argument for batch signatures to reduce latency is as follows: so long as connections are coming in at a rate slow enough for us to deal with them, all is good. But when connections come in faster than we can process, we can grind through the queue faster. I personally think TLS 1.3 should use a client key and server key to derive a forward-secure channel, and then carry out whatever proofs or verifications (certificate presentations, etc) are required within it. Done right this can be fast in latency and CPU terms. Done wrong we have what we have now. > > The goal of wanting to put the private key into hardware protection > also motivated the choice of signing primitive since we get what we're > given with hardware. I did come close to adding signature primitive > negotiation to ChannelID recently but, due to bugs in old F5 > firmwares, we cannot currently afford any extra bytes in the > ClientHello until we have workarounds in place. It may still appear in > the future. Options have burned us in the past: there was a recent email describing a case of deployments with incompatible cipher suites leading to interesting results. > >> When browsers implement Channel ID, what separations between different >> websites are required? Cross-site request forgery has long been the >> bane of web authentication technologies: does Channel ID provide >> additional benefits here? > > Dirk deals with the higher levels of the stack, so I'll pass on that question. > > > Cheers > > AGL Sincerely, Watson Ladd From trevp@trevp.net Tue Oct 22 11:32:57 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE2A811E8178 for ; Tue, 22 Oct 2013 11:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EqP67qs+XiW for ; Tue, 22 Oct 2013 11:32:50 -0700 (PDT) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id AB43611E8137 for ; Tue, 22 Oct 2013 11:32:49 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id x12so8212899wgg.4 for ; Tue, 22 Oct 2013 11:32:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hKrPR/wmH6kLZ+7/8aNkpPyUXSONiaR3ML1ywGCQ/a8=; b=TuEVmHv67DY08iAL67n7i7nnRyeVlpN56o0knWynMZ26LwKgHB8Izqp14Rr7aXoUHb JE9EdbImhMWQ2iiDIYnFn2VEtNRGXiOo5ka971HRXr2tvOkbYFIyln/8satA4vd6ifgF G0xHTISZogBm8qsw4/irVy2/RwO7sA/WWci3kuf4NcGXbaZHYyLhE72CHpiMGHPCglOf 3d2AJM/5dLlvqpvie5LE/6pKnRtAFNDS1y9F72ZxeSJOXd8QVaxkDGe40DlUxlep0Dgp PPwWCM1R4x8fA8miS+U1rfQ4/Me60tCQfrTDk4r/OQEdfzQGANqJLtXOxrakpFT2N7JQ SrNg== X-Gm-Message-State: ALoCoQnsmmeFzkCkyI2Ngd9bPIjcegqTCgEnQZlowJk/VTZWM3rDA/ZRCb6aylBgo89PX9zoPvah MIME-Version: 1.0 X-Received: by 10.180.160.165 with SMTP id xl5mr15641736wib.48.1382466768838; Tue, 22 Oct 2013 11:32:48 -0700 (PDT) Received: by 10.216.61.13 with HTTP; Tue, 22 Oct 2013 11:32:48 -0700 (PDT) X-Originating-IP: [199.83.223.81] In-Reply-To: References: Date: Tue, 22 Oct 2013 11:32:48 -0700 Message-ID: From: Trevor Perrin To: Watson Ladd Content-Type: text/plain; charset=ISO-8859-1 Cc: "tls@ietf.org" Subject: Re: [TLS] Channel ID and server load: comment on draft-balfanz-tls-channelid-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 18:32:57 -0000 On Tue, Oct 22, 2013 at 10:52 AM, Watson Ladd wrote: > On Tue, Oct 22, 2013 at 8:14 AM, Adam Langley wrote: >> On Mon, Oct 21, 2013 at 9:11 PM, Watson Ladd wrote: >>> Why could Channel ID identifiers not get stolen when the resumption >>> tickets are? Is there a reasonable threat model in which a client so >>> compromised as to lose resumption tickets has a meaningful benefit >>> from Channel ID? >> >> Because ChannelIDs have a public and private part, the private part >> can be much better protected. For example, by moving it out of the >> browser process completely, even on standard machines, and even under >> hardware-protection, where such capability exists. > Completely spurious: hardware (or a separate process) does not know > whether it is being asked to provide > the ChannelID for a request that is genuine or one that the attacker > provided after subverting the browser process. > There also is a replay attack: a signature of a static string provides > no liveness, contrary to assumptions made here. Hi Watson, I think you're misreading the draft: ChannelID signs hashes of handshake messages, not a "static string". I do think ChannelID needs to explain the value of storing private keys in a "secure element" further, and why storing ECDSA private keys is better than, say, HMAC keys. Trevor From n.mavrogiannopoulos@gmail.com Wed Oct 23 02:33:47 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C7B11E82B8 for ; Wed, 23 Oct 2013 02:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rysSENHDAPkR for ; Wed, 23 Oct 2013 02:33:46 -0700 (PDT) Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5345011E80F8 for ; Wed, 23 Oct 2013 02:33:43 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id b47so311214eek.31 for ; Wed, 23 Oct 2013 02:33:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :openpgp:content-type:content-transfer-encoding; bh=CkO4H9+at2Vbo9bQMIps+IGYd2btS3trUfm02HUUrpw=; b=G9eoO62wM2f1pIUkXOYT0mSPhaCTtQ6XZH5pNcljm1kk9ZBELkd4GBlNRZ6Fc5j1me WZHuMIndfcV62px99GcWOS0WVTLLcoR4j8ZorQNZ4Hns4vlBSlpDpYwTHG8KQ2K19qfF m0ulCSl25oZbWbwaKfgWfaTDNycG4SezImIfp02hPeutTpvQ0pe/wMTdWO6oA/nWa1K0 ouWfwaAK146LDlyJxWXpebahO0CL/AUCd1Zh764shb+g/glyxgg9ctdNnCRCtJAEmiVm LlMmwiJh0kMiP2qVDqlo0awcHdmGSAvnaz8OvpBtJIUupiTU78uCmKUxyMiDrTRmW5xh 3UVQ== X-Received: by 10.14.198.197 with SMTP id v45mr814846een.52.1382520821194; Wed, 23 Oct 2013 02:33:41 -0700 (PDT) Received: from [10.100.2.17] (ip-62-245-100-42.net.upcbroadband.cz. [62.245.100.42]) by mx.google.com with ESMTPSA id w6sm57250892eeo.12.2013.10.23.02.33.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 02:33:40 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <526797EE.2000206@gnutls.org> Date: Wed, 23 Oct 2013 11:33:34 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: "tls@ietf.org" X-Enigmail-Version: 1.5.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: =?windows-1252?Q?Joachim_Str=F6mbergson?= Subject: [TLS] comparison of draft-josefsson-salsa20-tls-02 and draft-agl-tls-chacha20poly1305-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 09:33:47 -0000 Hello, We are about to update draft-josefsson-salsa20-tls-02 by replacing UMAC-AES with POLY1305-AES, and given the opportunity we made a comparison of the two drafts that add a new stream cipher to TLS. That is draft-josefsson-salsa20-tls-02 and draft-agl-tls-chacha20poly1305-02. * Salsa20 vs Chacha draft-josefsson-salsa20-tls-02 uses Salsa20, a winner of an international competion of stream ciphers (eStream), which is easily implementable without leaking information through side-channels (i.e. timing attacks). draft-agl-tls-chacha20poly1305-02 selects Chacha instead, a derivative of Salsa20 that has been shown to be 7% faster in hardware and occupy 10% less space [0]. However, it only combines that cipher with a MAC that is of questionable efficiency in hardware (according to CFRG synopsis). This results overall, in a combination that isn't really well suited for hardware. Nevertheless, even if draft-agl-tls-chacha20poly1305-02 could be made efficient in hardware, in our opinion the performance benefits don't justify switching from a winner of an international competition to another algorithm (even if it is a derivative of it). * Applicability to Datagram TLS The draft-agl-tls-chacha20poly1305-02 is only applicable to TLS and not DTLS. That is because its combination with poly1305-chacha results to an RC4-like effect where rearranged or lost packets result in a desynchronization of the peers. draft-josefsson-salsa20-tls-02 applies to both TLS and DTLS (this results from the choice of having the block cipher AES in UMAC-AES). Having a stream cipher in DTLS was a main reason (for me at least) for draft-josefsson-salsa20-tls-02. * Adding a new cipher in stream or AEAD mode? The draft-josefsson-salsa20-tls-02 draft adds a new cipher to existing implementations and can be combined with the existing MAC algorithms in TLS (i.e., HMAC-SHA1). That is not the case in the draft-agl-tls-chacha20poly1305-02 draft, where a single combination is registered (of chacha with poly1305). Adding additional combinations in the latter draft would require defining more AEAD modes, something that could be a significant barrier that prevents its implementation (in contrast with just replacing a cipher in the stream setting of TLS). While I understand that there is quite some argumentation for using the AEAD mode in TLS for every cipher/mac combination I don't find it particularly convincing. In this specific case the AEAD mode adds 8 bytes of explicit nonce to the TLS record packet without providing any clear advantages compared to the original stream cipher interface. * An interesting observation on the usage of EtA in draft-agl-tls-chacha20poly1305-02 vs AtE. Both drafts introduce a universal hash based MAC. However, the chacha-poly1305 draft uses the encrypt-then-authenticate (EtA) construction while the salsa20 draft uses TLS' authenticate-then-encrypt (AtE) construction. When combined with ideal ciphers and MAC algorithms both modes can be equivalent. However, the AtE construction has the advantage of not revealing the MAC nor the authenticated data to an adversary. Interestingly enough the only known attacks on universal hash based MACs require access to MAC and data [1]. That is, these attacks (the key guessing and the divide and conquer) do not directly apply to draft-josefsson-salsa20-tls-02. Of course these attacks are of high complexity and impractical (unless some other weakness in the TLS protocol, or the MAC algorithm is found), but they nevertheless reinforce the view that the AtE construction has advantages on non-ideal MAC algorithms. best regards, Nikos [0]. Henzen, Luca, et al. "VLSI hardware evaluation of the stream ciphers Salsa20 and ChaCha, and the compression function Rumba." Signals, Circuits and Systems, 2008. SCS 2008. 2nd International Conference on. IEEE, 2008. [1]. Handschuh, Helena, and Bart Preneel. "Key-recovery attacks on universal hash function based MAC algorithms." Advances in Cryptology–CRYPTO 2008. Springer Berlin Heidelberg, 2008. 144-161. From 57756671618275-ietf-tls@sublist.cr.yp.to Wed Oct 23 02:47:31 2013 Return-Path: <57756671618275-ietf-tls@sublist.cr.yp.to> X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B675D11E8184 for ; Wed, 23 Oct 2013 02:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.991 X-Spam-Level: X-Spam-Status: No, score=-0.991 tagged_above=-999 required=5 tests=[AWL=-0.993, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzjfOreD5CB0 for ; Wed, 23 Oct 2013 02:47:27 -0700 (PDT) Received: from mace.cs.uic.edu (mace.cs.uic.edu [131.193.32.224]) by ietfa.amsl.com (Postfix) with SMTP id 2E64821F9FF2 for ; Wed, 23 Oct 2013 02:47:26 -0700 (PDT) Received: (qmail 11710 invoked by uid 1011); 23 Oct 2013 09:47:25 -0000 Received: from unknown (unknown) by unknown with QMTP; 23 Oct 2013 09:47:25 -0000 Received: (qmail 32764 invoked by uid 1001); 23 Oct 2013 09:47:10 -0000 Date: 23 Oct 2013 09:47:10 -0000 Message-ID: <20131023094710.32763.qmail@cr.yp.to> From: "D. J. Bernstein" To: tls@ietf.org Mail-Followup-To: tls@ietf.org Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. References: <523E176F.3050304@gmail.com> <52616365.1080108@nthpermutation.com> Subject: Re: [TLS] Safe ECC usage X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 09:47:31 -0000 Michael StJohns writes: > The existence of this document, created in 1997 would tend to suggest > that at least a few curves were created in X9 and not by NIST If you look at http://csrc.nist.gov/csrc/fedstandards.html you'll see NIST stating "These curves have been generated and reviewed by the government." Offhand I can't think of a NIST document admitting that the curves were created by NSA, but everyone in the community knows Jerry Solinas as the NSA point man on this. NSA's earlier contribution of the same curves to X9 is what led to X9 demanding seeds for curves (and incorrectly labeling seeded curves as "verifiably random"). ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago From ekr@rtfm.com Wed Oct 23 03:50:33 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0685311E8360 for ; Wed, 23 Oct 2013 03:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwG+NOkae-+e for ; Wed, 23 Oct 2013 03:50:27 -0700 (PDT) Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) by ietfa.amsl.com (Postfix) with ESMTP id BF10F11E819A for ; Wed, 23 Oct 2013 03:50:26 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id u57so607404wes.1 for ; Wed, 23 Oct 2013 03:50:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=vYPlzCEG2PS44JvgwFTlOrY39qgVACBWVcPoqr3dQa0=; b=e1WTk7K7yktA8pW6t7MgQ0Stgs6dXZQQAwD7Y758v0uvxSr6Ug/a+z/8ognTsfvTG/ En8n8ljcXur4J097pEgRT+uS26u0RpER0kLbUKbt125IYtSAGi1fnfwrS4ixcdzmJi1L O0wvfHzZY5bm5VD6OiSNR60GJPyrowcfRbzZkmM11tohUPB1dAtPJW3KzCpZ2/TCGfbW 3PisTDNeaf4Ti5DGs7MrWxcpI9jRAbCxyA8JQo1iHWP0V5OrlSyUBAU6FTS5vLkZmPvI LqnhqhZkvizjOGN9/IHSRxaDpMUjgIFLBry1h5uzsALtQl6cfq1wiT4oyt4cGQNaSyC2 xVkw== X-Gm-Message-State: ALoCoQktm5pj8CLEVZ6hWNJNTXvvBx+vE+LyhyMQMfZjpOCB7+4XKDc3f5k6RwCpIcrI4oO0eeHH X-Received: by 10.180.24.197 with SMTP id w5mr1549834wif.8.1382525425948; Wed, 23 Oct 2013 03:50:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.152.137 with HTTP; Wed, 23 Oct 2013 03:49:45 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <526797EE.2000206@gnutls.org> References: <526797EE.2000206@gnutls.org> From: Eric Rescorla Date: Wed, 23 Oct 2013 03:49:45 -0700 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=f46d044286e2e8358004e9664899 Cc: "tls@ietf.org" , =?ISO-8859-1?Q?Joachim_Str=F6mbergson?= Subject: Re: [TLS] comparison of draft-josefsson-salsa20-tls-02 and draft-agl-tls-chacha20poly1305-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 10:50:33 -0000 --f46d044286e2e8358004e9664899 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 23, 2013 at 2:33 AM, Nikos Mavrogiannopoulos wrote: > > * Adding a new cipher in stream or AEAD mode? > > The draft-josefsson-salsa20-tls-02 draft adds a new cipher to existing > implementations and can be combined with the existing MAC algorithms in > TLS (i.e., HMAC-SHA1). That is not the case in the > draft-agl-tls-chacha20poly1305-02 draft, where a single combination is > registered (of chacha with poly1305). Adding additional combinations in > the latter draft would require defining more AEAD modes, something that > could be a significant barrier that prevents its implementation (in > contrast with just replacing a cipher in the stream setting of TLS). > > While I understand that there is quite some argumentation for using the > AEAD mode in TLS for every cipher/mac combination I don't find it > particularly convincing. In this specific case the AEAD mode adds 8 > bytes of explicit nonce to the TLS record packet without providing any > clear advantages compared to the original stream cipher interface. > I don't believe that this is correct. That is how the GCM cipher suites are constructed, but it isn't required by RFC 5246, which says: Each AEAD cipher suite MUST specify how the nonce supplied to the AEAD operation is constructed, and what is the length of the GenericAEADCipher.nonce_explicit part. In many cases, it is appropriate to use the partially implicit nonce technique described in Section 3.2.1 of [AEAD]; with record_iv_length being the length of the explicit part. In this case, the implicit part SHOULD be derived from key_block as client_write_iv and server_write_iv (as described in Section 6.3), and the explicit part is included in GenericAEAEDCipher.nonce_explicit. With that said, the argument for having an explicit IV is as follows: it's desirable to have a cryptographic AEAD primitive which doesn't accidentally enable nonce reuse. In order to do this, you need to internally generate the nonce, which means it must be explicit. (For FIPS purposes, this means it must be generated inside the crypto boundary). That's why the GCM algorithms were done this way. You may or may not subscribe to this, but it's basically an orthogonal question to the rest of these issues. -Ekr --f46d044286e2e8358004e9664899 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Oct 23, 2013 at 2:33 AM, Nikos Mavrogiannopoulos <nmav@gnut= ls.org> wrote:
* Adding a new cipher in stream or AEAD mode?

The draft-josefsson-salsa20-tls-02 draft adds a new cipher to existing
implementations and can be combined with the existing MAC algorithms in
TLS (i.e., HMAC-SHA1). That is not the case in the
draft-agl-tls-chacha20poly1305-02 draft, where a single combination is
registered (of chacha with poly1305). Adding additional combinations in
the latter draft would require defining more AEAD modes, something that
could be a significant barrier that prevents its implementation (in
contrast with just replacing a cipher in the stream setting of TLS).

While I understand that there is quite some argumentation for using the
AEAD mode in TLS for every cipher/mac combination I don't find it
particularly convincing. In this specific case the AEAD mode adds 8
bytes of explicit nonce to the TLS record packet without providing any
clear advantages compared to the original stream cipher interface.

I don't believe that this is correct. That = is how the GCM cipher suites
are constructed, but it isn't re= quired by RFC 5246, which says:

=A0 =A0Each AEAD cipher suite MUST specify how the= nonce supplied to the
=A0 =A0AEAD operation is constructed, and = what is the length of the
=A0 =A0GenericAEADCipher.nonce_explicit= part. =A0In many cases, it is
=A0 =A0appropriate to use the partially implicit nonce technique descr= ibed
=A0 =A0in Section 3.2.1 of [AEAD]; with record_iv_length= being the length of
=A0 =A0the explicit part. =A0In this case, t= he implicit part SHOULD be derived
=A0 =A0from key_block as client_write_iv and server_write_iv (as descr= ibed
=A0 =A0in Section 6.3), and the explicit part is included in=
=A0 =A0GenericAEAEDCipher.nonce_explicit.

With that said, the argument for having an explicit IV is as follows: it= 9;s
desirable to have a cryptographic AEAD primitive which doesn&= #39;t
accidentally enable nonce reuse. In order to do this, you n= eed to
internally generate the nonce, which means it must be explicit.
<= div>(For FIPS purposes, this means it must be generated inside the crypto
boundary). That's why the GCM algorithms were done this way.

You may or may not subscribe to this, but it's basi= cally
an orthogonal question to the rest of these issues.

-Ekr

--f46d044286e2e8358004e9664899-- From hallam@gmail.com Wed Oct 23 06:46:36 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C2C11E818A for ; Wed, 23 Oct 2013 06:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJoCv0W9gYtE for ; Wed, 23 Oct 2013 06:46:19 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E27B111E81B0 for ; Wed, 23 Oct 2013 06:46:06 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id q8so530951lbi.19 for ; Wed, 23 Oct 2013 06:46:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=juzXtodRK9S0ahkop8MlXGLmKgrRm2zsbvt7QIpBzz8=; b=A4h6S77RA6uMbXkLiyQxQUFUqrzJRWGoquPxKszVcNFKvLbv12qnwix1CL8lQyPVXH eK2C3lkPoYTc0sIj3gexSHLotQDjVbUTMLC7vWiWb/3O9e9CNzP/12KZ50F4xvU1vyX/ 8ytLEYTEXjVTG+0qBJQH/l5a9UUHED30X2QINx8dyHUfy8/rkD0+LBvVA+eB1HfQDPb8 4RW6cWafdWBGo45GEDsH/8SdZVGcZ4s+qI7HvjVGSKeueqbSqqYvlkbNVLWj75eHSyTO pszPW+KJYVbOvjORehd/64oHgdnKMD1Njwiz1HOFeoVjQSLRiHpA7YYfjZ8nOMKFG2FG UFWg== MIME-Version: 1.0 X-Received: by 10.152.116.82 with SMTP id ju18mr139613lab.54.1382535965904; Wed, 23 Oct 2013 06:46:05 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Wed, 23 Oct 2013 06:46:05 -0700 (PDT) Date: Wed, 23 Oct 2013 09:46:05 -0400 Message-ID: From: Phillip Hallam-Baker To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c26e142315b804e968bd50 Subject: [TLS] OCSP Must Staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 13:46:36 -0000 --001a11c26e142315b804e968bd50 Content-Type: text/plain; charset=ISO-8859-1 We have been discussing MUST staple for quite some time. The ADs would like to know if there is support for adding this feature to certificates. The draft I wrote is designed to be agile so that it covers all new OCSP stapling like ideas rather than just being a one off. But it is pretty simple: http://tools.ietf.org/html/draft-hallambaker-tlsfeature-02 The advantage of MUST staple is that if a client receives a TLS cert chain with MUST Staple and no OCSP token then it can refuse the connection and hard fail rather than attempting to retrieve the token and soft failing. This allows for a performance improvement and a security improvement. -- Website: http://hallambaker.com/ --001a11c26e142315b804e968bd50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We have been discussing MUST staple for quite some time. T= he ADs would like to know if there is support for adding this feature to ce= rtificates.

The draft I wrote is designed to be agile so= that it covers all new OCSP stapling like ideas rather than just being a o= ne off. But it is pretty simple:

--001a11c26e142315b804e968bd50-- From agl@google.com Wed Oct 23 06:56:05 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FC611E838B for ; Wed, 23 Oct 2013 06:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4apVawg8aVO for ; Wed, 23 Oct 2013 06:56:05 -0700 (PDT) Received: from mail-vb0-x236.google.com (mail-vb0-x236.google.com [IPv6:2607:f8b0:400c:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8E73C11E8371 for ; Wed, 23 Oct 2013 06:56:04 -0700 (PDT) Received: by mail-vb0-f54.google.com with SMTP id q12so465446vbe.27 for ; Wed, 23 Oct 2013 06:56:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QwbuHmA+74k2OLipps3krNBtYE1pyYEx0NT4Vhj84z8=; b=VEj4Vp5EAA+pY17rq/2W8+On7hbLQKJUcUFXVBDh6eRMcmkwB+axS/83m3uGPOaJlx 9HYKMtZtWuD3Uvg8js8YrffTobTQa+3u6OSSPLkiPZLrbsFx7UGbyCb/rPwAU4gXRpVU kpEOJjgzliNkGWiD+xyMQs3d0CJ2f97495Rx7TnZHm0WdepuuJlFzEQbkU9lci5IVQyx zK3P4Bz113pRnviq9ZEaoCn+VKMvGgo5r9LjiXyKno6Qgb7vuqjFHzoENdU5lzck3ZMJ 2rQGGNdjkVFT4VhpJDTiR01vJY11+rTkq+iJ31UPzUa2NIDsbVs9eJ2Q8yk/qSw2OPW6 RNdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=QwbuHmA+74k2OLipps3krNBtYE1pyYEx0NT4Vhj84z8=; b=UpqNvEfmxmPixw9sri6p70N7x7YYORhXFtSzBKbExq9bYmG92gZdV9mkUNb+Z7JYKI 8NedEI6iOnbL2K3QPoopi3q3psY95U9V71pDWdOMRhIGCedt4GAbFNrEhfmuXgLSBDjq /Ie3V8vwe+VKtDbI6NZ3b6jX9y/wQzE3QsaYnbBwaILY/Ss5lGc8ro8rtl8ttvsCMOt3 E5+2Cs822nWoqvaB3oiLCJEgasUZB4cu4jEwJZan3nMz/JKwxMJLY7pB5WEuBAh92Oyw KA6bgVjUugrmgxBY5xP1op3vF4rsN91KtuzmO3hx09WG6wvqVxMEpAn1vBVf6KLmqyMG Y39A== X-Gm-Message-State: ALoCoQmKM5e+rlxJCzRk8/oVFW9kLZzpuLbB3eh0TdOyhRJAg5SIbh2L6ccfMl19O+BLcR3X2AHYthlT+BSDJD3/TKTa1pT0hFcsUn/098wYw3iEdFSKZqUYaJ63jUOjhmU1j75AUeyScNfB4MzjpL9vVovbed9hs5ves0B1Y9cPFtl/B6Oy8PUhDeDXy/Glp0x2HkQzWQnj X-Received: by 10.58.146.71 with SMTP id ta7mr1214689veb.23.1382536564053; Wed, 23 Oct 2013 06:56:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.100.40 with HTTP; Wed, 23 Oct 2013 06:55:42 -0700 (PDT) In-Reply-To: <526797EE.2000206@gnutls.org> References: <526797EE.2000206@gnutls.org> From: Adam Langley Date: Wed, 23 Oct 2013 09:55:42 -0400 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" , =?UTF-8?Q?Joachim_Str=C3=B6mbergson?= Subject: Re: [TLS] comparison of draft-josefsson-salsa20-tls-02 and draft-agl-tls-chacha20poly1305-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 13:56:05 -0000 On Wed, Oct 23, 2013 at 5:33 AM, Nikos Mavrogiannopoulos wrote: > Nevertheless, even if draft-agl-tls-chacha20poly1305-02 could be made > efficient in hardware, in our opinion the performance benefits don't > justify switching from a winner of an international competition to > another algorithm (even if it is a derivative of it). I don't think that there's much between them, but have a slight preference for ChaCha, which mirrors the CFRG: "The RG expressed a preference for ChaCha." [1] [1] http://www.ietf.org/mail-archive/web/tls/current/msg10221.html > * Applicability to Datagram TLS > > The draft-agl-tls-chacha20poly1305-02 is only applicable to TLS and not > DTLS. That is because its combination with poly1305-chacha results to an > RC4-like effect where rearranged or lost packets result in a > desynchronization of the peers. draft-josefsson-salsa20-tls-02 applies > to both TLS and DTLS (this results from the choice of having the block > cipher AES in UMAC-AES). Having a stream cipher in DTLS was a main > reason (for me at least) for draft-josefsson-salsa20-tls-02. I don't believe that this is correct. There is no state carried between encryptions of records. Given the sequence numbers of a set of records, they can be processed in any order. Although the ChaCha draft doesn't mention DTLS, I don't think there's any fundamental difference here. > While I understand that there is quite some argumentation for using the > AEAD mode in TLS for every cipher/mac combination I don't find it > particularly convincing. In this specific case the AEAD mode adds 8 > bytes of explicit nonce to the TLS record packet without providing any > clear advantages compared to the original stream cipher interface. This is incorrect, there is no explicit nonce in the ChaCha AEAD construction. Chrome is conducting experiments at the moment to test the transparency of the general Internet to TLS 1.0 and 1.2, although it will take a few months for the results. If TLS 1.2 turns out to be non-viable then I agree that some changes will be needed somewhere, but I'm still awaiting that data. > Both drafts introduce a universal hash based MAC. However, the > chacha-poly1305 draft uses the encrypt-then-authenticate (EtA) > construction while the salsa20 draft uses TLS' authenticate-then-encrypt > (AtE) construction. When combined with ideal ciphers and MAC algorithms > both modes can be equivalent. However, the AtE construction has the > advantage of not revealing the MAC nor the authenticated data to an > adversary. Interestingly enough the only known attacks on universal hash > based MACs require access to MAC and data [1]. That is, these attacks > (the key guessing and the divide and conquer) do not directly apply to > draft-josefsson-salsa20-tls-02. > > Of course these attacks are of high complexity and impractical (unless > some other weakness in the TLS protocol, or the MAC algorithm is found), > but they nevertheless reinforce the view that the AtE construction has > advantages on non-ideal MAC algorithms. On the other hand, EtA allows for faster forgery rejection which, while not so useful for TLS, is useful for DTLS. In any case, I don't believe that the security bounds laid out in the original Poly1305 paper[2] have been altered and I believe those bounds are sufficient for all users of (D)TLS. [2] http://cr.yp.to/mac/poly1305-20050329.pdf Cheers AGL From n.mavrogiannopoulos@gmail.com Wed Oct 23 07:51:41 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E017211E83BE for ; Wed, 23 Oct 2013 07:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRm8yZM9sySL for ; Wed, 23 Oct 2013 07:51:41 -0700 (PDT) Received: from mail-ee0-x22b.google.com (mail-ee0-x22b.google.com [IPv6:2a00:1450:4013:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B71D211E8217 for ; Wed, 23 Oct 2013 07:51:40 -0700 (PDT) Received: by mail-ee0-f43.google.com with SMTP id e52so574640eek.30 for ; Wed, 23 Oct 2013 07:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=EcqeZNUe1WK55oF4HF7DCLXOxn7gBXoEXN55GpHQMok=; b=fLfI39yQx0J0Bt22EPyzBVaYoc2jxCdhoa8jkzQVQ4SyaZ8HTWRYpX1/vGGOE25o5v GmmvKYGFQAWie8eCU8/Fm8XJKDQ5RJP18jobnnZCujysAKudblxzluZXxTSHscQnxuEn +jVP0ILoLYwecOwZJbtfPPe2F0GCd/nSjSmQr3XHK/8GjutNKXzWwlFfB8uPexabP/nd 2+NBBb56tZZM9us768k+o2rniOePwFVssQ7dd54XAPWf+n/Z673r14vGxgnT3iH8cybP 1fFVRl4bQpYSZPUPU2avCeiqcaUUN/jmov5Mq0cbZv/t1JaAu8HnStgXmiZ+J4g91gcp ai/g== X-Received: by 10.15.99.72 with SMTP id bk48mr2326503eeb.22.1382539899947; Wed, 23 Oct 2013 07:51:39 -0700 (PDT) Received: from [10.100.2.17] (ip-62-245-100-42.net.upcbroadband.cz. [62.245.100.42]) by mx.google.com with ESMTPSA id f49sm71017753eec.7.2013.10.23.07.51.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 07:51:39 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <5267E276.9050107@gnutls.org> Date: Wed, 23 Oct 2013 16:51:34 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: Adam Langley References: <526797EE.2000206@gnutls.org> In-Reply-To: X-Enigmail-Version: 1.5.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" , =?UTF-8?B?Sm9hY2hpbSBTdHLDtm1iZXJnc29u?= Subject: Re: [TLS] comparison of draft-josefsson-salsa20-tls-02 and draft-agl-tls-chacha20poly1305-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 14:51:42 -0000 On 10/23/2013 03:55 PM, Adam Langley wrote: >> * Applicability to Datagram TLS >> The draft-agl-tls-chacha20poly1305-02 is only applicable to TLS and not >> DTLS. That is because its combination with poly1305-chacha results to an >> RC4-like effect where rearranged or lost packets result in a >> desynchronization of the peers. draft-josefsson-salsa20-tls-02 applies >> to both TLS and DTLS (this results from the choice of having the block >> cipher AES in UMAC-AES). Having a stream cipher in DTLS was a main >> reason (for me at least) for draft-josefsson-salsa20-tls-02. > I don't believe that this is correct. There is no state carried > between encryptions of records. Given the sequence numbers of a set of > records, they can be processed in any order. > Although the ChaCha draft doesn't mention DTLS, I don't think there's > any fundamental difference here. As far as I understand you use chacha to generate the keystream for poly1305. Thus you carry state between records (chacha is a stream cipher). I don't know if I have missed anything there, but I don't see resetting chacha with a new IV per MAC calculation. >> While I understand that there is quite some argumentation for using the >> AEAD mode in TLS for every cipher/mac combination I don't find it >> particularly convincing. In this specific case the AEAD mode adds 8 >> bytes of explicit nonce to the TLS record packet without providing any >> clear advantages compared to the original stream cipher interface. > This is incorrect, there is no explicit nonce in the ChaCha AEAD construction. I missed that. Indeed. > On the other hand, EtA allows for faster forgery rejection which, > while not so useful for TLS, is useful for DTLS. Is that really an issue? If yes, then EtA isn't also invulnerable to a DoS attack, it is a big more lightweight. However, as a general comment I think DTLS' resilience on forged packets isn't that good. It makes it a perfect target to lay an attack. I think it would be much better to have a limit by default on the allowed packets with wrong MAC. > In any case, I don't believe that the security bounds laid out in the > original Poly1305 paper[2] have been altered and I believe those > bounds are sufficient for all users of (D)TLS. Of course, these attacks require another flaw or leak to be practical. However, my point is, that even with that additional flaw or information, they will still not be applicable in AtE mode. regards, Nikos From n.mavrogiannopoulos@gmail.com Wed Oct 23 07:58:58 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D153B11E83B8 for ; Wed, 23 Oct 2013 07:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03CTcc4r7dXO for ; Wed, 23 Oct 2013 07:58:58 -0700 (PDT) Received: from mail-ee0-x22e.google.com (mail-ee0-x22e.google.com [IPv6:2a00:1450:4013:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5363E11E83AC for ; Wed, 23 Oct 2013 07:58:54 -0700 (PDT) Received: by mail-ee0-f46.google.com with SMTP id c1so455852eek.5 for ; Wed, 23 Oct 2013 07:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=7qJJQDQTF2oweDLuPiBvrkzgI1uds1tkFEFt8UKn8dk=; b=WBKee3kCYuZygmEYUYFLGKoco+H5wk5qzIDpVJOzMvSE9u9Fp/69zJgsLBZnnjlX6W ZZOP7bI6hcVbs+OhH6MTsw6nEsjFs8XeuY/4gCg110qYomDsICGJaFoOfvsc6cudzAoN Nvo5ughR4qW+HzAJEYdJ8u31WYgRh6tyCXdPlsiutLJ4xJGg7Kyew1M7oiq+eZnwbp2W 7+/ENSl/dErzufP2Vq1e8qioWjaPoT4NeruBGXdQhQmmIn1u4EkWXoNAmE15AHjCaNEl dR5a6FdVTYzEef7hg71qDJka6r/kxaOygPJfC4CIYIGANd7AEuNboDOLFHIv9PRBqkYu fgkA== X-Received: by 10.15.53.132 with SMTP id r4mr2279875eew.5.1382540321410; Wed, 23 Oct 2013 07:58:41 -0700 (PDT) Received: from [10.100.2.17] (ip-62-245-100-42.net.upcbroadband.cz. [62.245.100.42]) by mx.google.com with ESMTPSA id u46sm71063370eep.17.2013.10.23.07.58.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 07:58:40 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <5267E41B.4080504@gnutls.org> Date: Wed, 23 Oct 2013 16:58:35 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: Eric Rescorla References: <526797EE.2000206@gnutls.org> In-Reply-To: X-Enigmail-Version: 1.5.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" , =?ISO-8859-1?Q?Joachim_Str=F6mbergso?= =?ISO-8859-1?Q?n?= Subject: Re: [TLS] comparison of draft-josefsson-salsa20-tls-02 and draft-agl-tls-chacha20poly1305-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 14:58:58 -0000 On 10/23/2013 12:49 PM, Eric Rescorla wrote: > * Adding a new cipher in stream or AEAD mode? > The draft-josefsson-salsa20-tls-02 draft adds a new cipher to existing > implementations and can be combined with the existing MAC algorithms in > TLS (i.e., HMAC-SHA1). That is not the case in the > draft-agl-tls-chacha20poly1305-02 draft, where a single combination is > registered (of chacha with poly1305). Adding additional combinations in > the latter draft would require defining more AEAD modes, something that > could be a significant barrier that prevents its implementation (in > contrast with just replacing a cipher in the stream setting of TLS). > > While I understand that there is quite some argumentation for using the > AEAD mode in TLS for every cipher/mac combination I don't find it > particularly convincing. In this specific case the AEAD mode adds 8 > bytes of explicit nonce to the TLS record packet without providing any > clear advantages compared to the original stream cipher interface. > I don't believe that this is correct. That is how the GCM cipher suites > are constructed, but it isn't required by RFC 5246, which says: Indeed, and it seems the chacha draft didn't use the explicit IV anyway, so I wasn't correct here. So I only don't get what is the advantage of that mode. The stream interface of TLS is easier to extend with new cipher/mac combinations without having to define again or differently the details of a new AEAD mode (TLS stream mode defines how authenticated-encryption is performed anyway, and there are no known issues with that). Thus from an implementer point of view I find the usage of the stream mode the natural thing to do, unless something very special needs to be done, or the cipher/mac combination is so tightly combined like GCM that warrants the usage of the AEAD interface. regards, Nikos From agl@google.com Wed Oct 23 07:59:10 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A6911E81AF for ; Wed, 23 Oct 2013 07:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RK+VXONiUMfX for ; Wed, 23 Oct 2013 07:59:09 -0700 (PDT) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 7A27511E838F for ; Wed, 23 Oct 2013 07:59:09 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id cz12so529551veb.3 for ; Wed, 23 Oct 2013 07:59:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=R3EOUPAE0mVHp4YSvbTqrAxpIUuF79ZPS4bYAv96xvU=; b=LxG8/EtooMLTznQyjdsSGN4R9iOSBWbl3sIl1NH01SU6mXF7GoScKpYklRl1b7YGyt FeKMNq5iXerFbmHWLlWMH+kO4ZlrPUyXozWD2KVbQmx/glBQwdGduDKaN2l/wnQjiQtx pn5xy0cTtTNGw7+Cdex/hJxjCwj84ECZBxXr/90xFsW0Tf/uacUMph4qJvEe+oENveWz sxoaXIq3axv4uOl2X+w6fdPNu99N5ttF9O8PCwvDeIWiCvkDie6kfy/rJJjLDCleqxOF +yREOApec442x0OhtFioIX9yy+ifSBILWCRDmh41pzqX5VlTU5ZWSFTTBZZE+rTHIKSN XRrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=R3EOUPAE0mVHp4YSvbTqrAxpIUuF79ZPS4bYAv96xvU=; b=KjpEqz9J8h9wtJ4JfhOKtYBQq8r3iPitlRz7J5IuzAyIazP+qSx+F93tke+1sw1/Rq /eVxWORwJmxXs2ZkTn+1FZD4shrnDA2KFsGEfMd9jya4q/724iMJqk/cnK5dAFTDrYhW MyT3lLK4JWh8bcyXJFh43r7/7/dCTI8NKFAK2xAL3pkmRYEpUs+JnJbpaWlh/cGWMqs3 9UBeeFRUoj6d+spI8GE4YHhabAfUbsry31iur29BGVmuIY3hyg7R9o4W+rnZkQ29GeOC 3rpsd57eXQ2RXghhDtMCoRLiPSB5wxTgDd2bOIDEc9oN35lqF7zt0kjF9W33mSEagjeR UBKQ== X-Gm-Message-State: ALoCoQnxYA2z4GRkZ5un4QD9ByhlxEegJsPJg6gzpwFHJ+v4eTly4++qOfZk4H8BdEPzveF3hRSMyGh+TZGEPFAdk4k6tkJYUTeNsOQGZahvCvNZGwgqj5HNfqbPDucTx3fu+T2yk1QvVGb/OK28/LzucMpldA2bKLW14Ny7l6Ry67cbnCa+z1Uq/wKAtaZ61/nUVlghzD+2 X-Received: by 10.220.145.75 with SMTP id c11mr787661vcv.30.1382540349070; Wed, 23 Oct 2013 07:59:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.100.40 with HTTP; Wed, 23 Oct 2013 07:58:48 -0700 (PDT) In-Reply-To: <5267E276.9050107@gnutls.org> References: <526797EE.2000206@gnutls.org> <5267E276.9050107@gnutls.org> From: Adam Langley Date: Wed, 23 Oct 2013 10:58:48 -0400 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" , =?UTF-8?Q?Joachim_Str=C3=B6mbergson?= Subject: Re: [TLS] comparison of draft-josefsson-salsa20-tls-02 and draft-agl-tls-chacha20poly1305-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 14:59:10 -0000 On Wed, Oct 23, 2013 at 10:51 AM, Nikos Mavrogiannopoulos wrote: > As far as I understand you use chacha to generate the keystream for > poly1305. Thus you carry state between records (chacha is a stream > cipher). I don't know if I have missed anything there, but I don't see > resetting chacha with a new IV per MAC calculation. There is no state carried between records: "ChaCha20 is run with the given key and nonce and with the two counter words set to zero. The first 32 bytes of the 64 byte output are saved to become the one-time key for Poly1305." (The nonce is the sequence number of the record.) (http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-00#section-5) Cheers AGL From agl@google.com Wed Oct 23 08:21:27 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA4A11E844A for ; Wed, 23 Oct 2013 08:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdtWZWNqH+IC for ; Wed, 23 Oct 2013 08:21:27 -0700 (PDT) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9054911E8445 for ; Wed, 23 Oct 2013 08:21:23 -0700 (PDT) Received: by mail-ve0-f171.google.com with SMTP id pa12so120655veb.16 for ; Wed, 23 Oct 2013 08:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+GWrw9jox1Si/eY3Of+UKbvm/QpuficoMh3ZdZ2ea7g=; b=KLG5d1Is8JYKe/gRNRUgz2s8JisHHZo+Q/zWspybsbpYDe7aoOZEohiKSaCAF+5yVQ zzdur5yW8ntCQxjnLLzc82DMxRuZtazlfySCTPuYKcgezZonnEzypxZdfgUbXqh6eCEj yqzQeXVLetczOxGjjze4b5+3wtCg4rzGhOA4egn7xDpFcs33KNEk/PG5FwT2yHkymxBW W4ksZMSGYEZ2llS7NldgaaSMrPVOWVcKruxHYEl2K1WW1IEfH++5/SFsWzWLATBgYYAL ZbtAjJ7VDw0me/2y6ORxdGX8L8S9UkfCpIZLpcUyNf5RRF+HxAgDZ28oDs5b5P+dvU48 7nhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+GWrw9jox1Si/eY3Of+UKbvm/QpuficoMh3ZdZ2ea7g=; b=eQHUJ7asbnEjgdzBwrndgWpJqMsMBnPzAdDOoyDq0qhMCHV9UFh3Pm8Px1MVLwCphe lCHc3uTeXtVKlBLcVnMGP+DEwD01csFVX4UxYUOw1Q9hXflIQh4Kvoscd6XtRHIGb6yB UkMrd07KAXzuehSEtjXuo+37b9MIK6B1QFztfxmTNm8KXe3EFzumYzYSzOu4Z0WboQZs MnGCYXQY67twtoR7lVam5MqM7wHdey//1p+gksLFrkP1jHGRMmG1z65+QVyDp5CmOMlN WargMTBevsPG3kssA6sdjA1j4N2O/00fyU8CCS5DjNuOnIsa64QJiMJoxJvd6ECQKce/ VUYg== X-Gm-Message-State: ALoCoQkHuvOvXh9NtmwBr85VqoyUYiUQhpF+IGU5mR284YbirCqkJuDiTrtlZ1HiOIgBaasg75Xg3Q/SuLHp5aLZHzxZD2JoJ46Paykitz9dfe565C1MqsVBHINs7/s/Z5jcjKdyj+QYXjRB2w/rEYEsB2PuUicFgh13FvmG29pjF1rtVs+bIxTnYIGFYCg49VxBR4E28STK X-Received: by 10.58.54.69 with SMTP id h5mr1521747vep.25.1382541683172; Wed, 23 Oct 2013 08:21:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.100.40 with HTTP; Wed, 23 Oct 2013 08:21:03 -0700 (PDT) In-Reply-To: References: From: Adam Langley Date: Wed, 23 Oct 2013 11:21:03 -0400 Message-ID: To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Channel ID and server load: comment on draft-balfanz-tls-channelid-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 15:21:27 -0000 On Tue, Oct 22, 2013 at 1:52 PM, Watson Ladd wrote: > Completely spurious: hardware (or a separate process) does not know > whether it is being asked to provide > the ChannelID for a request that is genuine or one that the attacker > provided after subverting the browser process. Certainly that's true. However, it limits the attacker to an online attack: closing the laptop etc stops them. That's a lot better than the current situation where cookie theft is a significant problem. Additionally, ChannelID can be extended to an "ignition key" model where connections need to reprove the presence of the ChannelID every $n minutes. (That might get the verification load to the point where batching is useful :) > There also is a replay attack: a signature of a static string provides > no liveness ChannelID signs the handshake which includes an nonce from the server. > Because of a stupid missing bit, you don't know which of two points > lead to the r value. If you did know this bit, you could > make the verification equation an identity in the curve and apply the > Bos-Coster trick Ed25519 does. I've not come up with > a way around this issue. Guess and check isn't worth it: it ends up > costing more than verifying one at a time. I have not looked into batching ECDSA verifies but [1] seems quite clear that it's dealing with unmodified ECDSA signatures (paywalled I'm afraid, but the first two pages are free). They report a speedup of 2x for batches with multiple signers, which is roughly equal to the reported speedup for Ed25519 (273K -> 134K cycles). [1] http://rd.springer.com/chapter/10.1007%2F978-3-642-31410-0_1 > Fair enough: I assume P256 is performant enough for the applications > being imagined, but given > the constant kvetching about performance, I'm not sure everyone shares > that. (Then again, they > kvetch while using interpreted languages...) I am not terribly happy with the performance implications of ChannelID either, but we're still exploring our options. Cheers AGL From agl@google.com Wed Oct 23 08:32:09 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7494F11E81AF for ; Wed, 23 Oct 2013 08:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kq4m3qI1aDbJ for ; Wed, 23 Oct 2013 08:32:08 -0700 (PDT) Received: from mail-vc0-x232.google.com (mail-vc0-x232.google.com [IPv6:2607:f8b0:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id B914C11E8450 for ; Wed, 23 Oct 2013 08:32:08 -0700 (PDT) Received: by mail-vc0-f178.google.com with SMTP id lh4so617393vcb.37 for ; Wed, 23 Oct 2013 08:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fZ4CBdmA3UnsJXjjT6hCfycytCQtK6AvI11hl/iD4xU=; b=W0tD2ahAzLh8mVV3NT1Gen1xkHretsZ+Y0P4zs9G3+gPJo815EqCH1F/iuyIgog395 0s9yyUOjAELvsVtTDDzxev8jdQ3lZO1fofRi2s06ga4uIcHeP8oh9E1bzPIO1LQwTHuw vKCJVwxEjfIZ4SJI1p6YoZpO8jrEK4zjKlXpt4dkdMQxmhg+2aFkg+wPrUh+1bkiZS6N SXS+bAxeAYrlTExCiEinLFDVM1WYbSEr8o2FUjveq/nqHm19F1ctB/IB0cEuYFWFiQt4 VSYG9lelm595fYLyQE6xuEQhOdDS55uUMElxzIZmYcthHj4DHZ2yX2PYwxVIuNbTqAVm tfIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fZ4CBdmA3UnsJXjjT6hCfycytCQtK6AvI11hl/iD4xU=; b=M1sPnRXuYxzIfwlI52upr0dIP3Qynq8/8wigTbxuLwh57MlI+L+B3kK4Ikwjtkdtuq Jlbg0xyp+8KFTMbY1bik19Fcr+5KoGVkdXQ7xJlrfkg0IxkylQtpJKBEkZNilCqpktZI U0oaYXFcvlFaQe+m/BMbWUbpI+eKYnEZPDNUav/b3CG5VKSawjU3VIj4QvHtCrfNH7NW QMXItInMNyIqbLMfooZj12G+o0eOTcb7Rm3WPiBfclHebgEvD5c/OEgo7OMx29ak7ylr yUH/MGZpySTNEsvJSmGH7l0pQdhdEgdn+tc20SoPXO2MwhyAi5+R+JpxMGuqKx3U1lQa 6GlA== X-Gm-Message-State: ALoCoQkDKhWGBhr/Go8LeIFz/AIZXMRW2haX4aN3GmrXVoaAi2FAlY8YJIBCHqhZg/91tRg2ffw7SyoPYYZPH1rw+7O+GG38x+ZzpeRIzNIpS1Q0hAaMtUJP8A38PbP1qex3AFmS/Q6Yo2byNvYcREJ+Yrt0tM8WQuk+NERo1DGs2fXeZpDAx/ijDRL3tXZt62XjbcJ4Vkg2 X-Received: by 10.52.118.73 with SMTP id kk9mr1275245vdb.13.1382541929533; Wed, 23 Oct 2013 08:25:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.100.40 with HTTP; Wed, 23 Oct 2013 08:25:09 -0700 (PDT) In-Reply-To: References: From: Adam Langley Date: Wed, 23 Oct 2013 11:25:09 -0400 Message-ID: To: Trevor Perrin Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Channel ID and server load: comment on draft-balfanz-tls-channelid-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 15:32:09 -0000 On Tue, Oct 22, 2013 at 2:32 PM, Trevor Perrin wrote: > On Tue, Oct 22, 2013 at 10:52 AM, Watson Ladd wrote: >> On Tue, Oct 22, 2013 at 8:14 AM, Adam Langley wrote: >>> On Mon, Oct 21, 2013 at 9:11 PM, Watson Ladd wrote: >>>> Why could Channel ID identifiers not get stolen when the resumption >>>> tickets are? Is there a reasonable threat model in which a client so >>>> compromised as to lose resumption tickets has a meaningful benefit >>>> from Channel ID? >>> >>> Because ChannelIDs have a public and private part, the private part >>> can be much better protected. For example, by moving it out of the >>> browser process completely, even on standard machines, and even under >>> hardware-protection, where such capability exists. >> Completely spurious: hardware (or a separate process) does not know >> whether it is being asked to provide >> the ChannelID for a request that is genuine or one that the attacker >> provided after subverting the browser process. >> There also is a replay attack: a signature of a static string provides >> no liveness, contrary to assumptions made here. > > Hi Watson, > > I think you're misreading the draft: ChannelID signs hashes of > handshake messages, not a "static string". > > I do think ChannelID needs to explain the value of storing private > keys in a "secure element" further, and why storing ECDSA private keys > is better than, say, HMAC keys. I agree that HMAC would, of course, be much faster but I believe that public/private is needed for some of the higher level capabilities: http://www.browserauth.net/proof-key-federation-protocols Cheers AGL From ekr@rtfm.com Wed Oct 23 08:44:02 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C6411E840D for ; Wed, 23 Oct 2013 08:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQPBqBD-fEh6 for ; Wed, 23 Oct 2013 08:43:54 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) by ietfa.amsl.com (Postfix) with ESMTP id D621011E83A2 for ; Wed, 23 Oct 2013 08:43:10 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id l12so7589732wiv.3 for ; Wed, 23 Oct 2013 08:43:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Px6GYLIWnL+h3OGCWVmWfSJq0wPoKzdp1WCCWr1g7tc=; b=Fz3BSDIs9ntsQKqEPvM2HDMawRlbvqBSLV3soQTxgnkx6/MGAH3EtEVgXvFjVm2rwj wwuzEgwJB8a9uwLB232r/A+haD7jtaNYKcSXkOJ0/XHxAqFexjaj1HyHhDIw7befsULw FUnu/2CRX5jGP/4tBpm09tdyCvaXYdVj1mEig79aMrlmAYpJthiOFcL+6ZRLZYpdT/bt NOggs/X17BqrpMQddERB4L9/9GlEicncLxfhPfvb5aASSYVAUbMHNeaKC/3/vTp+QM7X oHfb7uL0+JgZvfs8xJPIulkPrdqH15W1Mp7ypfeya6ZkdFxdC9bOkoC5rccpoLoB6fwc hBsQ== X-Gm-Message-State: ALoCoQmy6VYKjq55LGjnIvL/iOF6HqZXN7jt2Ymo+p6TV5ktppk/W7Sssm2oDXmPic0l9tWWtoMS X-Received: by 10.194.174.36 with SMTP id bp4mr2196827wjc.7.1382542990104; Wed, 23 Oct 2013 08:43:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.152.137 with HTTP; Wed, 23 Oct 2013 08:42:30 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <5267E276.9050107@gnutls.org> References: <526797EE.2000206@gnutls.org> <5267E276.9050107@gnutls.org> From: Eric Rescorla Date: Wed, 23 Oct 2013 08:42:30 -0700 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=089e0141a0aecff00404e96a5f3d Cc: "tls@ietf.org" , =?ISO-8859-1?Q?Joachim_Str=F6mbergson?= Subject: Re: [TLS] comparison of draft-josefsson-salsa20-tls-02 and draft-agl-tls-chacha20poly1305-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 15:44:02 -0000 --089e0141a0aecff00404e96a5f3d Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 23, 2013 at 7:51 AM, Nikos Mavrogiannopoulos wrote: > as a general comment I think DTLS' resilience on forged packets > isn't that good. It makes it a perfect target to lay an attack. I think > it would be much better to have a limit by default on the allowed > packets with wrong MAC. S 4.2.7 provides some guidance in this area, but it's pretty vague: Note that Alert messages are not retransmitted at all, even when they occur in the context of a handshake. However, a DTLS implementation which would ordinarily issue an alert SHOULD generate a new alert message if the offending record is received again (e.g., as a retransmitted handshake message). Implementations SHOULD detect when a peer is persistently sending bad messages and terminate the local connection state after such misbehavior is detected. It certainly seems like it would be a good thing to document some better guidance about how many bad MACs you should tolerate. Do you have any thoughts about what makes sense? -Ekr --089e0141a0aecff00404e96a5f3d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Oct 23, 2013 at 7:51 AM, Nikos Mavrogiannopoulos <nmav@gnut= ls.org> wrote:
as a= general comment I think DTLS' resilience on forged packets
isn't that good. It makes it a perfect target to lay an attack. I think=
it would be much better to have a limit by default on the allowed
packets with wrong MAC.

S 4.2.7 provides so= me guidance in this area, but it's pretty vague:

=A0 =A0Note that Alert messages are not retransmitted at all, even when = they
=A0 =A0occur in the context of a handshake. =A0However, a DTLS impleme= ntation
=A0 =A0which would ordinarily issue an alert SHOULD gener= ate a new alert
=A0 =A0message if the offending record is receive= d again (e.g., as a
=A0 =A0retransmitted handshake message). =A0Implementations SHOULD det= ect when
=A0 =A0a peer is persistently sending bad messages and t= erminate the local
=A0 =A0connection state after such misbehavior= is detected.

It certainly seems like it would be a good thing to doc= ument some
better guidance about how many bad MACs you should tol= erate.

Do you have any thoughts about what makes s= ense?

-Ekr

=A0
--089e0141a0aecff00404e96a5f3d-- From tom@ritter.vg Wed Oct 23 08:58:39 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F7111E80E7 for ; Wed, 23 Oct 2013 08:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7bV7PAVUr7X for ; Wed, 23 Oct 2013 08:58:39 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id BF1F611E8391 for ; Wed, 23 Oct 2013 08:58:38 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id lf10so1146764pab.34 for ; Wed, 23 Oct 2013 08:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4s2oVeKkARiJq3PeA3RtXCIQ+6kwuUGkmevFvh4hU8U=; b=QMuLuaCbUesTzNOlZs6IpwcvlCdK/5HtDazsLbgYuGY5nw7MwBsFVdxsgOM+EIx/Md KxCjt3dDSd6aVBegOxjwEVdiKwbo2/htit4j62HomJz96VdeB32iRH4zZ0q2iqjrvXdk Tq9ywvGjXTdMe5aUmDaCLDpAnOIv81Lgm+f5Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=4s2oVeKkARiJq3PeA3RtXCIQ+6kwuUGkmevFvh4hU8U=; b=jLNXafDcJH7bDrPgRU9m8wtcddeJNJpgZCGEjH5T46t9nO2g4sIiu1KRaoFYMv2qIi tiF08nu1o+NgFDzM+VfcsPDNtI36GDNoUuCpcYsRg71PGt9CsQEloZJ6imcCDyN+cxnm PLyzJ2iMZ6qdvD8alYUG6HD5CgE8m9/X/PQxBemnIDWisvcjao9nAT7WPebQFTb3R55m UHXx6zOsqoyHM+PC1EEv29kVEdOBlzFOcKDnMBcUoOaMdyzhKjMqW4NF9v/daBMn4hyp 7NOY648TsasJhxkgYcgSsKVGprYlj3uRNGuJR9sKOksYowGNzNP47gap8tjPKHCJ7Rbs Dc3A== X-Gm-Message-State: ALoCoQm4fRZ37VRZ1aqqypnzh2NdGxQ9DO8ldOkYwgRz4M5rYW5vz/zXHfi3KKyfWxkHj8t7sPCJ X-Received: by 10.68.131.70 with SMTP id ok6mr2417811pbb.126.1382543916943; Wed, 23 Oct 2013 08:58:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.129.3 with HTTP; Wed, 23 Oct 2013 08:58:11 -0700 (PDT) In-Reply-To: References: From: Tom Ritter Date: Wed, 23 Oct 2013 11:58:11 -0400 Message-ID: To: Phillip Hallam-Baker Content-Type: text/plain; charset=ISO-8859-1 Cc: "tls@ietf.org" Subject: Re: [TLS] OCSP Must Staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 15:58:39 -0000 I support this. I would also like to seek to have it added to the HTTP Strict Transport Security header as an option (same as includeSubdomains), so that it can pin to the domain as well as the certificate - although that may need to wait until this is standardized and identifiers solidified. -tom From n.mavrogiannopoulos@gmail.com Wed Oct 23 09:34:52 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63CC911E83E2 for ; Wed, 23 Oct 2013 09:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xJh85-mwuWT for ; Wed, 23 Oct 2013 09:34:50 -0700 (PDT) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8E121F9CA9 for ; Wed, 23 Oct 2013 09:34:49 -0700 (PDT) Received: by mail-ee0-f53.google.com with SMTP id c13so520959eek.26 for ; Wed, 23 Oct 2013 09:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=I928MMeP2v0uA7XU6SD+iL/L5ebTdj5Zj2zOeLISQIc=; b=wUhk5/9hYe2ENMj7ldVUQDHiGzVPVAgHj5p0MWAy0PV53TuWRfszkTtpO8WiCBCMl6 uqx2bDhMulaBl9zSO03aEwf+ck94Gy2dyJkTZ7DU8toLcIVs5ogeQ1KL02KdXpPX9jeD jO9cDb3m+TH2ShaGIvmwOucrfHMKA+yzqepupZ/JtpDNegAaXjWYIdeWecwrXrdkQIVc H6l3B5iUxcJFw+g0B2KTZiHetLnL6S9+eYOaHSwjp0TeEd7U38wXn2ZFGNNk3d12EZuJ hu1B0xd3ONgFdt4Xi2iqbXBW2myAjwOikwY/Vv29RUOsIqmhc2FEf7HyFQ9rWnvkzbSD WrHQ== X-Received: by 10.14.225.199 with SMTP id z47mr2845255eep.24.1382546088822; Wed, 23 Oct 2013 09:34:48 -0700 (PDT) Received: from [10.100.2.17] (ip-62-245-100-42.net.upcbroadband.cz. [62.245.100.42]) by mx.google.com with ESMTPSA id k7sm72050855eeg.13.2013.10.23.09.34.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 09:34:47 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <5267FAA7.80601@gnutls.org> Date: Wed, 23 Oct 2013 18:34:47 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: Adam Langley References: <526797EE.2000206@gnutls.org> <5267E276.9050107@gnutls.org> In-Reply-To: X-Enigmail-Version: 1.5.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" , =?UTF-8?B?Sm9hY2hpbSBTdHLDtm1iZXJnc29u?= Subject: Re: [TLS] comparison of draft-josefsson-salsa20-tls-02 and draft-agl-tls-chacha20poly1305-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 16:34:52 -0000 On 10/23/2013 04:58 PM, Adam Langley wrote: > On Wed, Oct 23, 2013 at 10:51 AM, Nikos Mavrogiannopoulos > wrote: >> As far as I understand you use chacha to generate the keystream for >> poly1305. Thus you carry state between records (chacha is a stream >> cipher). I don't know if I have missed anything there, but I don't see >> resetting chacha with a new IV per MAC calculation. > > There is no state carried between records: "ChaCha20 is run with the > given key and nonce and with the two counter words set to zero. The > first 32 bytes of the 64 byte output are saved to become the one-time > key for Poly1305." (The nonce is the sequence number of the record.) > (http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-00#section-5) I had assumed that you used the Poly1305-AES construction but with Chacha in place of AES. Clearly this isn't the case, and even the attacks described may not apply to your construction. I have not seen this construction before. It looks pretty elegant. Has it been used somewhere else? regards, Nikos From n.mavrogiannopoulos@gmail.com Wed Oct 23 09:41:36 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2872311E8452 for ; Wed, 23 Oct 2013 09:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHbtcAoZvOvk for ; Wed, 23 Oct 2013 09:41:34 -0700 (PDT) Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 61CDE11E840E for ; Wed, 23 Oct 2013 09:40:58 -0700 (PDT) Received: by mail-ee0-f41.google.com with SMTP id d49so532555eek.0 for ; Wed, 23 Oct 2013 09:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=XhYv6f1snI0NFja0GVZg9rVpm8pngi5xX7h6CjgEsT0=; b=cO4HlbKMt1xyKrocU0PMXyG9pMtSd6tLb/F9ni4gzXKu+wBOQyfIw5ok1Lzp7Jzmc7 /nkEP2sf6jw4B7zGgPi60qVS06QLT3DaslHQBld+a1A8Dfk6Ybt6W0O5aLjAfcqaa5Um uRwI6k3CxnjGM3tJ26ig+OVvrxEcGeZdI8hea4t3HKecN2CrVpuvV/Ep16r05ld3zjeD k1/RRRdoXMrxLrI6R1Z9CNm4mDnwXDMzy/2/vUCb3FPVqx8cLBDy07aHe6D5Km28Yxkr DCVmJwdqIJHQs0HzWJPdmp3tzmyq2gGjYH5S4A2Z93v3QgU8dJsp5C3LiwR6aVlt6np7 A5pA== X-Received: by 10.14.225.199 with SMTP id z47mr2877792eep.24.1382546449098; Wed, 23 Oct 2013 09:40:49 -0700 (PDT) Received: from [10.100.2.17] (ip-62-245-100-42.net.upcbroadband.cz. [62.245.100.42]) by mx.google.com with ESMTPSA id h45sm72162914eeg.5.2013.10.23.09.40.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 09:40:48 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <5267FC0A.7040009@gnutls.org> Date: Wed, 23 Oct 2013 18:40:42 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: "tls@ietf.org" References: <526797EE.2000206@gnutls.org> <5267E276.9050107@gnutls.org> In-Reply-To: X-Enigmail-Version: 1.5.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] comparison of draft-josefsson-salsa20-tls-02 and draft-agl-tls-chacha20poly1305-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 16:41:36 -0000 On 10/23/2013 05:42 PM, Eric Rescorla wrote: > as a general comment I think DTLS' resilience on forged packets > isn't that good. It makes it a perfect target to lay an attack. I think > it would be much better to have a limit by default on the allowed > packets with wrong MAC. > S 4.2.7 provides some guidance in this area, but it's pretty vague: > > Note that Alert messages are not retransmitted at all, even when they > occur in the context of a handshake. However, a DTLS implementation > which would ordinarily issue an alert SHOULD generate a new alert > message if the offending record is received again (e.g., as a > retransmitted handshake message). Implementations SHOULD detect when > a peer is persistently sending bad messages and terminate the local > connection state after such misbehavior is detected. > It certainly seems like it would be a good thing to document some > better guidance about how many bad MACs you should tolerate. > Do you have any thoughts about what makes sense? I was thinking of disabling wrong MAC tolerance completely if the underlying layer has checksums. UDP for example has checksums and packets that are altered due to transmission errors will be discarded anyway. In lower protocols such as ethernet we also have checksums. If someone needs to transmit in raw without any checksums, he could exceptionally allow wrong MAC tolerance. regards, Nikos From agl@google.com Wed Oct 23 09:46:29 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C7611E81BE for ; Wed, 23 Oct 2013 09:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2qBcXYNVKhp for ; Wed, 23 Oct 2013 09:46:28 -0700 (PDT) Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEB411E83C3 for ; Wed, 23 Oct 2013 09:46:24 -0700 (PDT) Received: by mail-vb0-f53.google.com with SMTP id i3so664260vbh.26 for ; Wed, 23 Oct 2013 09:46:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SYipiw6+Dz4z1DREz1r/u4FX46jsGDd7K9RldyTs6ks=; b=TfJFoICNHLmEhtHAJkXdVb/xhHCx8zODM8sgqoOutnnPA6meQ4HZuPh21IQ33vfJSZ 5IxmJCJUtuX37W5lIvtLFuuC/GDsOdOPySgCBD6Z3CkQnGu/K/bx0k/N875l2lm/FD/X iOV22Lx+wPccxWEVuaRuG11JlEu8kR+E25KHOKLM2EyA/VsOsLRaUjwQ5CWsxFgMU07N DfnWM2+u1xWUakI18Tm++t7zGn+iFMt8w5RRCD+NNDCfAkdsKLb4gbUJ82nqDrbWn0wO zKj3HTwUBPzMdMYCBiVgDVo/kAW5sDOuKLZ7ccDBpyn0JEQDvSjng6L75rpK1eBlsJ4s c5Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=SYipiw6+Dz4z1DREz1r/u4FX46jsGDd7K9RldyTs6ks=; b=GMFZLDjjB2yoDufeDQ9mU+mQ55m7u5J5WnBEqjX4rNFfpfoVE4Rcn7kBKny4r2Jvu0 5tjHbR6G3iR+Njmd69znsjx5k15i+7x2bx0Yjrm4ydFFMPg/oPi9st8MU5KasMDJgu7K 9h/mJcsIRDHqUA1L+lXHFilU2T/DSZ3sR7K9kYVNdd2fhS41MLAZ5NlixXO/dwSCejai t/7C4VlqpsWfd1sYo47bsaO7AWduQkQH9Bda74hu+AYY3LaZqcSrlFqZrQ1ZJWJCaLv2 M5Uo+lf8gda/hYirfWYXHefWNY5LBMS/QDDBQp4ZtJsUPoH2nBfhG7hZiQls4on4jIj+ QGKw== X-Gm-Message-State: ALoCoQlJVqfheZv1yBAjLqbnO2k2J99pXUio+mIMqPpiwEqo77LytQKeSTeRd09pu3ofXMN8XzdGQwkBz42UFaf/JgCzr0H+PYJQaQwgLxVApMqcvrtbon3Pl0XIjP7MgS5M5IjZy2JoYV9SInebKcuRUVEe77pqdvV7KslX3h5isOEvQPjW6gz3hobNKwDxVs/v4iZQbYPp X-Received: by 10.220.184.70 with SMTP id cj6mr1791138vcb.23.1382546783649; Wed, 23 Oct 2013 09:46:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.100.40 with HTTP; Wed, 23 Oct 2013 09:46:03 -0700 (PDT) In-Reply-To: <5267FAA7.80601@gnutls.org> References: <526797EE.2000206@gnutls.org> <5267E276.9050107@gnutls.org> <5267FAA7.80601@gnutls.org> From: Adam Langley Date: Wed, 23 Oct 2013 12:46:03 -0400 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" , =?UTF-8?Q?Joachim_Str=C3=B6mbergson?= Subject: Re: [TLS] comparison of draft-josefsson-salsa20-tls-02 and draft-agl-tls-chacha20poly1305-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 16:46:29 -0000 On Wed, Oct 23, 2013 at 12:34 PM, Nikos Mavrogiannopoulos wrote: > I had assumed that you used the Poly1305-AES construction but with > Chacha in place of AES. Clearly this isn't the case, and even the > attacks described may not apply to your construction. I have not seen > this construction before. It looks pretty elegant. Has it been used > somewhere else? I lifted it from NaCl, see section 9 of http://cr.yp.to/highspeed/naclcrypto-20090310.pdf. The difference is that the ChaCha AEAD doesn't use HChaCha, because the extended nonce isn't useful, and it moves the authenticator from the beginning to the end of the output because that fits more easily into existing code bases. Cheers AGL From rransom.8774@gmail.com Wed Oct 23 09:48:09 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399F911E8246 for ; Wed, 23 Oct 2013 09:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dm8iunwLLE69 for ; Wed, 23 Oct 2013 09:48:08 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 170B521F9A6C for ; Wed, 23 Oct 2013 09:48:02 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id w4so612371qcr.40 for ; Wed, 23 Oct 2013 09:47:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T9VZOSdssjnWRQIlFp0aojWVNOgfzHu7qfB9H3S4ojg=; b=rZsbZ2N/JS/Mv7WR7txJxiqz2hzFGpDEwuK/TjokXi1zUGv0C2UhOapMIsMPrPhmOf tslIX4iQn632eR9ir/be9L92gPpLxDTzXUFQZZkKRzQqo1P9pG4lkGAUxTnMjhZbpHU/ CV61Uii3DDxRXGvBOJkX5u5hUMq3E8gfOJeimYk77+EzqYjINZyUXe0ih+MZyeq7/nUy w1CU1IaKpLlkQA+x8Nme8rlcJcMhzyX0/OBH6pmiSmIAK2rD2L7jSd9tDJJUcsy1LFKU /MeJRA0Xc1tDz1aTzigaKwcjkeX6LYcg22MgcS9wOgpBn7Sa8dbU+JZk6/ZIr17wlzfV 8p8g== MIME-Version: 1.0 X-Received: by 10.49.25.47 with SMTP id z15mr3393669qef.27.1382546878348; Wed, 23 Oct 2013 09:47:58 -0700 (PDT) Received: by 10.229.12.198 with HTTP; Wed, 23 Oct 2013 09:47:58 -0700 (PDT) In-Reply-To: <5267FAA7.80601@gnutls.org> References: <526797EE.2000206@gnutls.org> <5267E276.9050107@gnutls.org> <5267FAA7.80601@gnutls.org> Date: Wed, 23 Oct 2013 09:47:58 -0700 Message-ID: From: Robert Ransom To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" , =?UTF-8?Q?Joachim_Str=C3=B6mbergson?= Subject: Re: [TLS] comparison of draft-josefsson-salsa20-tls-02 and draft-agl-tls-chacha20poly1305-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 16:48:09 -0000 On 10/23/13, Nikos Mavrogiannopoulos wrote: > On 10/23/2013 04:58 PM, Adam Langley wrote: >> On Wed, Oct 23, 2013 at 10:51 AM, Nikos Mavrogiannopoulos >> wrote: >>> As far as I understand you use chacha to generate the keystream for >>> poly1305. Thus you carry state between records (chacha is a stream >>> cipher). I don't know if I have missed anything there, but I don't see >>> resetting chacha with a new IV per MAC calculation. >> >> There is no state carried between records: "ChaCha20 is run with the >> given key and nonce and with the two counter words set to zero. The >> first 32 bytes of the 64 byte output are saved to become the one-time >> key for Poly1305." (The nonce is the sequence number of the record.) >> (http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-00#section-5) > > I had assumed that you used the Poly1305-AES construction but with > Chacha in place of AES. Clearly this isn't the case, and even the > attacks described may not apply to your construction. I have not seen > this construction before. It looks pretty elegant. Has it been used > somewhere else? It's used in the 'box' and 'secretbox' operations in NaCl. See also section 2.5 of . Robert Ransom From agl@google.com Wed Oct 23 11:16:22 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED27811E82D2 for ; Wed, 23 Oct 2013 11:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUhRDluZwWEn for ; Wed, 23 Oct 2013 11:16:22 -0700 (PDT) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id AD3CB11E83CA for ; Wed, 23 Oct 2013 11:16:20 -0700 (PDT) Received: by mail-vc0-f174.google.com with SMTP id ld13so418773vcb.5 for ; Wed, 23 Oct 2013 11:16:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UKxWfKqZ4OkgoZ1K5e1fmNsDq2BNIuOOhfFN/l9+nIs=; b=eFTZ5yYLMP4sAcpj5h63s24DliFJej0eZGtdJNRaOOxRgL22ydA4/8Shs2EO+0uF99 HrWVJoCc9rBF3U9yXeN/C8Vr9bRQzwRMQjIV5k9xJ2rJ3mkUlPThoxHV2D/46hpGqOkb 04fRZi/uxUecs9B/vPDGyZ5D6cjz3xVolOs5HlZ4ZFO9CcoknIybkwOjZnH7P+69c03D 1sJ6ALyPqJs6lGrcO/P+J9ufnsEjkYHtzLGJ1hNyzyoIWEgkfJecANmLw2O5SMsg0sAL 3g63XMp+uuY6yM+IXVezD5AXs1ZrVABs7/7NwTkANcidaALbaEwhRKiuOhszKz+20Q3f mKOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=UKxWfKqZ4OkgoZ1K5e1fmNsDq2BNIuOOhfFN/l9+nIs=; b=KUYYC2a0E/roz6WAtPheXMoUNiE8rklQ0js1nwqt1JZcEnME7ixVdjT46kjGRQmDYZ Xs2uPl9UtulO/jFBapr6N/zWqEUAbXEcEfSKdSksoYF9qpinbOxgmOBcixAJcIUO/1Df AKJhptupXrz5gV7Znx2uoIY/TesjdszK6GwZnwGONgUYge4Ic9HYqLQov+Fiq0Jx9qVs tZ0BaJVuHmd1rHafTLhn9wbWQTkKca3mxY988U6FqvezxRzx7tMAw2MnqmwYAGt8yBMi KE4XpnxLWGANL6vCH0R7r4+RsuMDvGBZIlVFsbk1Vv1n7o29chnvCKlHQ7HKTnKjEHZ/ Z9LA== X-Gm-Message-State: ALoCoQmsGDu3MVExZEHD2YbcLj9TJB2xDUykj92BNk+Ux4ApgpvAEZcI1Q3Hx//VUn8n7NKMLbpx0ncxfVxQTiQJswlLP6EAFx3/Z10VeffCuLX6m8+wupBtyH4m2RoN2Cz35QHpTVc8FmNJnY3KMegWWyLnBTouI84ISxCQlF5Ofaxa9MhZJvvtKETUt7Qs39IwWmuvNZRU X-Received: by 10.58.107.4 with SMTP id gy4mr17580veb.39.1382552180182; Wed, 23 Oct 2013 11:16:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.100.40 with HTTP; Wed, 23 Oct 2013 11:15:59 -0700 (PDT) In-Reply-To: References: From: Adam Langley Date: Wed, 23 Oct 2013 14:15:59 -0400 Message-ID: To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Channel ID and server load: comment on draft-balfanz-tls-channelid-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 18:16:23 -0000 On Wed, Oct 23, 2013 at 11:21 AM, Adam Langley wrote: > I have not looked into batching ECDSA verifies but [1] seems quite > clear that it's dealing with unmodified ECDSA signatures (paywalled > I'm afraid, but the first two pages are free). They report a speedup > of 2x for batches with multiple signers, which is roughly equal to the > reported speedup for Ed25519 (273K -> 134K cycles). > > [1] http://rd.springer.com/chapter/10.1007%2F978-3-642-31410-0_1 It's been pointed out to me that the technique described in that paper is broken in [2] (see section 2). So it may well be that ECDSA batch verification is infeasible. [2] http://cr.yp.to/badbatch/badbatch-20120919.pdf Cheers AGL From n.mavrogiannopoulos@gmail.com Wed Oct 23 13:50:21 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A8421F9DFB for ; Wed, 23 Oct 2013 13:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HL4uUlXzsTe for ; Wed, 23 Oct 2013 13:50:20 -0700 (PDT) Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 17F3711E8252 for ; Wed, 23 Oct 2013 13:50:18 -0700 (PDT) Received: by mail-ee0-f52.google.com with SMTP id d51so665356eek.39 for ; Wed, 23 Oct 2013 13:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=vkFoA8t+ryiiRiLcDUehgoa8PyT8TblbckdCqORUank=; b=XQaE207njQFU0TmLAEfz1NneAgYPc1t7DoLKmwJG8jjZkO85gFbdQlRZ8PyLFW8Tq8 EO8FQmMT3rLeWqgv33axj124DfiP9A9otWKiF6tZMEu/nIJSYE2cszOW8CdtDqD/Y2g+ VvZJhh6+vrpbU7UGQ+5mwYACXWKMbO8016rbcyUEHRFLWcrt/NJ7797K49AIH5D4xicv qj7sr42el5h3D2+qxiOCSuHafRX8wc/Yl/IZZ4afthSP9dv83nqa6nGiyCirj2SS4YIG RaW+Dx9RuQGjz0niHyYPeq/QD333Tn9wmZDKkXpNoIGI8axC6cRADUd4mKT081ucYI3P cczw== X-Received: by 10.15.98.194 with SMTP id bj42mr4032620eeb.12.1382561415008; Wed, 23 Oct 2013 13:50:15 -0700 (PDT) Received: from [10.100.2.17] (ip-62-245-100-42.net.upcbroadband.cz. [62.245.100.42]) by mx.google.com with ESMTPSA id r48sm74541933eev.14.2013.10.23.13.50.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Oct 2013 13:50:14 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <52683680.8020909@gnutls.org> Date: Wed, 23 Oct 2013 22:50:08 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: "tls@ietf.org" References: <526797EE.2000206@gnutls.org> <5267E276.9050107@gnutls.org> <5267FC0A.7040009@gnutls.org> In-Reply-To: <5267FC0A.7040009@gnutls.org> X-Enigmail-Version: 1.5.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [TLS] DTLS resilience [was: comparison of draft-josefsson-salsa20-tls-02 and draft-agl-tls-chacha20poly1305-02] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 20:50:21 -0000 On 10/23/2013 06:40 PM, Nikos Mavrogiannopoulos wrote: >> as a general comment I think DTLS' resilience on forged packets >> isn't that good. It makes it a perfect target to lay an attack. I think >> it would be much better to have a limit by default on the allowed >> packets with wrong MAC. >> S 4.2.7 provides some guidance in this area, but it's pretty vague: >> >> Note that Alert messages are not retransmitted at all, even when they >> occur in the context of a handshake. However, a DTLS implementation >> which would ordinarily issue an alert SHOULD generate a new alert >> message if the offending record is received again (e.g., as a >> retransmitted handshake message). Implementations SHOULD detect when >> a peer is persistently sending bad messages and terminate the local >> connection state after such misbehavior is detected. >> It certainly seems like it would be a good thing to document some >> better guidance about how many bad MACs you should tolerate. >> Do you have any thoughts about what makes sense? > > I was thinking of disabling wrong MAC tolerance completely if the > underlying layer has checksums. UDP for example has checksums and > packets that are altered due to transmission errors will be discarded > anyway. In lower protocols such as ethernet we also have checksums. > > If someone needs to transmit in raw without any checksums, he could > exceptionally allow wrong MAC tolerance. It seems I answered hastily. I think there is an issue with what I proposed. I see 2 things that need to be ensured here. 1. The session must be resilient to accidental transmission errors. 2. The session must be resilient to termination by someone who hasn't access on the communication line Do I miss something else? [I don't think there is point being resilient to someone with access to the communication line, as he could always cause a DoS by simply dropping all packets.] My proposal above handles 1, but not 2. In the UDP case anybody can forge a DTLS packet and send it on the server port claiming to be the client (he doesn't need to know the client port, he just sends many packets with all possible ports). DTLS will discard packets out of epoch, or with old sequence numbers, but sequence numbers are easy to guess in DTLS. They are sequential and start from 0. Thus one could "easily" avoid the window check in DTLS and pass a packet with an invalid MAC. So if wrong MAC tolerance is removed in a future revision of DTLS, it has to be combined with something that ensures (2). That could be random sequence numbers (similar to TCP), or something else. regards, Nikos From trevp@trevp.net Wed Oct 23 18:40:59 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E809A11E80DC for ; Wed, 23 Oct 2013 18:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcOaPiIfxKui for ; Wed, 23 Oct 2013 18:40:55 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4791F11E81A7 for ; Wed, 23 Oct 2013 18:40:55 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id n12so1646751wgh.35 for ; Wed, 23 Oct 2013 18:40:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BmERWkujDo1m0f/tikZ3ZTWDfp0l9IjI0bs5W/R6x48=; b=gtMtnooFFLpFeg6G5Sk4g6mOTohqnkcQo9tJ46EmD/Sw37uk2qjJ8CfZrU3PzWeRZp Ghhr3yg0aYeLZQJo24GsMXsTZ98UwsiStx/8NaD15K+lTpMZm1zXUjomZpeZFMdR2eIG KkLHXAREcD6ZhT+UsTuWHWKJrDVCLsWM76fux1fWUaXyX6mx7if0tQ3d9FWQrruanzuM ccGOW+GDp0Ikh4rTUW4GhJcvKg8uR7RyphEMAg1eMbw3M7Q8PzHTWdLLyZLfj6oEXkg9 IN33P13TmKpqmVpTdkP0UoC2DKwENxTyhn9mBHJviAQBPkoGDCzqeas98zqh1iANxMAp OrGw== X-Gm-Message-State: ALoCoQkhjXR7HP1O3zK9lSAuP1/GuCls6EiWT8NOAoIICnzvz7EPu2drF7v8RQ2Bpif6ZvecNQBc MIME-Version: 1.0 X-Received: by 10.180.9.139 with SMTP id z11mr4423824wia.22.1382578854243; Wed, 23 Oct 2013 18:40:54 -0700 (PDT) Received: by 10.216.61.13 with HTTP; Wed, 23 Oct 2013 18:40:54 -0700 (PDT) X-Originating-IP: [199.83.223.81] In-Reply-To: References: Date: Wed, 23 Oct 2013 18:40:54 -0700 Message-ID: From: Trevor Perrin To: Adam Langley Content-Type: text/plain; charset=ISO-8859-1 Cc: "tls@ietf.org" Subject: Re: [TLS] Channel ID and server load: comment on draft-balfanz-tls-channelid-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 01:41:00 -0000 On Wed, Oct 23, 2013 at 8:25 AM, Adam Langley wrote: > On Tue, Oct 22, 2013 at 2:32 PM, Trevor Perrin wrote: >> >> I do think ChannelID needs to explain the value of storing private >> keys in a "secure element" further, and why storing ECDSA private keys >> is better than, say, HMAC keys. > > I agree that HMAC would, of course, be much faster but I believe that > public/private is needed for some of the higher level capabilities: > http://www.browserauth.net/proof-key-federation-protocols For binding cookies to a browser you could get by with symmetric crypto. There's proposals from websec on this (eg "Smart Cookies" [1]). For binding a token sent from an IdP to an RP, I wonder if there might be a symmetric-key analogue to "Proof-key federation": AIUI, the goals are: 1) IdP receives some sort of proof that the same browser sharing channel key Ki with the IdP is also sharing channel key Kr with some RP. - IdP signs an assertion that is only useable by a browser with channel key Kr. "Proof-key federation"/ChannelID achieves this by: 1) A Javascript API where a browser signs cross-certificates between the ECDSA keys Ki and Kr 2) The IdP refers to Kr in its signed assertion Imagine instead if Ki and Kr were HMAC "cookie keys" associated with smart cookies between the (browser, IdP) and (browser, RP). A javascript API could be used to produce the triple: (nonce, HMAC(Ki, nonce), HMAC(Kr, nonce)) The triple would be forwarded to the IdP who would check HMAC(Ki, nonce), then include the triple in the signed assertion. The RP would check HMAC(Kr, nonce). The assertion is thus only usable to a browser that know Kr, and is only issued to a browser that knows Ki. Anyways, dunno if this is better than ChannelID or if I'm missing something (probably). But I'd like to see more analysis of why public-key was chosen for ChannelID, in light of computation costs. Trevor [1] http://www.ietf.org/mail-archive/web/websec/current/msg01729.html From watsonbladd@gmail.com Thu Oct 24 12:52:31 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDC311E8345 for ; Thu, 24 Oct 2013 12:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXvU+ytuF0+t for ; Thu, 24 Oct 2013 12:52:31 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id DE75811E82F8 for ; Thu, 24 Oct 2013 12:52:30 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id f12so2845138wgh.31 for ; Thu, 24 Oct 2013 12:52:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3bzCavslP9F9VCmy66dtQ+KQEK8uKrgeH8tAIEWS20s=; b=E14cG7Q0xsy2VBUxLbV0vK73mJA6x3dr5vC7ypvmMdmcwNhrs+91HU65F8vBzXc5D9 HP5iJ0GkDVJx0wsYI5gFTIa8/A0/X5tVPui/pgouuAwr5FRXKf8W2l/I8p5t0H4a4oIr KbPFGGjjX/eq4+FBIImgcqS/S2YkDRUc8IUYSVnUrGHd2sv3I5IxefMcYVGu2NwEP7tf 3wtWJeJOGCNmutO9Mmc/tJVuFSJzdcChK0koiys+3SYoEoFhGosBQsIxhqqXvgyO8ejO Bcys2FbZ1o68Ms2f2ChtqeEvZjhssLEFTxjbBZXszIKauvjZPwgSVbA2AXsOterr4fC7 kVoA== MIME-Version: 1.0 X-Received: by 10.180.76.205 with SMTP id m13mr3684376wiw.10.1382644350151; Thu, 24 Oct 2013 12:52:30 -0700 (PDT) Received: by 10.194.242.131 with HTTP; Thu, 24 Oct 2013 12:52:30 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 Oct 2013 12:52:30 -0700 Message-ID: From: Watson Ladd To: Adam Langley Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Channel ID and server load: comment on draft-balfanz-tls-channelid-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 19:52:32 -0000 On Wed, Oct 23, 2013 at 8:21 AM, Adam Langley wrote: > On Tue, Oct 22, 2013 at 1:52 PM, Watson Ladd wrote: >> Completely spurious: hardware (or a separate process) does not know >> whether it is being asked to provide >> the ChannelID for a request that is genuine or one that the attacker >> provided after subverting the browser process. > > Certainly that's true. However, it limits the attacker to an online > attack: closing the laptop etc stops them. That's a lot better than > the current situation where cookie theft is a significant problem. Nope: the attacker could provide their own ChannelID and force the user to reauthenticate, thus causing their secret key to be trusted. They could disable ChannelID entirely and force fallback to cookies, which they then steal. Online attack cleans out a bank account just as quickly as offline. ChannelID provides a benefit only if the user interaction authorizing access to the ID generator can be secured from malware interference, in which case we could just use a cookie there instead. > > Additionally, ChannelID can be extended to an "ignition key" model > where connections need to reprove the presence of the ChannelID every > $n minutes. (That might get the verification load to the point where > batching is useful :) Steal a resumption ticket and you have the same attacker issue for $n minutes. > >> There also is a replay attack: a signature of a static string provides >> no liveness > > ChannelID signs the handshake which includes an nonce from the server. Yes, I stand corrected on this point. > >> Because of a stupid missing bit, you don't know which of two points >> lead to the r value. If you did know this bit, you could >> make the verification equation an identity in the curve and apply the >> Bos-Coster trick Ed25519 does. I've not come up with >> a way around this issue. Guess and check isn't worth it: it ends up >> costing more than verifying one at a time. > > I have not looked into batching ECDSA verifies but [1] seems quite > clear that it's dealing with unmodified ECDSA signatures (paywalled > I'm afraid, but the first two pages are free). They report a speedup > of 2x for batches with multiple signers, which is roughly equal to the > reported speedup for Ed25519 (273K -> 134K cycles). > > [1] http://rd.springer.com/chapter/10.1007%2F978-3-642-31410-0_1 > > >> Fair enough: I assume P256 is performant enough for the applications >> being imagined, but given >> the constant kvetching about performance, I'm not sure everyone shares >> that. (Then again, they >> kvetch while using interpreted languages...) > > I am not terribly happy with the performance implications of ChannelID > either, but we're still exploring our options. > > > Cheers > > AGL -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From dkg@fifthhorseman.net Thu Oct 24 20:19:12 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 281CB11E8296 for ; Thu, 24 Oct 2013 20:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNusU36eU2rm for ; Thu, 24 Oct 2013 20:19:06 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 77A4211E8243 for ; Thu, 24 Oct 2013 20:19:03 -0700 (PDT) Received: from [192.168.42.101] (h-67-101-156-212.nycm.ny.dynamic.megapath.net [67.101.156.212]) by che.mayfirst.org (Postfix) with ESMTPSA id 60153F984 for ; Thu, 24 Oct 2013 23:18:58 -0400 (EDT) Message-ID: <5269E31F.3050203@fifthhorseman.net> Date: Thu, 24 Oct 2013 23:18:55 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9 MIME-Version: 1.0 To: IETF TLS WG References: <20130930192805.1984A1A9C2@ld9781.wdf.sap.corp> In-Reply-To: <20130930192805.1984A1A9C2@ld9781.wdf.sap.corp> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2JREKWNIHPTIPDOQPWDCL" Subject: Re: [TLS] New Algorithm identifier for EDH > 1024 bits? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: IETF TLS WG List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 03:19:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2JREKWNIHPTIPDOQPWDCL Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [picking up a slightly stale thread, sorry for the lag] On 09/30/2013 03:28 PM, Martin Rex wrote: > Peter Gutmann wrote: >> Could that be because of all of the TLS_DHE_DSS_* suites, with DSS lim= ited to >> 1024 bits so implementers also limited the matching DH to 1024 bits? = Just >> wondering what other reason there could possibly be for artificially l= imiting >> the size to 1024 bits. >=20 > The delay incurred by key generation maybe? >=20 > The app-supplied credentials are either RSA or DSA. So for DHE, > _everything_ has to be newly generated after process start and potentia= lly > in-band during the TLS handshake, unless the application caller has > written some code that does generation out-of-band and installs/updates= > the DHE keying material regularly. Just to clarify, for DHE not *everything* has to be generated at connection time or even after process start. The DH group itself (g and p) can be chosen (and remain static) at the time of installation or system configuration or service initialization, and only the secret key needs to be selected at connection time. DH parameter generation (group selection) is a significantly more expensive than secret key selection. There is quite a bit of software out there that allows the administrator to select or configure the DH parameters that will be offered by the server while doing ephemeral Diffie-Hellman without a large delay caused by secret generation. Regards, --dkg ------enig2JREKWNIHPTIPDOQPWDCL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQJ8BAEBCgBmBQJSaeMfXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcyFEQAJIVs811MwcwxsBFAhqfL+Rk tgD5S7s47BUIzE/NBY6BhILvRhycwhu2DKhoEzfH/8+9dQCK8oVQ7dx8WNA+yiYo y9EZp0XIsB9xqayln10gWrIl2P2dskkECQuXBVzkn+JTsfGwE7wLD7okqMyey9Dt pa59gQG4w6sw+soEsCNc4rQIUH/ArU7AyY7ZXz/AyjBhpfqhv8WIE2LwMQxgI9mh I0c09bBFfZVPVymADIy1IWM+0CZgJl/k4rgDoj1PZV4+GGqnQnHzFFZOLfTTaPKr gZmNneJyjGtB8TToL8iOWfG6AKZp7p9QmGyUBCgKqVarM1GrUTx0jYWYpG9OJ4rr zFm2fqO1VZS3rrfpmRiWYSnMh6ZD4JccanPsU6k/sBWcps1SLmCBW42qZse4MczU cYJYP2Br5hpI9E3dmevZuhkJUcdvfixIOEjgMBXbsabE2jfZtr9Met8TUs6b/RwR Gud2Z2m8nULrLSI43BJLBUPZDDLUZUbO1W3q1t7Q3hGuk58P+48j91ffUDcLUSxF KWF6dIfgpMSdo9NaLW4yCikqxH3J8K93cEfYJzrBZzcMQSAoso/rOTnBiQhL+iLq Lez9VU9/AkwNOajaCHfYy41ioEoZczdK2KaNTYrA+IVvH92XhdydBYNEhJ1zdzq3 gocvqrIoEbvJ2chYcPuo =8NPq -----END PGP SIGNATURE----- ------enig2JREKWNIHPTIPDOQPWDCL-- From anders.rundgren@telia.com Fri Oct 25 02:42:51 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621E211E82FD for ; Fri, 25 Oct 2013 02:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.134 X-Spam-Level: X-Spam-Status: No, score=-3.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4peJX5UTWWM for ; Fri, 25 Oct 2013 02:42:46 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id 7A35D11E8398 for ; Fri, 25 Oct 2013 02:42:38 -0700 (PDT) Received: from [192.168.1.99] (78.125.57.162) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 525152FC0082239F for tls@ietf.org; Fri, 25 Oct 2013 11:42:33 +0200 Message-ID: <526A3D01.5010301@telia.com> Date: Fri, 25 Oct 2013 11:42:25 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "'tls@ietf.org'" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [TLS] WebAuth - Replacement for HTTPS Client Certificate Authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 09:42:51 -0000 Maybe of interest: http://webpki.org/papers/PKI/webauth.pdf Comments are welcome! There are 3 independent possible standards targets in this proposal: 1. Browser bindings for JSON protocol invocations 2. JSON Clear-text Signature: https://openkeystore.googlecode.com/svn/resources/trunk/docs/JSON-Clear-Text-Signature-Scheme.pdf 3. And then WebAuth itself Cheers Anders From anders.rundgren@telia.com Fri Oct 25 07:34:30 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04CCA11E8340 for ; Fri, 25 Oct 2013 07:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.289 X-Spam-Level: X-Spam-Status: No, score=-3.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNhIDRDkE0lw for ; Fri, 25 Oct 2013 07:34:24 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 143F311E8314 for ; Fri, 25 Oct 2013 07:34:24 -0700 (PDT) Received: from [192.168.1.99] (78.125.57.162) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 521DAB1700ED8DAE for tls@ietf.org; Fri, 25 Oct 2013 16:34:22 +0200 Message-ID: <526A8166.7090702@telia.com> Date: Fri, 25 Oct 2013 16:34:14 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: "'tls@ietf.org'" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [TLS] n00b question regarding TLS-OBC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 14:34:30 -0000 If I understand it correctly TLS-OBC uses TLS CCA (Client Certificate Authentication) . But IMO TLS CCA has a number of thorny issues like: - TLS CCA is incompatible with the traditional web session model since TLS sessions run independently of web sessions - TLS CCA lacks a logout mechanism - Currently there is no support for TLS session management in for example Java Servlets - A bunch of rather tricky and browser-specific workarounds for coping with the mentioned issues makes HTTPS CCA integration in web applications complex and error-prone Does this not apply to TLS OBC as well? I like the idea very much though so I hope that I'm dead-wrong :-) Anders From agl@google.com Fri Oct 25 07:40:50 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F52011E81C0 for ; Fri, 25 Oct 2013 07:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gV79p6Iv2a0i for ; Fri, 25 Oct 2013 07:40:49 -0700 (PDT) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAA311E81B0 for ; Fri, 25 Oct 2013 07:40:32 -0700 (PDT) Received: by mail-ve0-f175.google.com with SMTP id jz11so2626208veb.6 for ; Fri, 25 Oct 2013 07:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=P6X9nmNXGMToyyKieGrVoAq+jdERBr9RQgC2fuDwqNw=; b=GGRJJeWhX8iem1gzl3W3SKJ4cHdd3eR6k78PnQGLaVAsP4sDaq1VfN9mUUdIAXcWQA Ygi0DayTqhfGb9SSG7KyZKDVibmzyCM4P/w9C4DrI6RuLETz6KBg65FS4fkMhxx1Jm+F qKalyF9xSSFC1x3iNfqCMuBd6jtMKoMMJB7dkZpG8CIFfGYb7jymFqa5k5+kayvbfbdy hx+BV7j2pVQEVU4EZpYDzueKDBhkNa6g4UTFin7DY4NDVVYt116ogcpI0iaFAGKCyaQW GcORaOfxbSybg5NfpYhvvTu4vJYSUT3+f2OIRUv+slqws9mAhLXqyx0YJcXOu5xVmhCr WhPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=P6X9nmNXGMToyyKieGrVoAq+jdERBr9RQgC2fuDwqNw=; b=UMxyp+pSwBRtM8Nu1mIA8NlEYbKzP/r6PEPmiiMbzr8UqxXyYYmIF06Kffd9qrDAXp AOMNxQp03Txnw0Y/XIg9H0U9KKd9VjTfuFTyjRCQdYrXpWs0nMTGZv80CqXzhQmPkO+Q U0j4TscE6U8vS3+D89+85n6e0ua00d/Yq9k1wX8okerbs04MWDc57vr7WjUjg2HfGxd1 VQWoiumA0fp7lmfo7HlnFSwhAInjEwoaWGP/DY49PIIvORghn1bffI0hEX7Q0Xo0kWaQ UqD4SizCuqul/maOjKd3nB3F68YIpdhKNLkdxusVBQNe51k6yfAtxDDK6gwZvH/4Rl56 UttA== X-Gm-Message-State: ALoCoQkLEmIqQrHddjAYwu/t2/+lzH+EiUY5jLn1KvzLsyFJLYq0oPD4KsVtx4JwrS6VHJiKIhXncYcMV1AkZLx9TrgXSFYp+z1tPMvD0gNXSu/rf4qxoeag4p4aMeHm0684rykDPt7u/TsI9SgCoekvVX8ga0nhu7ED1QTzzGKj0v4nQttKfgS8NkFZYrDqY5tltlwI1Jw2 X-Received: by 10.220.1.203 with SMTP id 11mr4870274vcg.15.1382712031826; Fri, 25 Oct 2013 07:40:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.100.40 with HTTP; Fri, 25 Oct 2013 07:40:10 -0700 (PDT) In-Reply-To: <526A8166.7090702@telia.com> References: <526A8166.7090702@telia.com> From: Adam Langley Date: Fri, 25 Oct 2013 10:40:10 -0400 Message-ID: To: Anders Rundgren Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] n00b question regarding TLS-OBC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 14:40:50 -0000 On Fri, Oct 25, 2013 at 10:34 AM, Anders Rundgren wrote: > If I understand it correctly TLS-OBC uses TLS CCA (Client Certificate Authentication) . OBC did, but that got replaced for the reasons given in https://tools.ietf.org/html/draft-balfanz-tls-channelid-00#section-2 Cheers AGL From agl@google.com Fri Oct 25 08:00:46 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B2011E8341 for ; Fri, 25 Oct 2013 08:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTM7pc6jTWsH for ; Fri, 25 Oct 2013 08:00:45 -0700 (PDT) Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B603711E81C9 for ; Fri, 25 Oct 2013 08:00:40 -0700 (PDT) Received: by mail-vb0-f46.google.com with SMTP id 10so2555186vbe.33 for ; Fri, 25 Oct 2013 08:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8q9vyLdH7Lt0eFINKssbZLMOAon674CWAyJKmVLohAA=; b=hgwdOW1Eo4EdZ7gWsV3rCsugQErBCl4j5gLlvCoYutHbuA/m668rTYxlotQt+LcbNE aJf8VoqxUMKp6w5EW8jYFyUJ/ltTV1XGBuyFEfQLyv1vZlY2RnrgvNnggjzxBZGTO/FN 6YZPEgVh2RG1dsfG9Jo/TAbyzItr9Oq3b/EQ6BIQN8XKlygNRgs6vDNR3203JZZjTioo Sqwf0MhklsFjCuqmEqPy9G9e+S1vbUiN9ee051/M4lJQn8D0qPAc/5EburxSqg251QwO Ttq1rDnEGH05YFmYJF/OkiqFhAvch80/WcPMLaUqYUWSfSQs8Txz1idXnVO/s4k6qo8I Il2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8q9vyLdH7Lt0eFINKssbZLMOAon674CWAyJKmVLohAA=; b=cqLx0L6gkW7HSnMsbRERs80YLjmaSp0TkhcpRfHEH85mqDPnT9HF34jXs0S1gLIx4t E6SilXaQkJqeleRX9FE+6mVHkXuLR6+yJ/TypWjc0QpnDT16m44VtDyT1KTVS4itLxKZ GWaKr9jLp6z+yp7uRQevlxTp2C9r7lBaHlzO8Yo+su36H+QXI9Mkpr3oUVzeF76FdVHm D+SmSivfqXn4xHqT1BZzYKEEjjDD/4f8p7NXKrEopJUd7AJMviYdgj5LkBK77AvLJ4OP NpJz8nGH8Kf4jraDItNNUFmn1TyJz/q4t8VXZF9BndOuV82EC9xU3plpjgJVKBJ3XYoh yv6Q== X-Gm-Message-State: ALoCoQmVKp11BpivVD1BdqTkUufngM5EtvU6KO2Cl2+0NIq1H60v9N4aFNuQiS/yyL1vGEcYyGtXegw7dV7akpngycy+TC63gr6GUbvj9OU4A2EDpbbaQih1AZK7x+y52IUTbmwXw8qGmQ24mOxDsq46LKr3Pf+RfJ3ZJtMeS+UFSxv7w+kLmGCxj9VW3UGoTMxH38YNv8ju X-Received: by 10.220.244.132 with SMTP id lq4mr591656vcb.31.1382713205042; Fri, 25 Oct 2013 08:00:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.100.40 with HTTP; Fri, 25 Oct 2013 07:59:44 -0700 (PDT) In-Reply-To: References: From: Adam Langley Date: Fri, 25 Oct 2013 10:59:44 -0400 Message-ID: To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Channel ID and server load: comment on draft-balfanz-tls-channelid-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 15:00:46 -0000 On Thu, Oct 24, 2013 at 3:52 PM, Watson Ladd wrote: > Nope: the attacker could provide their own ChannelID and force the > user to reauthenticate, > thus causing their secret key to be trusted. > They could disable ChannelID entirely and force fallback to cookies, > which they then steal. Likewise, someone could undermine the confidentiality of TLS by failing to set the secure flag on a cookie. Just because you could design a system that uses ChannelID and has these drawbacks isn't terribly meaningful. > Online attack cleans > out a bank account just as quickly as offline. That is rarely true in my experience. Rate limiting of transfers seems to be common practice. > Steal a resumption ticket and you have the same attacker issue for $n minutes. Session resumption tickets do not carry the authority of the ChannelID. The (hypothetical) reauthorisation idea prevented an attacker from taking over a connection, perhaps because the computer continues to run even though the user has stepped away. Cheers AGL From agl@google.com Fri Oct 25 08:02:31 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A5B11E8153 for ; Fri, 25 Oct 2013 08:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bZymXdxJMrR for ; Fri, 25 Oct 2013 08:02:31 -0700 (PDT) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id BB86911E833B for ; Fri, 25 Oct 2013 08:02:24 -0700 (PDT) Received: by mail-vb0-f47.google.com with SMTP id m10so2509062vbh.6 for ; Fri, 25 Oct 2013 08:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CuiCDjZs6DLBvxNZy3GUJIjMzUfKwbeoop/NfXTgZrA=; b=cbQknvzxWUStRVFSa9+HnIUBakQMgeVNebjykBITGEme5tzJPRET0vCL/jDXRZx7Da gjGEJvO6nKetRXp8JGAU0l7cGTAQz1KzptbRimC6pS/bpoYdrNHKVHeZT2pog12ZhanN oz+aVk/0796lo/l7+vMupH7YWiNMNduU21oB72oMxLfEVggOZgx1Y86ZNbVu74WPCfmr hjjOmnghLwojUFii2cMDbxWH4HlKubMyt6S47EeOzXRvh7OnBlTKHavGZZ7/S9v+SeNV KoBSLPcujSD+PWWrko0IGeVcbmsBvmbWDKUEhd3EUCQdOyMcKxejEgDxtJo3KKRzo9T0 /vmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=CuiCDjZs6DLBvxNZy3GUJIjMzUfKwbeoop/NfXTgZrA=; b=XoOvKIeBq8nfJiIv4LCRUZc45lxfloPon2dAnhi394kFdV8dfFfu/VV2JxAwsbByfU dSf1wOcxMwQlMhIhg25HSr1oCc/P9wdzP37AibilDzG4g8mtg91n5HFYHGwqKsLhHd42 ArRqR5hEcyY1DX2VSNuCcJ5lOsJ3LnoMQ0FiHUu58sUnawlOY8z8QM+U/xcReGV1lDmf BSUfsV3j2oVVsU8FAd9Ori2hcgXmX8/9jzQfcIQAmit1nIUwOdQIDXHdBRSYLbn3tnYo STsvJ4aedFxQ4C3PEumWkczdKfUgi/R7HQMfcW0qzBJMmUXVqoPxayYv2PIHbQiWfrvD /w1A== X-Gm-Message-State: ALoCoQnSgW8UWgTg3+yVgopuxFe/cOuOCbHkG8DMm5BPc3bKbPWpNbGwCsDn/AQVZz57EsI6XKWjQ6swo77mufjYhFHnZgQCnDGik3aP82gjLy+EJco+hwV0PKKHxyJDB45/R1PqeApD1bpHdpI4ciIzJioqgkUaOJ23kZgr4xC7sJyEYQSApaOJy/88b3b8/oDo7Jn/IhIY X-Received: by 10.52.105.195 with SMTP id go3mr4178339vdb.24.1382713341617; Fri, 25 Oct 2013 08:02:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.100.40 with HTTP; Fri, 25 Oct 2013 08:02:01 -0700 (PDT) In-Reply-To: References: From: Adam Langley Date: Fri, 25 Oct 2013 11:02:01 -0400 Message-ID: To: Trevor Perrin Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Channel ID and server load: comment on draft-balfanz-tls-channelid-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 15:02:32 -0000 On Wed, Oct 23, 2013 at 9:40 PM, Trevor Perrin wrote: > But I'd like to see more analysis of why > public-key was chosen for ChannelID, in light of computation costs. That sounds very reasonable, but I fear that I only have insight into a small part of the design here and can't usefully talk on this point. I'll see if I can pin Dirk down on it. Cheers AGL From anders.rundgren@telia.com Fri Oct 25 08:04:48 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB0D11E826B for ; Fri, 25 Oct 2013 08:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.367 X-Spam-Level: X-Spam-Status: No, score=-3.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2G9R4Q+9+VQr for ; Fri, 25 Oct 2013 08:04:43 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3E611E81B0 for ; Fri, 25 Oct 2013 08:04:40 -0700 (PDT) Received: from [192.168.1.99] (78.125.57.162) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 521DAB1700EDA84C; Fri, 25 Oct 2013 17:04:38 +0200 Message-ID: <526A887E.9090605@telia.com> Date: Fri, 25 Oct 2013 17:04:30 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Adam Langley References: <526A8166.7090702@telia.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] n00b question regarding TLS-OBC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 15:04:48 -0000 On 2013-10-25 16:40, Adam Langley wrote: > On Fri, Oct 25, 2013 at 10:34 AM, Anders Rundgren > wrote: >> If I understand it correctly TLS-OBC uses TLS CCA (Client Certificate Authentication) . > > OBC did, but that got replaced for the reasons given in > https://tools.ietf.org/html/draft-balfanz-tls-channelid-00#section-2 I'm not enough experienced in TLS to fully understand the draft but it seems right :-) That's great! Cheers Anders > > > Cheers > > AGL > From Johannes.Merkle@secunet.com Mon Oct 28 04:26:26 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99B311E8244 for ; Mon, 28 Oct 2013 04:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTMV+Mzf56f2 for ; Mon, 28 Oct 2013 04:26:20 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 602C611E818F for ; Mon, 28 Oct 2013 04:26:18 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 679F21A0075; Mon, 28 Oct 2013 12:27:47 +0100 (CET) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UBb-fuTujJnI; Mon, 28 Oct 2013 12:27:46 +0100 (CET) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 369F91A0076; Mon, 28 Oct 2013 12:27:46 +0100 (CET) Received: from [10.208.1.57] ([10.208.1.57]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Oct 2013 12:26:14 +0100 Message-ID: <526E49D5.50802@secunet.com> Date: Mon, 28 Oct 2013 12:26:13 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Peter Gutmann , "" References: <9A043F3CF02CD34C8E74AC1594475C735568B8CB@uxcn10-6.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C735568B8CB@uxcn10-6.UoA.auckland.ac.nz> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Oct 2013 11:26:14.0793 (UTC) FILETIME=[832FCF90:01CED3D0] Subject: Re: [TLS] Using RSA PSS in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 11:26:26 -0000 Peter Gutmann schrieb am 14.10.2013 14:31: > > (How many public-CA-issued -PSS certs have people seen in the wild?). The German e-tax system ELSTER issues certificates (to citizens and systems) that are signed with PSS. -- Johannes From Johannes.Merkle@secunet.com Mon Oct 28 05:29:17 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CE911E8112 for ; Mon, 28 Oct 2013 05:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.531 X-Spam-Level: X-Spam-Status: No, score=-3.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4U-O5zd-4Vk for ; Mon, 28 Oct 2013 05:29:13 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id D75D111E80F8 for ; Mon, 28 Oct 2013 05:29:10 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id CA32B1A0088; Mon, 28 Oct 2013 13:30:41 +0100 (CET) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fIIkybbDRXUf; Mon, 28 Oct 2013 13:30:40 +0100 (CET) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 728BA1A0085; Mon, 28 Oct 2013 13:30:40 +0100 (CET) Received: from [10.208.1.57] ([10.208.1.57]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Oct 2013 13:29:08 +0100 Message-ID: <526E5893.1020404@secunet.com> Date: Mon, 28 Oct 2013 13:29:07 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Santosh Chokhani , Rob Stradling , "" References: <9A043F3CF02CD34C8E74AC1594475C735568B823@uxcn10-6.UoA.auckland.ac.nz> <4262AC0DB9856847A2D00EF817E811390957D9@scygexch10.cygnacom.com> <525BD330.6080100@comodo.com> <4262AC0DB9856847A2D00EF817E811390959CF@scygexch10.cygnacom.com> In-Reply-To: <4262AC0DB9856847A2D00EF817E811390959CF@scygexch10.cygnacom.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Oct 2013 12:29:08.0533 (UTC) FILETIME=[4C82D650:01CED3D9] Subject: Re: [TLS] Using RSA PSS in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 12:29:17 -0000 Santosh Chokhani schrieb am 14.10.2013 13:21: > I was in error in the first place. So, the original question remains of how to tell each other of PSS. In TLS 1.2, the "signature_algorithms" extension is used to signal the supported / requested signature algorithms by both client and server. In order to support PSS in that extension, a new code point (or several, depending on the PSS parameters to be supported) had to be assigned in the corresponding IANA registry. http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-16 IMO it is not necessary to define new cipher suites. The semantics of "RSA" in cipher suites (and KeyExchangeAlgorithm indicated in the the server key exchange messages) could be widened to comply with both PKCS#1v1.5 and PSS, and the use of PSS would be defined eligible only if it has been signaled in the "signature_algorithms" extension by the other peer. Likewise, the semantics of RSA in the certificate_types field in the Certificate Request message could be clarified that an rsa key may refer to SPKI rsaPublicKey (general RSA key) as well as to SPKI id-RSASSA-PSS (PSS key), but that PSS-keys are eligible only if PSS had been listed by the client in the signature_algorithms extension. Thus, the changes seem limited and backward interoperability would be preserved in the specs. Although the definition of new code points in the TLS SignatureAlgorithm Registry does not necessarily require a standards track RFC, I am not sure if the change / extension of existing semantics in TLS 1.2 doesn't require the standard track anyway. Johannes From Johannes.Merkle@secunet.com Mon Oct 28 06:28:11 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444E211E8332 for ; Mon, 28 Oct 2013 06:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dNP5m1Y+oov for ; Mon, 28 Oct 2013 06:28:06 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id A6F5E11E82F2 for ; Mon, 28 Oct 2013 06:27:49 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 7562F1A0080; Mon, 28 Oct 2013 14:29:21 +0100 (CET) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JJuvX5i5NOb8; Mon, 28 Oct 2013 14:29:20 +0100 (CET) Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 78E781A007A; Mon, 28 Oct 2013 14:29:20 +0100 (CET) Received: from [10.208.1.57] ([10.208.1.57]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Oct 2013 14:27:47 +0100 Message-ID: <526E6653.3000403@secunet.com> Date: Mon, 28 Oct 2013 14:27:47 +0100 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Santosh Chokhani , Rob Stradling , "" References: <9A043F3CF02CD34C8E74AC1594475C735568B823@uxcn10-6.UoA.auckland.ac.nz> <4262AC0DB9856847A2D00EF817E811390957D9@scygexch10.cygnacom.com> <525BD330.6080100@comodo.com> <4262AC0DB9856847A2D00EF817E811390959CF@scygexch10.cygnacom.com> <526E5893.1020404@secunet.com> In-Reply-To: <526E5893.1020404@secunet.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Oct 2013 13:27:47.0739 (UTC) FILETIME=[7E1F0EB0:01CED3E1] Subject: Re: [TLS] Using RSA PSS in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 13:28:11 -0000 > IMO it is not necessary to define new cipher suites. The semantics of "RSA" in cipher suites (and KeyExchangeAlgorithm > indicated in the the server key exchange messages) could be widened to comply with both PKCS#1v1.5 and PSS, and the use > of PSS would be defined eligible only if it has been signaled in the "signature_algorithms" extension by the other peer. The signature algorithm that was actually used is specified (within a DigitallySigned struct) by an SignatureAndHashAlgorithm identifier of the same type as used in the "signature_algorithms" extension. Thus, the code points in this registry can be used for both signaling support of PSS and specifying the PSS as the signature algorithm that was actually selected. -- Johannes From alexey.melnikov@isode.com Mon Oct 28 09:17:07 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0608F11E8283 for ; Mon, 28 Oct 2013 09:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.892 X-Spam-Level: X-Spam-Status: No, score=-102.892 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sivQOa5vYCQ for ; Mon, 28 Oct 2013 09:17:04 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id B9A3511E827B for ; Mon, 28 Oct 2013 09:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1382977021; d=isode.com; s=selector; i=@isode.com; bh=5iGlyyFKyE+pUuZ63oaM/iOYY42f22dQ78ogI69Hmb8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=w93hsiTExnjpENahFao4LlWClvwfk5xBkksTXMXM5nsJZ83iDEpRGiHbyT3Qayup1A4PcU uIfnSRwTfWk7xLBeB1J1ynl/HeMMEFBzs+QXEh6QM0hbXrTzBYapz4iV0t9lGEwWOzLOsB IUjSOyNFc94WHtUqtgCTBE7fm3ZH0YE=; Received: from [172.16.1.29] (richard.isode.com [62.3.217.249]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 28 Oct 2013 16:17:01 +0000 Message-ID: <526E8DF3.8060506@isode.com> Date: Mon, 28 Oct 2013 16:16:51 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: Phillip Hallam-Baker References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] OCSP Must Staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 16:17:07 -0000 On 23/10/2013 14:46, Phillip Hallam-Baker wrote: > We have been discussing MUST staple for quite some time. The ADs would > like to know if there is support for adding this feature to certificates. > > The draft I wrote is designed to be agile so that it covers all new > OCSP stapling like ideas rather than just being a one off. But it is > pretty simple: > > http://tools.ietf.org/html/draft-hallambaker-tlsfeature-02 > > > The advantage of MUST staple is that if a client receives a TLS cert > chain with MUST Staple and no OCSP token then it can refuse the > connection and hard fail rather than attempting to retrieve the token > and soft failing. > > This allows for a performance improvement and a security improvement. I read the draft and this work looks interesting to me. From brian@briansmith.org Mon Oct 28 12:35:52 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8337921E8095 for ; Mon, 28 Oct 2013 12:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YbafYk4yyKt for ; Mon, 28 Oct 2013 12:35:37 -0700 (PDT) Received: from mail-qe0-f42.google.com (mail-qe0-f42.google.com [209.85.128.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC7711E82BD for ; Mon, 28 Oct 2013 12:35:30 -0700 (PDT) Received: by mail-qe0-f42.google.com with SMTP id gc15so4327766qeb.29 for ; Mon, 28 Oct 2013 12:35:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mKtltJBQUCUeItGnFJfjf44m6TjZOMKWkndYcMHWYic=; b=mG0TrCJyBFGvC27OnmIgQBKU/KnhgKTRs0xzINn1aafEPOm4OZU3aqxKJX099haK8A jUBdNebQ2boFjQ5pdIiElia3Do6v1FtyYNlAcnPR4audONzu6a7y7pEEf3L1Kly9dbKB MkYxsZ9zI23cLWHcYEprWm1KoUxZj5x6WGk0Dl4inHgx5efc+5jQN/1hrTXu/FCHvVW9 a4LPPfJnQATB99xQizp4qs72OXFu/vR8hihvJQPRQviGIDYhwwEjq2KA/i34Bao+wLKw 3w89+lT4CeFMPOBDgEqth8KUKltoN3WHezYP7YaC2BZWDh7jzaJ1/Z5KuVC+yovAsrQM yL5A== X-Gm-Message-State: ALoCoQkJkKFvglfTDDGX/6YpW9WJOUz/Zj5xebidRgTJwWEcHWKjT4Zmj2RtABlTghgP5/EaWvkW MIME-Version: 1.0 X-Received: by 10.49.39.161 with SMTP id q1mr31434357qek.66.1382988930322; Mon, 28 Oct 2013 12:35:30 -0700 (PDT) Received: by 10.224.38.5 with HTTP; Mon, 28 Oct 2013 12:35:30 -0700 (PDT) X-Originating-IP: [63.245.219.54] In-Reply-To: References: Date: Mon, 28 Oct 2013 12:35:30 -0700 Message-ID: From: Brian Smith To: Tom Ritter Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] OCSP Must Staple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 19:35:53 -0000 On Wed, Oct 23, 2013 at 8:58 AM, Tom Ritter wrote: > I support this. I would also like to seek to have it added to the > HTTP Strict Transport Security header as an option (same as > includeSubdomains), so that it can pin to the domain as well as the > certificate - although that may need to wait until this is > standardized and identifiers solidified. FWIW, I am working on a draft that is almost exactly that, but with a separate header named "Must-Staple." It has basically has the same syntax and similar semantics as Strict-Transport-Security (including includeSubDomains), with the additional qualification that it must be ignored unless it was received on a connection that stapled an OCSP response. This is complementary with the work that PHB is doing and it can be done independently. In fact, I'm planning to have Firefox support this Must-Staple header before it supports the X.509 extension, since we don't know what OID to use for the X.509 extension yet. I also intend for us to support the X.509 extension. We designed our normal OCSP stapling implementation with this in mind. In Firefox (beta) right now, if you staple an OCSP response then it must be a valid "Good" response or the connection fails. Unfortunately, we've seen servers stapling expired OCSP responses, so we're probably going to temporarily make an exception: If you staple an otherwise-valid "Good" response that is expired, then we'll do the fetching over OCSP with "hard fail" semantics. Then, the additional semantics of "Must-Staple" become "Fail the connection if there is no OCSP response stapled." PHB: I am happy to help with the "OCSP Stapling Required" X.509 draft too, if you would like. There are several editorial issues that should be addressed. If people are interested, we could set up a side discussion in Vancouver to go over these things, so that we can have a new, unexpired draft to finish up soon. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) From jsalowey@cisco.com Tue Oct 29 11:16:54 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA6821E809C for ; Tue, 29 Oct 2013 11:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsCDakJRks32 for ; Tue, 29 Oct 2013 11:16:49 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB6111E818E for ; Tue, 29 Oct 2013 11:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=206; q=dns/txt; s=iport; t=1383070602; x=1384280202; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=AD7Y0coSWex3v6Q0P7ZQiHELHlLT4+Si9sV5lf7f5fw=; b=hmbxwWZKVgRInNj7FC3Y4sMy2o3WkdQwQKvoNbIynqcCXd/UUQqvuNJT PLS1LQAcYE0tSojoKkGwf/SGm7LRcTz+gD2L37nkhfjC0mqnx70kCp/EM b/oypv22RESK39qEmi5YfdRzkhAJGzxhlLMq5DnoObzVOa4AsIQGh+wYz U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FADP7b1KtJV2d/2dsb2JhbABZgwc4VL80gSwWdIInAQQ6UQEqFEInBBuHfw2YN6FqBI8Wg1eBDQOqEoMmgio X-IronPort-AV: E=Sophos;i="4.93,595,1378857600"; d="scan'208";a="278098872" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 29 Oct 2013 18:16:40 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9TIGepQ019367 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 29 Oct 2013 18:16:40 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.23]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Tue, 29 Oct 2013 13:16:40 -0500 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: TLS at IETF 88 Thread-Index: AQHO1NMDr1xnbzBHt0WvLkGwHdegNA== Date: Tue, 29 Oct 2013 18:16:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.239] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [TLS] TLS at IETF 88 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 18:16:54 -0000 The TLS working group will meet at IETF 88 Tuesday,November 5, 2013 from 1610 to 1840 PST The latest Agenda can be found here: https://datatracker.ietf.org/meeting/8= 8/agenda/tls/ Thanks, Joe= From paul.hoffman@vpnc.org Tue Oct 29 11:37:00 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0EB21F8423 for ; Tue, 29 Oct 2013 11:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yB4s9UAze33E for ; Tue, 29 Oct 2013 11:36:57 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C344911E819A for ; Tue, 29 Oct 2013 11:36:49 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id r9TIajoG015733 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 29 Oct 2013 11:36:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Paul Hoffman In-Reply-To: Date: Tue, 29 Oct 2013 11:36:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1FC1B479-ECB7-46AD-83BE-BE0066AF70F5@vpnc.org> References: To: Joe Salowey X-Mailer: Apple Mail (2.1816) Cc: "" Subject: Re: [TLS] TLS at IETF 88 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 18:37:05 -0000 On Oct 29, 2013, at 11:16 AM, Joseph Salowey (jsalowey) = wrote: > The TLS working group will meet at IETF 88 > Tuesday,November 5, 2013 from 1610 to 1840 PST >=20 > The latest Agenda can be found here: = https://datatracker.ietf.org/meeting/88/agenda/tls/ So we can come prepared: What will the topics for the hour of "TLS 1.3" = be? --Paul Hoffman= From mrex@sap.com Tue Oct 29 13:41:06 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C0E11E81C3 for ; Tue, 29 Oct 2013 13:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.091 X-Spam-Level: X-Spam-Status: No, score=-10.091 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqgfY7MgOE-c for ; Tue, 29 Oct 2013 13:40:59 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBED11E81C0 for ; Tue, 29 Oct 2013 13:40:27 -0700 (PDT) Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r9TKeNZs007011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Oct 2013 21:40:23 +0100 (MET) In-Reply-To: <1FC1B479-ECB7-46AD-83BE-BE0066AF70F5@vpnc.org> To: Paul Hoffman Date: Tue, 29 Oct 2013 21:40:22 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20131029204022.E80B31AA45@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "" Subject: Re: [TLS] TLS at IETF 88 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 20:41:07 -0000 Paul Hoffman wrote: > Joseph Salowey (jsalowey) wrote: >> >> The TLS working group will meet at IETF 88 >> Tuesday,November 5, 2013 from 1610 to 1840 PST >> >> The latest Agenda can be found here: >> https://datatracker.ietf.org/meeting/88/agenda/tls/ > > So we can come prepared: What will the topics for the hour of "TLS 1.3" be? Maybe fixing the TLSv1.2 wreckage (e.g. the botched signature algorithm extension) and how to get rid of TLS protocol version on the wire to improve interoperability in the installed base and get rid of the fallback reconnects in TLS clients. -Martin From mike-list@pobox.com Wed Oct 30 08:49:37 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 227E711E8279 for ; Wed, 30 Oct 2013 08:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVCIWzl+OT2W for ; Wed, 30 Oct 2013 08:49:32 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA1811E8173 for ; Wed, 30 Oct 2013 08:49:20 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 67F7AE01C; Wed, 30 Oct 2013 11:49:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=LEw49q00jxSR uyZXGuwFlwHWpYI=; b=bEAhQLo6xsWzir6pUd3EFQs7aSAUOsUrmHd7Xo++UQAS 7SzH/IEd6f+ZzfYR1PLiGNNF+k3a6TH6Lk73w3rJZ+N32iwuPcIwnC74hmhV9nYH My/E5SVC5XbA34Uo0/Zl11IOdbgtWSLU12mVzbadYmPzjy0i2cR3YZ2Kuh8s/1A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=SGd23q bvBeWVGQTXJJb/N09tzzScMqxERypJ7NIQuZY48ERDy/fMqGMTNzOe2xsDSaVbvB TQphswlLjfCGXp2+Zj6axnyGCCOrTbAEtH6IDTp9+gyD1QD13LJPCILqirbJCj81 KU/1+KbIH8D3b6LopOAYBgelpO4WMdzfMwcmw= Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 40F3DE018; Wed, 30 Oct 2013 11:49:15 -0400 (EDT) Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 4651CE014; Wed, 30 Oct 2013 11:49:01 -0400 (EDT) Message-ID: <52712A6C.4050306@pobox.com> Date: Wed, 30 Oct 2013 08:49:00 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Paul Hoffman References: <1FC1B479-ECB7-46AD-83BE-BE0066AF70F5@vpnc.org> In-Reply-To: <1FC1B479-ECB7-46AD-83BE-BE0066AF70F5@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: CBFFF0CA-417A-11E3-AF3B-0A540E5B5709-38729857!a-pb-sasl-quonix.pobox.com Cc: TLS Mailing List Subject: [TLS] TLS 1.3 (Re: TLS at IETF 88) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 15:49:37 -0000 Paul Hoffman wrote: > On Oct 29, 2013, at 11:16 AM, Joseph Salowey (jsalowey) wrote: > >> The TLS working group will meet at IETF 88 >> Tuesday,November 5, 2013 from 1610 to 1840 PST >> >> The latest Agenda can be found here: https://datatracker.ietf.org/meeting/88/agenda/tls/ > > So we can come prepared: What will the topics for the hour of "TLS 1.3" be? I won't be at the meeting, but the one change I'd like to see in TLS 1.3 is a separation of cipher suites into two parts - authentication mechanism and encryption/mac algorithms. There are currently only 21 authentication mechanisms defined: DH_anon DH_DSS DH_RSA DHE_DSS DHE_PSK DHE_RSA ECDH_anon ECDH_ECDSA ECDH_RSA ECDHE_ECDSA ECDHE_PSK ECDHE_RSA KRB5 PSK PSK_DHE RSA RSA_PSK SRP_SHA SRP_SHA_DSS SRP_SHA_RSA and 31 combinations of encryption algorithm and MAC: 3DES_EDE_CBC_MD5 3DES_EDE_CBC_SHA AES_128_CBC_SHA AES_128_CBC_SHA256 AES_128_CCM AES_128_CCM_8 AES_128_GCM_SHA256 AES_256_CBC_SHA AES_256_CBC_SHA256 AES_256_CBC_SHA384 AES_256_CCM AES_256_CCM_8 AES_256_GCM_SHA384 ARIA_128_CBC_SHA256 ARIA_128_GCM_SHA256 ARIA_256_CBC_SHA384 ARIA_256_GCM_SHA384 CAMELLIA_128_CBC_SHA CAMELLIA_128_CBC_SHA256 CAMELLIA_128_GCM_SHA256 CAMELLIA_256_CBC_SHA CAMELLIA_256_CBC_SHA256 CAMELLIA_256_CBC_SHA384 CAMELLIA_256_GCM_SHA384 NULL_MD5 NULL_SHA NULL_SHA256 NULL_SHA384 RC4_128_MD5 RC4_128_SHA SEED_CBC_SHA Thus there could be 31 x 20 = 620 usable cipher suites, but we have only defined 286 of the possible combinations. Less-supported authentication mechanisms tend to have fewer options available to them. For example SRP is usable only with 3DES and AES_CBC at present since those are the only defined suites. Separating cipher suites into two values would allow any encryption/mac combo to be used with any authentication mechanism. I've noticed that there is current interest in adding more encryption algorithms (e.g. Salsa, Chacha) and MACs (UMAC, VMAC, Poly1305) to TLS. It seems to me that there'd be great value in only having to define a single code point for each encryption/mac combination and having them become immediately available for use with any authentication mechanism. Mike From beldmit@gmail.com Wed Oct 30 15:32:20 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B6121E8090 for ; Wed, 30 Oct 2013 15:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbu6iVkVsxoI for ; Wed, 30 Oct 2013 15:32:19 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 23FE421E8092 for ; Wed, 30 Oct 2013 15:32:17 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id er20so1148886lab.35 for ; Wed, 30 Oct 2013 15:32:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dRbdj/OglKKCFVGAGm7E4rcpOqgJPY1oRn3f8g1tVs4=; b=SHBxPRAyyt/8Kvg+1c0ZVfEwylmm6g+8NgR8z+0E9cYRWs7qhWupxY1ESVsoEp9kWO QKOprBBWFK/7XPObEvtGgK1aEO7Q1FJkWvaHlbFmrPBAXoPa/ewKKLqbSMAOCuXAS5kG ws7mmbV4E65stnLWYrkMDvSC4Op8y7xCW3ezBHIy4T8K7mhBCtfqvss202SAdqZ49I3B Tw2c3pUSeLF+89MipRaw38ML4tEzs8IHPceZGos8D68QmoFZOIzra6StHHP2jl/Lvbng ybLcWOPaNbKVcxBGQ0svWKfZfRKor6uTbxmSk/G6xJHPr2/Rnez2muOujflGYQkD1yEy HVKw== MIME-Version: 1.0 X-Received: by 10.112.130.138 with SMTP id oe10mr445414lbb.1.1383172337124; Wed, 30 Oct 2013 15:32:17 -0700 (PDT) Received: by 10.114.5.4 with HTTP; Wed, 30 Oct 2013 15:32:17 -0700 (PDT) In-Reply-To: <52712A6C.4050306@pobox.com> References: <1FC1B479-ECB7-46AD-83BE-BE0066AF70F5@vpnc.org> <52712A6C.4050306@pobox.com> Date: Thu, 31 Oct 2013 02:32:17 +0400 Message-ID: From: Dmitry Belyavsky To: "Michael D'Errico" Content-Type: multipart/alternative; boundary=047d7b3a88dad14b5304e9fce77a Cc: Paul Hoffman , TLS Mailing List Subject: Re: [TLS] TLS 1.3 (Re: TLS at IETF 88) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 22:32:20 -0000 --047d7b3a88dad14b5304e9fce77a Content-Type: text/plain; charset=UTF-8 Hello! In Russia we have some more authentication mechanisms and at least two cipher/MAC combinations. On Wed, Oct 30, 2013 at 7:49 PM, Michael D'Errico wrote: > Paul Hoffman wrote: > >> On Oct 29, 2013, at 11:16 AM, Joseph Salowey (jsalowey) < >> jsalowey@cisco.com> wrote: >> >> The TLS working group will meet at IETF 88 >>> Tuesday,November 5, 2013 from 1610 to 1840 PST >>> >>> The latest Agenda can be found here: https://datatracker.ietf.org/** >>> meeting/88/agenda/tls/ >>> >> >> So we can come prepared: What will the topics for the hour of "TLS 1.3" >> be? >> > > I won't be at the meeting, but the one change I'd like to see in TLS 1.3 > is a separation of cipher suites into two parts - authentication mechanism > and encryption/mac algorithms. There are currently only 21 authentication > mechanisms defined: > > DH_anon > DH_DSS > DH_RSA > DHE_DSS > DHE_PSK > DHE_RSA > ECDH_anon > ECDH_ECDSA > ECDH_RSA > ECDHE_ECDSA > ECDHE_PSK > ECDHE_RSA > KRB5 > PSK > PSK_DHE > RSA > RSA_PSK > SRP_SHA > SRP_SHA_DSS > SRP_SHA_RSA > > and 31 combinations of encryption algorithm and MAC: > > 3DES_EDE_CBC_MD5 > 3DES_EDE_CBC_SHA > AES_128_CBC_SHA > AES_128_CBC_SHA256 > AES_128_CCM > AES_128_CCM_8 > AES_128_GCM_SHA256 > AES_256_CBC_SHA > AES_256_CBC_SHA256 > AES_256_CBC_SHA384 > AES_256_CCM > AES_256_CCM_8 > AES_256_GCM_SHA384 > ARIA_128_CBC_SHA256 > ARIA_128_GCM_SHA256 > ARIA_256_CBC_SHA384 > ARIA_256_GCM_SHA384 > CAMELLIA_128_CBC_SHA > CAMELLIA_128_CBC_SHA256 > CAMELLIA_128_GCM_SHA256 > CAMELLIA_256_CBC_SHA > CAMELLIA_256_CBC_SHA256 > CAMELLIA_256_CBC_SHA384 > CAMELLIA_256_GCM_SHA384 > NULL_MD5 > NULL_SHA > NULL_SHA256 > NULL_SHA384 > RC4_128_MD5 > RC4_128_SHA > SEED_CBC_SHA > > Thus there could be 31 x 20 = 620 usable cipher suites, but we have only > defined 286 of the possible combinations. > > Less-supported authentication mechanisms tend to have fewer options > available to them. For example SRP is usable only with 3DES and AES_CBC > at present since those are the only defined suites. Separating cipher > suites into two values would allow any encryption/mac combo to be used > with any authentication mechanism. > > I've noticed that there is current interest in adding more encryption > algorithms (e.g. Salsa, Chacha) and MACs (UMAC, VMAC, Poly1305) to TLS. > It seems to me that there'd be great value in only having to define a > single code point for each encryption/mac combination and having them > become immediately available for use with any authentication mechanism. > > Mike > ______________________________**_________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/**listinfo/tls > -- SY, Dmitry Belyavsky --047d7b3a88dad14b5304e9fce77a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello!

In Russia we have some more authe= ntication mechanisms and at least two cipher/MAC combinations.


On Wed, Oct 30, = 2013 at 7:49 PM, Michael D'Errico <mike-list@pobox.com> wrote:
Paul Hoffman wrote:
On Oct 29, 2013, at 11:16 AM, Joseph Salowey (jsalowey) <jsalowey@cisco.com> wrote:<= br>
The TLS working group will meet at IETF 88
Tuesday,November 5, 2013 from 1610 to 1840 PST

The latest Agenda can be found here: https://datatracker.ietf.org/meeting/88/agenda/tls/

So we can come prepared: What will the topics for the hour of "TLS 1.3= " be?

I won't be at the meeting, but the one change I'd like to see in TL= S 1.3
is a separation of cipher suites into two parts - authentication mechanism<= br> and encryption/mac algorithms. =C2=A0There are currently only 21 authentica= tion
mechanisms defined:

=C2=A0 =C2=A0 DH_anon
=C2=A0 =C2=A0 DH_DSS
=C2=A0 =C2=A0 DH_RSA
=C2=A0 =C2=A0 DHE_DSS
=C2=A0 =C2=A0 DHE_PSK
=C2=A0 =C2=A0 DHE_RSA
=C2=A0 =C2=A0 ECDH_anon
=C2=A0 =C2=A0 ECDH_ECDSA
=C2=A0 =C2=A0 ECDH_RSA
=C2=A0 =C2=A0 ECDHE_ECDSA
=C2=A0 =C2=A0 ECDHE_PSK
=C2=A0 =C2=A0 ECDHE_RSA
=C2=A0 =C2=A0 KRB5
=C2=A0 =C2=A0 PSK
=C2=A0 =C2=A0 PSK_DHE
=C2=A0 =C2=A0 RSA
=C2=A0 =C2=A0 RSA_PSK
=C2=A0 =C2=A0 SRP_SHA
=C2=A0 =C2=A0 SRP_SHA_DSS
=C2=A0 =C2=A0 SRP_SHA_RSA

and 31 combinations of encryption algorithm and MAC:

=C2=A0 =C2=A0 3DES_EDE_CBC_MD5
=C2=A0 =C2=A0 3DES_EDE_CBC_SHA
=C2=A0 =C2=A0 AES_128_CBC_SHA
=C2=A0 =C2=A0 AES_128_CBC_SHA256
=C2=A0 =C2=A0 AES_128_CCM
=C2=A0 =C2=A0 AES_128_CCM_8
=C2=A0 =C2=A0 AES_128_GCM_SHA256
=C2=A0 =C2=A0 AES_256_CBC_SHA
=C2=A0 =C2=A0 AES_256_CBC_SHA256
=C2=A0 =C2=A0 AES_256_CBC_SHA384
=C2=A0 =C2=A0 AES_256_CCM
=C2=A0 =C2=A0 AES_256_CCM_8
=C2=A0 =C2=A0 AES_256_GCM_SHA384
=C2=A0 =C2=A0 ARIA_128_CBC_SHA256
=C2=A0 =C2=A0 ARIA_128_GCM_SHA256
=C2=A0 =C2=A0 ARIA_256_CBC_SHA384
=C2=A0 =C2=A0 ARIA_256_GCM_SHA384
=C2=A0 =C2=A0 CAMELLIA_128_CBC_SHA
=C2=A0 =C2=A0 CAMELLIA_128_CBC_SHA256
=C2=A0 =C2=A0 CAMELLIA_128_GCM_SHA256
=C2=A0 =C2=A0 CAMELLIA_256_CBC_SHA
=C2=A0 =C2=A0 CAMELLIA_256_CBC_SHA256
=C2=A0 =C2=A0 CAMELLIA_256_CBC_SHA384
=C2=A0 =C2=A0 CAMELLIA_256_GCM_SHA384
=C2=A0 =C2=A0 NULL_MD5
=C2=A0 =C2=A0 NULL_SHA
=C2=A0 =C2=A0 NULL_SHA256
=C2=A0 =C2=A0 NULL_SHA384
=C2=A0 =C2=A0 RC4_128_MD5
=C2=A0 =C2=A0 RC4_128_SHA
=C2=A0 =C2=A0 SEED_CBC_SHA

Thus there could be 31 x 20 =3D 620 usable cipher suites, but we have only<= br> defined 286 of the possible combinations.

Less-supported authentication mechanisms tend to have fewer options
available to them. =C2=A0For example SRP is usable only with 3DES and AES_C= BC
at present since those are the only defined suites. =C2=A0Separating cipher=
suites into two values would allow any encryption/mac combo to be used
with any authentication mechanism.

I've noticed that there is current interest in adding more encryption algorithms (e.g. Salsa, Chacha) and MACs (UMAC, VMAC, Poly1305) to TLS.
It seems to me that there'd be great value in only having to define a single code point for each encryption/mac combination and having them
become immediately available for use with any authentication mechanism.

Mike
_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls



--
SY, Dmitry Belyavsky
--047d7b3a88dad14b5304e9fce77a-- From watsonbladd@gmail.com Thu Oct 31 13:30:35 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2DCB11E8110 for ; Thu, 31 Oct 2013 13:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tB-JwGPL5FkT for ; Thu, 31 Oct 2013 13:30:35 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id F345511E8107 for ; Thu, 31 Oct 2013 13:30:34 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id t61so3262882wes.27 for ; Thu, 31 Oct 2013 13:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=kUerzWDE02rYf0jK8esfwbvj7RoQ27iMtWrVJf6CpXI=; b=ebsaWQZtWxjzHXaprIlFtz8FORKgfkAJ5Q6rwB1WH1EHwn+zye4JcOjteMjqOP5ogB wFT1e4GBlWPmjCupJYznIQhJUNCXFkV2whDJvPl4OwYvVy3tOEWiBxLg+CX5pmf+LEdr ymec210tT7RnqSNg767B/hN6BaQXsUyOH8rurNAwtmqF59SIh4oPFQeCFxLuGGmWLjSz Z3TfLYSFG5S4BexULbQPX7UfQLEK1HdlvJ/W2aVDJT7OlVQiMB1DSta+yp7IftI2OdSW q7WyOO1Gz0mslnCjXwfl+Y98kqeMxcgTALte+9x5KL5huEj8WcqtVDxmbOgk7bgztucP 7ncg== MIME-Version: 1.0 X-Received: by 10.194.122.99 with SMTP id lr3mr4422685wjb.21.1383251434039; Thu, 31 Oct 2013 13:30:34 -0700 (PDT) Received: by 10.194.242.131 with HTTP; Thu, 31 Oct 2013 13:30:33 -0700 (PDT) Date: Thu, 31 Oct 2013 13:30:33 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: [TLS] What would make TLS cryptographically better for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 20:30:35 -0000 Print out the documentation of TLS as it stands. Then take an ax to it. There are too many options that need to be supported. This leads to 2 implementations which people use in the real world, both of which are horrible, horrible nightmares to inspect and audit. We should include only those options required by major users today. The current MACs are all problematic. If you want to keep authenticate-then-encrypt, make the MAC include the requisite padding. This simplifies the job of implementers tremendously by preventing timing attacks. Or better yet, do encrypt-then-authenticate. Ask Rogaway for details. We do not need CBC. Counter mode is better in every way, especially with modern hardware support that depends on parallelizability for maximal performance. Intel's AES instructions can have high latency, necessitating having several encryptions in flight for performance. Counter mode is never worse in performance. If we keep CBC, we should do it correctly with explicit random IV. TLS 1.3 should significantly reduce the number of round trips required. To this end I propose the following obviously secure scheme: the client sends a point on a curve in ClientHello and the server responds with certificates (or some other authentication thing) and a point on a curve, so that when the client speaks again, it is with a negotiated, authenticated shared secret. Before everyone screams about needing one signature per connection, note the server can use a time based secret key, so only has to do one exponentiation per client. Renegotiation should be killed: it serves no purpose. RC4 must be eliminated to prevent the temptation of ever using it again. If we must have options, to prevent deployment hassles, they must be arranged and implementations forced to always ensure a common option exists. Options should be included in the key derivation or signed to prevent downgrade attacks. Sincerely, Watson Ladd From nico@cryptonector.com Thu Oct 31 16:10:09 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1E2D21F9DFC for ; Thu, 31 Oct 2013 16:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKB8WvSGmHFG for ; Thu, 31 Oct 2013 16:10:04 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 665E021F9F74 for ; Thu, 31 Oct 2013 16:10:04 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 2D407678063; Thu, 31 Oct 2013 16:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=gKKLqQ+8NFbs9p 956Lc24amEGGA=; b=wO1LbX9BjVSzD3h7lEu8zQr0/qLVizoMFvXhqCpJq8jMBt mwhru6c97Nw1F3LhmiAefxS/owUXNhEmOxPCxhdQxnPHjg5XSG+1zQgd3TsTAUve uoyxAzvozMiW4/BNsDCu7vKjfNfr0Lo2NIyuraO7SThNWEifJu1EEUBfozTlE= Received: from gmail.com (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 96C71678062; Thu, 31 Oct 2013 16:10:02 -0700 (PDT) Date: Thu, 31 Oct 2013 18:09:59 -0500 From: Nico Williams To: Watson Ladd Message-ID: <20131031230955.GB32733@gmail.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "tls@ietf.org" Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Oct 2013 23:10:09 -0000 My list: - It should be deployable, that's first; in particular, it needs to be deployable with ECDH PFS key exchanges. This means that the mess of *DHE* ciphersuite and group/curve negotiation urgently needs a revamp. We need to de-explode the cipher suite registry by separating negotiation of key exchange, KDF, and server authentication algorithms/methods from each other and from the symmetric cipher/modes. This should have the bonus of yielding smaller hello messages (except during the transition to 1.3, natch). - It needs to use modern cipher modes for AES and friends: GCM, CCM, and *maybe* an option for AEAD by generic composition (AES-CBC-SHA3 or AES-CBC-HMAC-SHA256, encrypt-then-mac, ... with random IV chaining). - Many fewer nonce bytes and random IVs where possible. Nonce payloads should be sent when needed, if needed. For example, to derive a session key from an DHE shared secret one does not really need nonces. This means that counter modes are better, for example, than CBC modes. - Renegotiation should be replaced with an NPN-like extension that provides privacy to the TLS client principal name. - Design-in channel bindings from the get-go. Nico --
Y[RFC6655]
0xC0,0xA7TLS_DHE_PSK_WITH_AES_256_CCMY[RFC6655]
0xC0,0xAATLS_PSK_DHE_WITH_AES_128_CCM_8Y[RFC6655]
0xC0,0xABTLS_PSK_DHE_WITH_AES_256_CCM_8Y[RFC6655]