Aaron Zauner wrote:
(of course I'd opt for SSLv5 just to mess with people).
I'm surprised nobody has yet suggested retroactive renaming:
SSLv4 == TLS 1.0
SSLv5 == TLS 1.1
SSLv6 == TLS 1.2
SSLv7 == TLS 1.3
Mike
___
TLS
Hi,
It's been a long time since I posted to this list but saw that the charter is
being updated and wanted to share an idea I had a while ago but have not found
the time to work on. The TL;DR is to deprecate TLS and rebuild security on top
of DTLS. With DTLS, you have encrypted packets, so
Hi,
It looks like QUIC is even better than what I proposed. Thank you for
suggesting it.
Mike
On Fri, Feb 14, 2020, at 15:03, Benjamin Kaduk wrote:
> Hi Mike,
>
> On Fri, Feb 14, 2020 at 09:46:56AM -0500, Michael D'Errico wrote:
> > Hi,
> >
> > It's been
Hi,
I get a weird feeling that the internet is being hijacked and soon it
will be impossible to reverse course. I have not followed the
development of TLS 1.3 but it seems very different from TLS 1.2. Also
TLS 1.2 is very different from TLS 1.0/1.1 (which are being
deprecated). QUIC looked
Just want to clarify what I meant by "It" below
where I said, "It seems like a lot of wasted effort
for very little gain"
"It" refers to "stateless HRR", not the pseudo
code I wrote. Even though I proof read the whole
message several times I missed this...
Mike
On 10/6/20 22:13, I wrote:
yourself that the HRR code path doesn't
depend on secrets used in the core handshake.
Chris P.
[1] https://eprint.iacr.org/2020/573
On Mon, Oct 5, 2020 at 2:47 PM Michael D'Errico <mailto:mike-l...@pobox.com>> wrote:
On 10/5/20 10:21, Christopher Patton wrote:
> A c
On 10/6/20 19:11, Nick Harper wrote:
I conclude that if this leads to some vulnerability, this implies the
ECDHE algorithm (or its implementation), not the TLS handshake, is flawed.
Thank you for the analysis!
Mike
___
TLS mailing list
TLS@ietf.org
On 10/6/20 10:28, I wrote:
ASN.1 is actually pretty cool
My favorite sentence in any RFC is:
In ASN.1, EXPLICIT tagging is implicit
unless IMPLICIT is explicitly specified.
(Not brown-nosing)
Mike
___
TLS mailing list
TLS@ietf.org
Using finite-field Diffie-Hellman with a generator
of 2 is probably not the best choice. Unfortunately
all of the published primes (RFCs 2409, 3526, and
7919) use 2 for the generator. Any other generator
would likely be (not sure how much?) more secure.
The problem is that 2^X consists of a
> This is speculation of course.
I retract this part of my message due to
the fact that the format of the primes in
the recent spec is the same as the format
going back to the original MODP primes.
Mike
___
TLS mailing list
TLS@ietf.org
I have not written any code, but have just been thinking
about what is going on and I am pretty sure that the
bottom 64 bits of 2^X mod P tell you information which
can help you determine X. The top bits are also suspect
but I haven't worried about those yet. My original
message below explains
I know that saying this will have no effect, but I'd
rather see deprecation of just TLS 1.0 and retain
version 1.1 as not recommended.
Also, we should not abandon RFC 7507 (downgrade
protection SCSV). What harm is there in keeping it
around? None.
Mike
On Tue, Oct 13, 2020, at 15:15, Benjamin Kaduk wrote:
> Hi Mike,
>
> On Tue, Oct 13, 2020 at 03:09:15PM -0400, Michael D'Errico wrote:
> > I know that saying this will have no effect, but I'd
> > rather see deprecation of just TLS 1.0 and retain
> > version 1.1 as not r
On 10/5/20 10:21, Christopher Patton wrote:
A couple pointers for getting started:
Thank you for providing these links! I'm going through
the first one now and will note that it does not even
mention the HelloRetryRequest message. So while I am
confident there has been quite a bit of study
Hi,
I'm pretty sure TLS 1.3 is completely broken. Can we
please stop deprecating things that TLS 1.2 uses and
make them all Recommended again?
Mike
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
BTW, if anybody is hoping I'll update my test server
to support TLS 1.3, I am not going to be doing that.
Version 1.3 is broken and I don't think anybody should
use it.
Mike
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
I would prefer the minimum encoding length.
But if the spec says MUST be minimum length,
I would feel compelled to check every one.
Please don't require minimum length unless
security would be weaker without it.
Mike
___
TLS mailing list
1994 called. It wanted to talk about distinguished encoding rules.
Yes, DER vs. BER. ASN.1 is actually pretty
cool (bits on the wire in X.690, not X.680).
The encoding also reminds me of UTF-8 which is
a variable length:
0xxx
110x 10yy
1110 10yy 10zz
> This is a reminder to keep discourse here courteous and respectful.
I am hoping this comment was not directed at me.
I find myself biting my tongue frequently, but will
try to do a better job of it going forward in any
case.
> We want this mailing list to be maximally useful for all readers.
On Fri, Oct 9, 2020, at 11:17, Christopher Wood wrote:
> Michael, since your question is more related to the cryptographic
> primitives used by TLS than the protocol itself, the chairs encourage
> you to continue this discussion on the CFRG mailing list [2].
>
> Thanks,
> Chris, on behalf of
Hi,
It appears that there may be a need to revert to the
old way of sending Diffie-Hellman parameters that
the server generates. I see that TLS 1.3 removed
this capability*; is there any way to add it back?
Mike
*From RFC 8446:
- Other cryptographic improvements were made,
including
gt;
>
>
> On 10/12/20, 13:32, "TLS on behalf of Ilari Liusvaara"
> wrote:
>
> On Mon, Oct 12, 2020 at 12:36:06PM -0400, Michael D'Errico wrote:
> >
> > It appears that there may be a need to revert to the
> > old way of sending Diff
The argument for the security is based on the parser synthetizer combinator, which
takes a parser p for type t1 and an injective function f:t1->t2 and returns a
parser p' for the type p2.
TLS, I don't even know you anymore
Mike
___
TLS
On Fri, Oct 9, 2020, at 17:22, Benjamin Kaduk wrote:
> [...] The behavior we should demand from our cryptographic
> constructions is that the cryptography itself correctly returns
> "valid" or "invalid" based on the input message, provided that
> the application inputs the correct key material.
> Hopefully https://tools.ietf.org/html/rfc8446#section-4.2.11.2
> makes it clear why the pre_shared_key extension must be at
> the end of the list.
I see what was done, but it still makes me a bit
sad that whatever security property was desired
couldn't have been done differently to avoid this
POC || GTFO
I showed how to do it just by using your brain. If
I'm wrong please explain.
And, no, you don't get to decide who belongs here.
Also I tried reading your thesis. It's waaay over
my head, but I think I learned that quaternions are
two-by-two matrices, really ing cool.
Mike
I think we are in agreement.
On 10/6/20 13:12, Christian Huitema wrote:
* Receiver side: receive the message, parser with generic ASN.1 decoder,
process the message using the "parsed" representation, re-encode with
DER, check the signature.
I recall that at least one root certificate had a
name a few), it
won't be hard to convince yourself that the HRR code path doesn't
depend on secrets used in the core handshake.
Chris P.
[1] https://eprint.iacr.org/2020/573
On Mon, Oct 5, 2020 at 2:47 PM Michael D'Errico <mailto:mike-l...@pobox.com>> wrote:
On 10/5/20 10:21, C
But if the spec says MUST be minimum length,
I would feel compelled to check every one.
"Be liberal in what you accept" no?
A requirement of MUST in a security protocol usually
means (or at least should mean) that there's a good
reason for the thing, whatever it is, so if you are
Okay, we disagree about things. Not sure it's worth proceeding.
I haven't read whatever spec cTLS is
Got it.
My advice is universally applicable, to whatever
spec you are working on. cTLS, QUIC, whatever-TF.
Mike
___
TLS mailing list
ity implementations that exist
(openSSL, boringSSL, NSS, Go's crypto/tls just to name a few), it
won't be hard to convince yourself that the HRR code path doesn't
depend on secrets used in the core handshake.
Chris P.
[1] https://eprint.iacr.org/2020/573
On Mon, Oct 5, 2020 at 2:47 PM M
On Sun, Sep 27, 2020, at 16:53, Ben Smyth wrote:
> The client will reject the server's ServerHello in your example.
OK, so all eggs in one basket? I'm afraid to keep reading
Mike
___
TLS mailing list
TLS@ietf.org
Hi,
Took a quick look at RFC 8446 and noticed that there is no
definition of ServerKeyExchange or ServerHelloDone which
are part of TLS 1.2 and prior. A 1.3 client talking to a 1.2
or earlier server is likely going to receive both of these
messages:
RFC 5246 TLS
Is stateless HelloRetryRequest even being used? If so, how?
NSS implements HRR this way always. We pack the necessary state for the
connection to continue into the cookie (which is protected with an AEAD). We
can also retain server state, in which case the retained state is compared
On 9/29/20 19:51, Martin Thomson wrote:
It's symmetric crypto[1]. Hardly worth noting.
[1] Mostly. NSS wraps the symmetric key with an asymmetric key so that server
clusters can share session ticket encryption keys without needing
interconnects. But encryption or decryption only happens once
[I'm resending this with a more appropriate Subject line. --Mike]
On 9/29/20 19:51, Martin Thomson wrote:
> It's symmetric crypto[1]. Hardly worth noting.
> [1] Mostly. NSS wraps the symmetric key with an asymmetric key so that
> server clusters can share session ticket encryption keys without
I wrote:
> Also the server can't be actually stateless since
> it needs to know the HelloRetryRequest message
> for the transcript hash, right?
How can you even implement stateless HRR with a
pseudo-session-ticket in the "cookie"? The server
needs to know the full HRR message to calculate the
On 9/30/20 17:34, Benjamin Kaduk wrote:
The HRR is presumed to be a deterministic function of the
initial ClientHello, and as I discussed in my earlier message,
the server can reconstruct the initial ClientHello from the
second ClientHello and verify it against the hash in the cookie.
I don't
> Not always; see TCP "fast open" options.
Maybe this should be disabled? Fortunately if you wanted
to there is a setsockopt for TCP_FASTOPEN.
Mike
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
DTLS 1.3 can be found here:
https://tools.ietf.org/html/draft-ietf-tls-dtls13-38
Thank you.
The HRR is used in DTLS 1.3 for DDoS prevention.
This makes sense since DTLS is over UDP, but TLS
is over TCP, so it's already undergone the SYN/ACK
handshake to establish there's an actual peer
Anyway, back on the topic of stateless HelloRetryRequest, I
don't see how this can work given that the client can make
several modifications to the ClientHello which will invalidate
the hash sent in the "cookie" (even if the client echos it back
as required without modification).
The hash
> The costs you describe are trivial.
The general idea among developers these days that CPU
cycles are free is a huge problem.
You didn't answer my biggest question, though, which was
whether you (or anybody else!) has had success using stateless
HelloRetryRequest to increase the number of
> I am having a difficult time understanding the tradeoffs you're facing.
This is the first time I'm reading the TLS 1.3 RFC. I have
implemented SSLv3, TLS 1.0, 1.1, and 1.2. You may have
used my test server at https www dot mikestoolbox dot
org or dot net to test your own code. It's kind of
On Sun, Sep 27, 2020, at 22:28, Michael D'Errico wrote:
>
> I'm afraid to keep reading
In section 4, HandshakeType and Handshake are missing the
value for the HelloRetryRequest message.
Oh wait, never mind, it's the same value as ServerHello (?).
Everything appears to be a hack
On Mon, Sep 28, 2020, at 11:07, Hannes Tschofenig wrote:
>
> Luckily, we don't have any angry cryptographers in this group.
Were they all pushed away too?
Anyway, back on the topic of stateless HelloRetryRequest, I
don't see how this can work given that the client can make
several modifications
On 10/2/20 14:15, I wrote:
The server also needs to know the entire HelloRetryRequest message
since this goes into the Transcript Hash calculation:
Transcript-Hash(ClientHello1, HelloRetryRequest, ... Mn) =
Hash(message_hash ||/* Handshake type */
00 00 Hash.length
> > You can't possibly implement [stateless HelloRetryRequest] the
> > way the spec suggests with just a hash in a HRR cookie extension.
>
> The only thing the server needs to know is the hash of the ClientHello
> (so it can restore the transcript hash) and that the server has already
> sent a
> If the client is trying to perform
> some sort of attack on the server by re-sending an old cookie, I assume
> that a prerequisite for this attack is that the TLS handshake succeeds.
Maybe you don't need the handshake to succeed? As a non-cryptographer
I can't say what the implications might
On 10/2/20 22:13, I wrote:
Please don't tell me all the current TLS 1.3 implementations
forgot to include the HelloRetryRequest in the transcript hash.
Is this the reason why Microsoft ditched Edge and rebuilt on
top of Chrome? There must have been a bug bounty for this.
Are there still bug
On 10/3/20 16:12, Nick Lamb wrote:
You can't possibly implement [stateless HelloRetryRequest] the
way the spec suggests with just a hash in a HRR cookie extension.
Lots of people have and it works just fine, so it seems to me that "You
can't possibly" here means something closer to "I still
Hi,
I used to be very active in the development of TLS
specifications (version 1.2) and some of the extensions.
At the time, all discussion was done on the mailing list.
I don't know if I'll be active going forward, but the
trend to move everything to GitHub is a mistake, in my
opinion.
Hi,
Is there a list somewhere stating which parts of TLS
require constant-time algorithms?
Mike
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Also, is it necessary for a TLS client to care about implementing
algorithms in constant time, or is this only of concern to servers?
Thanks,
Mike
On 5/14/21 14:56, Michael D'Errico wrote:
Hi,
Is there a list somewhere stating which parts of TLS
require constant-time algorithms?
Mike
53 matches
Mail list logo
