Re: [TLS] '15 TLS Fall Interim Minutes

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Wed, 23 September 2015 16:40 UTC

Return-Path: <ilari.liusvaara@elisanet.fi>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111FE1A6FB2 for <tls@ietfa.amsl.com>; Wed, 23 Sep 2015 09:40:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RBlaQpc5yXl for <tls@ietfa.amsl.com>; Wed, 23 Sep 2015 09:40:56 -0700 (PDT)
Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B3001A3BA2 for <tls@ietf.org>; Wed, 23 Sep 2015 09:40:54 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id 825EA900B6; Wed, 23 Sep 2015 19:40:52 +0300 (EEST)
Date: Wed, 23 Sep 2015 19:40:51 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20150923164051.GA26217@LK-Perkele-VII>
References: <A1F63168-7736-452D-BC1B-23B665D81989@sn3rd.com> <20150923105439.GA24394@LK-Perkele-VII> <CABcZeBOad9GDC5jQf9D5OqWyUNWi1=YdLdoCwRMayrEFOMVd0Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CABcZeBOad9GDC5jQf9D5OqWyUNWi1=YdLdoCwRMayrEFOMVd0Q@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/IAw8ADopCF_m4Y1Qs5iPMDNEhBQ>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] '15 TLS Fall Interim Minutes
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Sep 2015 16:40:59 -0000

On Wed, Sep 23, 2015 at 08:50:16AM -0700, Eric Rescorla wrote:
> On Wed, Sep 23, 2015 at 3:54 AM, Ilari Liusvaara <
> ilari.liusvaara@elisanet.fi> wrote:
> 
> > investigate: using the same construct for server/client sigs.
> >
> > Huh? Don't both currently use the same construct, except for the
> > context string? Are you proposing to remove the context string or
> > what?
> >
> 
> The idea on the table was to use an exported value to match Token binding.
> Input needed here.

One would then presumably also have to eject SC/SCV from ExMS
computation so the same ExMS is available for SCV? 

Also, bit of an issue here is that OCSP stapling (which is pretty much
regarded as the only sane way to actually use OCSP) is specified to
use its own message, which goes between SC and SCV (RFC6066). 

So it would at least need to be moved somewhere in order to merge SC
and SCV.

> > # Include randoms directly in digital signatures
> > >
> > > Issue 224
> > >
> > > Consensus at the interim was that this has straightforward to do by
> > > just having the authentication server supply the ServerRandom was
> > > enough since it can search through the handshake transcript.
> >
> > This assumes that authentication server receives full handshake and
> > not just handshake To-Be-Signed.
> >
> 
> There was a lot of confusion at the interim about whether the concern here
> was an auth server at the attesting party or the relying party.

Well, AFAICT if the privileges are different, on attesting party
signing code has higher privileges. On relying party, verification code
has lower privileges.

(The "lower privileges verify" can come up e.g. if performing pubkey
extraction is unacceptable risk in main TLS code. In that case, I don't
think you can do better than just trust output of that code).

But in case of higher privilege sign, I think there might be ways to
try to prevent higher privilege signing code from being abused.

> > > # PRF designation in server certificate verify
> > >
> > > Issue 227
> > >
> > > Consensus was to leave as-is. A hash identifier isn't the way to
> > > solve this.  What you really need is contributory behavior to solve
> > > this issue.
> >
> > Huh? This is about collisions between different hash algorithms. I
> > don't see how contributory behavior would help there (which is severly
> > limited by 1RTT maximum there).
> >
> > Now, the issue is probably entierely theoretical and thus would not
> > need solving.
> 
> There was confusion about this too. Could you provide a (perhaps contrived)
> example of the attack you are concerned about and a mechanism which would
> defend against it?

Suppose one has different hash functions G and H. Server signs handshake
hash G(handshake_attacker_server). Attacker manipulates the handshake so
that H(handshake_client_attacker) = G(handshake_attacker_server).

If client accepts hash function H, that results in inpersonation.

In theory, you can't prove security against this attack starting from
assumption that G and H are secure hash functions.

In practice, if G and H are even near secure and not closely related,
that attack should be infeasible.

In contrast, if Tag(F) is identifier for F, different for each hash,
then:

Tag(G)|G(x) = Tag(H)|H(y)

Impiles G=H and G(x)=G(y), which contradicts collision resistance of
G.


-Ilari