Below a long list of comments, generally minor. The document is
already very good - we're making great progress!
The record length field is limited by encrypted-length+2048.
Shouldn't it be 1024? - "Each AEAD cipher MUST NOT produce an
expansion of greater
On Mon, Aug 17, 2015 at 06:22:04AM -0400, Yaron Sheffer wrote:
>
> Below a long list of comments, generally minor. The document is
> already very good - we're making great progress!
> The record length field is limited by encrypted-length+2048.
> Shouldn't it be 1024? - "Eac
So apart from being an interesting paper, it also points out (yet again) that
TLS has wy too many baggage suites and mechanisms that provide nothing but
an attack vector (it's not unique in this regard, other protocols also carry
around a vast amount of baggage and unnecessary flexibility whose
On Sunday 09 August 2015 16:41:19 dott...@gmail.com wrote:
> I have a question regarding the handshake message length.
>
> The 'decode_error' alert in TLS 1.2 is defined as:
>
>decode_error
> A message could not be decoded because some field was out of the
> specified range or the
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 écrit :
On Fri, Jul 31, 2015 at 6:52 PM, Simon Bernard
mailto:cont...@simonbernard.eu>> wrote:
Thx.
What did you mean by
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 écrit :
>
>
>
> On Fri, Jul 31, 2
On Monday 17 August 2015 15:02:46 Ilari Liusvaara wrote:
> On Mon, Aug 17, 2015 at 06:22:04AM -0400, Yaron Sheffer wrote:
> > Below a long list of comments, generally minor. The document is
> > already very good - we're making great progress!
> >
> > The record length field is li
On Mon, Aug 17, 2015 at 12:38:54PM +, Peter Gutmann wrote:
> One thing that I'd really like to know is that given the non-PFS (EC)DH suites
> were obviously a dumb idea and barely supported by anything (not just in terms
> of TLS code, no public CA I know of will issue the required X9.42 certs
On Mon, Aug 17, 2015 at 03:18:14PM +, Viktor Dukhovni wrote:
> The relevant code was added to the 1.0.2 dev branch in Apr of 2012,
> backporting said code from the "master" branch where fixed DH
> support was enabled in January of 2012.
>
> On a related note, for what it's worth ECDSA certs a
Viktor Dukhovni writes:
>I can't answer why, but I know what and when:
I was trying to avoid finger-pointing so I didn't go through the changelog to
see whodunnit, I was more interested in the motivation. Same for Apple, why
would you implement something that pretty much no-one else (at the tim
> I was more interested in the motivation. Same for Apple,
> why would you implement something that pretty much no-one else (at the
> time) supported, and for good reason?
Perhaps because this was a year before Snowden and the mindset was
unquestioning complete RFC implementation?
_
On Mon, Aug 17, 2015 at 03:53:59PM +, Peter Gutmann wrote:
> Viktor Dukhovni writes:
>
> >I can't answer why, but I know what and when:
>
> I was trying to avoid finger-pointing so I didn't go through the changelog to
> see whodunnit, I was more interested in the motivation. Same for Apple,
I re-readed this paragraph and it's still not clear, what did you mean
by connection at transport layer for UDP.
I well understand that if a server receive a clientHello with epoch=0,
this means that a new handshake should be done.
But I still don't know what happends in a ResumeHandshake use
On Mon, Aug 17, 2015 at 9:20 AM, Simon Bernard
wrote:
> I re-readed this paragraph and it's still not clear, what did you mean by
> connection at transport layer for UDP.
>
> I well understand that if a server receive a clientHello with epoch=0,
> this means that a new handshake should be done.
>
On 17 August 2015 at 05:02, Ilari Liusvaara wrote:
>
> Actually, I think both should be 256 (256-byte expansion from AEAD
> is already quite much).
Pull request or it didn't happen ;)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/list
On Mon, Aug 17, 2015 at 06:22:04AM -0400, Yaron Sheffer wrote:
> * Server Configuration: how does the client know to whom the
>configuration applies? For example if I connected to
>"*.example.com" (a wildcard cert) and now I connect to
>"srv.example.com", should I use
My original mail had some 15 comments, some trivial, some not. Do you
expect 15 PRs?
Thanks,
Yaron
On 08/17/2015 10:37 AM, Martin Thomson wrote:
On 17 August 2015 at 05:02, Ilari Liusvaara wrote:
Actually, I think both should be 256 (256-byte expansion from AEAD
is already quite muc
Expect? No. That you sent an email is already highly useful.
A PR makes feedback even more useful. For truly trivial stuff, rolling
them up into a single PR is probably even more so.
On Aug 17, 2015 12:01 PM, "Yaron Sheffer" wrote:
> My original mail had some 15 comments, some trivial, some not
Hi there,
Sean Turner (turn...@ieca.com) invites you to participate in the
Doodle poll "Fall '15 TLS Interim."
This is a doodle poll for a 2-day TLS interim meeting. We're
currently planning for Seattle, Washington. The exact location in
Seattle is still TBD, but we've already got two offers.
On Monday, August 17, 2015 06:22:04 am Yaron Sheffer wrote:
> The record length field is limited by encrypted-length+2048. Shouldn't it be
> 1024? - "Each AEAD cipher MUST NOT produce an expansion of greater than 1024
> bytes".
See: https://github.com/tlswg/tls13-spec/issues/55
> Handshake_fail
On 08/11/2015 02:05 PM, Peter Gutmann wrote:
> Clemens Hlauschek writes:
>
>> I published a paper today on KCI-attacks in TLS. This might be of interest to
>> the TLS WG.
>>
>> https://www.usenix.org/conference/woot15/workshop-program/presentation/hlauschek
>
> Some comments on this, it looks
21 matches
Mail list logo
