Dear all,
This is a new document we have submitted on the TLS extension for server
redirect. It aims to solve the problems in some applications, e.g., HTTPS
redirect.
The "Hello Extensions" message is extended and a new TLS handshake packet is
defined to support this kind of applications.
Your
On Monday, October 19, 2015, Martin Thomson
wrote:
> On 19 October 2015 at 11:17, Eric Rescorla >
> wrote:
> > Yeah, I think that's riding the nonce far too hard.
>
> On what basis? Any change in the nonce will cause the record
> decryption to fail. That's the property we're looking for here, i
This is an exploration of what it might take to bootstrap 0RTT without
a prior TLS connection.
https://tools.ietf.org/html/draft-thomson-tls-offline-config-00
There are two important lessons I've learned from this:
1. authentication is important (and hard to get right)
2. TLS implicitly inclu
Option #2 seems fine to me.
Russ
On Oct 19, 2015, at 12:28 PM, Eric Rescorla wrote:
> Folks,
>
> https://github.com/tlswg/tls13-spec/issues/278
>
> The additional data field presently includes the version:
>
> additional_data = seq_num + TLSPlaintext.record_version
>
> However, TLSPla
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security Working Group of the
IETF.
Title : Transport Layer Security (TLS) Cached Information
Extension
Authors : Stefan Santesson
On 19 October 2015 at 11:17, Eric Rescorla wrote:
> Yeah, I think that's riding the nonce far too hard.
On what basis? Any change in the nonce will cause the record
decryption to fail. That's the property we're looking for here, isn't
it?
___
TLS mai
On Mon, Oct 19, 2015 at 11:13 AM, Martin Thomson
wrote:
> On 19 October 2015 at 11:12, Eric Rescorla wrote:
> >
> >
> > On Mon, Oct 19, 2015 at 11:06 AM, Martin Thomson <
> martin.thom...@gmail.com>
> > wrote:
> >>
> >> On 19 October 2015 at 09:28, Eric Rescorla wrote:
> >> > 1. Don't MAC
On 19 October 2015 at 11:12, Eric Rescorla wrote:
>
>
> On Mon, Oct 19, 2015 at 11:06 AM, Martin Thomson
> wrote:
>>
>> On 19 October 2015 at 09:28, Eric Rescorla wrote:
>> > 1. Don't MAC the version at all.
>> > 2. MAC the negotiated version (which should be clear at
>> > this
On Mon, Oct 19, 2015 at 11:06 AM, Martin Thomson
wrote:
> On 19 October 2015 at 09:28, Eric Rescorla wrote:
> > 1. Don't MAC the version at all.
> > 2. MAC the negotiated version (which should be clear at
> > this point).
>
>
> 3. Nothing
>
> The version is implicit in the key
On 19 October 2015 at 09:28, Eric Rescorla wrote:
> 1. Don't MAC the version at all.
> 2. MAC the negotiated version (which should be clear at
> this point).
3. Nothing
The version is implicit in the key derivation (yeah, there are lots of
rounds of HMAC between, but it's ther
The following errata report has been submitted for RFC5246,
"The Transport Layer Security (TLS) Protocol Version 1.2".
--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=4507
-
On Mon, Oct 19, 2015 at 06:58:52PM +0300, Yoav Nir wrote:
> Hi
>
> I’ve submitted version -04 of this draft, incorporating the new curves
> Curve25519 and Curve448.
>
> I’m sorry to say that I have made the merge far too quickly and the result is
> quite sketchy, but I did beat the deadline.
>
On 19 October 2015 at 08:08, Eric Rescorla wrote:
> overloading the time field
> lowers the risk of false positives because we can choose a sentinel that
> will never
> collide with a conformant TLS 1.2 ServerHello. By contrast, a sentinel in
> the
> randomly generated portion always has a 2^{-n}
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security Working Group of the
IETF.
Title : The Transport Layer Security (TLS) Protocol Version
1.3
Author : Eric Rescorla
What purpose does putting the version in the AD serve? It's not harmful,
sure, but just using the sequence number is simplest. It seems the only
reason we'd consider putting it into the AD is because historically the
record version was in there as part of the record header. In a vacuum, I'm
having
If (2.) is used, would it be nice to make it negotiated_version + seq_num?
I think for some algorithms, the MAC can be partially pre-computed if
things are in that order.
On Mon, Oct 19, 2015 at 9:28 AM, Eric Rescorla wrote:
> Folks,
>
> https://github.com/tlswg/tls13-spec/issues/278
>
> The ad
Folks,
https://github.com/tlswg/tls13-spec/issues/278
The additional data field presently includes the version:
additional_data = seq_num + TLSPlaintext.record_version
However, TLSPlaintext.record_version is now always {3, 1}, so
this is redundant. There seem to be two primary options her
Folks,
https://github.com/tlswg/tls13-spec/issues/224
At the interim we discussed whether it was worth having digital
signatures explicitly include the client and server random values
rather than just the transcript to enable privilege separation, as
proposed by Nikos. We had a little trouble get
Hi
I’ve submitted version -04 of this draft, incorporating the new curves
Curve25519 and Curve448.
I’m sorry to say that I have made the merge far too quickly and the result is
quite sketchy, but I did beat the deadline.
So I’m hoping to complete the merge soon.
Yoav
> Begin forwarded messa
Of course, if anyone wants to help with the merge via pull requests, that would
be great.
Yoav
> On 19 Oct 2015, at 6:58 PM, Yoav Nir wrote:
>
> Hi
>
> I’ve submitted version -04 of this draft, incorporating the new curves
> Curve25519 and Curve448.
>
> I’m sorry to say that I have made the
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security Working Group of the
IETF.
Title : Elliptic Curve Cryptography (ECC) Cipher Suites for
Transport Layer Security (TLS) Versions 1.2 and Ear
On Mon, Oct 19, 2015 at 11:10 AM Eric Rescorla wrote:
> On Mon, Oct 19, 2015 at 7:37 AM, Short, Todd wrote:
>
>> Does the sentinel have to be the first N bytes?
>>
>> RFC 5246 (S7.4.1.2) specifies Random as a combination of a uint32 time
>> value and 28 random bytes.
>>
>> Rather than risk break
Dear all,
I just submitted a draft for integrating PAKE in TLS (see below). The main idea
is to define one PAKE-identifier that can be used for different schemes alike
instead of having to specify a ClientHello-Extension for each and every new
scheme.
Any feedback/comments/further ideas are ve
On Mon, Oct 19, 2015 at 7:37 AM, Short, Todd wrote:
> Does the sentinel have to be the first N bytes?
>
> RFC 5246 (S7.4.1.2) specifies Random as a combination of a uint32 time
> value and 28 random bytes.
>
> Rather than risk breaking backwards compatibility by changing the
> definition of the f
Does the sentinel have to be the first N bytes?
RFC 5246 (S7.4.1.2) specifies Random as a combination of a uint32 time value
and 28 random bytes.
Rather than risk breaking backwards compatibility by changing the definition of
the first 4 bytes, perhaps the sentinel can be moved to another locat
Hello Benjamin / TLS WG,
I didn't mean to drop the list, so your full response is hereby included.
>>> No, mutual authentication requires the client to receive a message from
>>> the server.
>> Yes, I know -- the server needs to handle the session key or the subkey
>> to prove posession of its KD
26 matches
Mail list logo
