Re: [TLS] SHA-3 in SignatureScheme

2016-09-08 Thread Martin Thomson
On 7 September 2016 at 18:24, Ilari Liusvaara wrote: > Therefore I think that this work should be pursued in a separate spec, > not in TLS 1.3 core. I think that Ilari has it here. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo

Re: [TLS] 0-RTT encrypted data limits

2016-09-08 Thread Martin Thomson
On 1 September 2016 at 23:45, Eric Rescorla wrote: >> Should there be recommendation for clients to cut transfer and send >> Finished if the client receives EncryptedExtensions without >> early_data extension? > > > I thought that was implicit, but i'd take a PR that did that. Note that this is s

Re: [TLS] Finished stuffing

2016-09-08 Thread Hugo Krawczyk
On Thu, Sep 8, 2016 at 5:29 AM, Ilari Liusvaara wrote: > On Wed, Sep 07, 2016 at 07:43:53PM -0400, Hugo Krawczyk wrote: > > On Wed, Sep 7, 2016 at 7:18 PM, Eric Rescorla wrote: > > > > > > > > > > > On Wed, Sep 7, 2016 at 4:02 PM, Hugo Krawczyk > > > wrote: > > > > > > I also have a problem wit

Re: [TLS] Version negotiation, take two

2016-09-08 Thread Xiaoyin Liu
I support this proposal. Xiaoyin From: David Benjamin Sent: Thursday, September 8, 2016 12:09 PM To: tls@ietf.org Subject: [TLS] Version negotiation, take two Hi folks, I'd like to revisit the question of version negotiation. EKR wrote up some

Re: [TLS] Version negotiation, take two

2016-09-08 Thread Short, Todd
We already have a useless field in the record header; the record_version is fixed to { 3, 1 }; and this is not a coincidence. I think it would be better to maintain a 1.2-compatible version negotiation for backwards compatibility, and have a more robust and expressive version negotiation option.

Re: [TLS] PR#625: Change alert requirements

2016-09-08 Thread Hubert Kario
On Monday, 5 September 2016 11:02:57 CEST Eric Rescorla wrote: > PR: https://github.com/tlswg/tls13-spec/pull/625 Finally found some time to take a look at it. So in general I like the change to "abort the handshake with a alert", the "send a fatal alert and close the connection" was a bit clu

Re: [TLS] [Cfrg] 3DES diediedie

2016-09-08 Thread Kyle Rose
On Thu, Sep 8, 2016 at 12:46 PM, Yoav Nir wrote: > > Good questions, no doubt. But I don’t think they can be answered. > > Someone is going to specify protocols and algorithms. This could be the > IETF. This could be the ITU, or IEEE, or some other SDO. Makes no > difference. > Someone is going t

Re: [TLS] Finished stuffing

2016-09-08 Thread Salz, Rich
I’m fine with this. I am strongly in favor of having one PSK identity. ☺ -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [Cfrg] 3DES diediedie

2016-09-08 Thread Yoav Nir
> On 8 Sep 2016, at 7:08 PM, Kyle Rose wrote: > > On Thu, Sep 8, 2016 at 1:53 AM, Peter Gutmann > wrote: > The only data point I have is that every time I've tried to disable DES in > a new release (and by DES I mean single DES, not 3DES) I've had a chorus of >

Re: [TLS] [Cfrg] 3DES diediedie

2016-09-08 Thread Tony Arcieri
On Thu, Sep 8, 2016 at 8:01 AM, Derek Atkins wrote: > So they are finally up to 80-bit security? Woohoo! > That makes me feel so safe. > 1024-bit RSA is certainly less than ideal, but certainly better than nothing, which was the claim about devices in this class. Comparisons with symmetric cry

Re: [TLS] PR#625: Change alert requirements

2016-09-08 Thread Salz, Rich
I think an introductory section on "normal and exceptional flow of control" or such would help. It could also define consistent terminology to be used in the rest of the document. To take a stab at it: Close -- means cleanly close the connection at some point after the necessary alerts

Re: [TLS] [Cfrg] 3DES diediedie

2016-09-08 Thread Kyle Rose
On Thu, Sep 8, 2016 at 1:53 AM, Peter Gutmann wrote: > The only data point I have is that every time I've tried to disable DES in > a new release (and by DES I mean single DES, not 3DES) I've had a chorus of > complaints about it vanishing. ... > Alarms, for example, send data > quantities mea

[TLS] Version negotiation, take two

2016-09-08 Thread David Benjamin
Hi folks, I’d like to revisit the question of version negotiation. EKR wrote up some text for moving version negotiation to an extension: https://github.com/tlswg/tls13-spec/pull/632 I would like us to adopt this proposal. In Berlin, this really got framed as a pragmatic question: the current v

Re: [TLS] [Cfrg] 3DES diediedie

2016-09-08 Thread Derek Atkins
Peter Gutmann writes: > Richard Hartmann writes: > >>Is it correct when I say that the embedded programmers you talked to don't >>care about any form of DES as they need/must/prefer to do AES, anyway? > > The only data point I have is that every time I've tried to disable DES in > a new release

Re: [TLS] [Cfrg] 3DES diediedie

2016-09-08 Thread Derek Atkins
Tony Arcieri writes: > On Tue, Sep 6, 2016 at 9:15 PM, Peter Gutmann > wrote: > > When crypto hardware support is available, it's universally AES, > occasionally > SHA-1 and/or DES, and very rarely RSA and/or DH and/or ECDSA  > > EMV chip cards support RSA digital signatures. Granted

Re: [TLS] Finished stuffing

2016-09-08 Thread Ilari Liusvaara
On Wed, Sep 07, 2016 at 07:43:53PM -0400, Hugo Krawczyk wrote: > On Wed, Sep 7, 2016 at 7:18 PM, Eric Rescorla wrote: > > > > > > > On Wed, Sep 7, 2016 at 4:02 PM, Hugo Krawczyk > > wrote: > > > > I also have a problem with names. "Resumption context" is very explicit > >> about providing, well,