On Tuesday, March 22, 2016 08:38:13 pm Timothy Jackson wrote:
> How would this group feel about a proposal to address this by specifying in
> the 1.3 specification that implementations must ensure that the strength of
> the certificate must be >= strength of ECDHE/DHE >= strength of the cipher?
> How would this group feel about a proposal to address this by
> specifying in the 1.3 specification that implementations must ensure
> that the strength of the certificate must be >= strength of ECDHE/DHE >=
> strength of the cipher?
Strongly opposed, for the reasons Martin said. Insisting that
Please let the chairs know if you have an addition topic you wish to get on
the agenda. We can't guarantee that there will be time as TLS 1.3 work
takes precedence right now.
Thanks,
Joe
On Tue, Mar 22, 2016 at 11:53 AM, Sean Turner wrote:
> Thanks for the getting this out.
>
> Obviously, wha
On Tue, Mar 22, 2016 at 5:38 PM, Timothy Jackson
wrote:
> I’ve noted that many (most?) TLS implementations choose their ECDHE curves
> seemingly without regard to the cipher suite strength. Thus, they'll select
> an AES256 cipher suite (e.g. TLS_ECDHE_ECDSA_WITH_AES256_SHA384), but then
> generat
On 23 March 2016 at 11:38, Timothy Jackson wrote:
> How would this group feel about a proposal to address this by specifying in
> the 1.3 specification that implementations must ensure that the strength of
> the certificate must be >= strength of ECDHE/DHE >= strength of the cipher?
There are goo
I’ve noted that many (most?) TLS implementations choose their ECDHE curves
seemingly without regard to the cipher suite strength. Thus, they'll select an
AES256 cipher suite (e.g. TLS_ECDHE_ECDSA_WITH_AES256_SHA384), but then
generate an ECDHE key on the P256 curve. This seems odd to me, since t
writes:
> As far as I can see, the original text is correct, which is easy to
> see if you look at the corresponding paragraph of RFC 4347 (DTLS 1.0):
>
> version
> The version of the protocol being employed. This document
> describes DTLS Version 1.0, which uses the version { 254,
Thanks for the getting this out.
Obviously, what’s changed and what’s still outstanding is going to be the lion
share of our discussions in BA.
spt
> On Mar 22, 2016, at 13:16, internet-dra...@ietf.org wrote:
>
> A new Internet-Draft is available from the on-line Internet-Drafts
> directories
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(s) : E. Rescorla
Filename : draf
The IESG has received a request from the Transport Layer Security WG
(tls) to consider the following document:
- 'ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on thi
On Mon, Mar 21, 2016 at 9:22 PM, Dave Garrett
wrote:
> 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. ;)
We won't kn
On Tuesday 22 March 2016 00:26:46 Dave Garrett wrote:
> 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 Profi
On Tuesday 22 March 2016 10:45:32 Martin Thomson wrote:
> 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
On Tuesday 22 March 2016 09:55:07 Peter Gutmann wrote:
> Hubert Kario writes:
> >it doesn't explain where this "RSA-SHA-256" is used. IMHO it is
> >ambiguous.
> >
> >The "no MAC truncation" is also not explicit about what the sizes
> >should be.
> Well can you suggest some wording? I can't see ho
On Tuesday 22 March 2016 09:48:51 Peter Gutmann wrote:
> Joachim Strömbergson writes:
> >When you say that "a Cortex M3 isn't going to be able to handle
> >RSA-2048", what do you mean specifically? Considering that it is
> >being done by for example SharkSSL [1], is supported by ARM mbed TLS
> >(n
Hiya,
On 10/03/16 19:41, Stephen Farrell wrote:
> This is ready to go but I've one question. Sorry I don't
> recall if this was discussed previously, if it was, then
> just say and I'll move this along to IETF LC.
>
> My question is: Should the WG take the opportunity to more
> tightly define th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Aloha!
Peter Gutmann wrote:
> In these situations, crypto comes at about position 77 in the
> priority list, with most of the previous ones taken up by
> "reliability" and "availability". If you write a spec that in effect
> mandates a 15-second del
Hubert Kario writes:
>it doesn't explain where this "RSA-SHA-256" is used. IMHO it is ambiguous.
>
>The "no MAC truncation" is also not explicit about what the sizes should be.
Well can you suggest some wording? I can't see how much more unambiguous a
statement like "no MAC truncation" can be.
Joachim Strömbergson writes:
>When you say that "a Cortex M3 isn't going to be able to handle RSA-2048",
>what do you mean specifically? Considering that it is being done by for
>example SharkSSL [1], is supported by ARM mbed TLS (nee PolarSSL) [2] I fail
>to see what hardware limits you are seei
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Aloha!
Efthymios Iosifides wrote:
> The reputation aspect is not necessarily and strictly correlated
> with it's provenance, but with it's actual security and performance.
> And the SPECK we shall note that performs quite well. Also we shall
> not f
20 matches
Mail list logo
