> On 01 Mar 2017, at 14:29, Yoav Nir wrote:
>
>
>> On 1 Mar 2017, at 15:06, Aaron Zauner wrote:
>>
>>
>>> On 24 Feb 2017, at 14:07, Salz, Rich wrote:
>>>
>>>> Assuming 256-bit AES-CCM suites are needed, I think the better place to
> On 01 Mar 2017, at 13:18, Dang, Quynh (Fed) wrote:
>
>
>
> From: Aaron Zauner
> Date: Wednesday, March 1, 2017 at 8:11 AM
> To: 'Quynh'
> Cc: Sean Turner , "" , IRTF CFRG
>
> Subject: Re: [Cfrg] Closing out tls1.3 "Limits on key u
> On 25 Feb 2017, at 14:28, Dang, Quynh (Fed) wrote:
>
> Hi Sean, Joe, Eric and all,
>
> I would like to address my thoughts/suggestions on 2 issues in option a.
>
> 1) The data limit should be addressed in term of blocks, not records. When
> the record size is not the full size, some user mi
> On 24 Feb 2017, at 14:07, Salz, Rich wrote:
>
>> Assuming 256-bit AES-CCM suites are needed, I think the better place to put
>> them is in the TLS 1.3 document.
>
> That's a really big assumption. ;)
>
> I think the burden is on folks to *prove* (yeah, I know) that additional
> cipher suite
> On 16 Feb 2017, at 14:23, Dang, Quynh (Fed) wrote:
>
> Hi Kenny,
>
> I am glad to see that you enjoyed the discussion more than what you planed
> for the time on your vacation. We love crypto and the IETF!
>
> From: "Paterson, Kenny"
> Date: Wednesday, February 15, 2017 at 8:46 AM
> To: '
> On 15 Feb 2017, at 19:25, Martin Thomson wrote:
>
> On 16 February 2017 at 04:20, Yoav Nir wrote:
>> No, not really, but TLS is not just the web, and there are connections that
>> last for a long time and transfer large amounts of data. Think datacenter
>> synchronization. At packet-sized rec
> On 10 Feb 2017, at 07:07, Sean Turner wrote:
>
> All,
>
> We’ve got two outstanding PRs that propose changes to draft-ietf-tls-tls13
> Section 5.5 “Limits on Key Usage”. As it relates to rekeying, these limits
> have been discussed a couple of times and we need to resolve once and for all
* Sean Turner [18/11/2016 03:13:23] wrote:
> At IETF 97, the chairs lead a discussion to resolve whether the WG should
> rebrand TLS1.3 to something else. Slides can be found @
> https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pdf.
>
> The consensus in the room
Hi,
> On 06 Jun 2016, at 21:05, Peter Gutmann wrote:
>
> TLS-LTS, https://tools.ietf.org/html/draft-gutmann-tls-lts-03, has more or
> less stabilised, incorporating all the feedback I've had for it (there's only
> one open question still remaining), so I'd like to request that it now be
> adopte
> On 14 Jun 2016, at 19:25, Joseph Lorenzo Hall wrote:
>
> s/it's/its/ in one place in your errata text, Aaron.
Thank you. I suggest the RFC Errata editors change text and further
additions/recommendations by others along the way when publishing (if that's
the right way to proceed, I'm quite
Hi,
It's been a few weeks. We by now know of at least one other affected vendor. I
think this errata is valid and should be accepted. I'll take any feedback and
improvements if valid.
Aaron
signature.asc
Description: Message signed with OpenPGP using GPGMail
__
Hi,
> The first step of our attack involves attacker controlled content. So yes
> (phishing, unauthenticated HTTP, selective company DPI etc.). In our example
> we use a local proxy to carry out the attack. I hope I can post a full
> version of the actual paper and PoC to this thread soon.
htt
Hi Kenny,
> On 16 May 2016, at 17:24, Paterson, Kenny wrote:
>
> Good to get this cleared up. Yes, it's eminently practical to recover the
> two plaintexts from their XOR assuming you have a good language model
> (e.g. one can use a Markov model with a suitable memory length; this would
> work f
Hi Kenny,
> On 16 May 2016, at 16:48, Paterson, Kenny wrote:
>
> Maybe the confusion is this: in your authenticity attack, you do recover
> the GHASH key, and the effect is catastrophic. In the confidentiality
> attack, one can recover plaintexts for the records with repeated nonces,
> but not t
Hi Kenny,
> On 16 May 2016, at 16:18, Paterson, Kenny wrote:
>
> Hi Aaron,
>
> If AES-GCM ever generates two ciphertexts using the same key and the same
> 96-bit nonce, then the underlying CTR-mode keystreams will be the same.
> XORing the ciphertexts together then produces the XOR of the plain
Hi,
In the TLS case, RFC5288 defines the following IV construction (Section 3):
```
struct {
opaque salt[4];
opaque nonce_explicit[8];
} GCMNonce;
The salt is the "implicit" part of the nonce and is not sent in the
packet. Instead
On Sun, May 15, 2016 at 3:52 PM, Peter Gutmann
wrote:
> Aaron Zauner writes:
>
> >What do you think nonce stands for?
> >https://en.wikipedia.org/wiki/Cryptographic_nonce
>
> Well there's your first mistake, you're using Wikipedia as a reference.
> "non
Hi,
On May 15, 2016 10:28, "Peter Gutmann" wrote:
>
> RFC Errata System writes:
>
> >The following errata report has been submitted for RFC5288, "AES Galois
> >Counter Mode (GCM) Cipher Suites for TLS".
>
> I think the erratum needs an erratum.
No problem, but:
>Firstly, "nonce" doesn't mean "n
> On 25 Apr 2016, at 22:12, Sean Turner wrote:
> - Support adoption and are willing to review/comment on the draft by
> 201600429. Note that the extensions is pretty straight forward, but the
> chairs still need people to comment on the draft as we’re processing it down
> the path.
...
>
>
Hi Uri,
* Blumenthal, Uri - 0553 - MITLL [06/04/2016 20:37:35] wrote:
> I seem to recall that Ted Krovetz some time ago submitted a draft (to
> CFRG?) defining OCB: https://tools.ietf.org/html/draft-krovetz-ocb-04 .
> Perhaps these two should be brought to sync, since the nonce construction
> cha
Hi,
> On 30 Mar 2016, at 03:53, Sean Turner wrote:
>
> Hi!
>
> In Yokohama, we discussed changing the IANA registry assignment rules for
> cipher suites to allow anyone with a stable, publicly available, peer
> reviewed reference document to request and get a code point and to add an
> “IETF
s-ocb-04.txt
> Date: 4 April 2016 at 18:45:26 GMT+2
> To: "Aaron Zauner"
> Message-Id: <20160404164526.15645.26001.idtrac...@ietfa.amsl.com>
>
>
> A new version of I-D, draft-zauner-tls-aes-ocb-04.txt
> has been successfully submitted by Aaron Zauner and poste
* aluykx [23/03/2016 09:12:02] wrote:
> >Finally, and this calls for an opinion: do you believe that given these
> >results
> >we should include a KeyUpdate feature in TLS 1.3?
>
> Ideally it would be better to include a KeyUpdate feature, but the added
> complexity could risk introducing vulnera
Hi,
> On 17 Mar 2016, at 07:35, Efthymios Iosifides wrote:
>
> Hello all.
>
> I have just found on the ietf archives an email discussion about the
> inclusion of the SPECK Cipher
> in the tls standards.
> It's reference is below
> :https://www.ietf.org/mail-archive/web/tls/current/msg13824.ht
> On 23 Feb 2016, at 16:34, Salz, Rich wrote:
>
> Is anyone using SRP with TLS? The OpenSSL implementation in particular?
>
I have been in the past and know of some installations and customers that
actually use it.
Although the lack of modern cipher-suites for SRP makes it not very attractiv
Hi,
* sne...@dei.uc.pt [01/01/2016 18:19:26] wrote:
> The contention with GCM in this thread has been, so far, focused on
> confidentiality. This is because, by a result of Bernstein [1] (see also
> Appendix C of [2]), after q = 2^60 messages sent, plus q' = 2^60 attempted
> forgeries by an attac
Hi Samuel,
* Samuel Neves [01/01/2016 12:19:36] wrote:
> OCB is, if anything, worse than GCM when it comes to data volume limits. It
> has the same confidentiality bounds as GCM
> (slightly worse, in fact), but once you hit a collision you also lose
> authenticity and enable simple forgeries [1
* Aaron Zauner [01/01/2016 07:35:26] wrote:
> This might be a good time to point again to my existing AES-OCB
> draft that hasn't really seen a lot of discussion nor love lately.
> It expired but I've recently updated the draft (not yet uploaded
> to IETF as I'm waiti
Hi,
* Simon Josefsson [16/12/2015 09:44:55] wrote:
> I don't like re-keying. It is usually a sign that your primitives are
> too weak and you are attempting to hide that fact. To me, it is similar
> to discard the first X byte of RC4 output.
>
> If AES-GCM cannot provide confidentiality beyond
Errata:
Aaron Zauner wrote:
> BTW, I played with SNI DoS a few months back (not too much though as it
> wasn't worth a paper), seems not to be as bad as it used to be because
> implementations nowadays have at least some counter-measures.
Was supposed to say 'renegotiation
Hey,
Jacob Appelbaum wrote:
>> I don't think traffic analysis is in the treat model for TLS proper.
>
> I'm confused by what you mean by traffic analysis. We encrypt content
> in TLS because we know that we want confidentiality. We want that
> because we know people do basic traffic analysis look
PS:
Aaron Zauner wrote:
> No it's not. It's a very short presentation from a TLS-WG interim
> meeting. The threat-model concerns Akamai's (and other's) current and -
> possibly - future use of TLS. We're not trying to build an Onion routing
> protocol. Given t
Hi *,
Jacob Appelbaum wrote:
> I'm sorry but that analysis is just not a serious and rigorous analysis.
No it's not. It's a very short presentation from a TLS-WG interim
meeting. The threat-model concerns Akamai's (and other's) current and -
possibly - future use of TLS. We're not trying to build
Hi,
Hubert Kario wrote:
> then we need Best Current Practice for applications describing to them
> how TLS needs to be used, e.g. make sure that they are doing writes as
> big as possible, checking if timing of responses doesn't leak much
> information, etc. Forcing TLS implementation to combin
Hi,
As some might remember I've been working on a draft for AES-OCB
cipher-suites in TLS
(https://datatracker.ietf.org/doc/draft-zauner-tls-aes-ocb/). Where,
ideally, OCB would replace CCM [or even GCM, but I don't think that's
realistic] in TLS.
Beginning of this summer Rogaway and IBM (Jutla) f
On Wed, Sep 16, 2015 at 4:10 AM, Tom Ritter wrote:
> On 15 September 2015 at 20:42, Tony Arcieri wrote:
> > +1 for removing anonymous DH
>
> +1.
>
+1.
Aaron
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
PS:
* Aaron Zauner [06/08/2015 00:48:03] wrote:
> I've written to Gligor and Donescu (his mail address is bouncing though
> and I do not have another/current one). I've not received any replies as
> of today. Rogaway, like myself, is not sure if that patent actually
>
Hi,
Blumenthal, Uri - 0553 - MITLL wrote:
> Aaron,
>
> Great work! I can't wait to see OCB standardized and implemented.
>
> One thing though. There has been mentioning of Gligor patent(s) - were you
> able to look into that? Or perhaps Phil or Charanjit could comment on this
> (though technic
Hi,
A short update on the matter of IPR related to AES-OCB in TLS:
It took some time but over the past couple of weeks all IPR exemptions
have been filed by the original patent holders (Rogaway and IBM
[Jutla]). These IPR exemptions can be viewed over here:
https://datatracker.ietf.org/ipr/search
* Andrei Popov [25/07/2015 01:26:41] wrote:
> Yes, this sounds good to me too.
>
+1.
Aaron
signature.asc
Description: Digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Dave Garrett wrote:>
> It's wrong, though. If a server rejects a client connection because the
> server only supports RC4 and the client doesn't, the correct error for the
> server to return is "insufficient_security". If you invert the meaning, I
> guess the server has insufficient security,
Dave Garrett wrote:
> On Thursday, July 23, 2015 06:49:06 am Aaron Zauner wrote:
>> I mean I kinda agree that 'insufficent security' is a misleading name,
>> but as it has been used for decades in TLS I'm a bit hesitant if it's a
>> good idea to chang
Hi Dave,
Dave Garrett wrote:
>
> enum {
>handshake_failure(40),
>unsupported_cipher_suites(71), /* formerly insufficient_security */
>unsupported_dh_groups(72), /* new */
>client_authentication_failure(73), /* new */
>(255)
>} AlertDescription;
>
43 matches
Mail list logo
