Re: [TLS] AUTH48 [AR]: RFC 7250 <draft-ietf-tls-oob-pubkey-11.txt> changes

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Fri, 13 June 2014 23:49 UTC

Return-Path: <jsalowey@cisco.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 BF5A91B2AA4 for <tls@ietfa.amsl.com>; Fri, 13 Jun 2014 16:49:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level:
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 zEDbQeQ2JCwh for <tls@ietfa.amsl.com>; Fri, 13 Jun 2014 16:49:52 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2ADF1B2AA3 for <tls@ietf.org>; Fri, 13 Jun 2014 16:49:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2604; q=dns/txt; s=iport; t=1402703392; x=1403912992; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=6W8HC2vdWrJ7z8bPtJgXktfaVDuk1dw0OpzgBs7z5CQ=; b=leXZR8Ia9cNI6cBaAlVpmZqB6byxTc9DDvBSnw46nJU8D7qAAlOYkkG6 Z7w0bkFb6QK8zdhZjqXuF5TEJqnZ8q10+zWQ1jRYJyl8YZ8se7Oz6cK0Y CXq6q/iifVh2sM5wMTWnWGG0S48CnacET72KSrUZiNhKWBU7EgPwUckEG c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Aj8FAISNm1OtJA2E/2dsb2JhbABRCYMNUlmpYgEBAQEBB5Flhz0BgQUWdYQDAQEBAwEBAQE3NBALAgEIGB4QJwslAgQTiDoIDc9oEwSFXYVkgkMoOoMrgRYEmjeTV4M+gjA
X-IronPort-AV: E=Sophos;i="5.01,474,1400025600"; d="scan'208";a="333048391"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP; 13 Jun 2014 23:49:51 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s5DNnoYv003774 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <tls@ietf.org>; Fri, 13 Jun 2014 23:49:50 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.225]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Fri, 13 Jun 2014 18:49:50 -0500
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] AUTH48 [AR]: RFC 7250 <draft-ietf-tls-oob-pubkey-11.txt> changes
Thread-Index: AQHPedB3r/5JHL+RFEieWpJdLbQeBg==
Date: Fri, 13 Jun 2014 23:49:50 +0000
Message-ID: <8686EA69-5E48-413C-9AC6-3BE2AFB2379D@cisco.com>
References: <201405201629.s4KGTtoU021704@new.toad.com> <790AE3A2-37B2-4124-8093-69812232052C@cisco.com> <20140527181017.GN27883@mournblade.imrryr.org>
In-Reply-To: <20140527181017.GN27883@mournblade.imrryr.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.33.248.112]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8991A499C81D7E4B9ABD12F03945BE7B@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_QPK_fzE3lFlLtQC62CPFbkO1ss
Subject: Re: [TLS] AUTH48 [AR]: RFC 7250 <draft-ietf-tls-oob-pubkey-11.txt> changes
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: <http://www.ietf.org/mail-archive/web/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: Fri, 13 Jun 2014 23:49:53 -0000

On May 27, 2014, at 11:10 AM, Viktor Dukhovni <viktor1dane@dukhovni.org> wrote:

> On Tue, May 27, 2014 at 05:24:09PM +0000, Joseph Salowey (jsalowey) wrote:
> 
>>> Section 4.3:
>>> 
>>> OLD:
>>>  Authentication of the TLS client to the TLS server is supported only
>>>  through authentication of the received client SubjectPublicKeyInfo
>>>  via an out-of-band method.
>>> 
>>> NEW:
>>> 
>>>  When the TLS server has specified RawPublicKey as the
>>>  client_certificate_type, authentication of the TLS client to the
>>>  TLS server is supported only through authentication of the received
>>>  client SubjectPublicKeyInfo via an out-of-band method.
>>> 
>>> [...]
>>> 
>>> Add Section 4.4.  Server Authentication
>>> 
>>> NEW:
>>>  When the TLS server has specified RawPublicKey as the
>>>  server_certificate_type, authentication of the TLS server to the
>>>  TLS client is supported only through authentication of the received
>>>  client SubjectPublicKeyInfo via an out-of-band method.
> 
> Some (as I did briefly, though I think I have finally figured out
> what is meant) might find "authentication" here a bit confusing.
> 
> There are two parts to the traditional use of a public key in TLS for
> authentication:
> 
>    * The public key is used to sign the key exchange or decrypt
>      key transport.  This proves that the counter-party possesses
>      the corresponding private key.
> 
>    * The public key is delivered in the form of a certificate that
>      attests to a binding between the public key and some identity.
> 
> When I first read the quoted text out of context, I though it was
> saying that both parts were out of band, which is surely not the
> case.  Rather it is merely the identity mapping that is out of
> band, each side still verifies possession via appropriate signatures.
> 

[Joe] This is the correct interpretation.  

> Is the use of raw public keys to sign the relevant bits of the
> handshake that would otherwise have been signed by the public key
> embedded in the certificate too obvious to have to state explicitly?
> 

[Joe] I think so, this is core to TLS operation.  I'm not confident that I can come up with text that would be less confusing.   Do you have any suggested modifications?  I think we will probably leave the text as is, but I can pass on a suggestion if you have one.  

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