From: Mike Bishop <Michael.Bishop@microsoft.com>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: HTTP, Certificates, and TLS
Thread-Index: AdHjLHxhCRnLx2FySaWyrgvomVV7sw==
Date: Thu, 21 Jul 2016 09:38:59 +0000
Message-ID: <BLUPR03MB1330AB57841AE0A68F460A9987090@BLUPR03MB1330.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: microsoft.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
 boundary="_000_BLUPR03MB1330AB57841AE0A68F460A9987090BLUPR03MB1330namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2016 09:38:59.0559 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1332
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ayQ6yjTD5SbWmn0Pjat5fseVgQA>
Subject: [TLS] HTTP, Certificates, and TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 21 Jul 2016 09:39:07 -0000

--_000_BLUPR03MB1330AB57841AE0A68F460A9987090BLUPR03MB1330namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi, folks -

Martin and I had come previously to the TLS WG to discuss our work with han=
dling client certificates at the HTTP layer.  Based on that discussion, we =
revised our model to cover signatures of an exporter value and carry the pr=
oof in an HTTP/2 frame.  During BA, the HTTP WG expressed interest in flipp=
ing the model in the opposite direction - carrying additional server identi=
ties as well.  That means we now have a proposal for carrying both client a=
nd server certificates above TLS, found at https://tools.ietf.org/html/draf=
t-bishop-httpbis-http2-additional-certs.

We have also discussed that it might be preferable to pull part of this cap=
ability back into TLS, expanding post-handshake authentication to allow pro=
viding multiple certificates in either direction.  Since that would necessa=
rily require additional work on that part of the TLS 1.3 spec, we discussed=
 the possibility of splitting post-handshake authentication into a separate=
 spec so that the core TLS 1.3 spec could proceed to WGLC as scheduled and =
take a little longer on the second draft.

Having spoken to some other TLS WG members, some people would prefer to mov=
e post-handshake authentication entirely to our layer.  While that's probab=
ly not feasible (HTTP/1.1 still needs post-handshake auth from TLS, regardl=
ess of what HTTP/2 does), we can retain our application-layer authenticatio=
n.  This has the advantage of leaving TLS 1.3 unchanged, but keeps a securi=
ty draft in a non-security working group.  We are concerned that, by doing =
this at the HTTP layer, we'll be missing necessary security expert review a=
s this moves forward.  (EKR already suggested some necessary improvements t=
o our signature model to prevent some pretty trivial attacks; these aren't =
reflected in the current draft.)  If that's the route we go, I would greatl=
y appreciate some TLS folks visiting the HTTP WG and helping us review this=
 draft.

I was on the "time permitting" list to present in the TLS meeting on Tuesda=
y, and we didn't get a chance to.  We'll be discussing the actual draft tom=
orrow morning in HTTP; I'd be happy to have some TLS folks there to discuss=
 the draft, and I'd like to get a sense from the TLS WG whether there's a p=
reference for us to do this at the application layer or pass additional req=
uirements to post-handshake auth.

Thanks!
-Mike Bishop

--_000_BLUPR03MB1330AB57841AE0A68F460A9987090BLUPR03MB1330namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:#0563C1;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:#954F72;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"WordSection1">
<p class=3D"MsoNormal">Hi, folks &#8211;<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Martin and I had come previously to the TLS WG to di=
scuss our work with handling client certificates at the HTTP layer. &nbsp;B=
ased on that discussion, we revised our model to cover signatures of an exp=
orter value and carry the proof in an HTTP/2
 frame.&nbsp; During BA, the HTTP WG expressed interest in flipping the mod=
el in the opposite direction &#8211; carrying additional server identities =
as well.&nbsp; That means we now have a proposal for carrying both client a=
nd server certificates above TLS, found at https://tools.ietf.org/html/draf=
t-bishop-httpbis-http2-additional-certs.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">We have also discussed that it might be preferable t=
o pull part of this capability back into TLS, expanding post-handshake auth=
entication to allow providing multiple certificates in either direction.&nb=
sp; Since that would necessarily require
 additional work on that part of the TLS 1.3 spec, we discussed the possibi=
lity of splitting post-handshake authentication into a separate spec so tha=
t the core TLS 1.3 spec could proceed to WGLC as scheduled and take a littl=
e longer on the second draft.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Having spoken to some other TLS WG members, some peo=
ple would prefer to move post-handshake authentication
<i>entirely</i> to our layer.&nbsp; While that&#8217;s probably not feasibl=
e (HTTP/1.1 still needs post-handshake auth from TLS, regardless of what HT=
TP/2 does), we can retain our application-layer authentication.&nbsp; This =
has the advantage of leaving TLS 1.3 unchanged,
 but keeps a security draft in a non-security working group.&nbsp; We are c=
oncerned that, by doing this at the HTTP layer, we&#8217;ll be missing nece=
ssary security expert review as this moves forward.&nbsp; (EKR already sugg=
ested some necessary improvements to our signature
 model to prevent some pretty trivial attacks; these aren&#8217;t reflected=
 in the current draft.)&nbsp; If that&#8217;s the route we go, I would grea=
tly appreciate some TLS folks visiting the HTTP WG and helping us review th=
is draft.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">I was on the &#8220;time permitting&#8221; list to p=
resent in the TLS meeting on Tuesday, and we didn&#8217;t get a chance to.&=
nbsp; We&#8217;ll be discussing the actual draft tomorrow morning in HTTP; =
I&#8217;d be happy to have some TLS folks there to discuss the draft,
 and I&#8217;d like to get a sense from the TLS WG whether there&#8217;s a =
preference for us to do this at the application layer or pass additional re=
quirements to post-handshake auth.<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<p class=3D"MsoNormal">Thanks!<o:p></o:p></p>
<p class=3D"MsoNormal">-Mike Bishop<o:p></o:p></p>
</div>
</body>
</html>

--_000_BLUPR03MB1330AB57841AE0A68F460A9987090BLUPR03MB1330namp_--