Re: [TLS] Commentary on the client authentication presentation slides

David Benjamin <davidben@chromium.org> Tue, 28 July 2015 22:30 UTC

Return-Path: <davidben@google.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 EF3EF1B32E8 for <tls@ietfa.amsl.com>; Tue, 28 Jul 2015 15:30:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 UxYpBzO3Pttj for <tls@ietfa.amsl.com>; Tue, 28 Jul 2015 15:30:24 -0700 (PDT)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 73A611B32DE for <tls@ietf.org>; Tue, 28 Jul 2015 15:30:24 -0700 (PDT)
Received: by ioii16 with SMTP id i16so2795608ioi.0 for <tls@ietf.org>; Tue, 28 Jul 2015 15:30:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=xAdgOlRdyAOGK0VbAzHzgmog5QxwoqJmrULFY7eslvw=; b=KdSy0biH10e3c1Yjdot55VBzIQ+q9m30+vfBF557f8HHxr2O3ouPaipoxrHRsSmcmH lmQfGqkv0fBuS6kP2zEpxkrvhGv9OdCTwmgKOsHdfQMHWrQuClzrV2Xzk/I6fpYpAW3M YxyCq4yIpqxq7v3oaRJawuEybCNYaOCR1wkqs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=xAdgOlRdyAOGK0VbAzHzgmog5QxwoqJmrULFY7eslvw=; b=BUA4PRb4B8k1ZVUnbIcsVG4svOXm15ymoiq6b8FteuiwJS/eKQKKuzHBxFBqKy2/jE 49PvDZ8sqQoTjb1xcgZzMRI4XriMeHRLM5JvLsFid49a373C0sontM8326dHQBdE3qwF NpaHLvc+CRpI6a+g68Diaj09ilqGxs9P/K7thXws+M1GSlSIL019DuGZGA6LZgdYKv6k yDh7ZJZAcfneOppHvCXqjy2i0XA+MTVn6BvFCkzHnuR043Mb7748HRS0xP1JETsSlFRT bGLbChN6FV4dzV42zRW1UOqvDiVAeBHFuwiAtISU3tjFRNGELhhJTpkxEjg4LnrH52xF w/Ug==
X-Gm-Message-State: ALoCoQmyqSoLpItytiGEcjWpinxsiQatKfURdS28WMkP6/DE6Cf5IVdyTIXHThCp+XG8haWIQkQP
X-Received: by 10.107.170.204 with SMTP id g73mr41086281ioj.85.1438122623885; Tue, 28 Jul 2015 15:30:23 -0700 (PDT)
MIME-Version: 1.0
References: <20150720141036.GA32204@LK-Perkele-VII> <BLUPR03MB1396E33D0B7ADBED918C54D08C810@BLUPR03MB1396.namprd03.prod.outlook.com> <CAF8qwaAAXv3Ts8JB25e5GB4Xrh8DU2Xg3UCXuDUObgGHubUFUw@mail.gmail.com>
In-Reply-To: <CAF8qwaAAXv3Ts8JB25e5GB4Xrh8DU2Xg3UCXuDUObgGHubUFUw@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Tue, 28 Jul 2015 22:30:14 +0000
Message-ID: <CAF8qwaCz=ZtdANYas+vSatJGzai6AeyiLtw7_H_qP9iXf7dV8g@mail.gmail.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>, Ilari Liusvaara <ilari.liusvaara@elisanet.fi>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=001a1142721824089a051bf70429
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/PhjnY5zGqDHMg32dNwFNh_y_8wY>
Subject: Re: [TLS] Commentary on the client authentication presentation slides
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: Tue, 28 Jul 2015 22:30:27 -0000

