Re: [TLS] handling of duplication of extensions between ServerHello and EncryptedExtensions

2016-09-02 Thread Hubert Kario
On Friday, 2 September 2016 12:23:03 CEST Eric Rescorla wrote: > I agree. FWIW, this is how NSS behaves. A clarifying PR would be welcome > here. that was an easy one: https://github.com/tlswg/tls13-spec/pull/622 since there's already text prohibiting that situation: The ServerHello MUST only

Re: [TLS] SHA-3 in SignatureScheme

2016-09-02 Thread Blumenthal, Uri - 0553 - MITLL
On 9/2/16, 15:22 , "TLS on behalf of Eric Rescorla" wrote: But then we have: * AES and ChaCha (two modes for the former one even) * RSA and ECDSA * NIST curves and Bernstein curves * ECDHE key exchange an DHE key exchange only the SHA-2 stands

Re: [TLS] SHA-3 in SignatureScheme

2016-09-02 Thread Salz, Rich
> But then we have: > * AES and ChaCha (two modes for the former one even) > * RSA and ECDSA > * NIST curves and Bernstein curves > * ECDHE key exchange an DHE key exchange This is a good point to bring up, but I think it can be resolved easily. AES/ChaCha -- if only mobile you'll do chacha

Re: [TLS] handling of duplication of extensions between ServerHello and EncryptedExtensions

2016-09-02 Thread Eric Rescorla
I agree. FWIW, this is how NSS behaves. A clarifying PR would be welcome here. On Fri, Sep 2, 2016 at 12:21 PM, David Benjamin wrote: > Huh. I agree that text is weird. We should probably remove it. I think we > actually get something akin to what you suggest basically

Re: [TLS] SHA-3 in SignatureScheme

2016-09-02 Thread Eric Rescorla
On Fri, Sep 2, 2016 at 12:21 PM, Hubert Kario wrote: > On Friday, 2 September 2016 21:38:33 CEST Yoav Nir wrote: > > > On 2 Sep 2016, at 8:27 PM, Hubert Kario wrote: > > > > > > On Friday, 2 September 2016 12:06:55 CEST Benjamin Kaduk wrote: > > >> On

Re: [TLS] handling of duplication of extensions between ServerHello and EncryptedExtensions

2016-09-02 Thread David Benjamin
Huh. I agree that text is weird. We should probably remove it. I think we actually get something akin to what you suggest basically implicitly: Servers aren't allowed to send unsolicited extensions, so your SH and EE parsers should be rejecting any unknown extensions. If you combine that with not

Re: [TLS] SHA-3 in SignatureScheme

2016-09-02 Thread Hubert Kario
On Friday, 2 September 2016 21:38:33 CEST Yoav Nir wrote: > > On 2 Sep 2016, at 8:27 PM, Hubert Kario wrote: > > > > On Friday, 2 September 2016 12:06:55 CEST Benjamin Kaduk wrote: > >> On 09/02/2016 12:04 PM, Eric Rescorla wrote: > >>> On Fri, Sep 2, 2016 at 8:25 AM, Dave

Re: [TLS] SHA-3 in SignatureScheme

2016-09-02 Thread Benjamin Kaduk
On 09/02/2016 12:27 PM, Hubert Kario wrote: > > what would be the reasons not to add it now? > It seems that Yoav was faster than me, but the two main ones I had in mind were: We want the core protocol to be as small as possible while still fulfilling its goals. We already have extension

[TLS] Specify handling of errors by peers

2016-09-02 Thread Hubert Kario
While the specification already details a lot of situations that "MUST NOT" happen or that are errors, it doesn't specify how those situations should be handled by peers. Add information that they need to cause the receiving side to send a fatal alert with appropriate description. Most of the

Re: [TLS] SHA-3 in SignatureScheme

