On 2016-03-18 09:57, Peter Gutmann wrote:
Watson Ladd writes:
>As written supporting this draft requires adopting the encrypt-then-MAC
>extension. But there already is a widely implemented secure way to use MACs
>in TLS: AES-GCM.
This is there as an option if you want it. Since it offers no
Hubert Kario writes:
>I was thinking of something like the following:
>
> The length of verify_data (verify_data_length) in the Finished message
> MUST be equal to the length of output of the hash function used as the
> basis of the PRF selected for the ciphersuite. That is, in case of
> SHA-
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 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
-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
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 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
__
> 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 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
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
> 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
Karthikeyan Bhargavan writes:
>Yes, I’d suggest hashing in the log up to ServerHello, or if you don’t want
>to clone the hash state, then maybe the log up to ServerCertificate.
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
Peter Gutmann writes:
> compressed points are patented
Which patent are you referring to?
US 6141420, I suppose. Let's ignore the question of what's in the prior
art (1992 Harper--Menezes--Vanstone) and what's actually claimed in the
patent. Are you aware that this patent expired in July 2014?
>
On Sun, Mar 20, 2016 at 4:09 AM, Ilari Liusvaara
wrote:
>
> [1] TLS 1.3 doesn't completely fix this: Even if TLS 1.3 itself has
> negotiated DHE parameter sizes, there is nothing preventing down-
> negotiation to TLS 1.2, followed by server dumping some bad para-
> meter sizes (forcing client to e
> So presumably instead of hashing the bare nonces for the keyex sig you'd hash
> the entire hello message that contains them?
Yes, I’d suggest hashing in the log up to ServerHello, or if you don’t want to
clone the hash state,
then maybe the log up to ServerCertificate.
I agree that the benefi
Karthikeyan Bhargavan writes:
>Adding the handshake hash to the ServerKeyExchange (a la EMS) provides some
>nice protections against downgrade and seems to be worth the effort.
My only real concern with this is that if you've got an API that doesn't allow
forking, you're now running three hashes
> The problem with this is that the standard hash API is { Init, [ Update,
> Update, ... ], Final }, so this only works if you've got access to a custom
> API that allows you to fork the state so one branch goes to Final and the
> other continues with Update. It's good if you've got it, but a lot
ilariliusva...@welho.com writes:
>Well, if you have suitable implementation for it, the hash in EMS is over
>prefix of what hash in Finished is over (so if you can finalize multiple
>times, you can get away with just one computation).
The problem with this is that the standard hash API is { Init
On Sun, Mar 20, 2016 at 06:36:09AM +, Peter Gutmann wrote:
> Dave Garrett writes:
>
> >It would be a lot simpler, safer, and interoperable to just mandate use of
> >the Extended Master Secret Extension [RFC 7627].
> >
> >https://tools.ietf.org/html/rfc7627
>
> Yeah, in hindsight it makes mor
Dave Garrett writes:
>It would be a lot simpler, safer, and interoperable to just mandate use of
>the Extended Master Secret Extension [RFC 7627].
>
>https://tools.ietf.org/html/rfc7627
Yeah, in hindsight it makes more sense, I'll update the draft, although the
update may not get in before the I
Dave Garrett writes:
I've already replied to the other parts in an earlier reply, leaving:
>The big glaring problem, however, in multiple places, are the statements that
>something is "implicit in TLS-LTS, there is no need to signal it" via its
>designated extension. No! These features MUST be i
Hi
On 16/03/2016 15:02, "TLS on behalf of Watson Ladd" wrote:
>On Wed, Mar 16, 2016 at 5:36 AM, Peter Gutmann
> wrote:
>> After a number of, uh, gentle reminders from people who have been
>>waiting for
>> this, I've finally got around to posting the TLS-LTS draft I mentioned
>>a while
>> back.
Hi
On 16/03/2016 18:44, "Watson Ladd" wrote:
>On Wed, Mar 16, 2016 at 11:22 AM, Paterson, Kenny
> wrote:
>> Hi
>>
>> On 16/03/2016 15:02, "TLS on behalf of Watson Ladd"
>>> on behalf of watsonbl...@gmail.com> wrote:
>>
>>
>>
>>>The analysis of TLS 1.3 is just wrong. TLS 1.3 has been far more
>>
https://tools.ietf.org/html/draft-gutmann-tls-lts-01#section-3.2
> TLS-LTS adds a hash of the domain parameters into the master secret
> to protect against the use of manipulated curves/domain parameters:
>
> o TLS-LTS implementations MUST include a SHA-256 hash of the EDH or
> ECDH pa
Dear Kenny,
thank you for clarifying the state of the cryptographic analysis of TLS 1.2
and 1.3! I also do not see TLS 1.3 being nearly as good understood from a
security standpoint as the previous version. This is only natural given
that it is so recent. I am also not quite happy with the existin
Wan-Teh Chang writes:
>This is the procedure specified in PKCS #1 v2.1 (RFC 3447), Section 8.2.2,
>with the additional requirement that the comparison in Step 4 be constant-
>time, right?
Good catch, thanks! I've added it to the draft.
Peter.
___
TLS
On Wed, Mar 16, 2016 at 5:36 AM, Peter Gutmann
wrote:
> After a number of, uh, gentle reminders from people who have been waiting for
> this, I've finally got around to posting the TLS-LTS draft I mentioned a while
> back. It's now available as:
>
> http://www.ietf.org/id/draft-gutmann-tls-lts-00
On Wed, Mar 16, 2016 at 11:22 AM, Paterson, Kenny
wrote:
> Hi
>
> On 16/03/2016 15:02, "TLS on behalf of Watson Ladd" on behalf of watsonbl...@gmail.com> wrote:
>
>>On Wed, Mar 16, 2016 at 5:36 AM, Peter Gutmann
>> wrote:
>>> After a number of, uh, gentle reminders from people who have been
>>>wa
After a number of, uh, gentle reminders from people who have been waiting for
this, I've finally got around to posting the TLS-LTS draft I mentioned a while
back. It's now available as:
http://www.ietf.org/id/draft-gutmann-tls-lts-00.txt
Abstract:
This document specifies a profile of TLS 1.2
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 into that because it's such a rathole,
you've got everything from th
On Wed, Mar 16, 2016 at 5:36 AM, Peter Gutmann
wrote:
> After a number of, uh, gentle reminders from people who have been waiting for
> this, I've finally got around to posting the TLS-LTS draft I mentioned a while
> back. It's now available as:
>
> http://www.ietf.org/id/draft-gutmann-tls-lts-00
On Wednesday, March 16, 2016 08:36:05 am Peter Gutmann wrote:
> After a number of, uh, gentle reminders from people who have been waiting for
> this, I've finally got around to posting the TLS-LTS draft I mentioned a while
> back. It's now available as:
>
> http://www.ietf.org/id/draft-gutmann-tl
Watson Ladd writes:
>As written supporting this draft requires adopting the encrypt-then-MAC
>extension. But there already is a widely implemented secure way to use MACs
>in TLS: AES-GCM.
This is there as an option if you want it. Since it offers no length hiding,
it's completely unacceptable
On Friday 18 March 2016 08:57:26 Peter Gutmann wrote:
> Watson Ladd writes:
> >Likewise, this draft modifies the way the master secret is computed,
> >despite a widely implemented different solution to the problem,
> >namely the EMS triple handshake fix.
>
> Firstly, that solves an entirely diffe
41 matches
Mail list logo