Sent from the right email this time. (Sorry folks who got it twice. One of
these days I'll not mess this up! :-) )

On Tue, Jul 28, 2015 at 6:28 PM David Benjamin <davidben@google.com> wrote:

> On Fri, Jul 24, 2015 at 1:02 AM Andrei Popov <Andrei.Popov@microsoft.com>
> wrote:
>
>> Thanks for the detailed comments, Ilari.
>>
>> Based on the discussion at the TLS WG meeting, I created a pull request:
>> https://github.com/tlswg/tls13-spec/pull/209
>>
>> > - Mechanism like proposed looks dangerous when combined with HTTP/2.
>> I believe the same issue already exists in HTTP/1 where multiple requests
>> can be in flight at the same time.
>> The way we handle this in HTTP/1 is by having the server application
>> query the HTTP stack for the client cred.
>> If there's no cred available, the HTTP stack triggers client
>> authentication (and the server application waits until the client cred is
>> provided so it can authorize the request).
>>
>
> The issue only exists in HTTP/1 if the client does pipelining. As far as I
> know, no current[*] major browser deploys HTTP pipelining by default.
> Chrome certainly doesn't.
>
> [*] Wikipedia says Opera used to do it before they switched to Chromium?
>
> Are you intending that this mechanism be enabled by default for HTTP/2 or
> would the prohibition against renego still apply? Without any way for the
> client to tie the CertificateRequest to the HTTP request that triggered it,
> this mechanism would have many of the same problems as renego as far as
> HTTP/2 is concerned. (I realize Microsoft has a draft floating around for a
> TLS_RENEG_PERMITTED HTTP/2 setting. The setting can control this too I
> suppose.)
>
>
>> > - Regarding last point about interleaving: Assuming the scheme works
>>   in 1RTT (and I see no reason for requiring more rounds), you can't
>>   prevent application_data transmission after certificate_request.
>> We discussed at the meeting that this restriction cannot be implemented.
>> Instead, a server may block the processing of any in-flight requests
>> while waiting for the client to authenticate (if the server's architecture
>> requires this).
>>
>
> This requires the server buffer arbitrarily many requests from the client,
> which seems poor. For renego-based mid-stream auth, I believe Apache httpd
> does not do this and will actually fail the connection on interleave. (But
> I've never tested this, just glanced at how they use OpenSSL, so I could be
> wrong.)
>
> > - The certificate_types field in CertificateRequest is pretty much
>>   useless, since all supported algorithms are of signature type.
>> If the signature_algorithms extension officially becomes MTI, then
>> perhaps we can discus getting rid of certificate_types in the
>> CertificateRequest. Except we may want to use this field when we introduce
>> new certificate types (e.g. something like IEEE1609 certs).
>>
>> > - How does extension_values work? If multiple values for one
>>   OID are allowed, then the OID/value pair is repeated, once for
>>   each value?
>> Multiple values are DER-encoded per RFC that defines the OID that allows
>> multiple values.
>> The idea here is to simply reuse the existing OID-parsing code. A TLS
>> implementation (or certificate API) that recognizes the OID in the cert,
>> already knows how to parse its representation. A TLS implementation (or
>> certificate API) that does not recognize the OID in the cert will also skip
>> this OID in the extension_values. In the degenerate case, an implementation
>> may choose to skip all extension_values.
>>
>> Cheers,
>>
>> Andrei
>>
>> -----Original Message-----
>> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Ilari Liusvaara
>> Sent: Monday, July 20, 2015 4:11 PM
>> To: tls@ietf.org
>> Subject: [TLS] Commentary on the client authentication presentation slides
>>
>> Some commentary on client authentication slides (there is no linked draft
>> nor other material yet).
>>
>> - Mechanism like proposed looks dangerous when combined with HTTP/2.
>>   Multiplexed protocols are in general not safe to authenticate without
>>   application-layer signaling (which can be implicit via separate
>>   connections), especially if dealing with something like web
>>   environment.
>> - Regarding last point about interleaving: Assuming the scheme works
>>   in 1RTT (and I see no reason for requiring more rounds), you can't
>>   prevent application_data transmission after certificate_request.
>>   The best that can be done is to require the client to send all
>>   the authentication-related data in one go.
>> - The certificate_types field in CertificateRequest is pretty much
>>   useless, since all supported algorithms are of signature type.
>> - One can't just remove fields without breaking parse compatiblity,
>>   but adding field breaks parse compatiblity too, so removing
>>   field at the same time isn't a problem.
>> - How does extension_values work? If multiple values for one
>>   OID are allowed, then the OID/value pair is repeated, once for
>>   each value?
>>
>>
>>
>> -Ilari
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>