2016-09-02 Thread Salz, Rich
We should not add new "this is [cool|national-standard|strong|emerging]" crypto mechanisms to this spec. Any invention we do here, should be around the protocol, not the crypto. /r$ ___ TLS mailing list TLS@ietf.org

Re: [TLS] SHA-3 in SignatureScheme

2016-09-02 Thread Eric Rescorla
On Fri, Sep 2, 2016 at 11:38 AM, Yoav Nir wrote: > > > On 2 Sep 2016, at 8:27 PM, Hubert Kario wrote: > > > > On Friday, 2 September 2016 12:06:55 CEST Benjamin Kaduk wrote: > >> On 09/02/2016 12:04 PM, Eric Rescorla wrote: > >>> On Fri, Sep 2, 2016 at

Re: [TLS] Keeping TLS extension points working

2016-09-02 Thread David Benjamin
I've finally gotten to uploading https://tools.ietf.org/html/draft-davidben-tls-grease-01 which hopefully resolves the procedural issues (thanks again!). I've also revised the text slightly after some off-list feedback about the risks of non-deterministic failures. I didn't add text about what

[TLS] Add warning about RSA-CRT key leaks

2016-09-02 Thread Hubert Kario
https://github.com/tlswg/tls13-spec/pull/619 implementations should verify signatures after making them to protect against private key leaks -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno,

Re: [TLS] SHA-3 in SignatureScheme

2016-09-02 Thread Yoav Nir
> On 2 Sep 2016, at 8:27 PM, Hubert Kario wrote: > > On Friday, 2 September 2016 12:06:55 CEST Benjamin Kaduk wrote: >> On 09/02/2016 12:04 PM, Eric Rescorla wrote: >>> On Fri, Sep 2, 2016 at 8:25 AM, Dave Garrett >> >>>

[TLS] handling of duplication of extensions between ServerHello and EncryptedExtensions

2016-09-02 Thread Hubert Kario
So, the draft has following text: The same extension types MUST NOT appear in both the ServerHello and EncryptedExtensions. If the same extension appears in both locations, the client MUST rely only on the value in the EncryptedExtensions block. if the extension "MUST NOT" be

Re: [TLS] SHA-3 in SignatureScheme

2016-09-02 Thread Hubert Kario
On Friday, 2 September 2016 12:06:55 CEST Benjamin Kaduk wrote: > On 09/02/2016 12:04 PM, Eric Rescorla wrote: > > On Fri, Sep 2, 2016 at 8:25 AM, Dave Garrett > > > > wrote: > > On Friday, September 02, 2016 07:32:06 am Eric Rescorla

Re: [TLS] SHA-3 in SignatureScheme

2016-09-02 Thread Benjamin Kaduk
On 09/02/2016 12:04 PM, Eric Rescorla wrote: > > > On Fri, Sep 2, 2016 at 8:25 AM, Dave Garrett > wrote: > > On Friday, September 02, 2016 07:32:06 am Eric Rescorla wrote: > > On Fri, Sep 2, 2016 at 3:42 AM, Ilari Liusvaara >

Re: [TLS] SHA-3 in SignatureScheme

2016-09-02 Thread Eric Rescorla
On Fri, Sep 2, 2016 at 10:04 AM, Eric Rescorla wrote: > > > On Fri, Sep 2, 2016 at 8:25 AM, Dave Garrett > wrote: > >> On Friday, September 02, 2016 07:32:06 am Eric Rescorla wrote: >> > On Fri, Sep 2, 2016 at 3:42 AM, Ilari Liusvaara < >>

Re: [TLS] SHA-3 in SignatureScheme

2016-09-02 Thread Eric Rescorla
On Fri, Sep 2, 2016 at 8:25 AM, Dave Garrett wrote: > On Friday, September 02, 2016 07:32:06 am Eric Rescorla wrote: > > On Fri, Sep 2, 2016 at 3:42 AM, Ilari Liusvaara < > ilariliusva...@welho.com> wrote: > > > I also don't see why this should be in TLS 1.3 spec, instead

