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
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
>
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
Folks,
Several of the remaining TLS 1.3 issues have to do with the
ClientHello/HelloRetryRequest interaction. To recap, if the
ClientHello does not contain a KeyShare with an acceptable group, the
server sends a HelloRetryRequest indicating the correct group,
and the client sends a ClientHello wit
Folks,
At the Seattle interim, we decided to have a small ad hoc design team
go and figure out how to harmonize the various forms of client
authentication. I've posted a WIP version of the output of that work
at:
https://github.com/tlswg/tls13-spec/pull/316
The basic observation (due to
On Wed, Oct 21, 2015 at 11:07 AM, Benjamin Kaduk wrote:
> On 10/21/2015 12:32 PM, Eric Rescorla wrote:
>
> Folks,
>
> Several of the remaining TLS 1.3 issues have to do with the
> ClientHello/HelloRetryRequest interaction. To recap, if the
> ClientHello does not conta
-Todd Short
> // tsh...@akamai.com
> // "One if by land, two if by sea, three if by the Internet."
>
> On Oct 21, 2015, at 1:32 PM, Eric Rescorla wrote:
>
> Folks,
>
> Several of the remaining TLS 1.3 issues have to do with the
> ClientHello/HelloRetryRequest int
I think this is the right answer and parallels what we are doing with PSS.
-Ekr
On Wed, Oct 21, 2015 at 12:15 PM, Martin Thomson
wrote:
> The current draft permits the use of SHA-1 in the certificate chain,
> which gives SHA-1 a free pass indefinitely. Since we expressly forbid
> the use of SH
https://github.com/tlswg/tls13-spec/issues/311
I initially added this to make it easier to determine the end of the 0-RTT
handshake if the server had forgotten the key, but with content type
encryption
this is no longer relevant. I propose we remove this and simply use
Handshake here, allowing the
e of handshake. Now you have to be a
> little more selective.
I don't think this will make the implementation that hard :)
-Ekr
On 21 October 2015 at 15:44, Eric Rescorla wrote:
> > https://github.com/tlswg/tls13-spec/issues/311
> >
> > I initially added this to make i
On Wed, Oct 21, 2015 at 3:56 PM, Martin Thomson
wrote:
> On 21 October 2015 at 15:52, Eric Rescorla wrote:
> > I don't think this will make the implementation that hard :)
>
> Yeah, you have to actually pay attention to the early_data extension.
> That might not be
https://github.com/tlswg/tls13-spec/issues/292
Presently, RFC 4492 only specifies the EC points it can support in
ServerHello, but does not let the server indicate which EC curves it
supports. Unless I'm missing something, this means that there's
no way for the server to indicate what groups it wo
On Wed, Oct 21, 2015 at 5:29 PM, Dave Garrett
wrote:
> On Wednesday, October 21, 2015 07:56:13 pm Eric Rescorla wrote:
> > https://github.com/tlswg/tls13-spec/issues/292
> >
> > Presently, RFC 4492 only specifies the EC points it can support in
> > ServerHello,
On Thu, Oct 22, 2015 at 5:55 AM, Martin Rex wrote:
> Eric Rescorla wrote:
> > Dave Garrett wrote:
> >
> >> On Wednesday, October 21, 2015 07:56:13 pm Eric Rescorla wrote:
> >>> https://github.com/tlswg/tls13-spec/issues/292
> >>>
> >>
ct 19, 2015 at 5:46 PM, Adam Langley
wrote:
> 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 non
Thanks for the quick response, David. I now agree with Martin and
Adam that we should remove this.
Chairs, I haven't seen any objections any reason I shouldn't make this
change?
-Ekr
On Thu, Oct 22, 2015 at 6:59 AM, David McGrew (mcgrew)
wrote:
>
>
> *From:* Eric
:tls-boun...@ietf.org] *On Behalf Of *Eric Rescorla
> *Sent:* Thursday, October 22, 2015 6:29 AM
> *To:* m...@sap.com
> *Cc:* tls@ietf.org
> *Subject:* Re: [TLS] Allow NamedGroups from the server?
>
>
>
>
>
>
>
> On Thu, Oct 22, 2015 at 5:55 AM, Martin Rex
On Thu, Oct 22, 2015 at 10:26 AM, Ilari Liusvaara
wrote:
> On Wed, Oct 21, 2015 at 11:01:45AM -0700, Eric Rescorla wrote:
> > Folks,
> >
> > At the Seattle interim, we decided to have a small ad hoc design team
> > go and figure out how to harmonize the various forms o
On Thu, Oct 22, 2015 at 10:36 AM, Martin Rex wrote:
> Andrei Popov wrote:
> >
> > Then my argument would be: why send extra bytes in each ServerHello
> > when TLS client auth is not used most of the time? In this case,
> > CertificateRequest seems to be a better place.
>
> I'm perfectly OK with t
On Thu, Oct 22, 2015 at 11:00 AM, Salz, Rich wrote:
> > That is, the library update can be transparent to the end-user, who will
> > continue to expect normal functionality and expect everything to work.
>
> Should all applications suddenly start using TLS 1.3 without any changes?
> Really? Or s
On Thu, Oct 22, 2015 at 11:20 AM, Salz, Rich wrote:
> > If we (okay, not "we", library implementors) require explicit
> application opt-
> > in to TLS 1.3, the adoption rate is probably not going to be very good.
> So, yes,
> > I think applications should start using TLS 1.3 without any changes.
I took a quick look at this draft and IMO it is unnecessary, for two
reasons:
1. There is already no requirement that you have an explicit nonce. RFC5246
merely requires that you specify the length of the explicit nonce, but that
length can be 0, as it is in the ChaCha/Poly drafts. So, rather than
ce construction, so it's not like you could drop in a
construction
like this, but it would be slightly easier to do if we already MACed the
RSN.
I'm not sure which side of the fence I'm on here. What do others think?
-Ekr
On Thu, Oct 22, 2015 at 10:07 AM, Eric Rescorla wrote:
&
On Tue, Oct 27, 2015 at 11:09 AM, Ilari Liusvaara
wrote:
> On Tue, Oct 27, 2015 at 08:49:35AM -0400, Eric Rescorla wrote:
> > Thinking about this a little more:
> >
> > If we ever change the nonce construction to have an explicit nonce or
> > otherwise
> > not d
Sure. Like I said, I don't feel strongly about this, I just wanted to take
people's
temperature. I'm find with removing the seq from the AD.
-Ekr
On Tue, Oct 27, 2015 at 2:49 PM, Adam Langley
wrote:
> On Tue, Oct 27, 2015 at 8:56 AM, Eric Rescorla wrote:
> > Yes, that
tion, or
> dissemination) by persons other than the intended recipient's) is
> prohibited. If you receive this e-mail in error, please notify the sender
> by phone or email immediately and delete it!
>
> ***
Per discussion with Sean, I've merged this at:
https://github.com/tlswg/tls13-spec/commit/5f30bca74fdf8ded2bf50b112487ca780faa52ef
On Wed, Oct 28, 2015 at 3:53 AM, Eric Rescorla wrote:
> Sure. Like I said, I don't feel strongly about this, I just wanted to take
> people'
Sam,
Thanks for posting this. It's great to see people doing real formal
analysis of the TLS 1.3 draft; this is really helpful in guiding the design.
As you say, the current draft-10 doesn't permit certificate-based client
authentication when PSK is used [0], but it's clear that we want to at lea
On Sat, Oct 31, 2015 at 11:29 PM, Ilari Liusvaara
wrote:
> On Sat, Oct 31, 2015 at 10:55:24PM +0900, Eric Rescorla wrote:
> > Sam,
> >
> > Thanks for posting this. It's great to see people doing real formal
> > analysis of the TLS 1.3 draft; this is really
Can you expand on this a bit? Perhaps propose some text.
-Ekr
On Wed, Nov 4, 2015 at 11:12 AM, Alexey Melnikov
wrote:
> Just to clarify, I think it is fine to define TLS 1.3 replacement for
> tls-unique using Exporters. But I suggest for interoperability this should
> be defined as a new chann
On Thu, Nov 5, 2015 at 2:27 AM, Ilari Liusvaara
wrote:
> I thought of following scenario:
>
> Client: ClientHello+0RTT
> Server: 0RTT rejected. Fallback to 1RTT.
> Server: (Drains 0-RTT records)
> Client: Finished (corrupted in transit)
> Client: Appdata (request for something)
> Server: (Drains
Update: we discussed this extensively in Yokohama and based on Watson's
feedback and offline comments from David McGrew, the consensus was that we
needed to add some sort of rekeying mechanism to support long-lived flows.
Expect a PR on this next week.
Note: We'll still need guidance to implementa
On Fri, Nov 6, 2015 at 7:46 PM, Yoav Nir wrote:
>
> > On 7 Nov 2015, at 11:39 AM, Dave Garrett wrote:
> >
> > On Friday, November 06, 2015 08:13:44 pm Eric Rescorla wrote:
> >> Update: we discussed this extensively in Yokohama and based on Watson's
> >&
On Fri, Nov 6, 2015 at 6:39 PM, Dave Garrett wrote:
> On Friday, November 06, 2015 08:13:44 pm Eric Rescorla wrote:
> > Update: we discussed this extensively in Yokohama and based on Watson's
> > feedback and offline comments from David McGrew, the consensus was that
> we
On Fri, Nov 6, 2015 at 7:50 PM, Eric Rescorla wrote:
>
>
> On Fri, Nov 6, 2015 at 7:46 PM, Yoav Nir wrote:
>
>>
>> > On 7 Nov 2015, at 11:39 AM, Dave Garrett
>> wrote:
>> >
>> > On Friday, November 06, 2015 08:13:44 pm Eric Rescorla wr
b.com/tlswg/tls13-spec/pull/284
-Ekr
On Mon, Oct 19, 2015 at 10:05 AM, Martin Thomson
wrote:
> 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
> &g
On Mon, Nov 9, 2015 at 4:30 PM, Christian Huitema
wrote:
> On Monday, November 9, 2015 3:53 PM, Eric Rescorla wrote:
> > In an attempt to close the loop here, I've pushed a new PR version with
> a 64-bit sentinel with
> > the final byte being 00 for TLS 1.2 and 01
On Mon, Nov 9, 2015 at 4:41 PM, Christian Huitema
wrote:
> On Monday, November 9, 2015 4:34 PM, Eric Rescorla wrote:
>
> > On Mon, Nov 9, 2015 at 4:30 PM, Christian Huitema
> wrote:
> >
> >...
> >> Editorial: your proposed text says "...MUST set t
On Fri, Nov 13, 2015 at 12:12 AM, Bingzheng Wu <
bingzheng@alibaba-inc.com> wrote:
> Hi All,
>
> Without the Negotiated Groups extension,
>
> Case 1: if the server accepts the Groups in ClientHello.keyshare, it just
> use one of the Groups for DH, and CertificateVerify for both sides.
>
> Case
I support this code point assignment and we should also pull the same code
points into RFC 4492-bis.
On Sat, Nov 14, 2015 at 10:14 AM, Adam Langley
wrote:
> The IESG conflicts review for
> https://datatracker.ietf.org/doc/draft-irtf-cfrg-curves/ has now
> completed without issue[1].
>
> The edit
On Sat, Nov 14, 2015 at 10:47 AM, Adam Langley
wrote:
> On Sat, Nov 14, 2015 at 10:44 AM, Viktor Dukhovni
> wrote:
> > AFAIK the signature detailes are not pinned down yet. Is this
> > allocation in anticipation of the final details?
>
> It might well be that the X25519 and X448 code points are
On Sun, Nov 15, 2015 at 12:28 AM, Bingzheng Wu <
bingzheng@alibaba-inc.com> wrote:
> >> Without the Negotiated Groups extension,
> >>
> >> Case 1: if the server accepts the Groups in ClientHello.keyshare, it
> just use one of the Groups for DH, and CertificateVerify for both sides.
> >>
> >> C
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
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
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
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
On Mon, Nov 16, 2015 at 10:29 PM, Martin Thomson
wrote:
> 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.
>
On Tue, Nov 17, 2015 at 5:58 AM, Sean Turner wrote:
>
> > On Nov 17, 2015, at 01:18, Eric Rescorla wrote:
> >
> > Double-checking, I see that some of the entries in the "TLS 1.3" column
> > for Extensions are wrong. Will be updating shortly.
> >
The concern here is backward compatibility with inspection middleboxes which
expect the length field to be in a particular place. We agreed in Seattle to
wait for early deployment experience before modifying the header to move
the length.
-Ekr
On Tue, Nov 17, 2015 at 7:25 AM, Short, Todd wrote:
ites/extensions that
> are described in the 1.3 document. Other cipher suites/extensions can be
> marked as recommended through other documents.
>
>
>
>
> On 11/17/15, 6:54 AM, "TLS on behalf of Sean Turner" on behalf of s...@sn3rd.com> wrote:
>
> >On No
f.org] *On Behalf Of *Russ Housley
> *Sent:* Tuesday, November 17, 2015 10:01 AM
> *To:* IETF TLS
> *Subject:* Re: [TLS] PR#345: IANA Considerations
>
>
>
> +1. This seems like a reasonable way forward.
>
>
>
> Russ
>
>
>
>
>
> On Nov 17, 2015, a
> is generally unlikely to move to the “standard” category.
>
>
>
> *From:* Eric Rescorla [mailto:e...@rtfm.com]
> *Sent:* Tuesday, November 17, 2015 10:47 AM
> *To:* Andrei Popov
> *Cc:* Russ Housley ; IETF TLS
>
> *Subject:* Re: [TLS] PR#345: IANA Considerations
>
On Tue, Nov 17, 2015 at 11:06 AM, Viktor Dukhovni
wrote:
> On Tue, Nov 17, 2015 at 09:51:32AM -0800, Eric Rescorla wrote:
>
> > My proposal is that we:
> >
> > - List all the Standards Track cipher suites that are compatible with TLS
> > 1.3 in Appendix A.
> &
Indeed. It doesn't seem useful to carry around two fixed bytes
for alignment reasons
-Ekr
On Tue, Nov 17, 2015 at 12:45 PM, Daniel Kahn Gillmor wrote:
> On Tue 2015-11-17 12:09:30 -0500, Eric Rescorla wrote:
> > The concern here is backward compatibility with inspection middl
essors that need alignment. 2-bytes isn’t much better than
> 5-bytes in this regard.
> --
> -Todd Short
> // tsh...@akamai.com
> // "One if by land, two if by sea, three if by the Internet."
>
> On Nov 17, 2015, at 3:45 PM, Daniel Kahn Gillmor
> wrote:
>
&g
On Wed, Nov 18, 2015 at 8:02 AM, Hubert Kario wrote:
> On Monday 16 November 2015 15:16:50 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
On Thu, Nov 19, 2015 at 7:03 AM, Martin Rex wrote:
> Eric Rescorla wrote:
> >
> > There are presently four categories of cipher suites vis-a-vis TLS 1.3.
> >
> > 1. MUST or SHOULD cipher suites.
> > 2. Standards track cipher suites (or ones we are making ST,
if it's only a few weeks, let's just do all the signature code points
then.
-Ekr
On Mon, Nov 23, 2015 at 1:38 PM, Stephen Farrell
wrote:
>
> Hiya,
>
> On 23/11/15 14:21, Sean Turner wrote:
> > All,
> >
> > We’ve received an early code point assignment for the following 4
>
> Is the word "reque
On Tue, Nov 24, 2015 at 8:25 AM, Bill Cox wrote:
> Much of the world seems to have switched to Schnorr-signature inspired ECC
> signature schemes such as ECDSA-P256 and Ed25519. These schemes are very
> fast, but require two point multiplications to do a Schnorr-style
> verification. A simpler
On Tue, Nov 24, 2015 at 9:53 AM, Mike Hamburg wrote:
>
>
> In general, servers have signature keys, not static DH keys. QUIC bridges
> this by
> having the server generate an offline signature over a static DH key, but
> TLS explicitly
> rejected this as a generic approach because of concerns abo
On Tue, Nov 24, 2015 at 2:31 PM, Bill Cox wrote:
>
> From the paper, it sounds like using delegated keys currently has some
> unanticipated security problems, at least in the near term while we
> continue to accept incorrectly padded RSA based certs. Would Hugo's
> suggestions for extending certi
On Thu, Nov 26, 2015 at 2:50 PM, Dave Garrett
wrote:
> On Thursday, November 26, 2015 02:15:25 pm Ilari Liusvaara wrote:
> > I actually looked at the Editors's Copy. The description is a mess: It
> > seemingly first requires key_share extension, even for the first
> > ClientHello... Now, that ext
On Thu, Nov 26, 2015 at 3:03 PM, Dave Garrett
wrote:
> HelloRetryRequest is annoying
I guess this is a matter of opinion.
The main thing that comes to mind would be to provide a way for a server to
> respond to a client with a ServerConfiguration, but not a hello, and put
> group support in t
.
>
> Cheers,
>
> Joe
>
> On Thu, Nov 19, 2015 at 7:10 AM, Eric Rescorla wrote:
>
>>
>>
>> On Thu, Nov 19, 2015 at 7:03 AM, Martin Rex wrote:
>>
>>> Eric Rescorla wrote:
>>> >
>>> > There are presently four categories o
On Thu, Nov 26, 2015 at 3:36 PM, Dave Garrett
wrote:
> On Thursday, November 26, 2015 06:02:09 pm Eric Rescorla wrote:
> > On Thu, Nov 26, 2015 at 2:50 PM, Dave Garrett
> > wrote:
> > > On Thursday, November 26, 2015 02:15:25 pm Ilari Liusvaara wrote:
> > > >
s and
> preference, and key_share defines the shares only (no supported groups, no
> preference, the groups must be defined in "supported_groups" extension).
>
> Xuelei
>
> On Fri, Nov 27, 2015 at 7:47 AM, Eric Rescorla wrote:
>
>>
>>
>> On Thu, Nov 26
Hi Bill,
I am sorry, but I do not understand what you are proposing. Do you think
you could try restating the computation you have in mind, perhaps by
providing an equation that explains the construct?
Thanks,
-Ekr
On Mon, Nov 30, 2015 at 6:07 PM, Bill Cox wrote:
> I don't think even I agree
:06 PM, Eric Rescorla wrote:
>
>> Hi Bill,
>>
>> I am sorry, but I do not understand what you are proposing. Do you think
>> you could try restating the computation you have in mind, perhaps by
>> providing an equation that explains the construct?
>>
>
>
I have filed issue 353 for this so we don't lose it.
https://github.com/tlswg/tls13-spec/issues/353
Thanks.
-Ekr
On Mon, Nov 30, 2015 at 8:19 PM, Tony Arcieri wrote:
> On Mon, Nov 30, 2015 at 8:09 PM, Hugo Krawczyk
> wrote:
>
>> The more common term is "forward secrecy"
>>
>
> I'd second thi
I am planning to use "forward secrecy"
On Tue, Dec 1, 2015 at 4:17 AM, William Whyte wrote:
> If we want to change to “key erasure” we should synch with CFRG and SAAG
> to ensure it’s used IETF-wide. I don’t think that “forward secrecy” is so
> broken that it needs fixing.
>
>
>
> Cheers,
>
>
>
Hi folks,
I've merged a bunch of PRs into the editor's draft, including:
- https://github.com/tlswg/tls13-spec/pull/316
The new structure for client auth and post-handshake client
auth we discussed in Yokohama.
- https://github.com/tlswg/tls13-spec/pull/342
Using the "normal" content types
Ilari,
Thanks for your quick review.
On Tue, Dec 1, 2015 at 10:57 AM, Ilari Liusvaara
wrote:
> On Tue, Dec 01, 2015 at 10:11:17AM -0800, Eric Rescorla wrote:
> >
> > This clears out the big pipeline stall from PR#316, but probably has
> > created some bustage. Expec
On Tue, Dec 1, 2015 at 11:19 AM, Eric Rescorla wrote:
> Ilari,
>
> Thanks for your quick review.
>
> On Tue, Dec 1, 2015 at 10:57 AM, Ilari Liusvaara > wrote:
>
>> On Tue, Dec 01, 2015 at 10:11:17AM -0800, Eric Rescorla wrote:
>> >
>> > This clear
On Wed, Dec 2, 2015 at 5:38 AM, Yoav Nir wrote:
>
> I don’t think Bryan’s proposal will hurt the capabilities of a Check Point
> firewall, and it will make life difficult for me as a developer no more
> than it will make life difficult for developers of OpenSSL, NSS, SChannel,
> or any of a dozen
On Wed, Dec 2, 2015 at 1:07 AM, Bryan Ford wrote:
> On 02 Dec 2015, at 06:02, Martin Thomson wrote:
> > On 1 December 2015 at 08:22, Bryan A Ford wrote:
> >> The 2-byte length field in each record's header no longer indicates
> >> the length of the *current* record but instead indicates the len
On Wed, Dec 2, 2015 at 9:08 AM, Ilari Liusvaara
wrote:
> On Tue, Dec 01, 2015 at 11:19:15AM -0800, Eric Rescorla wrote:
> >
> > 3. The server provides g^y in his ServerHello and then g^xy and g^xs
> > are jointly used to produce the traffic keys and also to form a MAC over
On Wed, Dec 2, 2015 at 7:34 AM, Jacob Appelbaum wrote:
> On 12/2/15, Eric Rescorla wrote:
> > On Wed, Dec 2, 2015 at 1:07 AM, Bryan Ford
> wrote:
> >
> >> On 02 Dec 2015, at 06:02, Martin Thomson
> >> wrote:
> >> > On 1 December 2015 at 08:22
On Wed, Dec 2, 2015 at 10:00 AM, Salz, Rich wrote:
> > I think that is false. One could easily use the "cleartext" SNI field
> and insert an encrypted value. A hash of the name would be a simple example
> but not a secure example, of course.
>
> Encrypted SNI doesn't give you the kind of protecti
On Wed, Dec 2, 2015 at 11:23 AM, Ilari Liusvaara
wrote:
>
> > > > Trying to read between the lines, is your concern that the server is
> > > > now no longer explicitly signing over the ServerConfiguration in
> > > > its CertificateVerify [Note that the client continues to do so]? The
> idea
> > >
Subject: SNI Encryption Part XLVIII
Folks,
TL;DR.
This message describes a technique for doing SNI encryption that just
requires (re)adding EncryptedExtensions to the client's first flight [0]
defining an extension that indicates "tunnelled TLS" and (maybe) a new
TLS content type. We would only t
On Sat, Dec 5, 2015 at 4:24 PM, Bill Cox wrote:
> I am not sure why we have a 0-RTT connect, but only a 1-RTT resume. If
> anything, it seems like it would be easier to have a secure 0-RTT resume
> than a 0-RTT connect, though the 0-RTT connect does use some information
> from prior connections.
On Sat, Dec 5, 2015 at 7:06 PM, Tom Ritter wrote:
> On 5 December 2015 at 12:32, Eric Rescorla wrote:
> > Subject: SNI Encryption Part XLVIII
>
> A small concern that probably is "No, that can't happen", but I would
> want to be sure that a normal (non-en
On Sat, Dec 5, 2015 at 5:58 PM, Salz, Rich wrote:
> Can we embed an EncryptedExtension inside an existing EE?
>
I'm not sure I understand the design you're suggesting.
> That would let us do TOR purely within TLS, right?
>
See above.
>
> You said “in the interest of explicit signaling”
On Sat, Dec 5, 2015 at 8:20 PM, Tom Ritter wrote:
> On 5 December 2015 at 21:31, Eric Rescorla wrote:
> >
> >
> > On Sat, Dec 5, 2015 at 7:06 PM, Tom Ritter wrote:
> >>
> >> On 5 December 2015 at 12:32, Eric Rescorla wrote:
> >> > Subject: S
On Sun, Dec 6, 2015 at 6:46 AM, Salz, Rich wrote:
> > I'm not sure I understand the design you're suggesting.
>
> Does the EncryptedExtensions contain the entire hello for the "next hop"?
>
No. It (at most) says "the stuff that is post-handshake is actually a
ClientHello for the next hop". I.e.,
On Sun, Dec 6, 2015 at 6:50 AM, Bill Cox wrote:
> AFAIK, there has never been a session resumed with forward secrecy. Is
> this correct?
>
Yes, session resumption does not have PFS. Though note that with 1.3 that
will
no longer be true, because you can do PSK-DHE.
> In the past, there were
On Sun, Dec 6, 2015 at 8:17 AM, Bill Cox wrote:
> On Sun, Dec 6, 2015 at 7:12 AM, Eric Rescorla wrote:
>
>> On Sun, Dec 6, 2015 at 6:50 AM, Bill Cox wrote:
>>
>>> AFAIK, there has never been a session resumed with forward secrecy. Is
>>> this correct?
&g
On Mon, Dec 7, 2015 at 3:09 AM, Ilari Liusvaara
wrote:
> This came up while writing serializers/deserializers for various TLS
> 1.2 and 1.3 stuff... Didn't see issues/pull requests for any of
> these...
>
> 1) ServerConfiguration has field early_data_type, which is of type
> EarlyDataType. I don'
On Thu, Dec 10, 2015 at 12:40 PM, John Foley wrote:
> While reviewing the latest TLS 1.3 draft (revision 10), the description in
> section 6.3.3 uses the following wording:
>
> When this message will be sent:
>
> If this message is sent, it MUST be sent immediately after the
> ServerH
https://github.com/tlswg/tls13-spec/issues/362 so this doesn't get lost.
On Thu, Dec 10, 2015 at 12:55 PM, Eric Rescorla wrote:
>
>
> On Thu, Dec 10, 2015 at 12:40 PM, John Foley wrote:
>
>> While reviewing the latest TLS 1.3 draft (revision 10), the description
>&
On Sat, Dec 12, 2015 at 4:08 AM, Hannes Mehnert wrote:
> Hi,
>
> while implementing the TLS 1.3 draft, I came across the modified
> ServerHello message - it does neither contain a SessionID nor a
> CompressionMethod field. This makes code which supports both TLS 1.3
> and earlier versions more c
Watson kindly prepared some text that described the limits on what's safe
for AES-GCM and restricting all algorithms with TLS 1.3 to that lower
limit (2^{36} bytes), even though ChaCha doesn't have the same
restriction.
I wanted to get people's opinions on whether that's actually what we want
or w
For context, see:
https://github.com/tlswg/tls13-spec/pull/372
On Tue, Dec 15, 2015 at 1:14 PM, Eric Rescorla wrote:
> Watson kindly prepared some text that described the limits on what's safe
> for AES-GCM and restricting all algorithms with TLS 1.3 to that lower
> limit (2^{36
future? I can just leave this on ice till then...
-Ekr
> On Tue, Dec 15, 2015 at 4:15 PM, Eric Rescorla wrote:
> > For context, see:
> > https://github.com/tlswg/tls13-spec/pull/372
> >
> > On Tue, Dec 15, 2015 at 1:14 PM, Eric Rescorla wrote:
> >>
> &
he issue, what is the
> security concern that you would have if that limit is exceeded?
>
Watson provided these, so perhaps he can elaborate.
It would be good to have a value we all agree on.
Thanks,
-Ekr
>
> Thank you.
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *
On Tue, Dec 15, 2015 at 3:08 PM, Scott Fluhrer (sfluhrer) <
sfluh...@cisco.com> wrote:
>
>
> > -Original Message-
> > From: Watson Ladd [mailto:watsonbl...@gmail.com]
> > Sent: Tuesday, December 15, 2015 5:38 PM
> > To: Scott Fluhrer (sfluhrer)
On Tue, Dec 15, 2015 at 4:59 PM, Henrick Hellström
wrote:
> On 2015-12-16 01:31, Watson Ladd wrote:
>
>> You don't understand the issue. The issue is PRP not colliding, whereas
>> PRF can.
>>
>
> Oh, but I concur. This means that if you observe two same valued cipher
> text blocks, you know that
On Tue, Dec 15, 2015 at 7:59 PM, Martin Thomson
wrote:
> On 16 December 2015 at 14:57, Dave Garrett wrote:
> > In fact, if we're OK with setting this rather low threshold, then we
> could even get rid of the rekey signal entirely and just have an automatic
> rekey after every 4GiB for all cipher
On Wed, Dec 16, 2015 at 12:44 AM, Simon Josefsson
wrote:
> Eric Rescorla writes:
>
> > Watson kindly prepared some text that described the limits on what's safe
> > for AES-GCM and restricting all algorithms with TLS 1.3 to that lower
> > limit (2^{36} bytes), ev
On Thu, Dec 17, 2015 at 3:02 PM, Hugo Krawczyk
wrote:
> I have mentioned this in private conversations but let me say this here: I
> would prefer that the nonces be explicitly concatenated to the handshake
> hash. That is,
>
> handshake_hash = Hash(
>
> client random
101 - 200 of 1635 matches
Mail list logo
