Re: [TLS] '15 TLS Fall Interim Minutes

Eric Rescorla <ekr@rtfm.com> Wed, 23 September 2015 15:51 UTC

Return-Path: <ekr@rtfm.com>
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 9C6841A86FA for <tls@ietfa.amsl.com>; Wed, 23 Sep 2015 08:51:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 0sXzN-ij1wXd for <tls@ietfa.amsl.com>; Wed, 23 Sep 2015 08:51:04 -0700 (PDT)
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B130B1A86F6 for <tls@ietf.org>; Wed, 23 Sep 2015 08:50:57 -0700 (PDT)
Received: by wicgb1 with SMTP id gb1so212039777wic.1 for <tls@ietf.org>; Wed, 23 Sep 2015 08:50:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=G7PnS4oaO0M1m0SYYHcD0718GSC+nhYey/J6PIjgwqo=; b=P1ehySfEfHZ94hoY46tw2TO9YsEBkHKMGPUawbZ3C7wDyqEAJTFSEiNbkZkoxFKqD9 TYQF+9o3cVKyLPGonuh8ynssAMzd8ut12lVmtHTLEojznOmMoUby4EInHUlrDNj8ypf5 qyMvd/B2cBZrALBYEBPglcmNWksrYDtjXCNU1tiFGdl2v3RpgFBUgteXE48k8/xq+clZ QhDm/v9o5CRq/IVMrp6KT3l9/XiaP4oIHROFtpDAREdi++kREaPV628rVzUYJ0WgPgiM GuwbPymegU0ABPRQgHV6THj9lYh4LRw/YgV7amR62jaYNtruh7JA7OMp3W+aBv5y37p4 os7A==
X-Gm-Message-State: ALoCoQmz4Xg02WSBevEAeI41zaQX7NBZuqiKBoYGYw9Pp50Ycx/wMycyOPx6kr1+vnpFuqiva7nO
X-Received: by 10.180.88.4 with SMTP id bc4mr5189743wib.68.1443023456184; Wed, 23 Sep 2015 08:50:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.79.200 with HTTP; Wed, 23 Sep 2015 08:50:16 -0700 (PDT)
In-Reply-To: <20150923105439.GA24394@LK-Perkele-VII>
References: <A1F63168-7736-452D-BC1B-23B665D81989@sn3rd.com> <20150923105439.GA24394@LK-Perkele-VII>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 23 Sep 2015 08:50:16 -0700
Message-ID: <CABcZeBOad9GDC5jQf9D5OqWyUNWi1=YdLdoCwRMayrEFOMVd0Q@mail.gmail.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Content-Type: multipart/alternative; boundary=f46d04428ee48252ea05206c146a
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/4s_AWTfMPnCufBHF6kxl_bFHljw>
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 15:51:06 -0000

On Wed, Sep 23, 2015 at 3:54 AM, Ilari Liusvaara <
ilari.liusvaara@elisanet.fi> wrote:

> On Tue, Sep 22, 2015 at 04:27:35PM -0700, Sean Turner wrote:
> > I’ve gone ahead and posted the minutes/list of decisions to:
> >
> >
> https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-interim-2015-tls-3
>
> Minutes:
>
> > ## Issue 223 - absolute or relative time
> >
> > Leave as-is because a) switching to relative time is painful and it's
> > not standalone, b) it's not entirely clear what > benefit we get from
> > this, and c) we're already using absolute time for other things like
> > certificates & OCSP.
>
> One thing to note: The time is 4 octets, and 32 bit time since unix
> epoch runs out a good bit faster than what I would like.
>

I will fix this.



> > ## Client Authentication
> >
> > We agreed that we need to support this in TLS 1.3.
> >
> > ### How
> >
> > 2. We will modify the data that's signed to conform with what Andrei
> > is proposing provided we also terminate the transcript for key
> > derivation before the CC/CCV.
>
> Oh yay, Server 0-RTT?
>

Yes, the server can send immediately after receiving the first flight.


> 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.




> > 5. We agreed to take out the ClientCertificatType from
> CertificateRequest.
>
> Yeah, that one is not needed for anything.
>
> > 6. We want a consolidated certificate message and certificate verify.
>
> Just be careful that certificate is still signed, as many signature
> algorithms fail to even properly bind the key, and nothing binds the
> certificate.
>

Yes, there was consensus to include the certificate.



> # 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.



> > # 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?

Thanks,
-Ekr



>
>
> -Ilari
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>