Re: [TLS] Application data during renegotiation handshake
[Reordering your message slightly so the important question is first.] [MB] When I say “application,” I mean the code being hosted by the web server that’s actually responding to the interpreted requests. While I’d like to minimize code changes in the HTTP server, my primary constraint is that I don’t change the application they’re hosting at all. The change to HTTP/2 and/or TLS 1.3 should be as transparent as possible. Keeping auth that’s currently done via TLS still in TLS helps to reduce those changes at higher layers. [DB] Right, this is why, again, I'm asking for what interface, specifically, are you trying to hold fixed? I can imagine a number of interfaces, ranging from the OpenSSL/Apache boundary (basically impossible, but not your definition of "application") to the Apache/.htaccess boundary (compat is trivial, but probably simpler than your "application"). Without knowing what interface constrains you, it's very difficult to explore the problem space. On Thu, Nov 12, 2015 at 4:09 PM Mike Bishop wrote: > Doing it at the HTTP layer (as an authentication mechanism) is > challenging, since applications aren’t expecting to receive it that way, > and moves the authenticated exchange onto a different stream than triggered > it. > Note I provided two (sketches of) proposals, only one of which switches streams. What's incompatible with adapting the SPDY CREDENTIAL frame but tweaking it so it is asserted mid-stream? I would prefer two separate requests, but it seems we could avoid touching the socket layer either way. > I know that there’s the possibility for a layer to fake the client going > away while actually sending a 401, but then you have to be able to tie the > client’s second attempt back to the challenge, don’t you? > I don't believe so. But, again, you haven't given me the actual interface, so I have to speculate. Can't you can defer checking against the challenge to when you receive it? So, something like: First request: 1. Client hits frontend. 2. [frontend <-> application] Frontend forwards HTTP request to appropriate application. 3. [frontend <-> application] Application requests certificate auth, handing frontend information to go in CertificateRequest, along with information on how to verify the certificate. 4. Frontend surfaces CertificateRequest information with the HTTP 401 response or similar. Request ends, frontend saves no state. 5. [frontend <-> application] Application thinks the client ran away. Second request (maybe doesn't happen, maybe happens without the first request, doesn't matter): 1. Client hits frontend. It authenticates the request with certificate chain C. (I dunno, sign an exporter value or whatever. Or maybe you do the CREDENTIAL frame + slotted SYN_STREAM route to save on signatures. Or maybe there's something more complex with nonces. We can sort out the exact details.) 2. Frontend checks the client is authenticated as C, but doesn't do anything with C as it doesn't remember the application's challenge. Whether C is a meaningful identity is not its problem yet. 3. [frontend <-> application] Frontend forwards HTTP request to appropriate application. 4. [frontend <-> application] Application requests certificate auth, handing frontend information to go in CertificateRequest, along with information on how to verify the certificate. This is the same output as in step 3 of the first request. 5. Frontend verifies C against information the application gave, etc. Whatever it would have done before. 6. [frontend <-> application] Frontend reports that the client, remarkably quickly :-), received the challenge and authenticated as C. Application continues as it did with the renego hack. > In the HttpBis working group meeting, there was fairly strong consensus > that we needed a backward-compatibility mechanism for existing apps moving > to HTTP/2 over TLS 1.[23]; there was also interest in defining something > cleaner in the future for new apps that could adopt something brand new, > but not at the expense of quickly enabling current apps to keep working. > The draft below is the current candidate for least-ugly compat solution. > Doing it at the framing layer is definitely a good option for the something > cleaner. > It's possible that I'm misunderstanding the requirements, but if it is possible for the "something cleaner" and "ugly compat solution" to be the same, that is certainly preferable, no? It's possible my guesses about your constraints are incorrect, but so far I'm not seeing any reason that wouldn't be possible. What am I missing here? David > > > *From:* David Benjamin [mailto:david...@chromium.org] > *Sent:* Thursday, November 12, 2015 12:43 PM > *To:* Yoav Nir ; Adam Langley > > *Cc:* Mike Bishop ; tls@ietf.org > *Subject:* Re: [TLS] Application data during renegotiation handshake > > > > On Wed, Nov 11, 2015 at 10:43 PM Yoav Nir wrote: > > > > On 12 Nov 2015, at 3:32 AM, Adam Langley wrote: > > > > The TLS 1.3 post-handshake client-auth was
[TLS] PR#345: IANA Considerations
PR: https://github.com/tlswg/tls13-spec/pull/345 Per discussion in Yokohama, I have rewritten the IANA considerations section so that the 16-bit code spaces are "Specification Required" and they have a "Recommended" column. 1. The Cipher Suites "Recommended" column was populated based on the Standards Track RFCs listed in the document (and I removed the others). 2. The Extensions "Recommended"column was populated by taking all the Standards Track RFCs and marking them "Yes" and marking others "No". I recognize that this probably marks a bunch of extensions which we actually don't love as "Yes" (and perhaps others as "No") and if people want to move some from one column to another, that seems like a great mailing list discussion which I will let the chairs drive. Thanks, -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR#345: IANA Considerations
Double-checking, I see that some of the entries in the "TLS 1.3" column for Extensions are wrong. Will be updating shortly. On Mon, Nov 16, 2015 at 3:16 PM, Eric Rescorla wrote: > PR: https://github.com/tlswg/tls13-spec/pull/345 > > Per discussion in Yokohama, I have rewritten the IANA considerations > section > so that the 16-bit code spaces are "Specification Required" and they have > a "Recommended" column. > > 1. The Cipher Suites "Recommended" column was populated based on > the Standards Track RFCs listed in the document (and I removed the > others). > > 2. The Extensions "Recommended"column was populated by taking all > the Standards Track RFCs and marking them "Yes" and marking > others "No". I recognize that this probably marks a bunch of extensions > which we actually don't love as "Yes" (and perhaps others as "No") > and if people want to move some from one column to another, that > seems like a great mailing list discussion which I will let the chairs > drive. > > Thanks, > -Ekr > > > > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] PR#346: Individual traffic key generation
https://github.com/tlswg/tls13-spec/pull/346 As discussed in Seattle and Yokohama, I've broken out the traffic key generation into individual values. This makes life somewhat easier for those dealing the cryptographic modules, because some of this data needs to be public and some of it needs to be secret. This general change already had consensus, so I plan to merge it on Wednesday modulo major objections. Please advise here or on Github if you find any errors or you violently object. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR#346: Individual traffic key generation
I have to ask why the continued insistence on calling the thing that forms part of the nonce an "IV". I find it to be misleading. Also, it might be worth noting that the string "early data key expansion, server write " is never needed. On 16 November 2015 at 17:25, Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/pull/346 > > As discussed in Seattle and Yokohama, I've broken out the traffic key > generation > into individual values. This makes life somewhat easier for those dealing > the > cryptographic modules, because some of this data needs to be public and some > of it needs to be secret. > > This general change already had consensus, so I plan to merge it on > Wednesday > modulo major objections. Please advise here or on Github if you find any > errors > or you violently object. > > -Ekr > > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR#346: Individual traffic key generation
On Mon, Nov 16, 2015 at 7:01 PM, Martin Thomson wrote: > I have to ask why the continued insistence on calling the thing that > forms part of the nonce an "IV". I find it to be misleading. > This is the historical terminology that TLS has used. > > Also, it might be worth noting that the string "early data key > expansion, server write " is never needed. > Yes, that's fair. -Ekr > > On 16 November 2015 at 17:25, Eric Rescorla wrote: > > https://github.com/tlswg/tls13-spec/pull/346 > > > > As discussed in Seattle and Yokohama, I've broken out the traffic key > > generation > > into individual values. This makes life somewhat easier for those dealing > > the > > cryptographic modules, because some of this data needs to be public and > some > > of it needs to be secret. > > > > This general change already had consensus, so I plan to merge it on > > Wednesday > > modulo major objections. Please advise here or on Github if you find any > > errors > > or you violently object. > > > > -Ekr > > > > > > > > ___ > > 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] An new "theoretically and practically unbreakable" and fast encryption algorithm
Hello,
I've developed a new encryption algorithm, which dynamically changes the
key according to plaintext and practically impossible to break. I also
opened to public with MIT License.
It is also quite fast; ~80% faster than the fastest mode of AES without cpu
instruction set support.
I will present a paper on a Turkish National Symposium on 3 December:
Inet-tr 2015. I am sending the document as an attachment Sorry, it is in
Turkish Language.
I've studied political sciences. Unfortunately, I haven't mathematical
background to write the proof. But it is a very simple logic. Anyone who
looks at the attached C code may understand why and how it is unbreakable.
I use the key as jump table and with every encrypted byte, I change the
jump table(the key) as a result of 3-4 parameters including the last
plaintext byte itself.
The code is self documented in English.
On Linux simply
gcc HohhaDynamicXOR.c -O2 -Wall
./a.out
will make integrity checks and print benchmarks. It is production ready.
Other algorithm results are the output of the "openssl speed" command.
If I am right; you will not be disappointed to include "Hohha Dynamic XOR
Encryption Algorithm" on TLS 1.3 Draft. Here are the benchmarks for
16,64,256,1024,8192 byte values with -O2 optimization level(-O3 gives ~20%
better results).Hop2 is 2 jump results and Hop3 is 3 jump results.
Please feel free to ask any questions or any explanation I can give.
PS: I've sent 2 other mails but they are blocked because of max. attachment
size quota. If admin allows, you can see my paper to be presented on
Turkish National Internet Symposium.
Regards
Ismail Kizir
*Algoritma*
*16*
*64*
*256*
*1024*
*8192*
Memcpy
663.42
1052.33
1043.33
1147.54
869.60
*Hohha XOR-Hop2*
*162.33*
*193.15*
*198.17*
*198.65*
*202.56*
*Hohha XOR Hop3*
*116.46*
*127.42*
*130.00*
*130.36*
*127.33*
des cbc
44.98
46.53
46.90
47.14
47.05
des ede3
17.65
18.00
18.03
18.03
18.06
rc2 cbc
26.58
27.10
27.28
27.25
27.35
rc4
22.22
36.02
41.81
43.71
43.63
blowfish cbc
84.71
90.58
91.71
91.28
91.41
Cast cbc
81.23
86.99
88.62
89.00
89.10
aes-128 cbc
77.85
85.20
87.91
18.27
18.59
aes-192 cbc
65.98
71.70
72.70
15.53
15.65
Aes-256 cbc
57.59
61.22
62.43
133.67
134.40
Camellia-128
74.04
109.17
124.03
12.87
12.88
Camellia-192
62.57
85.60
94.68
97.20
98.11
Camellia-256
62.58
85.63
94.69
97.35
97.97
aes-128 ige
78.44
82.05
83.08
83.42
83.17
Aes-192 ige
66.25
69.13
69.75
69.95
69.94
Aes-256 ige
57.69
59.71
60.22
60.40
60.27
/*B.
Hohha Dynamic XOR Algorithm. Copyright (c) 2015 İsmail Kizir
Permission is hereby granted, free of charge, to any person obtaining a copy of this software
and associated documentation files (the "Software"), to deal in the Software without restriction,
including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense,
and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so,
subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
/* BASE64 ENCODE/DECODE FUNCTIONS -
*/
/*
cencoder.c - c source to a base64 encoding algorithm implementation
This is part of the libb64 project, and has been placed in the public domain.
For details, see http://sourceforge.net/projects/libb64
*/
typedef enum
{
step_A, step_B, step_C
} base64_encodestep;
typedef struct
{
base64_encodestep step;
char result;
int stepcount;
} base64_encodestate;
typedef enum
{
step_a, step_b, step_c, step_d
} base64_decodestep;
typedef struct
{
base64_decodestep step;
char plainchar;
} base64_decodestate;
const int CHARS_PER_LINE = 72;
void base64_init_encodestate(base64_encodestate* state_in)
{
state_in->step = step_A;
state_in->result = 0;
state_in->stepcount = 0;
}
char base64_encode_value(char value_in)
{
static const char* encoding = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/";
if (value_in > 63) return '=';
return encoding[(int)value_in];
}
int base64_encode_block(const char* plaintext_in, int length_in, char* code_out, base64_encodestate* state_in)
{
const char* plainchar = plaintext_in;
const char* const plaintextend = plaintext_in +
[TLS] Is anyone using DTLS heartbeats?
Please reply to me, I will summarize. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Hohha Dynamic XOR Encyrption Algorithm Source Code
Hello, Unfortunately the system doesn't allow me to attach .c files. The documented source code is on my blog: http://ismail-kizir.blogspot.com.tr/2015/11/hohha-dynamic-xor-algorithm-source-code.html I am also regularly updating the site. Please feel free to ask any questions. Regards Ismail Kizir ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] PR#346: Individual traffic key generation
On 16 November 2015 at 19:52, Eric Rescorla wrote: >> I have to ask why the continued insistence on calling the thing that >> forms part of the nonce an "IV". I find it to be misleading. > > > This is the historical terminology that TLS has used. It was actually accurate when we were using CBC modes, but now it's just confusing. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
