On Mon, Jul 13, 2015 at 9:28 AM, Ilari Liusvaara <
ilari.liusva...@elisanet.fi> wrote:
> On Mon, Jul 13, 2015 at 06:10:52PM +0200, Martin Rex wrote:
> > Dave Garrett wrote:
> > > On Monday, July 13, 2015 10:30:06 am Martin Rex wrote:
> > >> Section 7.4.1.4 Hello Extensions and its subsections are
We absolutely should have harmony between 1.3 and 4492bis.
Since Uri objected, i'll let the chairs decide if/when we have consensus.
-Ekr
On Wed, Jul 15, 2015 at 12:52 PM, Yoav Nir wrote:
>
> > On Jul 15, 2015, at 9:19 PM, Benjamin Beurdouche <
> benjamin.beurdou...@inria.fr> wrote:
> >
> > H
I don't feel really strongly about this, but I'd prefer to keep P-521.
I suggest we remove sect571tr1 now and then we can debate P-521 later.
-Ekr
On Wed, Jul 15, 2015 at 4:46 PM, Tony Arcieri wrote:
> On Wed, Jul 15, 2015 at 4:40 PM, Brian Smith wrote:
>
>> I agree, except that I think we s
Ilari,
Thanks for your detailed comments.
> > Header
>
> Isn't 4346 already obsoleted by 5246, which this document also obsoletes?
>
> 4366 seems to be jointly obsoleted by 5246 and 6066.
>
> 5246 and 5077 are not in numerical order, whereas the rest are.
This was updated in a recent PR by Dave
On Fri, Jul 17, 2015 at 9:37 PM, Dave Garrett
wrote:
> Brian Smith posted an RFE to GitHub a few months ago requesting "A
> mechanism is needed to indicate that a session will not be resumed":
> https://github.com/tlswg/tls13-spec/issues/137
>
> The goal is to provide a simple way for either endp
I'm not seeing a lot of value here. Remember that servers are not
required (and have never been required) to do session resumption, but
much of the overhead of doing it (having to have a database, session
ticket machinery) is associated with being willing to do session
resumption at all, so if a sm
On Sun, Jul 19, 2015 at 8:53 PM, Manuel Pegourie-Gonnard
wrote:
> Hi,
>
> sorry for resurecting an old message on a fairly tangential point.
>
> On 6/12/15 10:31, Ilari Liusvaara wrote:
>
>> AFAICT, In TLS 1.2, DHE+ECDSA is legal, if client signals support for
>> both DHE (via ciphersuites) and E
On Sun, Jul 19, 2015 at 10:17 PM, Brian Smith wrote:
> On Sun, Jul 19, 2015 at 1:16 PM, Viktor Dukhovni
> wrote:
>
>> On Sun, Jul 19, 2015 at 02:56:22PM +0200, Eric Rescorla wrote:
>>
>> > I'm not seeing a lot of value here. Remember that servers are not
On Sun, Jul 19, 2015 at 10:40 PM, Brian Smith wrote:
> Eric Rescorla wrote:
>
>> On Sun, Jul 19, 2015 at 10:17 PM, Brian Smith
>> wrote:
>>
>>> Maybe I'm misunderstanding, but it looks like the current TLS 1.3 draft
>>> actually contains a
On Sun, Jul 19, 2015 at 11:03 PM, Viktor Dukhovni
wrote:
> On Sun, Jul 19, 2015 at 04:40:15PM -0400, Brian Smith wrote:
>
> > Here's the part that is not is still not
> > clear to me: Is the SessionTicket extension still to be used or not?
>
> While we now have
>
>https://tools.ietf.org/html/
On Mon, Jul 20, 2015 at 12:12 AM, Dave Garrett
wrote:
> On Sunday, July 19, 2015 05:28:27 pm Brian Smith wrote:
> > It depends on how the server implements tickets. The server could
> implement
> > tickets the same way that it implements session ID-based resumption.
> That's
> > not a good idea,
On Sun, Jul 19, 2015 at 11:28 PM, Brian Smith wrote:
> Eric Rescorla wrote:
>
>> On Sun, Jul 19, 2015 at 10:40 PM, Brian Smith
>> wrote:
>>
>>> It seems weird that the server can supply a lifetime hint but the client
>>> can't, especially in
On Mon, Jul 20, 2015 at 9:04 AM, Dave Garrett
wrote:
> On Monday, July 20, 2015 12:27:42 am Eric Rescorla wrote:
> > I think perhaps you have misunderstood the forward secrecy properties of
> the
> > current draft. Unlike TLS 1.2 and previous, the current draft has a
> se
The known_configuration mechanism in the current draft allows the
client to resurrect the handshake parameters (though not the keys)
which were negotiated in a previous handshake, but this is done
implicitly, i.e., the server provides a label and the client returns
it on the next connection. This h
On Tue, Jul 21, 2015 at 1:10 PM, Martin Thomson
wrote:
> On 21 July 2015 at 04:04, Eric Rescorla wrote:
> > - The client indicates configuration ID and cryptographic configuration,
> > including the cipher suites and cryptographic extensions. This
> > MUST replicate t
Yeah, or it could just have the semantics "this is my most preferred
configuration and if you send me anything compatible with it, I will
pick it"
-Ekr
On Tue, Jul 21, 2015 at 1:30 PM, Martin Thomson
wrote:
> On 21 July 2015 at 04:12, Eric Rescorla wrote:
> >
> >
On Tue, Jul 21, 2015 at 2:41 PM, Ilari Liusvaara <
ilari.liusva...@elisanet.fi> wrote:
> On Tue, Jul 21, 2015 at 01:31:41PM +0200, Eric Rescorla wrote:
> > On Tue, Jul 21, 2015 at 1:30 PM, Martin Thomson <
> martin.thom...@gmail.com>
> > wrote:
> >
> >
On Tue, Jul 21, 2015 at 4:15 PM, Ilari Liusvaara <
ilari.liusva...@elisanet.fi> wrote:
> On Tue, Jul 21, 2015 at 06:38:28AM -0700, Martin Thomson wrote:
> > On 21 July 2015 at 06:08, Ilari Liusvaara
> wrote:
> > > Well, if it is about supported ciphers, there could be multiple, and
> > > the prop
On Tue, Jul 21, 2015 at 7:20 PM, Ilari Liusvaara <
ilari.liusva...@elisanet.fi> wrote:
> On Tue, Jul 21, 2015 at 11:30:15AM -0400, Dave Garrett wrote:
> > On Tuesday, July 21, 2015 10:47:05 am Ilari Liusvaara wrote:
> > > I thought that Brainpool curves weren't removed (even if those aren't
> > >
On Tue, Jul 21, 2015 at 5:21 PM, Martin Thomson
wrote:
> On 21 July 2015 at 08:17, Ilari Liusvaara
> wrote:
> >> > *deadlock*.
> >>
> >>
> >> Is this the case where the server is accepting 0-RTT or rejecting it?
> >
> > Apparently, only for accepting case.
> >
> > (If the server rejects, it can
On Wed, Jul 22, 2015 at 9:55 PM, Blake Matheny wrote:
> One of the topics of discussion at the WG discussion was whether
> ServerConfiguration.expiration_date should be an absolute or relative
> value. Subodh (CC) dug into our production data and found that nearly half
> of the TLS errors we see
I guess what I'm trying to get at is the following:
Are there a lot of people whose clocks are accurate enough that they will
be able to connect to the server and check the certificate/OCSP but not
accurate enough to process ServerConfiguration if it is in absolute time.
On Wed, Jul 22, 2015 at 10
d indicate that
>> this is the case.
>>
>> -Blake
>>
>>
>>
>>
>> On 7/22/15, 10:58 PM, "Eric Rescorla" wrote:
>>
>> I guess what I'm trying to get at is the following:
>>> Are there a lot of people whose
On Thu, Jul 23, 2015 at 7:06 PM, Stephen Farrell
wrote:
>
>
> On 23/07/15 16:43, Dave Garrett wrote:
> > We should just get more serious about banning old crap entirely to
> > make dangerous misconfiguration impossible for TLS 1.3+
> > implementations.
> >
> > Right now, the restrictions section
It's not clear to me that there is consensus that more granular error
codes are a good idea. I'll defer to the chairs on the process question.
-Ekr
On Thu, Jul 23, 2015 at 3:39 AM, Dave Garrett
wrote:
> Hubert Kairo found quite a few more spots in need of explicit error
> designations, which h
To be clear: TLS 1.3 does not support RC4.
The only question is whether it's legal to concurrently offer RC4 with TLS
1.3
for purposes of using RC4 with TLS 1.2 (just as you can offer AES-CBC
even though TLS 1.3 does not support it.) I am trying to work through this
myself, as the interactions wit
On Sat, Jul 25, 2015 at 8:53 PM, Dave Garrett
wrote:
> I'm pretty sure some/all of this was likely mentioned elsewhere, but I
> don't see any discussion on-list. (it was mentioned in part of the IETF 93
> recording I watched as this whole topic needing to go to the list, as well)
> There's also r
The epoch is set to 0 at the start of each connection and then incremented
with each handshake on that connection.
-Ekr
On Fri, Jul 31, 2015 at 4:41 PM, Simon Bernard
wrote:
> Hi,
>
> I search in DTLS RFC 6347 if the epoch should be (re)set to 0 when we
> start a resume handshake, or if we ke
g this out.
Best,
-Ekr
Hugo
>
> On Mon, Jul 27, 2015 at 7:26 AM, Sean Turner wrote:
>
>> All,
>>
>> I asked ekr to write a brief summary of the server-side signing issue.
>> The summary provided matches the WG consensus as judged by the chairs.
>> Please let
On Mon, Aug 3, 2015 at 11:51 PM, Ilari Liusvaara <
ilari.liusva...@elisanet.fi> wrote:
> On Sat, Jul 25, 2015 at 09:07:49PM +0200, Eric Rescorla wrote:
> >
> >
> > We agreed on how to do this in Prague. The sticking point was
> establishing
> > the cipher suit
On Thu, Aug 6, 2015 at 1:35 PM, Scott Fluhrer (sfluhrer) wrote:
> I recently reviewed the most recent TLS 1.3 draft, and I must say that I
> am impressed; the protocol appears to be a significant improvement. In
> particular, you simplify the protocol significantly, and as we all know,
> complex
I've updated the PR based on feedback from Dave, Ilari, and Martin.
https://github.com/tlswg/tls13-spec/pull/211
I'll merge this PR on 8/11 unless there are serious objections. As usual
please send minor changes as github comments and/or PRs.
-Ekr
On Tue, Aug 4, 2015 at 5:40 AM, Eri
Please see RFC 6347 S 4.2.8
-Ekr
On Mon, Aug 17, 2015 at 7:20 AM, Simon Bernard
wrote:
> I'm sorry to insist, but What did you mean by transport level connection ?
> For me UDP was a connectionless protocol.
>
> Simon
>
>
> Le 31/07/2015 18:53, Eric Rescorla a écri
poch > 0. Otherwise, epoch = 0.
-Ekr
>
> Le 17/08/2015 16:24, Eric Rescorla a écrit :
>
> Please see RFC 6347 S 4.2.8
>
> -Ekr
>
>
> On Mon, Aug 17, 2015 at 7:20 AM, Simon Bernard
> wrote:
>
>> I'm sorry to insist, but What did you mean by transpo
On Mon, Aug 24, 2015 at 1:56 PM, Viktor S. Wold Eide <
viktor.s.wold.e...@gmail.com> wrote:
> Hi,
>
> I am looking for a way to achieve identity hiding for DTLS 1.2, which also
> hopefully can be used in (D)TLS 1.3, when available.
>
> From what I understand, for (D)TLS 1.2 it would be possible to
On Mon, Aug 24, 2015 at 2:33 PM, Paul Wouters wrote:
> On Mon, 24 Aug 2015, Eric Rescorla wrote:
>
> TLS 1.3 encrypts both the client's and server's certificates already.
>> The server's certificate is secure only against passive attack.
>>
>
> Not hav
On Thu, Aug 27, 2015 at 1:37 AM, Viktor S. Wold Eide <
viktor.s.wold.e...@gmail.com> wrote:
>
> On Mon, Aug 24, 2015 at 11:17 PM, Eric Rescorla wrote:
>
>>
>>
>> On Mon, Aug 24, 2015 at 1:56 PM, Viktor S. Wold Eide <
>> viktor.s.wold.e...@gmail.com>
On Thu, Aug 27, 2015 at 2:14 AM, Viktor S. Wold Eide <
viktor.s.wold.e...@gmail.com> wrote:
> On Mon, Aug 24, 2015 at 11:17 PM, Eric Rescorla wrote:
>
>>
>>
>> TLS 1.3 encrypts both the client's and server's certificates already.
>> The server'
On Thu, Aug 27, 2015 at 11:48 AM, Martin Thomson
wrote:
> I've been looking at the latest TLS 1.3 spec and there are a lot of
> MUSTs that are completely toothless. To pick on a recent changeset:
>
> > The signature algorithm and hash algorithm MUST be a pair offered in the
> "signature_algorith
On Thu, Aug 27, 2015 at 12:19 PM, Dave Garrett
wrote:
> On Thursday, August 27, 2015 02:48:15 pm Martin Thomson wrote:
> > I've been looking at the latest TLS 1.3 spec and there are a lot of
> > MUSTs that are completely toothless. To pick on a recent changeset:
> >
> > > The signature algorithm
r the *absence* of the
extension.
-Ekr
> On Aug 27, 2015 12:26 PM, "Eric Rescorla" wrote:
>
>>
>>
>> On Thu, Aug 27, 2015 at 12:19 PM, Dave Garrett
>> wrote:
>>
>>> On Thursday, August 27, 2015 02:48:15 pm Martin Thomson wrote:
>>>
gt; In this case, that means that if you include an ECDHE suite without an
> ECDHE named_group, don't expect to have the connection succeed.
> On Aug 27, 2015 12:51 PM, "Dave Garrett" wrote:
>
>> On Thursday, August 27, 2015 03:26:03 pm Eric Rescorla wrote:
>>
Folks,
I've just posted draft-08 which includes the changes discussed on-list
to require digital signatures from the client even if you are re-using
a previous configuration in 0-RTT (per WG discussion).
This version also includes a bunch of other cleanup, as detailed below:
- Remove support for
https://github.com/tlswg/tls13-spec/issues/233
Folks,
We presently have some support for DH_anon cipher suites. I agree that this
is a useful use case, but it's yet another mode.
I would like to suggest that we instead deprecate it and instead always use
Raw Public Key mode (https://tools.ietf.o
nature of having an explicit DH_anon signal, I
> tend to think that (on balance) removing this signal does more good
> than harm. I expect certain others to disagree, of course, but we can
> talk about why a vigorous defense of the cipher suite signal isn't a
> good use of their energ
On Fri, Aug 28, 2015 at 11:33 AM, Viktor Dukhovni
wrote:
> On Fri, Aug 28, 2015 at 11:07:02AM -0700, Martin Thomson wrote:
>
> > This seems fine to me, though I'll note that 7250 only really saves
> > you space when it comes down to it. You can wrap your raw public key
> > in a certificate, just
On Mon, Aug 31, 2015 at 9:13 AM, Nico Williams
wrote:
> On Fri, Aug 28, 2015 at 06:33:17PM +, Viktor Dukhovni wrote:
> > On Fri, Aug 28, 2015 at 11:07:02AM -0700, Martin Thomson wrote:
> > Furthermore, anon-DH has strong privacy properties, the server
> > sends no identity information, not ev
On Mon, Aug 31, 2015 at 9:45 AM, Nico Williams
wrote:
> On Mon, Aug 31, 2015 at 09:18:34AM -0700, Eric Rescorla wrote:
> > On Mon, Aug 31, 2015 at 9:13 AM, Nico Williams
> > wrote:
> > > I'm not sure how I feel about this. The idea that we always do a DH
> key
>
>
> As Alissa, I was wondering why it wasn’t easier to fix the one
> implementation instead.
>
>
Because it's widely fielded, and browsers don't know in advance what
kind of server they are talking to.
> The shepherd wrote: "Since then it has been found that this extension can
> server (sic)
Note: RFC 4642 does not seem to have been a work product of the TLS WG,
so you probably want to raise this in UTA.
-Ekr
On Wed, Sep 2, 2015 at 7:53 AM, Salz, Rich wrote:
> > Maybe a new RFC obsoleting RFC 4642 (which could at the same time
> > become a standard instead of a proposed standard)?
See:
http://www.ietf.org/mail-archive/web/tls/current/msg17184.html
On Fri, Sep 4, 2015 at 8:27 AM, Russ Housley wrote:
> In Section 7.1, the document says:
>
> 4. finished_secret = HKDF-Expand-Label(xSS,
> "finished secret",
>
he ServerKeyShare. If you include ES in the Finished key, then you are
using ES to authenticate ServerKeyShare, which apparently makes analysis
harder.
-Ekr
Russ
>
>
> On Sep 4, 2015, at 11:33 AM, Eric Rescorla wrote:
>
> See:
> http://www.ietf.org/mail-archive/web/tls/curr
https://github.com/tlswg/tls13-spec/pull/239
Based on the WG discussion, I've created a PR for adding support for PSS.
The basic tactic I took is:
- All in-protocol RSA signatures (i.e., in CertificateVerify) are PSS
- You must use MGF1 with the same hash as you used for the content.
- I added a
Issue: https://github.com/tlswg/tls13-spec/issues/242
In https://github.com/tlswg/tls13-spec/pull/231, Brian Smith argues:
"Nobody must ever be *required* to send an alert. Any requirement for
sending an alert should be SHOULD, at most."
As Dave Garrett notes in the same thread, this is a common
On Sat, Sep 12, 2015 at 2:13 PM, Martin Thomson
wrote:
> On 12 September 2015 at 13:49, Eric Rescorla wrote:
> > "Nobody must ever be required to send an alert. Any requirement for
> sending
> > an alert should be SHOULD, at most."
>
> This was a point
On Sat, Sep 12, 2015 at 3:18 PM, Viktor Dukhovni
wrote:
> On Sat, Sep 12, 2015 at 01:49:49PM -0700, Eric Rescorla wrote:
>
> > "Nobody must ever be *required* to send an alert. Any requirement for
> > sending an alert should be SHOULD, at most."
>
To be clear,
Sorry it's taken me so long to respond, but I'm not convinced that it's not
necessary
to have a secure digest here. Do you have a security analysis that
demonstrates
that that's the case?
-Ekr
On Thu, Sep 10, 2015 at 7:59 AM, Martin Thomson
wrote:
> Hi Hannes,
>
> I've followed a similar chain
I think the potential issue here is needing a way for the server to tell the
client "don't bother sending me data until you've authenticated" (though,
as MT says, you could argue that the client's signature retroactively
authenticates, which does seem like the simplest way to think about things).
I should add: I do think this general line of consolidating all the client
auth modes is a good idea, assuming we can work out the details.
-Ekr
On Wed, Sep 16, 2015 at 11:18 AM, Eric Rescorla wrote:
> I think the potential issue here is needing a way for the server to tell
> the
&g
On Wed, Sep 16, 2015 at 11:35 AM, Andrei Popov
wrote:
> To clarify, the proposal includes removing ECDH_anon, right?
>
Yes.
> If it does, I support it.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Joseph Salowey
> *Sent:* Tuesday, September 1
In addition, they are already part of TLS, so the question would be if we
have
consensus to remove them
-Ekr
On Wed, Sep 16, 2015 at 2:01 PM, Nico Williams
wrote:
> On Wed, Sep 16, 2015 at 01:20:37PM -0700, Brian Smith wrote:
> > I think it is a good idea to remove DH_anon_* and similar EC
On Wed, Sep 16, 2015 at 2:25 PM, Brian Smith wrote:
> On Wed, Sep 16, 2015 at 2:05 PM, Eric Rescorla wrote:
>
>> In addition, they are already part of TLS, so the question would be if we
>> have
>> consensus to remove them
>>
>
> This thread is about the
On Wed, Sep 16, 2015 at 2:24 PM, Nico Williams
wrote:
> On Wed, Sep 16, 2015 at 02:12:07PM -0700, Tony Arcieri wrote:
> > On Wednesday, September 16, 2015, Eric Rescorla wrote:
> >
> > > In addition, they are already part of TLS, so the question would be if
> we
&g
On Wed, Sep 16, 2015 at 4:07 PM, Dave Garrett
wrote:
> On Wednesday, September 16, 2015 06:55:02 pm Nico Williams wrote:
> > On Wed, Sep 16, 2015 at 02:25:52PM -0700, Brian Smith wrote:
> > > On Wed, Sep 16, 2015 at 2:05 PM, Eric Rescorla wrote:
> > > > In addition
On Wed, Sep 16, 2015 at 5:31 PM, Daniel Kahn Gillmor
wrote:
> --dkg
>
> [0] I do not think that clients engaged in a DH key exchange should be
> uniformly required to claim an identity at the TLS layer :)
I agree with this and that's not the intention.
-Ekr
>
https://github.com/tlswg/tls13-spec/pull/248
Folks,
Hugo Krawczyk, Hoeteck Wee, and Bjorn Tackmann suggested a revision
to the key hierarchy that separates out the computation of the MS from the
computation of the keys that are derived from ES and SS. Specifically,
xES and xES are to be used to d
On Sun, Sep 20, 2015 at 6:56 PM, Brian Smith wrote:
> On Sun, Sep 20, 2015 at 4:58 PM, Eric Rescorla wrote:
>
>> https://github.com/tlswg/tls13-spec/pull/248
>>
>> Aside from some analytic advantages
>>
>
> What are the analytic advantages?
>
As I said,
"Versions of TLS prior to 1.3 had limited support for padding. This padding
scheme was selected because it allows padding of any encrypted TLS record
by an arbitrary size (from zero up to TLS record size limits) without
introducing new content types. The design also enforces all-zero padding
octets
On Wed, Sep 23, 2015 at 3:54 AM, Ilari Liusvaara <
ilari.liusva...@elisanet.fi> wrote:
> On Tue, Sep 22, 2015 at 04:27:35PM -0700, Sean Turner wrote:
> > I’ve gone ahead and posted the minutes/list of decisions to:
> >
> >
> https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-i
On Fri, Sep 25, 2015 at 6:13 PM, Dave Garrett
wrote:
> On Tuesday, September 22, 2015 07:27:35 pm Sean Turner wrote:
> > I’ve gone ahead and posted the minutes/list of decisions to:
> >
> >
> https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-interim-2015-tls-3
>
> Issue #185
On Fri, Oct 2, 2015 at 8:24 AM, Salz, Rich wrote:
>
> > 1) We know CRIME threat, but it can not be risk for everyone.
> > e.g., CVSS v2 Base Score: 2.6 (LOW)
>
> CVSS isn't always appropriate; CVSS2 called Heartbleed a 5; CVS v3 called
> it 7.5
>
> > Which one is safer, "tls1.2" v.s. "tls1.3 with
On Sat, Oct 3, 2015 at 3:36 PM, takamichi saito
wrote:
>
> On 2015/10/02, at 22:59, Roland Zink wrote:
>
> > Browsers are not a concern as they already have their own comp/decomp
> codes. HTTP/1 can compress content (Content-encoding and transfer-encoding)
> and HTTP2 has additional header compre
On Sun, Oct 4, 2015 at 1:01 PM, Jeffrey Walton wrote:
> >> Typically compression is used to lower the overall size of data,
> working on
> >> a wide class of inputs. In the perceptual coding case the class of
> inputs
> >> is constrained, and the goal is to keep the data rate constant, not
> >> o
On Sun, Oct 4, 2015 at 7:19 PM, Jeffrey Walton wrote:
> On Sun, Oct 4, 2015 at 9:28 PM, Salz, Rich wrote:
> >> There are many lessons to be learned from this: that a bearer token
> that is
> >> repeated many times is not a good idea; that the trust model in the web
> is
> >> not great; but also
On Sun, Oct 4, 2015 at 9:01 PM, Martin Thomson
wrote:
> On 4 October 2015 at 19:26, Eric Rescorla wrote:
> > Consider the trivial case of ASCII text. Each character takes up the
> > same amount of room, but if you compress (as an intuition pump,
> > think of a simple Huf
On Wed, Oct 7, 2015 at 9:51 PM, Martin Rex wrote:
> Eric Rescorla wrote:
> >
> > That is what the document says:
> > "Versions of TLS before 1.3 supported compression and the list of
> > compression methods was supplied in this field. For any TLS 1.3
> > Cli
On Wed, Oct 7, 2015 at 11:11 PM, Martin Rex wrote:
> Eric Rescorla wrote:
> > Martin Rex wrote:
> >> Eric Rescorla wrote:
> >>>
> >>> That is what the document says:
> >>> "Versions of TLS before 1.3 supported compression and the list o
Todd Short
> // tsh...@akamai.com
> // "One if by land, two if by sea, three if by the Internet."
>
> On Oct 7, 2015, at 5:15 PM, Eric Rescorla wrote:
>
>
>
> On Wed, Oct 7, 2015 at 11:11 PM, Martin Rex wrote:
>
>> Eric Rescorla wrote:
>> > Marti
On Thu, Oct 8, 2015 at 11:29 AM, Simon Josefsson
wrote:
> The notes from the interim meeting mentions 'tls-unique' and points to
> issue #228 on github. I want to get your attention on the draft below.
> Doesn't it do what you are looking for? There is a little in the way of
> a problem stateme
On Thu, Oct 8, 2015 at 12:16 PM, Simon Josefsson
wrote:
> Eric Rescorla writes:
>
> > On Thu, Oct 8, 2015 at 11:29 AM, Simon Josefsson
> > wrote:
> >
> >> The notes from the interim meeting mentions 'tls-unique' and points to
> >> issue
On Thu, Oct 8, 2015 at 1:20 PM, Simon Josefsson wrote:
> > > The introduction says:
> > >
> > >There exists a TLS extension [I-D.ietf-tls-session-hash] that
> > > modify TLS so that the definition of 'tls-unique' [RFC5929] has the
> > > intended properties. If widely implemented and deployed
On Thu, Oct 8, 2015 at 11:22 PM, Martin Rex wrote:
> Eric Rescorla wrote:
> > Short, Todd wrote:
> >>
> >> However, for those ClientHello?s that support older versions, the
> >> compression_method field may contain other values. This means that if a
>
Hi folks,
Please take a look at the following PR which documents a suggestion
made by Karthik Bhargavan about how to prevent protection against
downgrade against downgrade from TLS 1.3 to TLS 1.2 and below.
https://github.com/tlswg/tls13-spec/pull/284
The idea is that if a TLS 1.3 server recei
On Fri, Oct 9, 2015 at 3:09 PM, Karthikeyan Bhargavan <
karthik.bharga...@gmail.com> wrote:
>
> > For reference, the version field in the TLS premaster secret is not
> checked by many servers, IIRC some of them have large market shares.
>
> That’s good to know. It would be tempting to recommend th
On Fri, Oct 9, 2015 at 3:23 PM, Short, Todd wrote:
>
>
> On Oct 9, 2015, at 8:48 AM, Karthikeyan Bhargavan <
> karthik.bharga...@gmail.com> wrote:
>
> - There is a 1/(2^N) chance that valid connections to TLS 1.2 servers will
> be dropped by
>TLS 1.3 clients, because of this proposal. This on
uch
a server and a TLS 1.3 client is 2^{-32}, which seemed a bit high.
-Ekr
On Fri, Oct 9, 2015 at 10:15 PM, Dave Garrett
wrote:
> On Friday, October 09, 2015 08:23:30 am Eric Rescorla wrote:
> > https://github.com/tlswg/tls13-spec/pull/284
> >
> > The idea is that if a TLS 1.3
On Sat, Oct 10, 2015 at 4:44 AM, Dave Garrett
wrote:
> There is one problem with the current proposed sentinel value,
> 0x030403040304. It limits what can be done with future versions. It's not
> as simple as just making that use 0x030503050305, because we want 1.3
> clients to be able to recogni
On Sat, Oct 10, 2015 at 7:37 PM, Dave Garrett
wrote:
> In light of completely unsurprising recent events [0], I think it's time
> to reconsider the current consensus on how to deal with SHA-1 in TLS 1.3.
> Currently, it's allowed if needed by servers that have nothing better [1].
To be clear, t
This seems like a good approach.
-Ekr
On Sun, Oct 11, 2015 at 6:46 AM, Watson Ladd wrote:
> On Sun, Oct 11, 2015 at 8:17 AM, Ilari Liusvaara
> wrote:
> > On Sun, Oct 11, 2015 at 09:25:10AM +0200, Rick van Rein wrote:
> >> > *From:* internet-dra...@ietf.org
> >> >
> >> > Name: dr
On Mon, Oct 12, 2015 at 4:40 AM, Hubert Kario wrote:
> On Thursday 08 October 2015 22:20:42 Stephen Farrell wrote:
> > Hiya,
> >
> > First, thanks all for all your ongoing work on TLS1.3. I'm sure we're
> > all aware that this is important stuff that needs to be, and is being,
> > done carefully
On Mon, Oct 12, 2015 at 7:58 AM, Ilari Liusvaara
wrote:
> On Mon, Oct 12, 2015 at 04:48:08AM -0700, Eric Rescorla wrote:
> > On Mon, Oct 12, 2015 at 4:40 AM, Hubert Kario wrote:
> >
> > > aren't we still missing the 0-RTT mode?
> >
> > It's in th
On Thu, Oct 15, 2015 at 12:17 PM, Dave Garrett
wrote:
> On Thursday, October 15, 2015 09:09:39 am Ilari Liusvaara wrote:
> > So, there are four primitives: Ed25519, Ed25519ph, Ed448 and
> > Ed448ph. And keys MUST NOT be mixed between those.
> >
> > I propose the following:
> > - EdDSA uses one Si
Trying to close the loop on this, I think people are generally in favor of
this
mechanism, so we just need a concrete construction.
I propose we use an N bit field divided as follows
- N - 8 bits of fixed sentinel.
- 8 bits of version number with the semantics being the highest TLS version
numb
On Sat, Oct 17, 2015 at 12:00 PM, Viktor Dukhovni
wrote:
> On Sat, Oct 17, 2015 at 11:35:35AM -0700, Eric Rescorla wrote:
>
> > Trying to close the loop on this, I think people are generally in favor
> of
> > this
> > mechanism, so we just need a concrete constructio
On Sat, Oct 17, 2015 at 2:08 PM, Dave Garrett
wrote:
> On Saturday, October 17, 2015 03:10:18 pm Martin Thomson wrote:
> > The observation is still valuable in the sense that prohibiting values
> > > 1.3 would reduce the likelihood of a false positive by some
> > miniscule amount. In other words
On Sat, Oct 17, 2015 at 2:34 PM, Dave Garrett
wrote:
> On Saturday, October 17, 2015 05:16:49 pm Eric Rescorla wrote:
> > On Sat, Oct 17, 2015 at 2:08 PM, Dave Garrett
> > wrote:
> >
> > > On Saturday, October 17, 2015 03:10:18 pm Martin Thomson wrote:
> > &
On Sat, Oct 17, 2015 at 3:05 PM, Viktor Dukhovni
wrote:
> On Sat, Oct 17, 2015 at 02:53:57PM -0700, Eric Rescorla wrote:
>
> > > It also has a slightly better collision risk, though it's already down
> > > quite low
> >
> > Given that the TCP checksum
On Sat, Oct 17, 2015 at 3:17 PM, Viktor Dukhovni
wrote:
> On Sat, Oct 17, 2015 at 03:10:01PM -0700, Eric Rescorla wrote:
>
> > > This argument is not complete. The false negative rate from TCP
> > > is not by itself sufficient to determine the observed error rate.
&g
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
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
1 - 100 of 1555 matches
Mail list logo
