On Monday, March 21, 2016, Dave Garrett wrote:
> I don't exactly see a 'T' for "LTS" in "Legacy Support Profile"... ;)
>
Haha, oops. LSP?
--
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Monday, March 21, 2016 09:59:27 pm Tony Arcieri wrote:
> On Mon, Mar 21, 2016 at 12:42 PM, Dave Garrett wrote:
> > Frankly, I think this document should be renamed "Extended Support
> > Profile", rather than "Long-term Support Profile" (and ESP instead of LTS).
>
> Legacy Support Profile? Then
On Monday, March 21, 2016 06:08:45 pm Eric Rescorla wrote:
> Ah, I see. Let me see if I can clear this up, if you wanted to send a PR,
> that wouldn't help too.
I assume you meant "wouldn't hurt" or "would help" here. ;)
Dave
___
TLS mailing list
TLS@
On Mon, Mar 21, 2016 at 12:42 PM, Dave Garrett
wrote:
> Frankly, I think this document should be renamed "Extended Support
> Profile", rather than "Long-term Support Profile" (and ESP instead of LTS).
Legacy Support Profile? Then you don't have to change the acronym
--
Tony Arcieri
__
Folks,
I've just submitted TLS 1.3 draft-12 and it should appear once it
makes its way through secretariat processing. Until then, you can find
it at:
http://tlswg.github.io/tls13-spec/
This revision is largely cleanup of a bunch of outstanding PRs and of
issues found during interop testing.
On 22 March 2016 at 06:40, Hubert Kario wrote:
> Only in theory, in practice you can do most of the same things in GET's
> as you can in POSTs.
>
> in other words, basically web frameworks can be made to modify server
> state upon receiving GET request
Ahh yes, but it's not the *client's* fault
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security of the IETF.
Title : Elliptic Curve Cryptography (ECC) Cipher Suites for
Transport Layer Security (TLS) Versions 1.2 and Earlier
Aut
> On 21 Mar 2016, at 3:19 PM, Salz, Rich wrote:
>
>
>> OK, I've posted another update that specifies this, as well as use of EMS,
>> and
>> cleans up a few other areas. It's a bit of a rush job because of the
>> impending
>> lockdown for IETF 95, but hopefully the gist is there:
>>
>> http:
On Mon, Mar 21, 2016 at 2:59 PM, Hannes Tschofenig <
hannes.tschofe...@gmx.net> wrote:
> Hi Ekr,
>
> ~snip~
>
> > Section 6.3.1.2 explains that the ServerHello message handling:
> >
> > "
> > The server will send this message in response to a ClientHello
> message
> > when it was a
Hi Ekr,
~snip~
> Section 6.3.1.2 explains that the ServerHello message handling:
>
> "
> The server will send this message in response to a ClientHello message
> when it was able to find an acceptable set of algorithms and the
> client’s “key_share” extension was acceptable.
On Monday 14 March 2016 12:12:51 Geoffrey Keating wrote:
> Colm MacCárthaigh writes:
> > On Mon, Mar 14, 2016 at 11:04 AM, Subodh Iyengar
wrote:
> > > Like Kyle mentioned the thing that 0-RTT adds to this is infinite
> > > replayability. As mentioned in the other thread we have ways to
> > > red
On Monday, March 21, 2016 10:38:43 am Hubert Kario wrote:
> If your hardware really can't do anything better than 2048 bit RSA, it's
> not LTS, it's a crippled embedded system, and it definitely shouldn't
> get a stamp of approval "good for next X0 years" or anything similar
> like a LTS moniker
Hi
I think Rich Salz already said exactly what CFRG would say:
> If someone wants to see SPECK adopted by IETF protocols, the first thing
>that will have to happen is papers analyzing it.
There's some analysis already, but not that much.
Regards,
Kenny
On 21/03/2016 14:27, "TLS on behalf
On Fri, Mar 18, 2016 at 8:41 PM, RFC Errata System
wrote:
> The following errata report has been submitted for RFC6347,
> "Datagram Transport Layer Security Version 1.2".
>
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.
Our long national nightmare is over.
On Mon, Mar 21, 2016 at 7:42 AM, Sean Turner wrote:
> FYI
>
> > Begin forwarded message:
> >
> > From: "Sean Turner"
> > Subject: Publication has been requested for draft-ietf-tls-falsestart-01
> > Date: March 21, 2016 at 10:42:10 EDT
> > To:
> > Cc: "Sean
On Monday 21 March 2016 12:35:25 Peter Gutmann wrote:
> Hubert Kario writes:
> >Note that I asked for "being able to handle", not "selects and uses".
>
> The issue here is that a Cortex M3 isn't going to be able to handle
> RSA-2048, no matter what an RFC says :-). That's what the "ability
> of
FYI
> Begin forwarded message:
>
> From: "Sean Turner"
> Subject: Publication has been requested for draft-ietf-tls-falsestart-01
> Date: March 21, 2016 at 10:42:10 EDT
> To:
> Cc: "Sean Turner" , iesg-secret...@ietf.org,
> tls-cha...@ietf.org, s...@sn3rd.com
>
> spt has requested publication
On Mar 09, 2016, at 09:16, Hannes Tschofenig wrote:
…snip
> -
>
> In a nutshell, while I do not believe that the attack described is
> realistic I am sensitive to the problem of creating brittle code.
>
> If it is OK for the working group then I would like to revert back to
> t
If we’re going to get into the cryptanalysis of SPECK then this thread should
move off the TLS list and possibly to the CFRG list.
spt
> On Mar 21, 2016, at 10:07, Efthymios Iosifides wrote:
>
> >I don't see any compelling argument for the inclusion of SPECK? Not only
> >would the affiliation
> other hand we shall evaluate if the SPECK could be actually used
> what about the future specifications
> what if we could prove that ..
Those are all great questions. But in the current state of things, they are
unanswered questions.
If someone wants to see SPECK adopted by IETF protocols, t
>I don't see any compelling argument for the inclusion of SPECK? Not only
would the affiliation with NSA give the >TLS-WG a bad rep. in the public,
more importantly, it makes one of our main problems worse: combinatorial
explosion >of possible cipher-suites in TLS. This problem is so bad that it
ne
> OK, I've posted another update that specifies this, as well as use of EMS, and
> cleans up a few other areas. It's a bit of a rush job because of the
> impending
> lockdown for IETF 95, but hopefully the gist is there:
>
> http://www.ietf.org/id/draft-gutmann-tls-lts-02.txt
So is someone "in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Aloha!
Peter Gutmann wrote:
> Hubert Kario writes:
>
>> Note that I asked for "being able to handle", not "selects and
>> uses".
>
> The issue here is that a Cortex M3 isn't going to be able to handle
> RSA-2048, no matter what an RFC says :-).
Hubert Kario writes:
>Note that I asked for "being able to handle", not "selects and uses".
The issue here is that a Cortex M3 isn't going to be able to handle RSA-2048,
no matter what an RFC says :-). That's what the "ability of the hardware to
deal with large keys" was meant to say.
When I'v
On Saturday 19 March 2016 09:30:26 Peter Gutmann wrote:
> Hubert Kario writes:
> >also, if it really is supposed to be Long Term Support, why it
> >doesn't say anything about implementation explicitly being able to
> >handle big key sizes? both RSA and DHE?
>
> I've deliberately avoided getting i
Watson Ladd :
The use of predictable IVs in TLS 1.0 was first commented on by
> Rogaway in 1995. (I'm hunting down the source, but this is from a
> presentation of Patterson)
I think you mean
http://web.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt,
which discussed the probl
On Sat, 2016-03-19 at 07:51 -0700, Watson Ladd wrote:
> On Fri, Mar 18, 2016 at 4:31 PM, Peter Gutmann
> wrote:
> >
> > Watson Ladd writes:
> >
> > >
> > > Then use a padding extension that solves all problems, instead of
> > > relying on
> > > a side effect of CBC mode.
> > It's not a "side-e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Aloha!
Tom Ritter wrote:
> On 17 March 2016 at 21:09, Martin Thomson
> wrote:
>> On 18 March 2016 at 12:37, Mike Hamburg
>> wrote:
>>> No. The goal should be to remove ciphers, not add new ones,
>>> unless we have a really compelling reason.
>> A
28 matches
Mail list logo