Re: [TLS] [Cfrg] 3DES diediedie

2016-09-02 Thread Derek Atkins
"Steven M. Bellovin" writes: > On 31 Aug 2016, at 10:17, Derek Atkins wrote: > >> "Steven M. Bellovin" writes: >> >>> Yes. To a large extent, the "IoT devices are too puny for real >>> crypto" is a hangover from several years ago. It was once true;

Re: [TLS] SHA-3 in SignatureScheme

2016-09-02 Thread Dave Garrett
On Friday, September 02, 2016 07:32:06 am Eric Rescorla wrote: > On Fri, Sep 2, 2016 at 3:42 AM, Ilari Liusvaara > wrote: > > I also don't see why this should be in TLS 1.3 spec, instead of being > > its own spec (I looked up how much process BS it would be to get the >

Re: [TLS] SHA-3 in SignatureScheme

2016-09-02 Thread Blumenthal, Uri - 0553 - MITLL
Speaking of PRF hash, I want to bring up the fact that‎ SHA-3 is a better PRF by design, as that was one of the explicitly stated competition requirements (unlike MD*, SHA-1, and SHA-2). Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.   Original Message   From:

Re: [TLS] SHA-3 in SignatureScheme

2016-09-02 Thread Eric Rescorla
On Fri, Sep 2, 2016 at 3:42 AM, Ilari Liusvaara wrote: > On Fri, Sep 02, 2016 at 12:08:47PM +0200, Hubert Kario wrote: > > On Thursday, 1 September 2016 19:22:18 CEST Dave Garrett wrote: > > > > > > The reason I see is that we currently specify exactly one valid hash >

Re: [TLS] SHA-3 in SignatureScheme

2016-09-02 Thread Hubert Kario
On Friday, 2 September 2016 13:42:40 CEST Ilari Liusvaara wrote: > On Fri, Sep 02, 2016 at 12:08:47PM +0200, Hubert Kario wrote: > > On Thursday, 1 September 2016 19:22:18 CEST Dave Garrett wrote: > > > The reason I see is that we currently specify exactly one valid hash > > > algorithm (in a

Re: [TLS] SHA-3 in SignatureScheme

2016-09-02 Thread Ilari Liusvaara
On Fri, Sep 02, 2016 at 12:08:47PM +0200, Hubert Kario wrote: > On Thursday, 1 September 2016 19:22:18 CEST Dave Garrett wrote: > > > > The reason I see is that we currently specify exactly one valid hash > > algorithm (in a variety of sizes). The precedent argument is good enough > > for me. I

Re: [TLS] KeyUpdate and unbounded write obligations

2016-09-02 Thread Keith Winstein
You seem to be raising a complaint with my option #1, the "1-bit" option. You're correct -- in that scheme, a node can only assume that the other side has read as many KeyUpdates as it has gotten in response. If the client decides to send KeyUpdates every 5 minutes, but the other side is only

Re: [TLS] KeyUpdate and unbounded write obligations

2016-09-02 Thread Ilari Liusvaara
On Thu, Sep 01, 2016 at 02:11:13PM -0700, Keith Winstein wrote: > I think we have to oppose a change to KeyUpdate that adds P4 (bounded > write obligations) but not P3 (ability to learn that a KeyUpdate was > read by other side). These are orthogonal and easily achievable with a > pretty small

Re: [TLS] KeyUpdate and unbounded write obligations

2016-09-02 Thread Ilari Liusvaara
On Thu, Sep 01, 2016 at 02:32:41PM -0700, Eric Rescorla wrote: > On Thu, Sep 1, 2016 at 2:29 PM, Ilari Liusvaara > wrote: > > > On Thu, Sep 01, 2016 at 02:20:02PM -0700, Eric Rescorla wrote: > > > On Thu, Sep 1, 2016 at 2:09 PM, Ilari Liusvaara < > >