From nobody Wed Nov 1 06:04:20 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE5A13FC99 for ; Wed, 1 Nov 2017 06:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 tBdQBcWVSVwn for ; Wed, 1 Nov 2017 06:04:13 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 BF65013F442 for ; Wed, 1 Nov 2017 06:04:12 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id q1so1754979ywh.5 for ; Wed, 01 Nov 2017 06:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JWqxGPIZLTHqiC1sngDVpQaiIRbnWy3jBF90zsJ221E=; b=sq1BU3h1iLH9qGkLUJ2gZcM4KVf3TvwHqcLiayLr/1YEFt7H/+ng25RWVVz5Sv3uMk pUuXXvoRwK5S/IcRVrnBY95/4Bzes1GNxwSW48MUv5X49WUowwbnUt+3OBZcy6XBbAhy iFm6HUijOA3LikQ1EkqY327/e6ujmxCuHSyte81Kzx9moZt6fWpFJw3j4peGUgtXTOJh DmV6t143XjTs61LZ9e0npkwpFjnN498/fRLeIGmxe0xmuyN8Nglgp5LyvqenOpsNYxtB fcT5y+Y28BxtmC41RMYh6NGuE/Y6euapOn5fuwWd4bPHB71L6rPvmSwPbWNRWzW5VXGk 6Lvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JWqxGPIZLTHqiC1sngDVpQaiIRbnWy3jBF90zsJ221E=; b=Ij3mD34wLoJMQmHU4ZDeShWYd4n3cAXO/QpW5ne19tGBfW4wjdtKl7dmirXOalnrPQ i3bSayeVIqvPJjRUsTBVQMeh7WXM0nBbApzzO/NjvdGhr5TuOHZx8T27IJhhHy+XPr7M QNcieCX5zsoCaNE67BE4OVkJNOG3KN//XYECbZH/j6dYXph138eRSfNWROV30DHBGwGF IvRQdhuMqkAOQ5CvLiRuJpMzx+OrR6Qz08s5cebtVMDZV/sM4fzaaxP4ZceOPK8Pv1n2 jQ60a5tu/u52hiHFldnhthU4thQxrro0UjEZlJq06BzMMSUjCixAauabzmoseSYthhko uTNQ== X-Gm-Message-State: AMCzsaVNZ/56tzXNlNBXVtzoBk/ZsiDjYyuB11km72g/IvX5VKmVxa8i lT8XXqbv4PqELojtQuBdwm/dpZSO1RDJxqAulduGt4kb X-Google-Smtp-Source: ABhQp+SvhSwXrB3EfmKbofjFsDL6KhGefF+kkhe7y2IWRE2DDCjePIk46PloiMfyBZHvIWR5Gm9lC4XtoJ99Xq0Uonw= X-Received: by 10.37.209.208 with SMTP id i199mr3374998ybg.339.1509541451925; Wed, 01 Nov 2017 06:04:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Wed, 1 Nov 2017 06:03:31 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 1 Nov 2017 06:03:31 -0700 Message-ID: To: Martin Thomson Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c05e1a6043398055ceb826c" Archived-At: Subject: Re: [TLS] DTLS KeyUpdate X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 13:04:14 -0000 --94eb2c05e1a6043398055ceb826c Content-Type: text/plain; charset="UTF-8" On Tue, Oct 31, 2017 at 10:45 PM, Martin Thomson wrote: > (From https://github.com/tlswg/dtls13-spec/issues/25) > > Using the TLS process for KeyUpdate - as the current draft does - > leads to a suboptimal set of choices in implementations. > > Sending KeyUpdate followed immediately by a key change means that > KeyUpdate isn't a reliable indicator of a key change at the receiver. > If the record containing the KeyUpdate is lost, then the receiver will > be unable to decrypt anything sent after it unless it looks at the > epoch and tries the new keys. It's important to be clear that this creates head-of-line blocking, not deadlock. The sender will retransmit the KeyUpdate eventually. And (though it's not in the document), the sender could also retransmit the packet itself. Given the comparative rarity of KeyUpdates, I don't actually think either of these is disastrous. I would prefer a different design, even if it diverges from the TLS design. > > 1. That could be the same design as QUIC uses, with the epoch bit > signaling intent. The cost there is that you need to use the bit as an > acknowledgment of a key update, so you end up having to keep key > updates in lock step, even if no update is needed. If there are > asymmetric sending patterns, this isn't ideal. > Yeah, I don't think this is a good design in QUIC and I wouldn't be in favor of it here. We've gone to some trouble to have explicit updates in DTLS and this is far cleaner than the situation in QUIC, and I'm not eager to make a change in the opposite direction. > 2. Wait until the KeyUpdate is acknowledged before installing new > keys. When KeyUpdate is received, the receiver installs new keys, but > retains old keys on a timer (the holddown timer would do). This is already required by the spec and would be needed in any case. > The sender > waits for the ACK and starts using new keys when it sees it. The cost > here is that switching keys can't be immediate True, but that logic only happens at the sender. > and it requires hooks > into the ACK handling logic, neither of which is ideal > As above, I'm not persuaded that this change is necessary, given that DTLS is inherently a lossy protocol, and that receivers *can* be clever, but if the resolution is that it is, then I think this is the right approach. -Ekr > I have implemented the former and it's a little ugly, but I haven't > tried the latter. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c05e1a6043398055ceb826c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Tue, Oct 31, 2017 at 10:45 PM, Martin Thomson <martin.thomson@gm= ail.com> wrote:
(From https://github.com/tlswg/dtls13-spec/issues/25)
Using the TLS process for KeyUpdate - as the current draft does -
leads to a suboptimal set of choices in implementations.

Sending KeyUpdate followed immediately by a key change means that
KeyUpdate isn't a reliable indicator of a key change at the receiver. If the record containing the KeyUpdate is lost, then the receiver will
be unable to decrypt anything sent after it unless it looks at the
epoch and tries the new keys.

It's imp= ortant to be clear that this creates head-of-line blocking, not
d= eadlock. The sender will retransmit the KeyUpdate eventually. And
(though it's not in the document), the sender could also retransmit
the packet itself. Given the comparative rarity of KeyUpdates, I
don't actually think either of these is disastrous.
<= br>

I would prefer a different design, even if it diverges from the TLS design.=

1. That could be the same design as QUIC uses, with the epoch bit
signaling intent. The cost there is that you need to use the bit as an
acknowledgment of a key update, so you end up having to keep key
updates in lock step, even if no update is needed. If there are
asymmetric sending patterns, this isn't ideal.
Yeah, I don't think this is a good design in QUIC and I wou= ldn't be in
favor of it here. We've gone to some trouble = to have explicit updates
in DTLS and this is far cleaner than the= situation in QUIC, and I'm
not eager to make a change in the= opposite direction.


2. Wait until the KeyUpdate is acknowledged before installing new
keys. When KeyUpdate is received, the receiver installs new keys, but
retains old keys on a timer (the holddown timer would do).

This is already required by the spec and would be needed in= any case.
=C2=A0
The sender=
waits for the ACK and starts using new keys when it sees it. The cost
here is that switching keys can't be immediate

True, but that logic only happens at the sender.

=C2=A0
and it requires hook= s
into the ACK handling logic, neither of which is ideal

As above, I'm not persuaded that this change is necessa= ry, given that
DTLS is inherently a lossy protocol, and that rece= ivers *can* be clever,
but if the resolution is that it is, then = I think this is the right approach.

-Ekr

=C2=A0
I have implemented the former and it's a little ugly, but I haven't=
tried the latter.

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

--94eb2c05e1a6043398055ceb826c-- From nobody Wed Nov 1 07:18:36 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B9E13FBAE for ; Wed, 1 Nov 2017 07:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 EDNHuh01imAA for ; Wed, 1 Nov 2017 07:18:34 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D44FA13FAF6 for ; Wed, 1 Nov 2017 07:18:33 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id vA1EIV13015265 for ; Wed, 1 Nov 2017 14:18:31 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=wqVrpP9UX0EDeqNhadWuuJF/JLv96s5RHoRM7ZoBi1w=; b=JU5M0eMAMEP+9Dy1IAqMMoUV63kZYp/mfWATPWDlfFYN7eeyCIwP3UB2xkhIbZumea6n kset3P6AFVcscj4MiAzeEOEy5IOv2D0lHrrESwQ+mLSsYZfZs+4y8E9hOjJwGQOT2kgw sgM6SwXE0S9ok02byJgWwbU1ncL2V0RgoS40CPwv+SXiPUVGiuEKjTUpYeIVe4Chq8DS qiANS2IxE3ocCCvujPX1+4szs+yAyS2Nx5m4UHtm1QjgTUJ4H0DB9uSva9DUPz66oviw OD1vAFe0DJwtUqk1pc8mr77kVwtKcnxoQjczPkyB1FPBOwkJ7cpFad2pJuvlsWRce2zY fw== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050102.ppops.net-00190b01. with ESMTP id 2dvmqnxxtd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 01 Nov 2017 14:18:30 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vA1EBKWi020841 for ; Wed, 1 Nov 2017 10:18:25 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint3.akamai.com with ESMTP id 2dvn7w65t2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 01 Nov 2017 10:18:25 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 1 Nov 2017 10:18:23 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 1 Nov 2017 10:18:23 -0400 From: "Salz, Rich" To: "tls@ietf.org" Thread-Topic: Draft RHRD Thread-Index: AQHTUxxGq1PtJ6qqTE65Tfal4qdsDA== Date: Wed, 1 Nov 2017 14:18:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.44] Content-Type: multipart/alternative; boundary="_000_C2DD79920A5A49708DDBDBA651B4D6D7akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-01_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711010198 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-01_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 lowpriorityscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711010198 Archived-At: Subject: [TLS] Draft RHRD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 14:18:35 -0000 --_000_C2DD79920A5A49708DDBDBA651B4D6D7akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi90bHMvY3VycmVudC9tc2cy NDc4OS5odG1sLCBOaWNrIFN1bGxpdmFuIGNvbmNsdWRlZDoNCg0KPi0gb24gdGhlIG90aGVyIGhh bmQgdXNpbmcgZHJhZnQtcmhyZCBpcyBzYWZlciB0aGFuIGFsbG93aW5nIG9yZ2FuaXphdGlvbnMg dG8gaGFjayBzaW5nbGUta2V5IGVzY3JvdyBpbnRvIFRMUyAxLjMgb3IgY29udGludWUgdG8gdXNl IFRMUyAxLjIgd2l0aCBub24tZm9yd2FyZC1zZWNyZXQgY2lwaGVyIHN1aXRlcw0KDQpJIHRoaW5r IHRoaXMgc2V0cyB1cCBhIGZhbHNlIGNvbXBhcmlzb24uICBFeGlzdGluZyBUTFMgMS4zIGRlYnVn Z2luZyBzeXN0ZW1zIOKAkyBXaXJlc2hhcmsg4oCTIGNhbiBkZWJ1ZyBpbmRpdmlkdWFsIFRMUyBz ZXNzaW9ucyB3aXRoIHRoZSBzZXNzaW9uIGtleSBpbmZvcm1hdGlvbiBiZWluZyBtYWRlIGF2YWls YWJsZS4gIFRoaXMgaXMgd2hhdCB0aGUgUkhSRCBkcmFmdCB3b3VsZCByZXF1aXJlIGFuIG9yZ2Fu aXphdGlvbiB0byBkbywgYnV0IGl0IGFkZHMgdGhlIGFkZGl0aW9uYWwgc2lnbmFsaW5nIHRoYXQg dGhlIGNsaWVudCBpcyB3aWxsaW5nIHRvIGFsbG93IGl0LiBUaGUgV2lyZXNoYXJrIGV4YW1wbGUg c2hvd3MgdGhhdCB0aGUgc2lnbmFsaW5nIGlzIG5vdCBuZWVkZWQuICBTZXJ2ZXJzIGNhbiB1bmls YXRlcmFsbHkgZG8gaXQgbm93Lg0KDQpJIG1haW50YWluIHRoYXQgdGhlIGNsZWFydGV4dCBzaWdu YWwgc2VydmVycyBubyB1c2VmdWwgcHVycG9zZSwgZXhjZXB0IHRvIHByb3ZpZGUgYSBtZWNoYW5p c20gZm9yIGVudGl0aWVzIHRvIHNlZ3JlZ2F0ZSB0cmFmZmljLg0KDQo= --_000_C2DD79920A5A49708DDBDBA651B4D6D7akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <4BCF9406CF3CDB4A9487B710122F0CDA@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3Jh cGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHls ZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1h cmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9z ZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHls ZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxp c3QgbDANCgl7bXNvLWxpc3QtaWQ6MTA0ODg0NTM4MTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTk2NTE3ODIwOCA3MzgzNzQ3MDggNjc2OTg2OTEgNjc2 OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2 OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Ijt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciLHNlcmlmO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIs c2VyaWY7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBs MDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVT IiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PkluIDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvdGxzL2N1 cnJlbnQvbXNnMjQ3ODkuaHRtbCI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL3Rscy9jdXJyZW50L21zZzI0Nzg5Lmh0bWw8L2E+LCBOaWNrIFN1bGxpdmFuIGNvbmNsdWRl ZDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZndDstIG9uIHRo ZSBvdGhlciBoYW5kIHVzaW5nIGRyYWZ0LXJocmQgaXMgc2FmZXIgdGhhbiBhbGxvd2luZyBvcmdh bml6YXRpb25zIHRvIGhhY2sgc2luZ2xlLWtleSBlc2Nyb3cgaW50byBUTFMgMS4zIG9yIGNvbnRp bnVlIHRvIHVzZSBUTFMgMS4yIHdpdGggbm9uLWZvcndhcmQtc2VjcmV0IGNpcGhlciBzdWl0ZXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkgdGhpbmsgdGhpcyBz ZXRzIHVwIGEgZmFsc2UgY29tcGFyaXNvbi4mbmJzcDsgRXhpc3RpbmcgVExTIDEuMyBkZWJ1Z2dp bmcgc3lzdGVtcyDigJMgV2lyZXNoYXJrIOKAkyBjYW4gZGVidWcgaW5kaXZpZHVhbCBUTFMgc2Vz c2lvbnMgd2l0aCB0aGUgc2Vzc2lvbiBrZXkgaW5mb3JtYXRpb24gYmVpbmcgbWFkZSBhdmFpbGFi bGUuJm5ic3A7IFRoaXMgaXMgd2hhdCB0aGUgUkhSRCBkcmFmdA0KIHdvdWxkIHJlcXVpcmUgYW4g b3JnYW5pemF0aW9uIHRvIGRvLCBidXQgaXQgYWRkcyB0aGUgYWRkaXRpb25hbCBzaWduYWxpbmcg dGhhdCB0aGUgY2xpZW50IGlzIHdpbGxpbmcgdG8gYWxsb3cgaXQuIFRoZSBXaXJlc2hhcmsgZXhh bXBsZSBzaG93cyB0aGF0IHRoZSBzaWduYWxpbmcgaXMgbm90IG5lZWRlZC4mbmJzcDsgU2VydmVy cyBjYW4gdW5pbGF0ZXJhbGx5IGRvIGl0IG5vdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPkkgbWFpbnRhaW4gdGhhdCB0aGUgY2xlYXJ0ZXh0IHNpZ25hbCBzZXJ2 ZXJzIG5vIHVzZWZ1bCBwdXJwb3NlLCBleGNlcHQgdG8gcHJvdmlkZSBhIG1lY2hhbmlzbSBmb3Ig ZW50aXRpZXMgdG8gc2VncmVnYXRlIHRyYWZmaWMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_C2DD79920A5A49708DDBDBA651B4D6D7akamaicom_-- From nobody Wed Nov 1 07:24:40 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515AB13FC00 for ; Wed, 1 Nov 2017 07:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 r4nFf28irXij for ; Wed, 1 Nov 2017 07:24:37 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AAAD13FBE8 for ; Wed, 1 Nov 2017 07:24:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BB12FBE50; Wed, 1 Nov 2017 14:24:34 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAuisWEbT5Ei; Wed, 1 Nov 2017 14:24:34 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 64401BE3E; Wed, 1 Nov 2017 14:24:34 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1509546274; bh=h8FULmKCPWI/9Rp+a2xVVJp0Y5kvphI3aIGM/6/r3wc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=YWd4RL8WGpSOUVh8WpHPRbJpAnWVPKrfRFm6F+SoguLywSBE5eS+u1y96J14jtvXP Xh/m7Zn2cyEf0mi23H/rA4Tq7Kqi7GT6JpOpd/v+J/W2EyxbtwOLOZ/xH/57751FeM QC6GRS8XIIrj1c+qCdobBJwP3LXiX+B64PHO3ORw= To: "Salz, Rich" , "tls@ietf.org" References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Wed, 1 Nov 2017 14:24:33 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GdeuDFG0Lv9QBxcbA8GJdbcrdijbBb92p" Archived-At: Subject: Re: [TLS] Draft RHRD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 14:24:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GdeuDFG0Lv9QBxcbA8GJdbcrdijbBb92p Content-Type: multipart/mixed; boundary="KT8btrpgERHGfCh2wldL6p7EiLqiXWDr1"; protected-headers="v1" From: Stephen Farrell To: "Salz, Rich" , "tls@ietf.org" Message-ID: Subject: Re: [TLS] Draft RHRD References: In-Reply-To: --KT8btrpgERHGfCh2wldL6p7EiLqiXWDr1 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 01/11/17 14:18, Salz, Rich wrote: > In https://www.ietf.org/mail-archive/web/tls/current/msg24789.html, > Nick Sullivan concluded: >=20 >> - on the other hand using draft-rhrd is safer than allowing >> organizations to hack single-key escrow into TLS 1.3 or continue to >> use TLS 1.2 with non-forward-secret cipher suites >=20 > I think this sets up a false comparison. Existing TLS 1.3 debugging > systems =E2=80=93 Wireshark =E2=80=93 can debug individual TLS sessions= with the > session key information being made available. This is what the RHRD > draft would require an organization to do, but it adds the additional > signaling that the client is willing to allow it. The Wireshark > example shows that the signaling is not needed. Servers can > unilaterally do it now. >=20 > I maintain that the cleartext signal servers no useful purpose, > except to provide a mechanism for entities to segregate traffic. I agree. I'd also like to point out that that in no way implies that the absence of the visible signal is any better. As we saw with draft-green, it was not. S. >=20 >=20 >=20 > _______________________________________________ TLS mailing list=20 > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >=20 --KT8btrpgERHGfCh2wldL6p7EiLqiXWDr1-- --GdeuDFG0Lv9QBxcbA8GJdbcrdijbBb92p Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ+dkhAAoJEC88hzaAX42iYKAH/3Dc00iGCT0hg5FMa6m1IuVE 8pCqc4Lxz+NRGbKdNrYUiy6jG5eCbpmmbcVcGbpvDuzVfUu4ZsigpOkM6j69VUif YIiQtupo4X0rVpv818+YCzKR8uG1Z+NOqpYl0ec1pB3jE72rZY689punhxBhs34c ZRdBBDy1Qvu5LO1KhSzTttlDAbqBnILILVm6qvuubwOlF1Znxu3EuO1vZ4Bctq+p STUjiKgGqZfXzZDTIdQLP0ZvJmVVSjKqK6x2nap3W53IgiGXJqw5EmDhR/WrGG0Y CywJmdNwnh6TqX7QPSp+pLY4R/ZGwdNZzBsvJVvEUlHCQxqx3BiU6FwjFM+fO7M= =kDnl -----END PGP SIGNATURE----- --GdeuDFG0Lv9QBxcbA8GJdbcrdijbBb92p-- From nobody Wed Nov 1 07:51:42 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F28413FCFC for ; Wed, 1 Nov 2017 07:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 OECAiMBF8BjT for ; Wed, 1 Nov 2017 07:51:38 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C540E13FCF4 for ; Wed, 1 Nov 2017 07:51:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3397D3005D6 for ; Wed, 1 Nov 2017 10:51:38 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id W9Ne9iotm-bs for ; Wed, 1 Nov 2017 10:51:36 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 4E6193005D0; Wed, 1 Nov 2017 10:51:36 -0400 (EDT) From: Russ Housley Message-Id: <2161E083-EB01-4D04-9E9F-2E763E9EC06D@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_46D95FEE-2C4E-472A-ADF5-DFD09A4501EA" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 1 Nov 2017 10:51:35 -0400 In-Reply-To: Cc: IETF TLS To: Rich Salz References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Draft RHRD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 14:51:40 -0000 --Apple-Mail=_46D95FEE-2C4E-472A-ADF5-DFD09A4501EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Rich: > On Nov 1, 2017, at 10:18 AM, Salz, Rich wrote: >=20 > In https://www.ietf.org/mail-archive/web/tls/current/msg24789.html = , Nick = Sullivan concluded: > =20 > >- on the other hand using draft-rhrd is safer than allowing = organizations to hack single-key escrow into TLS 1.3 or continue to use = TLS 1.2 with non-forward-secret cipher suites > =20 > I think this sets up a false comparison. Existing TLS 1.3 debugging = systems =E2=80=93 Wireshark =E2=80=93 can debug individual TLS sessions = with the session key information being made available. This is what the = RHRD draft would require an organization to do, but it adds the = additional signaling that the client is willing to allow it. The = Wireshark example shows that the signaling is not needed. Servers can = unilaterally do it now. > =20 > I maintain that the cleartext signal servers no useful purpose, except = to provide a mechanism for entities to segregate traffic. Indeed, anyone can implement the approach in draft-green, which has no = opt-in capability. In Prague, we heard that a lot of people would be = more comfortable with an opt-in capability, so we specified an extension = that does so. Russ --Apple-Mail=_46D95FEE-2C4E-472A-ADF5-DFD09A4501EA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Rich:

On Nov 1, 2017, at 10:18 AM, = Salz, Rich <rsalz@akamai.com> wrote:

In https://www.ietf.org/mail-archive/web/tls/current/msg24789.html= , Nick Sullivan concluded:
 
>- on the = other hand using draft-rhrd is safer than allowing organizations to hack = single-key escrow into TLS 1.3 or continue to use TLS 1.2 with = non-forward-secret cipher suites
 
I think this sets = up a false comparison.  Existing TLS 1.3 debugging systems =E2=80=93 = Wireshark =E2=80=93 can debug individual TLS sessions with the session = key information being made available.  This is what the RHRD draft = would require an organization to do, but it adds the additional = signaling that the client is willing to allow it. The Wireshark example = shows that the signaling is not needed.  Servers can unilaterally = do it now.
 
I maintain that = the cleartext signal servers no useful purpose, except to provide a = mechanism for entities to segregate traffic.


Indeed, anyone can implement = the approach in draft-green, which has no opt-in capability.  In = Prague, we heard that a lot of people would be more comfortable with an = opt-in capability, so we specified an extension that does so.

Russ

= --Apple-Mail=_46D95FEE-2C4E-472A-ADF5-DFD09A4501EA-- From nobody Wed Nov 1 08:03:58 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F9D13F717 for ; Wed, 1 Nov 2017 08:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 VBGkqz8bTY61 for ; Wed, 1 Nov 2017 08:03:50 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE2D913B13E for ; Wed, 1 Nov 2017 08:03:50 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vA1Evkjo001738; Wed, 1 Nov 2017 15:03:49 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=WfuQjonxRlLY3NHO053xc1HG9w2wLjls9XLc/RNAjOA=; b=B645Ir+ey906+xDJFphSgK9Jy4XvV5iBjIH1u765tmQsCQCTzY3F1HXYiAzaeGamo1/D khbCrnlUqJ9QbyFMDeUhHBtjQcdScsdUeK93xTptlt2HwjNBQfFOymOF+f+ySNlxV9pA EvtTPLSeTlJ+1R0jc3ykFaeC0ROWWZYlvIj3VGFKebhYkDrdgdJDWinVD3KllIRhuUmP YvjaA31WE8p3gbIS15wmHAu769xXOdaBGF/RbCwkz+v/AjW7+mJLdA+KdDp7+9FH82lj 3tLbo2/coBfE7xGWBgYNiCOBTc4IqbXljC+ANlKbd7MNadOSVHyBx+dpOI7fIw0ywFFB 7g== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2dvmw2pdyh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 01 Nov 2017 15:03:48 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vA1F1Ntv005353; Wed, 1 Nov 2017 11:03:46 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2dvn7u3pva-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 01 Nov 2017 11:03:46 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 1 Nov 2017 11:03:46 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 1 Nov 2017 11:03:46 -0400 From: "Salz, Rich" To: Russ Housley CC: IETF TLS Thread-Topic: [TLS] Draft RHRD Thread-Index: AQHTUyDtk5mAfD7MmEOXeSzZheIE1qL/4gaA Date: Wed, 1 Nov 2017 15:03:45 +0000 Message-ID: <287A1689-6DE4-4D2E-BD67-8B8A36ECF741@akamai.com> References: <2161E083-EB01-4D04-9E9F-2E763E9EC06D@vigilsec.com> In-Reply-To: <2161E083-EB01-4D04-9E9F-2E763E9EC06D@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.44] Content-Type: multipart/alternative; boundary="_000_287A16896DE44D2EBD678B8A36ECF741akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-01_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711010209 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-01_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 lowpriorityscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711010208 Archived-At: Subject: Re: [TLS] Draft RHRD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 15:03:57 -0000 --_000_287A16896DE44D2EBD678B8A36ECF741akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSW5kZWVkLCBhbnlvbmUgY2FuIGltcGxlbWVudCB0aGUgYXBwcm9hY2ggaW4gZHJhZnQt Z3JlZW4sIHdoaWNoIGhhcyBubyBvcHQtaW4gY2FwYWJpbGl0eS4gIEluIFByYWd1ZSwgd2UgaGVh cmQgdGhhdCBhIGxvdCBvZiBwZW9wbGUgd291bGQgYmUgbW9yZSBjb21mb3J0YWJsZSB3aXRoIGFu IG9wdC1pbiBjYXBhYmlsaXR5LCBzbyB3ZSBzcGVjaWZpZWQgYW4gZXh0ZW5zaW9uIHRoYXQgZG9l cyBzby4NCg0KSSBnZXQgaXQuICBBbmQgaW4gcmV0cm9zcGVjdCwgSSBhbSBjb252aW5jZWQgdGhh dCB3YXMgYSBiYWQgZGVjaXNpb24uICBMaWtlIHRoZSBxdW90ZSBmcm9tIHRoZSBtb3ZpZSBfQW5p bWFsIEhvdXNlXyBhYm91dCB0cnVzdC4g4pi6DQo= --_000_287A16896DE44D2EBD678B8A36ECF741akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <994A1732D8847D4E8402EB796326090E@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJBcHBsZSBDb2xvciBFbW9qaSI7DQoJ cGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQ YXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXtt c28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZp bml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTM5MzQ1NzUyNzsNCgltc28tbGlz dC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTYyMjQzODA0MiA2NzY5ODY5 OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0 OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+D mDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglt c28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tYmlkaS1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30NCkBsaXN0IGww OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2 ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1 bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdj b2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBl PSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+SW5kZWVkLCBhbnlvbmUgY2FuIGltcGxlbWVu dCB0aGUgYXBwcm9hY2ggaW4gZHJhZnQtZ3JlZW4sIHdoaWNoIGhhcyBubyBvcHQtaW4gY2FwYWJp bGl0eS4gJm5ic3A7SW4gUHJhZ3VlLCB3ZSBoZWFyZCB0aGF0IGEgbG90IG9mIHBlb3BsZSB3b3Vs ZCBiZSBtb3JlIGNvbWZvcnRhYmxlIHdpdGggYW4gb3B0LWluIGNhcGFiaWxpdHksDQogc28gd2Ug c3BlY2lmaWVkIGFuIGV4dGVuc2lvbiB0aGF0IGRvZXMgc28uPG86cD48L286cD48L2xpPjwvdWw+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIGdldCBpdC4mbmJzcDsgQW5kIGluIHJldHJvc3BlY3QsIEkgYW0g Y29udmluY2VkIHRoYXQgd2FzIGEgYmFkIGRlY2lzaW9uLiZuYnNwOyBMaWtlIHRoZSBxdW90ZSBm cm9tIHRoZSBtb3ZpZSBfPGk+QW5pbWFsIEhvdXNlPC9pPl8gYWJvdXQgdHJ1c3QuDQo8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXBwbGUgQ29sb3IgRW1vamkmcXVvdDsiPuKYujwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_287A16896DE44D2EBD678B8A36ECF741akamaicom_-- From nobody Wed Nov 1 09:10:44 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3BFA13FEB7 for ; Wed, 1 Nov 2017 09:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 gXQ4QV-H7cAH for ; Wed, 1 Nov 2017 09:10:36 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 60ECB13FE5C for ; Wed, 1 Nov 2017 09:08:20 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id r196so5890213wmf.2 for ; Wed, 01 Nov 2017 09:08:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=80Sax2bqZfWbP+S53rJ9Oxtq+vlcNfJouoT7Zmzx700=; b=bfMZuH9Hs8D36ZEkoDMjjNvWWe1FllrOCgwHblcK/UzzoXjEk9THUGSJw7H1weKacy uYTsDt7KXcmit0wPEy7G5DS8ROJPPl/n2Q2CMP0p9UqS0BJWlGgP72H1LoUkKXsQ1y24 y0UDAVsJQPGEjUjpmBcKzu4Ongdz9XFHYDmdJAxjWSWSu6AXOEP5Qh50wvrlhpj5basA lTkt/qar0ykAkXo3cqYHJoFyiA4Ys9+NbRejcXUBhA6gKv813z0tK7z64rrNTJwL/NG4 I+4K19doSQA0iFRmzhjLNQhfcW1p/FwYBcHN4Q2nsF/HIVFm16KjNp3/RAVrJ6Yp+qsN yioQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=80Sax2bqZfWbP+S53rJ9Oxtq+vlcNfJouoT7Zmzx700=; b=hOwVJnJPjHtIBbBjVOyqlfLRD3ANu9eHbEoCK/lpkKOhM8hbW1TvEvkqwPUqJvxVHH gFdIx8fIpEhWegorWNjPra6Y06dJIDpb1/t6Zv8BsbpUECAXoa3K7z0xkm4t7aXZf6CH KilKqfKNK/PVctXblMGdbDpT65/MUxPDKrSX07n/VVu0qeS2Yvh8Wb5u9gdoWx1g7ZC2 tpifMb5wJZ8C/FE5Q/d9KppSXkY9LWjCPRDqGQ615tOXG9DRLp6/21nkpizbl3OrbtR2 m+znwJ0IqrtRkFYQkYGpreBUv4b/2Yq5qHtmIJnerXZ3LOwf0UP3LI8H1/cSaic5UeMp +nhw== X-Gm-Message-State: AMCzsaXK2mzGQ5r32lJA391t+IsjiL2kis/xOEg4g0I7SEcwep+Aihja X+pVAQFJ+iHBR5Ms4njbed2mrZKx2wZyJoPwpoI= X-Google-Smtp-Source: ABhQp+Sb7aSusehKU1qLkrj7ZQ6uxMDA/vS89sll6mR6AWTefKF8lFMcmHNT6dS5ENKZpm9uhKG4EBoKWZhKhDhgHmA= X-Received: by 10.28.87.17 with SMTP id l17mr616562wmb.158.1509552498649; Wed, 01 Nov 2017 09:08:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nick Sullivan Date: Wed, 01 Nov 2017 16:08:07 +0000 Message-ID: To: "Salz, Rich" Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a11443a5273af4f055cee1488" Archived-At: Subject: Re: [TLS] Draft RHRD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 16:10:43 -0000 --001a11443a5273af4f055cee1488 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Rich, I think you're mixing things up a bit. There is no false comparison. I am not comparing draft-rhrd to the Wireshark option, they are fundamentally different. I'm comparing draft-rhrd to draft-green. The wireshark option requires storage of n keys to inspect n connections, both draft-rhrd and draft-green only require a single master key to inspect n connections. The Wireshark option is always possible with TLS, it just has scaling issues. You export the session keys on a connection-by-connection basis from one of the endpoints and can then use them to decrypt the transcript after the fact. This is possible with TLS 1.2, TLS 1.3 and every version of TLS that uses symmetric keys for encryption. This keeps TLS a two-party protocol, and is my preferred solution to datacenter visibility, and I assume Stephen's as well. There have been arguments here that this is not a tenable solution in some environments, but I haven't found them convincing for the datacenter visibility case. The other two options, the master key options draft-rhrd and draft-green, turn TLS into a quasi three-party protocol. Server operators can just implement draft-green (or a variant thereof that doesn't repeat DH keys, but instead generates them deterministically) no matter what the IETF says. It's not prohibited by TLS 1.3 either structurally or by policy. If datacenter operators want a master key option and there is no standard to use, they can just implement draft-green and the client will have no idea this is happening. Your rejection of the cleartext signal expresses implies a preference for draft-green over draft-rhrd, not a preference for the wireshark option over draft-rhrd. Without draft-rhrd, it's likely that draft-green gets implemented whether it's standardized or not and no client will be able to opt out or even know that it's happening. In the situation where draft-green become the de facto standard for key escrow in TLS, the public debates around national firewalls trying to force clients to opt into wiretapping will become moot, firewalls won't have to block users who have the cleartext signal, they'll just force servers to implement draft-green unbeknownst to users. Users won't have any option, or any knowledge that servers are using a master key to protect the confidentiality of their connection and that their security may be lessened because of it (compared to a Wireshark-type system which is more difficult to implement at nation-scale due to how many keys you need to manage). Furthermore, researchers won't be able to measure the prevalence of this type of technology. With draft-green, civil society goes dark, with draft-rhrd, there will be public data to inform a public debate. Nick On Wed, Nov 1, 2017 at 7:19 AM Salz, Rich wrote: > In https://www.ietf.org/mail-archive/web/tls/current/msg24789.html, Nick > Sullivan concluded: > > > > >- on the other hand using draft-rhrd is safer than allowing organization= s > to hack single-key escrow into TLS 1.3 or continue to use TLS 1.2 with > non-forward-secret cipher suites > > > > I think this sets up a false comparison. Existing TLS 1.3 debugging > systems =E2=80=93 Wireshark =E2=80=93 can debug individual TLS sessions w= ith the session > key information being made available. This is what the RHRD draft would > require an organization to do, but it adds the additional signaling that > the client is willing to allow it. The Wireshark example shows that the > signaling is not needed. Servers can unilaterally do it now. > > > > I maintain that the cleartext signal servers no useful purpose, except to > provide a mechanism for entities to segregate traffic. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11443a5273af4f055cee1488 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Rich,

I think you're mixing things = up a bit. There is no false comparison. I am not comparing draft-rhrd to th= e Wireshark option, they are fundamentally different. I'm comparing dra= ft-rhrd to draft-green. The wireshark option requires storage of n keys to = inspect n connections, both draft-rhrd and draft-green only require a singl= e master key to inspect n connections.

The Wiresha= rk option is always possible with TLS, it just has scaling issues. You expo= rt the session keys on a connection-by-connection basis from one of the end= points and can then use them to decrypt the transcript after the fact. This= is possible with TLS 1.2, TLS 1.3 and every version of TLS that uses symme= tric keys for encryption. This keeps TLS a two-party protocol, and is my pr= eferred solution to datacenter visibility, and I assume Stephen's as we= ll. There have been arguments here that this is not a tenable solution in s= ome environments, but I haven't found them convincing for the datacente= r visibility case.

The other two options, the mast= er key options draft-rhrd and draft-green, turn TLS into a quasi three-part= y protocol. Server operators can just implement draft-green (or a variant t= hereof that doesn't repeat DH keys, but instead generates them determin= istically) no matter what the IETF says. It's not prohibited by TLS 1.3= either structurally or by policy. If datacenter operators want a master ke= y option and there is no standard to use, they can just implement draft-gre= en and the client will have no idea this is happening.

=
Your rejection of the cleartext signal expresses implies a preference = for draft-green over draft-rhrd, not a preference for the wireshark option = over=C2=A0draft-rhrd. Without=C2=A0draft-rhrd, it's likely that draft-g= reen gets implemented whether it's standardized or not and no client wi= ll be able to opt out or even know that it's happening.

<= /div>
In the situation where draft-green become the de facto standard f= or key escrow in TLS, the public debates around national firewalls trying t= o force clients to opt into wiretapping will become moot, firewalls won'= ;t have to block users who have the cleartext signal, they'll just forc= e servers to implement draft-green unbeknownst to users. Users won't ha= ve any option, or any knowledge that servers are using a master key to prot= ect the confidentiality of their connection and that their security may be = lessened because of it (compared to a Wireshark-type system which is more d= ifficult to implement at nation-scale due to how many keys you need to mana= ge). Furthermore, researchers won't be able to measure the prevalence o= f this type of technology. With draft-green, civil society goes dark, with = draft-rhrd, there will be public data to inform a public debate.
=
Nick

On Wed, Nov 1, 2017 at 7:19 AM Salz, Rich <rsalz@akamai.com> wrote:

In https://www.ietf.org/mail-archive/web/tls/current/msg24789.html, Nick S= ullivan concluded:

=C2=A0

>- on the other = hand using draft-rhrd is safer than allowing organizations to hack single-k= ey escrow into TLS 1.3 or continue to use TLS 1.2 with non-forward-secret c= ipher suites

=C2=A0

I think this sets u= p a false comparison.=C2=A0 Existing TLS 1.3 debugging systems =E2=80=93 Wi= reshark =E2=80=93 can debug individual TLS sessions with the session key in= formation being made available.=C2=A0 This is what the RHRD draft would require an organization to do, but it adds the additional signaling = that the client is willing to allow it. The Wireshark example shows that th= e signaling is not needed.=C2=A0 Servers can unilaterally do it now.=

=C2=A0

I maintain that the= cleartext signal servers no useful purpose, except to provide a mechanism = for entities to segregate traffic.

=C2=A0

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a11443a5273af4f055cee1488-- From nobody Wed Nov 1 09:27:25 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC66913F7FA for ; Wed, 1 Nov 2017 09:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 dMLXT7Yr7V-a for ; Wed, 1 Nov 2017 09:27:22 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D11C13F7A6 for ; Wed, 1 Nov 2017 09:27:21 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id vA1GP2pn025896; Wed, 1 Nov 2017 16:27:18 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=VOuVciEHVAwGbHbwZAdo+maScx2fMBfsSy2rLWKkMiM=; b=BV7xA6Nqhqk6jdmA3Uh+Wh1j6MTMp2qoz6N0dXUi2+RTD8omju0cOZNVDmrxJ1i4YXlu TFdz+REOJ4I8qU+HlryfBxKpNLQK6XJ3wg4n9HF4QulvkABtNPkMOJAHIlhA2Y42/M2Q AHb3HXVr22i+1F4fuYaZQaX7J9rBynQjsJOBhBZAyxca1CPVVP9OzIoYe0dSxQ81uRYC s5slztps09ZAIkJN38euKD1Y0c3X3QHrVzdmu/5yCbZLWhdw0gjuwy+/mvDIWaAMogjX ost4/5jRcDuZN/KRD9E0xX95dH436euBIJB1cp6XTeuK3ELF3l5uuJPVTWEKfU8RvNl7 QQ== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050096.ppops.net-00190b01. with ESMTP id 2dvmwkfb3r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 01 Nov 2017 16:27:17 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vA1GGU0o009575; Wed, 1 Nov 2017 12:27:17 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2dvn7uuxa5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 01 Nov 2017 12:27:17 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 1 Nov 2017 12:27:16 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 1 Nov 2017 12:27:16 -0400 From: "Salz, Rich" To: Nick Sullivan CC: "tls@ietf.org" Thread-Topic: [TLS] Draft RHRD Thread-Index: AQHTUyukRAt1aB3Y8ka0ENvf7zGMLqL/+UYA Date: Wed, 1 Nov 2017 16:27:16 +0000 Message-ID: <5D22EE0B-248C-4614-99B5-0007E8E72E2B@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.44] Content-Type: multipart/alternative; boundary="_000_5D22EE0B248C461499B50007E8E72E2Bakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-01_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711010219 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-01_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711010219 Archived-At: Subject: Re: [TLS] Draft RHRD X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 16:27:24 -0000 --_000_5D22EE0B248C461499B50007E8E72E2Bakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSSB0aGluayB5b3UncmUgbWl4aW5nIHRoaW5ncyB1cCBhIGJpdC4NCg0KVGhhdOKAmXMg cXVpdGUgcG9zc2libGUuDQoNCg0KICAqICAgSSdtIGNvbXBhcmluZyBkcmFmdC1yaHJkIHRvIGRy YWZ0LWdyZWVuLiBUaGUgd2lyZXNoYXJrIG9wdGlvbiByZXF1aXJlcyBzdG9yYWdlIG9mIG4ga2V5 cyB0byBpbnNwZWN0IG4gY29ubmVjdGlvbnMsIGJvdGggZHJhZnQtcmhyZCBhbmQgZHJhZnQtZ3Jl ZW4gb25seSByZXF1aXJlIGEgc2luZ2xlIG1hc3RlciBrZXkgdG8gaW5zcGVjdCBuIGNvbm5lY3Rp b25zLg0KDQpEcmFmdC1ncmVlbiByZXF1aXJlcyBsaW1pdGVkIHVzZSBvZiBFQ0RIIGtleXMsIHNv IHRoYXQgdGhleSBjYW4gYmUgc2VudCB0byB0aGUgdGhpcmQgcGFydHkuICBEcmFmdC1yaHJkIGFs bG93cyBsaW1pdGVkIHVzZSwgYnV0IGRvZXMgbm90IHJlcXVpcmUgaXQuICBJdCBhbGxvd3MgYSBn cmVhdCBkZWFsIG9mIGZsZXhpYmlsaXR5LCBmcm9tIG9uZSBrZXkgZm9yIGRheXMsIHRvIG9uZSBr ZXkgZm9yIGVhY2ggc2Vzc2lvbi4gIFJpZ2h0Pw0KDQpXZSBjYW7igJl0IGNvbnRyb2wgd2hhdCBh IHNlcnZlciB3aWxsIGRvLCBhbmQgd2UgbmV2ZXIgY291bGQuICBObyBtYXR0ZXIgaG93IG11Y2gg d2UganVtcCB1cCBhbmQgZG93biBhbmQgc2F5IOKAnGRvbuKAmXQgZ2l2ZSBhd2F5IHRoZSBrZXlz IHVubGVzcyB5b3Ugc2VlIHRoZSBSSFJEIGV4dGVuc2lvbuKAnSB3ZeKAmWxsIG5ldmVyIGtub3cu ICBBbiB1bmZvcmNlYWJsZSBydWxlIGlzIGEgdmVyeSBiYWQgcnVsZSBhbmQgc2hvdWxkbuKAmXQg YmUgYSBydWxlLiAgRHJhZnQtZ3JlZW4gaXMgbXVjaCBtb3JlIGludGVsbGVjdHVhbGx5IGhvbmVz dCwgYW5kIGRvZXNu4oCZdCBwcm92aWRlIHRoZSBjbGVhcnRleHQgc2lnbmFsLg0KDQoNCg0KICAq ICAgWW91ciByZWplY3Rpb24gb2YgdGhlIGNsZWFydGV4dCBzaWduYWwgZXhwcmVzc2VzIGltcGxp ZXMgYSBwcmVmZXJlbmNlIGZvciBkcmFmdC1ncmVlbiBvdmVyIGRyYWZ0LXJocmQsIG5vdCBhIHBy ZWZlcmVuY2UgZm9yIHRoZSB3aXJlc2hhcmsgb3B0aW9uIG92ZXIgZHJhZnQtcmhyZC4gV2l0aG91 dCBkcmFmdC1yaHJkLCBpdCdzIGxpa2VseSB0aGF0IGRyYWZ0LWdyZWVuIGdldHMgaW1wbGVtZW50 ZWQgd2hldGhlciBpdCdzIHN0YW5kYXJkaXplZCBvciBub3QgYW5kIG5vIGNsaWVudCB3aWxsIGJl IGFibGUgdG8gb3B0IG91dCBvciBldmVuIGtub3cgdGhhdCBpdCdzIGhhcHBlbmluZy4NCg0KWWVz OyBJIGFtIHN1cnByaXNlZCB0aGF04oCZcyBiZWluZyBxdWVzdGlvbmVkLCBidXQgYWZ0ZXIgdGhp cyBub3RlIGl0IHNob3VsZCBiZSBvYnZpb3VzIHRvIGFsbC4gIEluIGZhY3QsIEkgdGhpbmsgaXQg d2FzIGJlZm9yZSBNYXR04oCZcyBwcm9wb3NhbCB0aGF0IEkgc3Rvb2QgYXQgdGhlIG1pYyBhbmQg c2FpZCB3ZSBzaG91bGQgdHJlYXQgaXQgbGlrZSBwcm9oaWJpdGlvbjog4oCcdGhpcyBpcyBncmFw ZSBqdWljZSwgYnV0IGlmIHlvdSBkbyB0aGlz4oCmIGFuZCB0aGlz4oCmIGFuZCB0aGlz4oCmIGl0 IHdpbGwgYmVjb21lIHdpbmUuIFRoYXTigJlzIGlsbGVnYWwgc28gZG9u4oCZdCBkbyB0aGF0LuKA nQ0KDQoNCg0KICAqICAgVXNlcnMgd29uJ3QgaGF2ZSBhbnkgb3B0aW9uLCBvciBhbnkga25vd2xl ZGdlIHRoYXQgc2VydmVycyBhcmUgdXNpbmcgYSBtYXN0ZXIga2V5IHRvIHByb3RlY3QgdGhlDQpj b25maWRlbnRpYWxpdHkgb2YgdGhlaXIgY29ubmVjdGlvbiBhbmQgdGhhdCB0aGVpciBzZWN1cml0 eSBtYXkgYmUgbGVzc2VuZWQgYmVjYXVzZSBvZiBpdA0KDQpUaGV5IHN0aWxsIGRvbuKAmXQuIFdl IG1pZ2h0IGFsbCBsaWtlIHRvIHRoaW5rIHRoYXQgdGhleSBkbywgYnV0IHdpdGggb3Igd2l0aG91 dCBlaXRoZXIgZHJhZnQsIHRoZXJlIGlzIG5vIHdheSB0byBlbnN1cmUgYW55dGhpbmcgYWJvdXQg dGhlIHNlcnZlcuKAmXMgYmVoYXZpb3IgYmV5b25kIHRoZSBiaXRzIGl0IHNlbmRzIG9uIHRoZSB3 aXJlLiAgSXQgd2FzIGFsd2F5cyBzbywgYW5kIGhvcGluZyB0aGF0IHNvbWUgdGV4dCB3aWxsIG1h a2UgaXQgbW9yZSB0aGFuIHRoaXMgaXMgYSBkaXNzZXJ2aWNlIHRvIHRoZSBlbmQgdXNlcnMuDQoN Cg0K --_000_5D22EE0B248C461499B50007E8E72E2Bakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwg bGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXBy aW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2lu LWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1l OiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDox MTA3MzEwNzcwOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czo2NzQxNDgwNzQgNjc2OTg2OTkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJ e21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 IixzZXJpZjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30NCkBsaXN0 IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4N CjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHVsIHN0eWxlPSJt YXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPkkgdGhpbmsg eW91J3JlIG1peGluZyB0aGluZ3MgdXAgYSBiaXQuPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoYXTigJlzIHF1aXRlIHBvc3NpYmxlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGlu IiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+SSdtIGNvbXBhcmluZyBkcmFmdC1y aHJkIHRvIGRyYWZ0LWdyZWVuLiBUaGUgd2lyZXNoYXJrIG9wdGlvbiByZXF1aXJlcyBzdG9yYWdl IG9mIG4ga2V5cyB0byBpbnNwZWN0IG4gY29ubmVjdGlvbnMsIGJvdGggZHJhZnQtcmhyZCBhbmQg ZHJhZnQtZ3JlZW4gb25seSByZXF1aXJlIGEgc2luZ2xlIG1hc3RlciBrZXkNCiB0byBpbnNwZWN0 IG4gY29ubmVjdGlvbnMuPG86cD48L286cD48L2xpPjwvdWw+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EcmFm dC1ncmVlbiByZXF1aXJlcyBsaW1pdGVkIHVzZSBvZiBFQ0RIIGtleXMsIHNvIHRoYXQgdGhleSBj YW4gYmUgc2VudCB0byB0aGUgdGhpcmQgcGFydHkuJm5ic3A7IERyYWZ0LXJocmQgYWxsb3dzIGxp bWl0ZWQgdXNlLCBidXQgZG9lcyBub3QgcmVxdWlyZSBpdC4mbmJzcDsgSXQgYWxsb3dzIGEgZ3Jl YXQgZGVhbCBvZiBmbGV4aWJpbGl0eSwgZnJvbSBvbmUga2V5IGZvciBkYXlzLCB0byBvbmUga2V5 IGZvciBlYWNoIHNlc3Npb24uJm5ic3A7DQogUmlnaHQ/PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PldlIGNhbuKAmXQgY29udHJvbCB3aGF0IGEgc2VydmVyIHdpbGwgZG8sIGFuZCB3ZSBuZXZlciBj b3VsZC4mbmJzcDsgTm8gbWF0dGVyIGhvdyBtdWNoIHdlIGp1bXAgdXAgYW5kIGRvd24gYW5kIHNh eSDigJxkb27igJl0IGdpdmUgYXdheSB0aGUga2V5cyB1bmxlc3MgeW91IHNlZSB0aGUgUkhSRCBl eHRlbnNpb27igJ0gd2XigJlsbCBuZXZlciBrbm93LiZuYnNwOyBBbiB1bmZvcmNlYWJsZSBydWxl IGlzIGEgdmVyeSBiYWQgcnVsZSBhbmQgc2hvdWxkbuKAmXQNCiBiZSBhIHJ1bGUuJm5ic3A7IERy YWZ0LWdyZWVuIGlzIG11Y2ggbW9yZSBpbnRlbGxlY3R1YWxseSBob25lc3QsIGFuZCBkb2VzbuKA mXQgcHJvdmlkZSB0aGUgY2xlYXJ0ZXh0IHNpZ25hbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGlu Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9 ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5Zb3VyIHJlamVjdGlvbiBvZiB0aGUgY2xlYXJ0 ZXh0IHNpZ25hbCBleHByZXNzZXMgaW1wbGllcyBhIHByZWZlcmVuY2UgZm9yIGRyYWZ0LWdyZWVu IG92ZXIgZHJhZnQtcmhyZCwgbm90IGEgcHJlZmVyZW5jZSBmb3IgdGhlIHdpcmVzaGFyayBvcHRp b24gb3ZlciZuYnNwO2RyYWZ0LXJocmQuIFdpdGhvdXQmbmJzcDtkcmFmdC1yaHJkLA0KIGl0J3Mg bGlrZWx5IHRoYXQgZHJhZnQtZ3JlZW4gZ2V0cyBpbXBsZW1lbnRlZCB3aGV0aGVyIGl0J3Mgc3Rh bmRhcmRpemVkIG9yIG5vdCBhbmQgbm8gY2xpZW50IHdpbGwgYmUgYWJsZSB0byBvcHQgb3V0IG9y IGV2ZW4ga25vdyB0aGF0IGl0J3MgaGFwcGVuaW5nLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXM7IEkgYW0gc3VycHJpc2VkIHRoYXTigJlzIGJlaW5nIHF1 ZXN0aW9uZWQsIGJ1dCBhZnRlciB0aGlzIG5vdGUgaXQgc2hvdWxkIGJlIG9idmlvdXMgdG8gYWxs LiZuYnNwOyBJbiBmYWN0LCBJIHRoaW5rIGl0IHdhcyBiZWZvcmUgTWF0dOKAmXMgcHJvcG9zYWwg dGhhdCBJIHN0b29kIGF0IHRoZSBtaWMgYW5kIHNhaWQgd2Ugc2hvdWxkIHRyZWF0IGl0IGxpa2Ug cHJvaGliaXRpb246IOKAnHRoaXMgaXMgZ3JhcGUganVpY2UsIGJ1dA0KIGlmIHlvdSBkbyB0aGlz 4oCmIGFuZCB0aGlz4oCmIGFuZCB0aGlz4oCmIGl0IHdpbGwgYmVjb21lIHdpbmUuIFRoYXTigJlz IGlsbGVnYWwgc28gZG9u4oCZdCBkbyB0aGF0LuKAnTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW4i PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0i ZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDow aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPlVzZXJzIHdvbid0IGhhdmUgYW55IG9wdGlvbiwg b3IgYW55IGtub3dsZWRnZSB0aGF0IHNlcnZlcnMgYXJlIHVzaW5nIGEgbWFzdGVyIGtleSB0byBw cm90ZWN0IHRoZQ0KPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5j b25maWRlbnRpYWxpdHkgb2YgdGhlaXIgY29ubmVjdGlvbiBhbmQgdGhhdCB0aGVpciBzZWN1cml0 eSBtYXkgYmUgbGVzc2VuZWQgYmVjYXVzZSBvZiBpdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGV5IHN0aWxsIGRvbuKAmXQuIFdlIG1pZ2h0IGFsbCBsaWtlIHRvIHRoaW5rIHRoYXQgdGhleSBk bywgYnV0IHdpdGggb3Igd2l0aG91dCBlaXRoZXIgZHJhZnQsIHRoZXJlIGlzIG5vIHdheSB0byBl bnN1cmUgYW55dGhpbmcgYWJvdXQgdGhlIHNlcnZlcuKAmXMgYmVoYXZpb3IgYmV5b25kIHRoZSBi aXRzIGl0IHNlbmRzIG9uIHRoZSB3aXJlLiZuYnNwOyBJdCB3YXMgYWx3YXlzIHNvLCBhbmQgaG9w aW5nIHRoYXQgc29tZSB0ZXh0DQogd2lsbCBtYWtlIGl0IG1vcmUgdGhhbiB0aGlzIGlzIGEgZGlz c2VydmljZSB0byB0aGUgZW5kIHVzZXJzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5D22EE0B248C461499B50007E8E72E2Bakamaicom_-- From nobody Wed Nov 1 10:17:30 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B50A813F978 for ; Wed, 1 Nov 2017 10:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.733 X-Spam-Level: X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 4Xvm_c_Ri5n1 for ; Wed, 1 Nov 2017 10:17:18 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id EFD9F13F971 for ; Wed, 1 Nov 2017 10:17:17 -0700 (PDT) Received: from mail-lf0-f53.google.com (mail-lf0-f53.google.com [209.85.215.53]) by linode64.ducksong.com (Postfix) with ESMTPSA id 2F8FF3A7DD for ; Wed, 1 Nov 2017 13:17:15 -0400 (EDT) Received: by mail-lf0-f53.google.com with SMTP id l23so3308853lfk.10 for ; Wed, 01 Nov 2017 10:17:15 -0700 (PDT) X-Gm-Message-State: AJaThX7mSeZcN9yHN0UDdjZBB5viO9Cdq7mVZiIBY9Jyl7PpnvFItfRT zMifVIktI0+xCjGjtFoNTAm9DKn2/XHCmVKPV2g= X-Google-Smtp-Source: ABhQp+QF5220CdF8LSjKnD6Uivc8bA3c0YpHBvUTx/RSyqqs8QmNwJU8QsLedBP1j3LiD4WwJJQa9CM20LFUt/k0jxA= X-Received: by 10.25.84.134 with SMTP id b6mr180796lfl.168.1509556632738; Wed, 01 Nov 2017 10:17:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.22 with HTTP; Wed, 1 Nov 2017 10:17:11 -0700 (PDT) In-Reply-To: <6d448c71-8585-be88-302d-feee7e098ac9@cs.tcd.ie> References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> <2f5fba1a-2ee4-4881-7df1-b925a4468fba@cs.tcd.ie> <9989a0aee6784a7ba96bda23cf51d69b@XCH-RCD-012.cisco.com> <6d448c71-8585-be88-302d-feee7e098ac9@cs.tcd.ie> From: Patrick McManus Date: Wed, 1 Nov 2017 18:17:11 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Stephen Farrell Cc: "Owen Friel (ofriel)" , Richard Barnes , "" Content-Type: multipart/alternative; boundary="94eb2c1cdec0dd06a3055cef0a50" Archived-At: Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 17:17:28 -0000 --94eb2c1cdec0dd06a3055cef0a50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Some feedback, in no particular order: * have a hard think about handshake/termination loads. istm this scheme devolves pretty quickly to a termination per object HTTP/1.0 style so you'll be fairly quickly looking to do some kind of multiplexing and reuse on top of it for the same reasons HTTP evolved that way. as an alternative - HTTP/2 inside of a CONNECT tunnel (e.g. HTTP/2 on one stream of an HTTP/2 session) is something browsers already do and may be a carrot worth chasing if you want to give up on the dream of just deploying js into the current environment. * read the current websockets over http/2 thread on httpbis with an eye to the discussion about CONNECT vs (a hypothetical) TUNNEL. There are some similarities to the discussion here. * also take a look at https://tools.ietf.org/html/dr aft-nottingham-bcp56bis-00 (to be adopted imminently by httpbis) - for general foo over http guidance. In particular note that requiring particular behavior from http response codes beyond what is already defined (adding semantics) is called out as a practice to be avoided. * I don't really understand how s->c data flows other than as a reply to client data. hanging get? polling? push? * istm you are using http as a reliable messaging layer. That 'reliable' part might get you into trouble.. various events can cause an http transaction to fail and I'm not sure how you recover that state without record number etc.. Is there room for a off path malicious actor to disrupt your stream state (e.g. send a get with your session ID to get a few bytes of ciphertext - which means you never get them?)? Perhaps this works better as a more generic "datagram over http" framework which you can obviously run some form of reliable stream and tls (and http) on top of. why is a tls record the best scope here? On Tue, Oct 31, 2017 at 10:26 PM, Stephen Farrell wrote: > > Hi Owen, > > On 31/10/17 21:03, Owen Friel (ofriel) wrote: > >> Interesting. One bit puzzles me: wouldn't the new content-type > >> give the game away and cause middleboxes to block this? > >> > >> S. > >> > > [ofriel] The intention isn=E2=80=99t to try and obscure the fact that t= here > > is an ATLS session. Even if that new content-type was not defined, > > it would be easy to write a simple pattern match script on the > > middlebox to identity the JSON body and leading base64 bytes of the > > TLS records in the body. > > So that leaves me puzzled still, sorry. > > I can't think of a situation with a middlebox that isn't ok > with the client doing proper TLS but is ok with ATLS. > > Can you give an example of such a situation? > > In case it helps, I can imagine that some middleboxes won't > (yet) know about this and will let it through for a while, > but that seems fairly brittle. So, I'd have thought it may > be worthwhile trying to hide what's what here if you want > it to be robust against an antagonistic middlebox or censor. > But maybe you guys analysed that already and figured it'd > not work. (Which brings me back to "puzzled":-) > > Cheers, > S. > > > > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c1cdec0dd06a3055cef0a50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Some feedback, in no particular order:

=
* have a hard think about handshake/termination loads. istm this= scheme devolves pretty quickly to a termination per object HTTP/1.0 style = so you'll be fairly quickly looking to do some kind of multiplexing and= reuse on top of it for the same reasons HTTP evolved that way. as an alter= native - HTTP/2 inside of a CONNECT tunnel (e.g. HTTP/2 on one stream of an= HTTP/2 session) is something browsers already do and may be a carrot worth= chasing if you want to give up on the dream of just deploying js into the = current environment.

* read the current websoc= kets over http/2 thread on httpbis with an eye to the discussion about CONN= ECT vs (a hypothetical) TUNNEL. There are some similarities to the discussi= on here.

* also take a look at htt= ps://tools.ietf.org/html/draft-nottingham-bcp56bis-00 (to be adopt= ed imminently by httpbis) - for general foo over http guidance. In particul= ar note that requiring particular behavior from http response codes beyond = what is already defined (adding semantics) is called out as a practice to b= e avoided.

* I don't really understand ho= w s->c data flows other than as a reply to client data. hanging get? pol= ling? push?

* istm you are using http as a rel= iable messaging layer. That 'reliable' part might get you into trou= ble.. various events can cause an http transaction to fail and I'm not = sure how you recover that state without record number etc.. Is there room f= or a off path malicious actor to disrupt your stream state (e.g. send a get= with your session ID to get a few bytes of ciphertext - which means you ne= ver get them?)? Perhaps this works better as a more generic "datagram = over http" framework which you can obviously run some form of reliable= stream and tls (and http) on top of. why is a tls record the best scope he= re?



On Tue, Oct 31, 2017 at 10:26 PM, Stephen F= arrell <stephen.farrell@cs.tcd.ie> wrote:

Hi Owen,

On 31/10/17 21:03, Owen Friel (ofriel) wrote:
>> Interesting. One bit puzzles me: wouldn't the new content-type=
>> give the game away and cause middleboxes to block this?
>>
>> S.
>>
> [ofriel] The intention isn=E2=80=99t to try and obscure the fact that = there
> is an ATLS session. Even if that new content-type was not defined,
> it would be easy to write a simple pattern match script on the
> middlebox to identity the JSON body and leading base64 bytes of the > TLS records in the body.

So that leaves me puzzled still, sorry.

I can't think of a situation with a middlebox that isn't ok
with the client doing proper TLS but is ok with ATLS.

Can you give an example of such a situation?

In case it helps, I can imagine that some middleboxes won't
(yet) know about this and will let it through for a while,
but that seems fairly brittle. So, I'd have thought it may
be worthwhile trying to hide what's what here if you want
it to be robust against an antagonistic middlebox or censor.
But maybe you guys analysed that already and figured it'd
not work. (Which brings me back to "puzzled":-)

Cheers,
S.


>
>


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


--94eb2c1cdec0dd06a3055cef0a50-- From nobody Wed Nov 1 22:24:37 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3D913F452 for ; Wed, 1 Nov 2017 22:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 czzcyqMVF9DJ for ; Wed, 1 Nov 2017 22:24:34 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03E291375C9 for ; Wed, 1 Nov 2017 22:24:34 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 6E256B810B3; Wed, 1 Nov 2017 22:24:24 -0700 (PDT) To: sfriedl@cisco.com, andreipo@microsoft.com, agl@google.com, emile.stephan@orange.com, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: igrigorik@gmail.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20171102052424.6E256B810B3@rfc-editor.org> Date: Wed, 1 Nov 2017 22:24:24 -0700 (PDT) Archived-At: Subject: [TLS] [Technical Errata Reported] RFC7301 (5176) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 05:24:35 -0000 The following errata report has been submitted for RFC7301, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5176 -------------------------------------- Type: Technical Reported by: Ilya Grigorik Section: 6 Original Text ------------- IANA Considerations Corrected Text -------------- +Protocol: HTTP/1.0 +Protocol: HTTP/0.9 Notes ----- RFC does not register ALPN identifiers for http/0.9 or http/1.0. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7301 (draft-ietf-tls-applayerprotoneg-05) -------------------------------------- Title : Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension Publication Date : July 2014 Author(s) : S. Friedl, A. Popov, A. Langley, E. Stephan Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Wed Nov 1 22:30:25 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D8913F48B for ; Wed, 1 Nov 2017 22:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 D9CGrtefrZ4c for ; Wed, 1 Nov 2017 22:30:22 -0700 (PDT) Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::233]) (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 1C37F1375C9 for ; Wed, 1 Nov 2017 22:30:22 -0700 (PDT) Received: by mail-ot0-x233.google.com with SMTP id n74so613623ota.8 for ; Wed, 01 Nov 2017 22:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=567v/2IeuG8PH6qNrSBnf9LQvoFYOKg0V2p7bAG7MkA=; b=NOveci3K3/hzphmLoRK7NbTnpvTdT8E6koGdyIBpsXTypVm6Vbd+iyRggg69aRj1N4 d/nsdh17glwWLhV/lTG8Eh1J2etCdQxvSiz76MG7TTqnFMf0i57ksxmqOz277Ix2GO96 +gSG6wwMgSd7pzT0ZL4AD317+ViuVm3qKusq3wG1RF6JjiK5TDcrncI3RNY6ILQSRztY 02keIhgj0SWunmAW9VmraV5vrU4HO46pwR+gMg89gJYWoxr61Ut3WnTI8/WmROIFMTAO bh1oNhrSgMvBMAXn0DKxP+JLXpxNGsxQq//zaJZUK1J8n4u2Ct3ZBw9RGou62mqkywbr Xksw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=567v/2IeuG8PH6qNrSBnf9LQvoFYOKg0V2p7bAG7MkA=; b=t2UqwgbTYLUqYflutT8QfbGV9MkEylmpxCd5suzjLfkD5gr+5WFdOAywlH1AlKFNxB UkSRwKNW0AWc+UZBhgwvatR/wBHSoEbNdBRoJHJXqlPUpan2WMa8l8reqZ5ac+WeDWvP BuEQ6Sn/IEWkQAogjvh5l6msUtSvSiBPb+JvxfXPMX+A6e/5JGUTrb4Vl4Twd9IXpd07 5T/96eEJXeqZ00TIl3aiPI+xRdDpjZE95xHlxREhIhAP3EaGdzVyOm3yGacGO3LcxAAC JpivJt3wPBtzbNzLQeA+0OwvYF+PgLWq/nnUd+zYb6HEGI6RK4/aOf029r2qgPr6whpV QmMA== X-Gm-Message-State: AJaThX684xx4Z8caJWiqYGWhHcitAqfzno5neG5QuyqGPYiizWA9yUXW zrKt5YjUjAtBtNudm4W5dcpjf7IIUi5RKRiQtk9D7A== X-Google-Smtp-Source: ABhQp+TJqKZEnAvfhCPWRuab4IyFXS7rj8e82ee4MyvFINrWT1fYpewP+EkIMdy92aR3O9N5k7uNXkeRqNKU9rO6GeI= X-Received: by 10.157.47.199 with SMTP id b7mr1319969otd.377.1509600621014; Wed, 01 Nov 2017 22:30:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Wed, 1 Nov 2017 22:30:20 -0700 (PDT) In-Reply-To: <20171102052424.6E256B810B3@rfc-editor.org> References: <20171102052424.6E256B810B3@rfc-editor.org> From: Martin Thomson Date: Thu, 2 Nov 2017 16:30:20 +1100 Message-ID: To: "tls@ietf.org" Cc: "Stephan Friedl (sfriedl)" , andreipo@microsoft.com, Adam Langley , "emile.stephan@orange.com" , Kathleen Moriarty , Eric Rescorla , Joseph Salowey , sean+ietf@sn3rd.com, Ilya Grigorik Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] [Technical Errata Reported] RFC7301 (5176) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 05:30:24 -0000 I don't think that this is an appropriate way to request the addition of ALPN labels. If it is important to register ALPN labels for these protocols, then the HTTP working group can produce a short document defining them. On Thu, Nov 2, 2017 at 4:24 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC7301, > "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5176 > > -------------------------------------- > Type: Technical > Reported by: Ilya Grigorik > > Section: 6 > > Original Text > ------------- > IANA Considerations > > Corrected Text > -------------- > +Protocol: HTTP/1.0 > +Protocol: HTTP/0.9 > > Notes > ----- > RFC does not register ALPN identifiers for http/0.9 or http/1.0. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7301 (draft-ietf-tls-applayerprotoneg-05) > -------------------------------------- > Title : Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension > Publication Date : July 2014 > Author(s) : S. Friedl, A. Popov, A. Langley, E. Stephan > Category : PROPOSED STANDARD > Source : Transport Layer Security > Area : Security > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Nov 1 22:34:34 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF42C13F5DE for ; Wed, 1 Nov 2017 22:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 fL6mkaGzgmU3 for ; Wed, 1 Nov 2017 22:34:30 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 0A5841375C9 for ; Wed, 1 Nov 2017 22:34:30 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id j58so5300781qtj.0 for ; Wed, 01 Nov 2017 22:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5JEaOtugOPznW25txzZxbSsVFK79oyhYYlo4Sq/teTI=; b=OY0ux0KmDqyi9aWrRQR8q+WYTpV4qezXm4SWBpFEZD5A62QPPvdj0XoVxHfxqQaP2c gUStdD/wAOGFDRtZ8cNxn8pgiy9J8lP12ylAm5b2SO9UkMw+AvJKV4xiCOLWaF3Vja7v jvp9k8OdOf/B1yRM91qyMoZniMCxdIT8XF9UMVzcYCFOXm6EB7j2J/EhgfgyhrLTIagY UzNS7gWQ2TVEJE6luAeKbud3PGVAKEBFGPyFS7E8gBqYz2v7UBL16Vzcqw9vOf+7D9sA zywm2fSN0vV91oMcs9L3xbe8+WEJ+/9o6c5sGUqxTZ+xd3CJvFS73KYgjgnnLuEKkog8 U6jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5JEaOtugOPznW25txzZxbSsVFK79oyhYYlo4Sq/teTI=; b=n+41sjaMcLAEQXnbC2+jnoBrGkNl60PqykSiLnjZDfCy32Dl8nIN9YWgIGENB9uI45 0hBjhiBsorp2F7ad8fM54/vCNxITM8h7QRG+sSxALmuAMYLpQT9BFREv8r4dstvXvLNx O0tkOD66NLprmjNVNKaSVIkoV/BVxiB3VtM4j9Eba8Piij3Kma6yReOFdT/RzpjN/zh7 m1iAar1oFDvwbCmFqDuVu8OLz14+ltaG3K7MsgEtFQ0PytyEw9YMIlYi7jl5IMQqGuIZ wea1MeGhzfMoawN+uOVW2VbNrcWuHCUlanpvRBJn/Ojm88qpq/YHpyFpfw6goasWeiUD qUpg== X-Gm-Message-State: AMCzsaWrY0FLP7b1+84kgvRPWSMwENCUI/4I2xtc9fCuqLXDgDhDQeff SSqqlraW7X1UgtDKE6tULuOxjH4gsIOXRsDGLVI= X-Google-Smtp-Source: ABhQp+QIYBSwr8gAp311ALmf395U46qE+C6j5pGKrFUNg0scOKCcypGNo578RPmzAyEiisMi02szVbQCfbwjT1twr2Q= X-Received: by 10.200.19.7 with SMTP id e7mr3527599qtj.192.1509600868865; Wed, 01 Nov 2017 22:34:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.19.107 with HTTP; Wed, 1 Nov 2017 22:33:48 -0700 (PDT) In-Reply-To: References: <20171102052424.6E256B810B3@rfc-editor.org> From: Ilya Grigorik Date: Wed, 1 Nov 2017 22:33:48 -0700 Message-ID: To: Martin Thomson Cc: "tls@ietf.org" , "Stephan Friedl (sfriedl)" , andreipo@microsoft.com, Adam Langley , "emile.stephan@orange.com" , Kathleen Moriarty , Eric Rescorla , Joseph Salowey , sean+ietf@sn3rd.com, Mark Nottingham Content-Type: multipart/alternative; boundary="089e0828d8608a9b81055cf957b3" Archived-At: Subject: Re: [TLS] [Technical Errata Reported] RFC7301 (5176) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 05:34:32 -0000 --089e0828d8608a9b81055cf957b3 Content-Type: text/plain; charset="UTF-8" Wasn't sure what the appropriate route is.. apologies for the noise. :-) Should I file a bug against http-wg ? On Wed, Nov 1, 2017 at 10:30 PM, Martin Thomson wrote: > I don't think that this is an appropriate way to request the addition > of ALPN labels. If it is important to register ALPN labels for these > protocols, then the HTTP working group can produce a short document > defining them. > > On Thu, Nov 2, 2017 at 4:24 PM, RFC Errata System > wrote: > > The following errata report has been submitted for RFC7301, > > "Transport Layer Security (TLS) Application-Layer Protocol Negotiation > Extension". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata/eid5176 > > > > -------------------------------------- > > Type: Technical > > Reported by: Ilya Grigorik > > > > Section: 6 > > > > Original Text > > ------------- > > IANA Considerations > > > > Corrected Text > > -------------- > > +Protocol: HTTP/1.0 > > +Protocol: HTTP/0.9 > > > > Notes > > ----- > > RFC does not register ALPN identifiers for http/0.9 or http/1.0. > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC7301 (draft-ietf-tls-applayerprotoneg-05) > > -------------------------------------- > > Title : Transport Layer Security (TLS) Application-Layer > Protocol Negotiation Extension > > Publication Date : July 2014 > > Author(s) : S. Friedl, A. Popov, A. Langley, E. Stephan > > Category : PROPOSED STANDARD > > Source : Transport Layer Security > > Area : Security > > Stream : IETF > > Verifying Party : IESG > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > --089e0828d8608a9b81055cf957b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Wasn't sure what the appropriate route is.. apologies = for the noise. :-)

Should I file a bug against http-wg?


On Wed, Nov 1, 2017 at 10:30 PM, Martin Thomson <= martin.thomson@gmail.com> wrote:
I don't think that this is an appropriate way to request the addi= tion
of ALPN labels.=C2=A0 If it is important to register ALPN labels for these<= br> protocols, then the HTTP working group can produce a short document
defining them.

On Thu, Nov 2, 2017 at 4:24 PM, RFC Errata System
<rfc-editor@rfc-editor.org<= /a>> wrote:
> The following errata report has been submitted for RFC7301,
> "Transport Layer Security (TLS) Application-Layer Protocol Negoti= ation Extension".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5176
>
> --------------------------------------
> Type: Technical
> Reported by: Ilya Grigorik <= igrigorik@gmail.com>
>
> Section: 6
>
> Original Text
> -------------
> IANA Considerations
>
> Corrected Text
> --------------
> +Protocol:=C2=A0 HTTP/1.0
> +Protocol:=C2=A0 HTTP/0.9
>
> Notes
> -----
> RFC does not register ALPN identifiers for http/0.9 or http/1.0.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary= , please
> use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC7301 (draft-ietf-tls-applayerprotoneg-05)
> --------------------------------------
> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Transpor= t Layer Security (TLS) Application-Layer Protocol Negotiation Extension
> Publication Date=C2=A0 =C2=A0 : July 2014
> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: S. Friedl, A. Popo= v, A. Langley, E. Stephan
> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD<= br> > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Transport Lay= er Security
> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security=
> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

--089e0828d8608a9b81055cf957b3-- From nobody Wed Nov 1 22:54:11 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36EB13F857 for ; Wed, 1 Nov 2017 22:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 GSsWSVseXczS for ; Wed, 1 Nov 2017 22:54:08 -0700 (PDT) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::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 040C813F5F5 for ; Wed, 1 Nov 2017 22:54:08 -0700 (PDT) Received: by mail-ot0-x22f.google.com with SMTP id 96so646695otw.11 for ; Wed, 01 Nov 2017 22:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+Z4PwGOqPU2FTx89aLJdwwIMyVD1qCoYFfU04U/fdHc=; b=tBpDffgH04YikpWlLfNV4RRxxVVo5kZq6m6HLj+/z1NeZHohC5jHv2LNK4giW0F392 gfWCtSMXLzzIJAm78cQZXEOZj0EA/9wV57W1BUmFpmC1SuSv7CWjvqj+BbD7nRjqoPER gHYgb5XhPb/DevnkTBxVkNxs8ZfSCFbW/mOPHxj7U7DYfdpJ/NFanTjWAf0PrhhEZwfi qglr2oz9uu1gE7cPBzgpqq3FVWnmmBPLE+PhcOOH2C7J+1/qj5A1FQANsrpc++ChrPuz 9zOhRwS9Hhy85RZqnaZJeB8Wq+pofKIT9LE7TN1T930mfQNEbUA8ZSoEfJO1nKxxg75W Xv0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+Z4PwGOqPU2FTx89aLJdwwIMyVD1qCoYFfU04U/fdHc=; b=ijb/zb3Jhgk0X5juzvFxOPzNOSJ+7RlOosjIgMAGIvlxi9Uh3Y1riZLT+loprBoWMw XlFgfRk/qyZZGPx/+k3rSwI+2RcnaDzstWsjVo7l58Sk+cpj7Dyb0PY3eVwHnLHJ6uYo TcdkqKz9mSBi4v0JZ2ZDvMCoRCWJAsZZ1UnuWdW3Qx5g1ceMLGUPaLZ0ZIwBd5v/D6dA eN0NSbfISrWC6fEtzo3OOJgTIB/2D72lvdejkAsnlOC3qPbZwwiU+xRmjU5N7T3iOVIL 1Z7gDVjtenbvTSSw4bqcmdcHhsJ3VMjiUvWnBAjqj2/6BOlJ9gaCUd333RcCOOE5bY3l F5nw== X-Gm-Message-State: AJaThX4MfDWDleijOxlME1H7lZlPRfZV1R2O/5G3lhdisr2iNtaNR7R1 kamoBrzhQRs0uRe79QWnW2Sr5ZilF/9uYSCs14k= X-Google-Smtp-Source: ABhQp+ShCIfvsXps4o2maUTiFS4lXAyy2gWwRmMGy7h2rCBX41phwWNunF58cHeF466nl2WWGotfsAqXSkoAg9m+wzw= X-Received: by 10.157.37.90 with SMTP id j26mr1582182otd.401.1509602047192; Wed, 01 Nov 2017 22:54:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Wed, 1 Nov 2017 22:54:06 -0700 (PDT) In-Reply-To: References: <20171102052424.6E256B810B3@rfc-editor.org> From: Martin Thomson Date: Thu, 2 Nov 2017 16:54:06 +1100 Message-ID: To: Ilya Grigorik Cc: "tls@ietf.org" , "Stephan Friedl (sfriedl)" , andreipo@microsoft.com, Adam Langley , "emile.stephan@orange.com" , Kathleen Moriarty , Eric Rescorla , Joseph Salowey , sean+ietf@sn3rd.com, Mark Nottingham Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] [Technical Errata Reported] RFC7301 (5176) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 05:54:10 -0000 Maybe you should start by sending an email to the working group, explaining why you think that this is necessary. Because the way to change these things ultimately is to publish an RFC. On Thu, Nov 2, 2017 at 4:33 PM, Ilya Grigorik wrote: > Wasn't sure what the appropriate route is.. apologies for the noise. :-) > > Should I file a bug against http-wg? > > > > On Wed, Nov 1, 2017 at 10:30 PM, Martin Thomson > wrote: >> >> I don't think that this is an appropriate way to request the addition >> of ALPN labels. If it is important to register ALPN labels for these >> protocols, then the HTTP working group can produce a short document >> defining them. >> >> On Thu, Nov 2, 2017 at 4:24 PM, RFC Errata System >> wrote: >> > The following errata report has been submitted for RFC7301, >> > "Transport Layer Security (TLS) Application-Layer Protocol Negotiation >> > Extension". >> > >> > -------------------------------------- >> > You may review the report below and at: >> > http://www.rfc-editor.org/errata/eid5176 >> > >> > -------------------------------------- >> > Type: Technical >> > Reported by: Ilya Grigorik >> > >> > Section: 6 >> > >> > Original Text >> > ------------- >> > IANA Considerations >> > >> > Corrected Text >> > -------------- >> > +Protocol: HTTP/1.0 >> > +Protocol: HTTP/0.9 >> > >> > Notes >> > ----- >> > RFC does not register ALPN identifiers for http/0.9 or http/1.0. >> > >> > Instructions: >> > ------------- >> > This erratum is currently posted as "Reported". If necessary, please >> > use "Reply All" to discuss whether it should be verified or >> > rejected. When a decision is reached, the verifying party >> > can log in to change the status and edit the report, if necessary. >> > >> > -------------------------------------- >> > RFC7301 (draft-ietf-tls-applayerprotoneg-05) >> > -------------------------------------- >> > Title : Transport Layer Security (TLS) Application-Layer >> > Protocol Negotiation Extension >> > Publication Date : July 2014 >> > Author(s) : S. Friedl, A. Popov, A. Langley, E. Stephan >> > Category : PROPOSED STANDARD >> > Source : Transport Layer Security >> > Area : Security >> > Stream : IETF >> > Verifying Party : IESG >> > >> > _______________________________________________ >> > TLS mailing list >> > TLS@ietf.org >> > https://www.ietf.org/mailman/listinfo/tls > > From nobody Thu Nov 2 06:57:47 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74B013F60C for ; Thu, 2 Nov 2017 06:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 ecztAHINXa4U for ; Thu, 2 Nov 2017 06:57:44 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 CC43F13F56A for ; Thu, 2 Nov 2017 06:57:43 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id t71so4850080ywc.3 for ; Thu, 02 Nov 2017 06:57:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1Pkt2fJUu9GeZb0sReyBkFWzk0bimZnWXSPvaLt679o=; b=j8u0o1lc5qahSTDq/R/ngYcH0tNBQ4GFHTCtSRjdan8AaumTMbpPxFab4pqN5reQnf RB+6YM8O6f+5ZZfnL2k2GpnPs1PxTcBuWCTYFErYWECXMZj+n4tQ1Lv42C8Si0b8JpZ5 V5ifDnW5MCH7512p7zVA0kQR5E+jxITVztXJ3zv8iUN5ikjyT7YoUchdKZTyL9XpCTLs rrUindQhoEbv12O9ijQczSmNczzDT5qJrwUqu+3h76ZMoFr0wj7cmul62hyxMu/JX5Nw c65oc774dTfpe7J2pHf8w5fqPKO2A6EDJ7QZFJteQ/k43pGoCHEP2t8NBQKhq7KLSBfU ISOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1Pkt2fJUu9GeZb0sReyBkFWzk0bimZnWXSPvaLt679o=; b=hbEGACUlNrq5xzh8YuEqz7ZEBrNjuwklt6ik9ZFHZbF6gL7yxaJKTNZiVc3Pa8svLE 15U8RWW8MZZ8uO7bsOvuIze32XH4z9FfMYIZPhJlMxFH6JOPY4mtpLmbGq/TqOj5H+1E oqQdoGTsPsbbo2t+91mHlUBqOCWONwblLQpbcH9Ct+9aPOwwACW+aH3wOCGm21aIbWiJ QOX5GF8liY4Rf4z+PaU1sItIAAydL8c2bx86A7XAQHO2w+1TwrijHdHQQjpEkRcYXZQf x8ohrgIfFwCwnFBN6oS9AndlBmejAEUATuDCiV09KbWjQWaA2KCVtDy6YPM/6xwlGzeH 7j8Q== X-Gm-Message-State: AMCzsaVHQEFtqNKy5/iH7Ze/ZflvwR00RLP1xpklIX2cycWOyIpComJ4 vES5eLGOqZbHIKzSg2NRrIwHXyXwHjJYN5sZMpk/FQ== X-Google-Smtp-Source: ABhQp+SNvgTGRqI90Jp079Tmg/cDXeM/ASe92jM31SEh0Ru7HAQBWkxg6ps0vAETwSD2SgDrkFO6Gc5bQveYh9vdzAo= X-Received: by 10.37.83.66 with SMTP id h63mr2160457ybb.397.1509631063051; Thu, 02 Nov 2017 06:57:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.61.12 with HTTP; Thu, 2 Nov 2017 06:57:02 -0700 (PDT) In-Reply-To: References: <20171102052424.6E256B810B3@rfc-editor.org> From: Eric Rescorla Date: Thu, 2 Nov 2017 06:57:02 -0700 Message-ID: To: Ilya Grigorik Cc: Martin Thomson , "tls@ietf.org" , "Stephan Friedl (sfriedl)" , andreipo@microsoft.com, Adam Langley , "emile.stephan@orange.com" , Kathleen Moriarty , Joseph Salowey , sean+ietf@sn3rd.com, Mark Nottingham Content-Type: multipart/alternative; boundary="001a113e688e4165bc055d005fb3" Archived-At: Subject: Re: [TLS] [Technical Errata Reported] RFC7301 (5176) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 13:57:46 -0000 --001a113e688e4165bc055d005fb3 Content-Type: text/plain; charset="UTF-8" See: https://tools.ietf.org/html/rfc7301#section-6 " This registry operates under the "Expert Review" policy as defined in [RFC5226 ]. The designated expert is advised to encourage the inclusion of a reference to a permanent and readily available specification that enables the creation of interoperable implementations of the identified protocol." And then see: https://tools.ietf.org/html/rfc8126#section-1.2 And finally: https://www.iana.org/help/protocol-registration -Ekr On Wed, Nov 1, 2017 at 10:33 PM, Ilya Grigorik wrote: > Wasn't sure what the appropriate route is.. apologies for the noise. :-) > > Should I file a bug against http-wg > ? > > > > On Wed, Nov 1, 2017 at 10:30 PM, Martin Thomson > wrote: > >> I don't think that this is an appropriate way to request the addition >> of ALPN labels. If it is important to register ALPN labels for these >> protocols, then the HTTP working group can produce a short document >> defining them. >> >> On Thu, Nov 2, 2017 at 4:24 PM, RFC Errata System >> wrote: >> > The following errata report has been submitted for RFC7301, >> > "Transport Layer Security (TLS) Application-Layer Protocol Negotiation >> Extension". >> > >> > -------------------------------------- >> > You may review the report below and at: >> > http://www.rfc-editor.org/errata/eid5176 >> > >> > -------------------------------------- >> > Type: Technical >> > Reported by: Ilya Grigorik >> > >> > Section: 6 >> > >> > Original Text >> > ------------- >> > IANA Considerations >> > >> > Corrected Text >> > -------------- >> > +Protocol: HTTP/1.0 >> > +Protocol: HTTP/0.9 >> > >> > Notes >> > ----- >> > RFC does not register ALPN identifiers for http/0.9 or http/1.0. >> > >> > Instructions: >> > ------------- >> > This erratum is currently posted as "Reported". If necessary, please >> > use "Reply All" to discuss whether it should be verified or >> > rejected. When a decision is reached, the verifying party >> > can log in to change the status and edit the report, if necessary. >> > >> > -------------------------------------- >> > RFC7301 (draft-ietf-tls-applayerprotoneg-05) >> > -------------------------------------- >> > Title : Transport Layer Security (TLS) Application-Layer >> Protocol Negotiation Extension >> > Publication Date : July 2014 >> > Author(s) : S. Friedl, A. Popov, A. Langley, E. Stephan >> > Category : PROPOSED STANDARD >> > Source : Transport Layer Security >> > Area : Security >> > Stream : IETF >> > Verifying Party : IESG >> > >> > _______________________________________________ >> > TLS mailing list >> > TLS@ietf.org >> > https://www.ietf.org/mailman/listinfo/tls >> > > --001a113e688e4165bc055d005fb3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
See:

" This registry operates under the "Expert Review" = policy as defined in
=C2=A0 =C2=A0[RFC5226]. The designated expert is advised = to encourage the
=C2=A0 =C2=A0inclusion of a reference to a perma= nent and readily available
=C2=A0 =C2=A0specification that enable= s the creation of interoperable
=C2=A0 =C2=A0implementations of t= he identified protocol."

And then see:
<= div>https://too= ls.ietf.org/html/rfc8126#section-1.2

And final= ly:

-Ekr




On Wed, Nov 1, 2017 at 10:33 PM, Ilya Grigorik <= igrigorik@gmail.co= m> wrote:
Wasn't sure what the appropriate route is.. apologie= s for the noise. :-)

Should I file a bug against htt= p-wg?



On Wed, Nov 1, 2017 at 10:30 PM, Martin Thomson <= martin.thomson@gmail.com> wrote:
I don't think that this is an appropriate way = to request the addition
of ALPN labels.=C2=A0 If it is important to register ALPN labels for these<= br> protocols, then the HTTP working group can produce a short document
defining them.

On Thu, Nov 2, 2017 at 4:24 PM, RFC Errata System
<rfc-edit= or@rfc-editor.org> wrote:
> The following errata report has been submitted for RFC7301,
> "Transport Layer Security (TLS) Application-Layer Protocol Negoti= ation Extension".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5176
>
> --------------------------------------
> Type: Technical
> Reported by: Ilya Grigorik <igrigorik@gmail.com>
>
> Section: 6
>
> Original Text
> -------------
> IANA Considerations
>
> Corrected Text
> --------------
> +Protocol:=C2=A0 HTTP/1.0
> +Protocol:=C2=A0 HTTP/0.9
>
> Notes
> -----
> RFC does not register ALPN identifiers for http/0.9 or http/1.0.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary= , please
> use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC7301 (draft-ietf-tls-applayerprotoneg-05)
> --------------------------------------
> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Transpor= t Layer Security (TLS) Application-Layer Protocol Negotiation Extension
> Publication Date=C2=A0 =C2=A0 : July 2014
> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: S. Friedl, A. Popo= v, A. Langley, E. Stephan
> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD<= br> > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Transport Lay= er Security
> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security=
> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


--001a113e688e4165bc055d005fb3-- From nobody Thu Nov 2 07:41:36 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4D313F958 for ; Thu, 2 Nov 2017 07:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 eh-v2JaEttBG for ; Thu, 2 Nov 2017 07:41:34 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 017EA13F90F for ; Thu, 2 Nov 2017 07:41:33 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id vA2EcTdU003220; Thu, 2 Nov 2017 14:41:00 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=9sXUQzl9gpbaZzzMG1HClcLYjSs+HZ9i5+O1kXCqcOw=; b=KP7/1pjXlEC/QqT0l3kOmrpBcgF1mdpUlb3cysCbtsBOOG2+tu79fHT6NRQk40HtCwuf YHCdT9v7C8afChJH344eGwWc13ymWwY+Adie1CjcwzkSKfto/tGEsz+Z+4iMksWltatn HRfqCD3KOrSlQVhW1vouTWyBDg/iczvP6ob20TTM3shEAYt/rq3lhuyk1BNDw8KYLly1 k2GrVthPNqpBgzWUn1HDle2CEn0iy3s/CbOeEH4WSMcLqacgbxDHeNoIR9a542uKBuNs mzP/4sE62R9L+EdSlZloobofPRlqWnLb/frwqAYHxn6rLHsRbjm6b1x6wqHE261hr8BI Mg== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050095.ppops.net-00190b01. with ESMTP id 2dyu101xed-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 02 Nov 2017 14:41:00 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vA2EepWl005827; Thu, 2 Nov 2017 10:40:59 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2dvn7uxvhm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 02 Nov 2017 10:40:59 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 2 Nov 2017 10:40:58 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Thu, 2 Nov 2017 10:40:58 -0400 From: "Salz, Rich" To: Martin Thomson , Ilya Grigorik CC: "Stephan Friedl (sfriedl)" , "sean+ietf@sn3rd.com" , Adam Langley , "tls@ietf.org" , "andreipo@microsoft.com" Thread-Topic: [TLS] [Technical Errata Reported] RFC7301 (5176) Thread-Index: AQHTU5rkuMwEYZyQEkGMEFEePlQiJaMA0zEAgAAA9wCAAAWsAIAAkzUA Date: Thu, 2 Nov 2017 14:40:58 +0000 Message-ID: <3917A0A6-FED6-4C21-907C-317512AE4E21@akamai.com> References: <20171102052424.6E256B810B3@rfc-editor.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.225] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-02_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711020184 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-02_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711020183 Archived-At: Subject: Re: [TLS] [Technical Errata Reported] RFC7301 (5176) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 14:41:35 -0000 DQrinqIgICAgIE1heWJlIHlvdSBzaG91bGQgc3RhcnQgYnkgc2VuZGluZyBhbiBlbWFpbCB0byB0 aGUgd29ya2luZyBncm91cCwNCiAgICBleHBsYWluaW5nIHdoeSB5b3UgdGhpbmsgdGhhdCB0aGlz IGlzIG5lY2Vzc2FyeS4gIEJlY2F1c2UgdGhlIHdheSB0bw0KICAgIGNoYW5nZSB0aGVzZSB0aGlu Z3MgdWx0aW1hdGVseSBpcyB0byBwdWJsaXNoIGFuIFJGQy4NCiAgICANCg0KV2VsbCwgc29tZW9u ZSBtaWdodCBoYXZlIHRvIHdyaXRlIGFuIFJGQy4gIEkgZm9yZ2V0IGRldGFpbHMgb2YgaG93IHRo aXMgcmVnaXN0cnkgd2FzIHNldCB1cC4gIEl0IG1pZ2h0IGJlIGFzIHNpbXBsZSBhcyBzb21lb25l IHNheWluZyDigJx5dXDigJ0NCg0K From nobody Thu Nov 2 07:46:18 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4D813FA2E for ; Thu, 2 Nov 2017 07:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 wrFQAVFcR2Ih for ; Thu, 2 Nov 2017 07:46:15 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 EFA1213FA17 for ; Thu, 2 Nov 2017 07:46:13 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id k11so5001923ywh.1 for ; Thu, 02 Nov 2017 07:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7f6BKlwXtQOgneYSIIJ5EGtlrR3ljxlXKEvdBPbWPR8=; b=tgjte+ag0vnq0K25meMrztsSowoI6Infl7qVlsC0hm5Z17U/tQQ8PZgnr1WSNmBm9t kzYaPO+hxjNy5cACArQXxeEcixltvj/8ACbxehQNnSgJkr6DW5zJHwWOKIgnkXFs4ty5 m01VfQR85EwlvoypsXhnj+ZewxABILkPG9HZh1uXN50g6HPiR+jX6KlJ/kMroK//gzCs fyPfZKh8VFhCdN+dVL6L/O5NYy6lpU8SYKIihMtWa6olF1OkschJkKWULCdr3WR6B9+y aDWc3W0DL1wWGkVy4wUvyJ5M5OYXLFqYqDGzsaRr/wIgERpI4rBD9fLcblmTBHTwMALB DI2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7f6BKlwXtQOgneYSIIJ5EGtlrR3ljxlXKEvdBPbWPR8=; b=Om6XlowY4TudMWotjZhtRkKxM4J93q4nW0ysBz4PrnxhRNUjyNRaTmpd8qjd0OsVwp oQQAHs2AyzAjMmFgX0YQrHc67tRMkn3HJXnCH5MrLFfptJnATEXNbKjYv+OZdOmUvFHN hF8tSTCZHmbDM1SeJKvyTpGakxH8RUIqpy6qSlQ8GyG2pkmvfZwIzAIIwNYffPxrZV4U yCQZqRRWqXHU03TklTqCmRUqFmK+NC5SMQYlHDMK4ot3QHk8T+e3QOLI09C6hgO8ipeJ cZI5jH18qu7NIrjQNGQ2B5V7WrTqPx+nZAvFvlaf3ZJ5GcdgFb4tpO5RtOTGieeF9uRq jBnw== X-Gm-Message-State: AMCzsaU0NrfO9FDWiDog8pssBZ8WKjX70ZRHFNKuZIRO6+eXYmpxXXqa jS+un8B1tz2FXXzPNfat746IHiACKLt8+L5TbfDsYg== X-Google-Smtp-Source: ABhQp+T9PR7VBPUWOUERXRQ8NidjXH/GLoCT8ZddJWROTDEn/3EXfsNxDq7uIarCoK94tAUBDwCKDRjHSQAWLn5CBVM= X-Received: by 10.37.22.8 with SMTP id 8mr2501077ybw.353.1509633973209; Thu, 02 Nov 2017 07:46:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.61.12 with HTTP; Thu, 2 Nov 2017 07:45:32 -0700 (PDT) In-Reply-To: <3917A0A6-FED6-4C21-907C-317512AE4E21@akamai.com> References: <20171102052424.6E256B810B3@rfc-editor.org> <3917A0A6-FED6-4C21-907C-317512AE4E21@akamai.com> From: Eric Rescorla Date: Thu, 2 Nov 2017 07:45:32 -0700 Message-ID: To: "Salz, Rich" Cc: Martin Thomson , Ilya Grigorik , "sean+ietf@sn3rd.com" , "Stephan Friedl (sfriedl)" , "tls@ietf.org" , Adam Langley , "andreipo@microsoft.com" Content-Type: multipart/alternative; boundary="001a11416718b6d95e055d010c9d" Archived-At: Subject: Re: [TLS] [Technical Errata Reported] RFC7301 (5176) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 14:46:17 -0000 --001a11416718b6d95e055d010c9d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It's Expert Review with the requirement being a stable reference. -Ekr On Thu, Nov 2, 2017 at 7:40 AM, Salz, Rich wrote: > > =E2=9E=A2 Maybe you should start by sending an email to the working g= roup, > explaining why you think that this is necessary. Because the way to > change these things ultimately is to publish an RFC. > > > Well, someone might have to write an RFC. I forget details of how this > registry was set up. It might be as simple as someone saying =E2=80=9Cyu= p=E2=80=9D > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11416718b6d95e055d010c9d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's Expert Review with the requirement being a stable= reference.

-Ekr


On Thu, Nov 2, 2017 at 7:40 AM= , Salz, Rich <rsalz@akamai.com> wrote:

=E2=9E=A2=C2=A0 =C2=A0 =C2=A0Maybe you should start by sending an email to = the working group,
=C2=A0 =C2=A0 explaining why you think that this is necess= ary.=C2=A0 Because the way to
=C2=A0 =C2=A0 change these things ultimately is to publish an RFC.


Well, someone might have to write an RFC.=C2=A0 I forget details of = how this registry was set up.=C2=A0 It might be as simple as someone saying= =E2=80=9Cyup=E2=80=9D

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

--001a11416718b6d95e055d010c9d-- From nobody Thu Nov 2 07:52:14 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED9313FA92 for ; Thu, 2 Nov 2017 07:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 M7k_ny8bS1t2 for ; Thu, 2 Nov 2017 07:52:11 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 75A8713FA8E for ; Thu, 2 Nov 2017 07:52:11 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id f199so6474800qke.2 for ; Thu, 02 Nov 2017 07:52:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Gpu1qOHqYyLZcdTSzaf7JOmLMM1xybXIUm76EioPJGw=; b=FmhXhIplkexVnb0wrPiRbLcJ8nNFfladfcRzAo0m0AzRfOKxC6q6UfbC2KhrNye6LZ 0uxBBqOijoI2O+i6TxuwH4RgKVYg4OwEU+edG2ERC3isvuPlBl4hdK/KI129d2qNvm5Y neRrFHn+L4rALGia/N7R+gr76JxP/atknyJIg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Gpu1qOHqYyLZcdTSzaf7JOmLMM1xybXIUm76EioPJGw=; b=YRLHNXrm7jIhWv31JFH7mqySKpBEuG1WQerbz0mpbOELdA2pfuuMqSFrmZXnASSXV3 TwzcXgH19BsbecyMBu4nHpSXd02mbIqWIEFPur8oV0lL6gqN86UNKaj2eSVoe8PoDXTE kYBHn3c7/wjziotsZiQsmuUt6Kc/rI2uhQppwXXN2UBZF+JYwZmpptCappPi4sxd1V8Z 3q2fJlpu1g3yzmjd3Tba3KtKR580inDwHdi/BnOzTStvZJQVjhMR3vQV+1/aLlLBUD0F KjhxEt+OUkNNmEjCB39bA7RJUqHgLPb4ey9xrot1LZV/4eV8GDSQE5NgT1z7W/COStHx Z8wA== X-Gm-Message-State: AMCzsaWC03aQ3XZHqpHn7f+c7xvCa+eQNoHh6AfciK1hAKgDApzhNf22 Z0D28j7L+LsjLwNEGDcQk16wOxuNw8Y= X-Google-Smtp-Source: ABhQp+Qptg9GENDMRE4xXLzXqhCo8pdNkzKReTyBkbOAACkKHvl9aTIod28FgInbZBgal4p6Fe38xw== X-Received: by 10.55.209.86 with SMTP id s83mr5291156qki.145.1509634330562; Thu, 02 Nov 2017 07:52:10 -0700 (PDT) Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id m65sm2149916qkl.87.2017.11.02.07.52.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Nov 2017 07:52:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: Date: Thu, 2 Nov 2017 10:52:08 -0400 Cc: Rich Salz , Martin Thomson , Ilya Grigorik , "sean+ietf@sn3rd.com" , "Stephan Friedl (sfriedl)" , "tls@ietf.org" , Adam Langley , "andreipo@microsoft.com" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20171102052424.6E256B810B3@rfc-editor.org> <3917A0A6-FED6-4C21-907C-317512AE4E21@akamai.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] [Technical Errata Reported] RFC7301 (5176) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 14:52:14 -0000 yep > On Nov 2, 2017, at 10:45, Eric Rescorla wrote: >=20 > It's Expert Review with the requirement being a stable reference. >=20 > -Ekr >=20 >=20 > On Thu, Nov 2, 2017 at 7:40 AM, Salz, Rich wrote: >=20 > =E2=9E=A2 Maybe you should start by sending an email to the = working group, > explaining why you think that this is necessary. Because the way = to > change these things ultimately is to publish an RFC. >=20 >=20 > Well, someone might have to write an RFC. I forget details of how = this registry was set up. It might be as simple as someone saying = =E2=80=9Cyup=E2=80=9D >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 From nobody Thu Nov 2 09:32:27 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E0B13F5BA for ; Thu, 2 Nov 2017 09:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=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 fT-gLNa91sB2 for ; Thu, 2 Nov 2017 09:32:23 -0700 (PDT) Received: from mta.openssl.org (mta.openssl.org [IPv6:2001:608:c00:180::1:e6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59DB413B262 for ; Thu, 2 Nov 2017 09:32:22 -0700 (PDT) Received: from [10.51.10.6] (unknown [104.238.169.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta.openssl.org (Postfix) with ESMTPSA id 0A7BAE66A4 for ; Thu, 2 Nov 2017 16:32:19 +0000 (UTC) To: tls@ietf.org References: From: Matt Caswell Message-ID: <4833b54e-880b-c2c4-99ed-4dde0c96fc5c@openssl.org> Date: Thu, 2 Nov 2017 16:32:18 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 16:32:25 -0000 On 17/10/17 22:35, Martin Thomson wrote: > On Tue, Oct 17, 2017 at 9:26 PM, Fossati, Thomas (Nokia - > GB/Cambridge, UK) wrote: >> The following case (NAT box reboot) is problematic: >> >> 1. Application '1' on host A (A.1) uses DTLS+CID with application '1' on >> host B (B.1); >> 2. Application '2' on host A (A.2) uses plain-old DTLS with B.1; >> 3. The NAT box reboots (all previous 5-tuple mappings are lost); >> 4. B.1 receives a record from A.1 (whose 5-tuple has changed in the >> meanwhile); >> >> How is B.1 supposed to correctly interpret the bytes starting at offset >> +11? (For what it knows, it could be CID from A.1 or the length field >> from A.2.) > > I don't think that this is a problem. > > connection = five_tuples.lookup(packet.five_tuple) > if (!connection) { > connection = connection_ids.lookup(packet[connection_id_offset:connection_id_offset+connection_id_length]) > } Just skimming this old thread...doesn't this fail in the case where the five tuple has been reused? In that case five_tuples.lookup will return an old stale connection which the server thinks is still valid so we never get to lookup the connection id. With an explicit marking we would not fail in this scenario. Matt From nobody Thu Nov 2 09:37:41 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337DC13F729 for ; Thu, 2 Nov 2017 09:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 cHTRNALCPKzU for ; Thu, 2 Nov 2017 09:37:37 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 4C9BB13F73B for ; Thu, 2 Nov 2017 09:37:37 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id n5so125236qke.11 for ; Thu, 02 Nov 2017 09:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=6yl/leI+hidTRqL1tkaz0U4m59vZ5ZfRXtfTfc8GPPQ=; b=ZdLWlwpf3vKmc2NXP8qQr+Ab0yRxycHc6f7zAvGUUxzVOEBIZ10fd6L2jKIUqf6Cuo IO4H7SmTo7dhnys4F0NKGTT+rRezwEyLUADElOw7VKu2Bt7JE/DpGfoUvdJtadZMzzlU MRVPKzA+41ZRGE/0vekMGkNG/xoOkx8jS73LM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=6yl/leI+hidTRqL1tkaz0U4m59vZ5ZfRXtfTfc8GPPQ=; b=K5idOgp3xVZ5eHjFu9kz5c+UYxlQLwUoQPbLPxB1TEmRmfD0BKp5b1l4mes2YhmVJU RZUsCqgaj3SX4v51wm9CYG1edVibEmXAP69hBcLDo+gTxSTHNcrQczbIHSHEraLbX4P5 eTudAYXXAjG4zwkdG9PgG9QtWH2xjxXdiCmX+obgoMtABE0qA5npKk98/SCnFlI1knSS x9hsk5FM67P+BgpE7CTSDWRRmVtuIYi25y9Zj0Sx73cDiH6CegFeTwNHAL41fHzYP4a7 9TqHaSic2nxnQ49OQghC18Ay1noTgMloNkGzRQDopt3zsof2HTp8FxtFB10IIb5vh5tR B8tA== X-Gm-Message-State: AJaThX68TtOofdjF36s2z23x6jiAF/iXS+jjqOAWUG4vbQD+4CLBNg5p LZnIJt/V4BKuVoMG3iz470se86mIeVM= X-Google-Smtp-Source: ABhQp+SlzIyS34upSwS059appndfI7w5uMIM/C7yygxhkDiD1ZkFhPeYoJuJvKQVXicX18z4HaxujA== X-Received: by 10.55.102.215 with SMTP id a206mr5765036qkc.269.1509640654839; Thu, 02 Nov 2017 09:37:34 -0700 (PDT) Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id v12sm2312406qkl.43.2017.11.02.09.37.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Nov 2017 09:37:34 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 2 Nov 2017 12:37:33 -0400 References: <732B27C6-817B-4F02-BF5D-0EDCBDB91793@sn3rd.com> To: "" In-Reply-To: <732B27C6-817B-4F02-BF5D-0EDCBDB91793@sn3rd.com> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] TLS@IETF100: Agenda Requests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 16:37:39 -0000 All, Due to some unforeseen circumstances neither author of = draft-rhrd-tls-tls13-visibility is able to attend IETF 100. As a = result, they=E2=80=99ve withdrawn their request for agenda time. Based on agenda requests received to date, we also believe that we will = only need the 2.5 hour session on Wednesday. We will shortly submit a = request to the secretariat to cancel that session to allow others to = claim that time. J&S > On Oct 24, 2017, at 12:32, Sean Turner wrote: >=20 > All, >=20 > You will have seen that the chairs requested two sessions for IETF 100 = TLS (on 20170929) and you will have also seen the that our request was = granted (on 20171020). The sessions are currently scheduled as follows: >=20 > tls Session 1 (2:30:00) > Thursday, Morning Session I 0930-1200 > Room Name: Canning size: 250 > --------------------------------------------- > tls Session 2 (1:00:00) > Monday, Afternoon Session III 1740-1840 > Room Name: Padang size: 300 > --------------------------------------------- >=20 > We would like to get a sense of who wants to request agenda time so = please send in your requests by 20171029; this will give the chairs time = to upload a draft agenda due on 20171030. Along with your request = please let us know how long you would like. >=20 > NOTE: Those that have already submitted requests need not do so again. >=20 > J&S From nobody Thu Nov 2 09:38:45 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22FD013F73B for ; Thu, 2 Nov 2017 09:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 rgxnMIoIIp75 for ; Thu, 2 Nov 2017 09:38:41 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 4258113F724 for ; Thu, 2 Nov 2017 09:38:41 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id z28so124191qtz.13 for ; Thu, 02 Nov 2017 09:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=5Xy1uICXhN7G9Onc4qVbEz9XykQE4aEQYU6mLkP//5s=; b=jtwkZR/uPaQ2L2KtSlTkbAH77knIZQdzH2AhI0s1comFjwf48hgNYMourBDeZp38zs q8matzossjTeVCCYFWbwBKk163KCdKgF6CTzPS1FQvAOPCzpTOhrj/U7sGGHgyOXcoUb 3/VTVytmlXiNcyJqJ+QN0BiAoK6rfEigE3sTc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=5Xy1uICXhN7G9Onc4qVbEz9XykQE4aEQYU6mLkP//5s=; b=RtYy/aETnFu4QPg8FCcCWd2YGQXrGLNnqeBQq4JZtysZ92l0vRq0OO8JFfYmf6xhld pOZuH4fIqfe+UibvKDHSpCHkWfBQa18+5FTpF9/MuiP71utad0pqtPol8JoQHLbyyZyr jG47aJ0YH88tVs+H6CK4o7BSInkjhTb54GBbHUIm2JOlLKtF2VOkCpub+5OFZq8jt0oT n4wHf8+OErDECPPf1gnJnGYYjhkbpt/oprBPoHDSheDP2WpyqMJxLMIrIVVaVqS+Q+HL Aukpkym6JSV4yMB/e/VzhMQAGKTGEX/2C3kYMGEQt6oGsp2rj3aCA4J3HOE/f+vVZcwF NQMA== X-Gm-Message-State: AMCzsaWeKzFrY/ATW2U02GJH5CpxZ6PSXIE/ZnRrdAPtzURekF5MQrBV qvBelb4NCfdnH2ohgyFrFCF5XJ064Yc= X-Google-Smtp-Source: ABhQp+Sg70P29l/yCEEIGMbLoYq71OQRc//91RShbnw5xlU+n2KO8DJdKxjerGpX/2s85muVmhpQuQ== X-Received: by 10.200.27.221 with SMTP id m29mr6034779qtk.152.1509640720337; Thu, 02 Nov 2017 09:38:40 -0700 (PDT) Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id v12sm2312406qkl.43.2017.11.02.09.38.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Nov 2017 09:38:39 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 2 Nov 2017 12:38:39 -0400 References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> <17ae3ecd-ab72-59ac-c0fd-fb040dc67faa@akamai.com> <403C3386-2B86-45B4-BB6B-B627CBE85B9D@akamai.com> <5D88D34E-E950-40E9-9483-D65D978D2758@akamai.com> To: "tls@ietf.org" In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 16:38:43 -0000 > On Oct 24, 2017, at 12:49, Joseph Salowey wrote: >=20 > As is normal IETF practice, we will be giving this topic agenda time = in Singapore to see if a consensus emerges one way or the other. Just in case you=E2=80=99re following this thread and not the other = administrivia emails, please see my email concerning agenda requests = related to this draft: https://mailarchive.ietf.org/arch/msg/tls/AX5eg4dzS4QBMcNkXK25UCMpFmA spt= From nobody Thu Nov 2 09:40:23 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D2013F724 for ; Thu, 2 Nov 2017 09:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 hYuHZAUAWSZL for ; Thu, 2 Nov 2017 09:40:20 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABC5713F706 for ; Thu, 2 Nov 2017 09:40:20 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vA2GWJ2b023542; Thu, 2 Nov 2017 16:40:18 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=ochv05xWVJdHF9vLZjWnmapHD6+V67NnccDnXad0hn8=; b=EUH2ht3CLzioeu7hyeKruNaPgng8biOXwnF2Kgo+tn7Zg89EMZqYnmD5IfuvtWApsmNu xyr19pgKGYialqWqv4cIZgbTbLF8eQ665MSCKPFfsOopzc3SS2h+7ggFyHcsB6QyrCUa /SpRC30SYi/2X/HS7IO2SaP2y0twkfrspkTMmyhXIlQ+PFH9t5GcbzO9qsMmWM2OtDV2 z5OHOzn2a1xt3itfbyhiEZi0Obogy5VSQSEc5qu6jv6poeQZQxQ3AxGwK8S7Q+y1aC0e c7SkzwEUCzIxvJGE6EUeTiYVZw0o3lRCybAIehe9ruJCOrI3DCslXAc9lBTNcraSrkQR Qg== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2dyu14t9gw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 02 Nov 2017 16:40:17 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vA2Ga4SK016999; Thu, 2 Nov 2017 12:40:17 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2dvn7u78x8-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 02 Nov 2017 12:40:17 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 2 Nov 2017 12:40:16 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 2 Nov 2017 12:40:16 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Thu, 2 Nov 2017 12:40:16 -0400 From: "Salz, Rich" To: Sean Turner , "" Thread-Topic: [TLS] TLS@IETF100: Agenda Requests Thread-Index: AQHTTOWwew2Q2aAdy06XmH3DbvIHJqMBmwaAgAAAv4A= Date: Thu, 2 Nov 2017 16:40:15 +0000 Message-ID: <6B3ADE1C-1019-4C81-BA94-EA3737ADED1A@akamai.com> References: <732B27C6-817B-4F02-BF5D-0EDCBDB91793@sn3rd.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.222] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-02_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711020204 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-02_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 lowpriorityscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711020204 Archived-At: Subject: Re: [TLS] TLS@IETF100: Agenda Requests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 16:40:22 -0000 4p6iIER1ZSB0byBzb21lIHVuZm9yZXNlZW4gY2lyY3Vtc3RhbmNlcyBuZWl0aGVyIGF1dGhvciBv ZiBkcmFmdC1yaHJkLXRscy10bHMxMy12aXNpYmlsaXR5IGlzIGFibGUgdG8gYXR0ZW5kIElFVEYg MTAwLiAgQXMgYSByZXN1bHQsIHRoZXnigJl2ZSB3aXRoZHJhd24gdGhlaXIgcmVxdWVzdCBmb3Ig YWdlbmRhIHRpbWUuDQogICAgDQpJIHRoaW5rIGl0IHdvdWxkIHN0aWxsIGJlIHdvcnRod2hpbGUg dG8gaGF2ZSB0aW1lIGZvciB0aGUgV0cgdG8gc2VlIGlmIGl0IGNhbiBjb21lIHRvIGNvbnNlbnN1 cyBvbiB3aGV0aGVyIG9yIG5vdCB0byBkbyBhbnl0aGluZyBpbiB0aGlzIGFyZWEgYXQgdGhpcyB0 aW1lLg0KDQo= From nobody Thu Nov 2 16:34:09 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E802213F7A6 for ; Thu, 2 Nov 2017 16:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 R7bJU2uB-13h for ; Thu, 2 Nov 2017 16:34:06 -0700 (PDT) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (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 1119013F79E for ; Thu, 2 Nov 2017 16:34:06 -0700 (PDT) Received: by mail-ot0-x232.google.com with SMTP id s88so1052865ota.4 for ; Thu, 02 Nov 2017 16:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Jy5dM01vCHlsoUn1gED0OEE69ef4wHCLl+C7YnG72Ac=; b=RUpkOZyV0u76bntuasjMJ9WSCJ22S9V1uLAr7dIUH+gdNygrjJS5fsX2KI+tNzKgqc l4KMZOfJNoN7x+284ShTEY1sgZaFKvjvrIPPfem6JYbOuC4we2/4OTNWgCJ9lupeZlRj lKXhrtFCgvgc0F1EEUngEypJxI9DwJZILIvYXNL3gW0yBQHRcmmB9sHPQMByF3Lv6Dkj qXCypANkjbkatAWDFRWWwIwPwUvaczSiplGZJuZ6AdeApFdHBbbGkCzhErTBJ3h4gfOh QptHAB42+sOAk9R7gcLqnDaQT5pLWCKATemhv7mRSTPkpMgFJI0G5yE/q2TOjA4W9IXf 62uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Jy5dM01vCHlsoUn1gED0OEE69ef4wHCLl+C7YnG72Ac=; b=DYTzc+4bpDs5c7QWi9vYtuanqv6ROSi/xO8z/JgFAhBk0rdrmypO923uU7Wkto6cPi gHILgXv43TTbh2gLfDZIlJMK+zQMQrm2VThF3h3u98DtyYXJsBAJPKyyRbNI1EXR2DE7 6hDWxt46c4rxO5u095HiEVvU9+0EG0V45NxqJOOaLciY7yrmwfBMNpO5FRmIJElvQU6E cYCTCE6pYOSmDswBiaaUnvscyQ182zd95cDJ/Gs1kgCRRT5tzaofEjwqAeWzMQaeQWYW 9f+BzQu9WV6Es5dR+JUjxXs2pzryp9BnjL7vgFim6G+koQpFgvlBgfqqg6+6IzvTnfMj BsKA== X-Gm-Message-State: AJaThX4o9ZZz7AQIpQG3v6GdeIr101mdw6akctfc9MkjKbXtpWQ8lGWn IiZePI6+NhnQVv7WR8FTLDH4NxVJyL+o7xasK/0= X-Google-Smtp-Source: ABhQp+SjpKGe9o/c0VW3V9pvAoIKktp/vVe8piqvIrcsGFyRkiqLoPlpZ3J/ZCwdJx7WbMukeRDkKqNsKNV3w8jLzSM= X-Received: by 10.157.47.199 with SMTP id b7mr3088459otd.377.1509665645396; Thu, 02 Nov 2017 16:34:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Thu, 2 Nov 2017 16:34:04 -0700 (PDT) In-Reply-To: <4833b54e-880b-c2c4-99ed-4dde0c96fc5c@openssl.org> References: <4833b54e-880b-c2c4-99ed-4dde0c96fc5c@openssl.org> From: Martin Thomson Date: Fri, 3 Nov 2017 10:34:04 +1100 Message-ID: To: Matt Caswell Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 23:34:08 -0000 On Fri, Nov 3, 2017 at 3:32 AM, Matt Caswell wrote: > Just skimming this old thread...doesn't this fail in the case where the > five tuple has been reused? In that case five_tuples.lookup will return > an old stale connection which the server thinks is still valid so we > never get to lookup the connection id. With an explicit marking we would > not fail in this scenario. I'm assuming that once a connection is closed (or moved), the entry is removed. There's some fudging needed there for migrations (it might be in two places at once for a while), but I don't see a significant problem. (Note that I didn't include the update parts of this code - when a packet decrypts successfully, you need to update the five_tuples list.) From nobody Thu Nov 2 18:12:43 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1335813FAF1 for ; Thu, 2 Nov 2017 18:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 7srWvAeGNXFy for ; Thu, 2 Nov 2017 18:12:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00FDB13FAF3 for ; Thu, 2 Nov 2017 18:12:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRX66209; Fri, 03 Nov 2017 01:12:37 +0000 (GMT) Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 3 Nov 2017 01:12:37 +0000 Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.204]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0361.001; Fri, 3 Nov 2017 09:12:32 +0800 From: yinxinxing To: Matt Caswell , Martin Thomson CC: "tls@ietf.org" Thread-Topic: [TLS] Connection ID Draft Thread-Index: AdNUQFDyStmyp7iqRDGhOkJFQ/YFTQ== Date: Fri, 3 Nov 2017 01:12:31 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.225.248] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0204.59FBC286.0067, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.204, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f4e239171d64f650785ae4a1845856df Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 01:12:42 -0000 SSBhZ3JlZSB3aXRoIE1hdHQuIFRoZSBwb3J0L0lQIGNvdWxkIGJlIHJlYWxsb2NhdGVkIHRvIHRo ZSBwZWVyIHRoYXQgc2VuZHMgcGFja2V0cyB3aXRoIGNvbm5lY3Rpb24gSUQuDQoNCllpbiBYaW54 aW5nDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBUTFMgW21haWx0bzp0bHMtYm91bmNl c0BpZXRmLm9yZ10gtPqx7SBNYXR0IENhc3dlbGwNCreiy83KsbzkOiAyMDE3xOoxMdTCM8jVIDA6 MzINCsrVvP7IyzogdGxzQGlldGYub3JnDQrW98ziOiBSZTogW1RMU10gQ29ubmVjdGlvbiBJRCBE cmFmdA0KDQoNCg0KT24gMTcvMTAvMTcgMjI6MzUsIE1hcnRpbiBUaG9tc29uIHdyb3RlOg0KPiBP biBUdWUsIE9jdCAxNywgMjAxNyBhdCA5OjI2IFBNLCBGb3NzYXRpLCBUaG9tYXMgKE5va2lhIC0g DQo+IEdCL0NhbWJyaWRnZSwgVUspIDx0aG9tYXMuZm9zc2F0aUBub2tpYS5jb20+IHdyb3RlOg0K Pj4gVGhlIGZvbGxvd2luZyBjYXNlIChOQVQgYm94IHJlYm9vdCkgaXMgcHJvYmxlbWF0aWM6DQo+ Pg0KPj4gMS4gQXBwbGljYXRpb24gJzEnIG9uIGhvc3QgQSAoQS4xKSB1c2VzIERUTFMrQ0lEIHdp dGggYXBwbGljYXRpb24gJzEnIG9uDQo+PiAgICBob3N0IEIgKEIuMSk7DQo+PiAyLiBBcHBsaWNh dGlvbiAnMicgb24gaG9zdCBBIChBLjIpIHVzZXMgcGxhaW4tb2xkIERUTFMgd2l0aCBCLjE7IDMu IA0KPj4gVGhlIE5BVCBib3ggcmVib290cyAoYWxsIHByZXZpb3VzIDUtdHVwbGUgbWFwcGluZ3Mg YXJlIGxvc3QpOyA0LiBCLjEgDQo+PiByZWNlaXZlcyBhIHJlY29yZCBmcm9tIEEuMSAod2hvc2Ug NS10dXBsZSBoYXMgY2hhbmdlZCBpbiB0aGUNCj4+ICAgIG1lYW53aGlsZSk7DQo+Pg0KPj4gSG93 IGlzIEIuMSBzdXBwb3NlZCB0byBjb3JyZWN0bHkgaW50ZXJwcmV0IHRoZSBieXRlcyBzdGFydGlu ZyBhdCANCj4+IG9mZnNldA0KPj4gKzExPyAgKEZvciB3aGF0IGl0IGtub3dzLCBpdCBjb3VsZCBi ZSBDSUQgZnJvbSBBLjEgb3IgdGhlIGxlbmd0aCANCj4+ICtmaWVsZA0KPj4gZnJvbSBBLjIuKQ0K PiANCj4gSSBkb24ndCB0aGluayB0aGF0IHRoaXMgaXMgYSBwcm9ibGVtLg0KPiANCj4gY29ubmVj dGlvbiA9IGZpdmVfdHVwbGVzLmxvb2t1cChwYWNrZXQuZml2ZV90dXBsZSkNCj4gaWYgKCFjb25u ZWN0aW9uKSB7DQo+ICAgY29ubmVjdGlvbiA9IA0KPiBjb25uZWN0aW9uX2lkcy5sb29rdXAocGFj a2V0W2Nvbm5lY3Rpb25faWRfb2Zmc2V0OmNvbm5lY3Rpb25faWRfb2Zmc2V0DQo+ICtjb25uZWN0 aW9uX2lkX2xlbmd0aF0pDQo+IH0NCg0KSnVzdCBza2ltbWluZyB0aGlzIG9sZCB0aHJlYWQuLi5k b2Vzbid0IHRoaXMgZmFpbCBpbiB0aGUgY2FzZSB3aGVyZSB0aGUgZml2ZSB0dXBsZSBoYXMgYmVl biByZXVzZWQ/IEluIHRoYXQgY2FzZSBmaXZlX3R1cGxlcy5sb29rdXAgd2lsbCByZXR1cm4gYW4g b2xkIHN0YWxlIGNvbm5lY3Rpb24gd2hpY2ggdGhlIHNlcnZlciB0aGlua3MgaXMgc3RpbGwgdmFs aWQgc28gd2UgbmV2ZXIgZ2V0IHRvIGxvb2t1cCB0aGUgY29ubmVjdGlvbiBpZC4gV2l0aCBhbiBl eHBsaWNpdCBtYXJraW5nIHdlIHdvdWxkIG5vdCBmYWlsIGluIHRoaXMgc2NlbmFyaW8uDQoNCk1h dHQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRM UyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90bHMNCg== From nobody Fri Nov 3 02:15:22 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876A813FD20 for ; Fri, 3 Nov 2017 02:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 pjPCrnxPd4yX for ; Fri, 3 Nov 2017 02:15:17 -0700 (PDT) Received: from mta.openssl.org (mta.openssl.org [IPv6:2001:608:c00:180::1:e6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD30913FA91 for ; Fri, 3 Nov 2017 02:15:16 -0700 (PDT) Received: from [10.35.10.6] (unknown [104.238.169.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta.openssl.org (Postfix) with ESMTPSA id 6420CE6665; Fri, 3 Nov 2017 09:15:13 +0000 (UTC) To: Martin Thomson Cc: "tls@ietf.org" References: <4833b54e-880b-c2c4-99ed-4dde0c96fc5c@openssl.org> From: Matt Caswell Message-ID: Date: Fri, 3 Nov 2017 09:15:12 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 09:15:20 -0000 On 02/11/17 23:34, Martin Thomson wrote: > On Fri, Nov 3, 2017 at 3:32 AM, Matt Caswell wrote: >> Just skimming this old thread...doesn't this fail in the case where the >> five tuple has been reused? In that case five_tuples.lookup will return >> an old stale connection which the server thinks is still valid so we >> never get to lookup the connection id. With an explicit marking we would >> not fail in this scenario. > > I'm assuming that once a connection is closed (or moved), the entry is > removed. There's some fudging needed there for migrations (it might > be in two places at once for a while), but I don't see a significant > problem. (Note that I didn't include the update parts of this code - > when a packet decrypts successfully, you need to update the > five_tuples list.) > Imagine the scenario where you have a large number of clients sitting behind a NAT middlebox talking to a server. If the NAT crashes/reboots then all of the associations are lost and the server will not know to remove any of them from its table. It then seems highly likely that a tuple will get reused with stale connections in the server's table. It was my understanding that it is precisely this sort of problem that this draft was attempting to address. Explicit marking would solve this. Matt From nobody Fri Nov 3 02:28:49 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5932513FD2B for ; Fri, 3 Nov 2017 02:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 hdPfTSn2PZQz for ; Fri, 3 Nov 2017 02:28:47 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 012CE13FD2C for ; Fri, 3 Nov 2017 02:28:46 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id r128so1641421oig.9 for ; Fri, 03 Nov 2017 02:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8A1J+SRgRBuwHAB3DgXG27s4uZjxx+0Vq6jPA+eRxIc=; b=fReg2yNOXpi8bv67lTIh2ALMkdcRlJhsod5wdoe+2uAinvbSqj+9+yr+Xp1N6pPc+8 PtmV/5Bv0gwZPoWfVuc36iFeokkovQQC9N6A22ZSr5j3VU2MaEVu1uQ6yfi77wXruFVr pg8ZH6IGXgSB1ep9+WBw4DgYP/CwAr2Qxw2hwQTiOh9q2OR058eG/dHo/Q9+2uZYTeRN kwBWkhT/ckIHk+GQTyx7Zbqf6nA//fumZw8YIzpqsBTEmZxLHVhX6PscXgYk31oiQop1 RRHuc8RROduRzPLnm3zg2FaZZJFMQwIY689OLqBk5iR9O4sFwV8DJhC7Sd6V0PPLxWpQ JExg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8A1J+SRgRBuwHAB3DgXG27s4uZjxx+0Vq6jPA+eRxIc=; b=DnaESaukFlpDPnYEb53M7T246q1m/SwRNaeMeup7MMUFgGOltKnUAF7NtdqCxssT7Q 1bHpbzXXo4CERPjRCcnnrQmOJI3FCxTDy7AEnbfJyZyvBemIAiab0g9GIQFIQl5JCyBs e8/uICe/nNOhg1zrfYN+x9UJDGf88Y0SK9oHwb50qStII7oKXg3ztWV5ckrHA0Fc4TLN JMy5DaxyprFBJCns6WOPs13wJc1FtV+5N7jVpKkO0F36aV4ww5i+j3pxm/hXcpkNIPC0 cmq99HRUV38RfcxTMycFkqZQyeiHXhEBbeDepGIx4BePuq8s5wIOGZshykIAiywG1xP4 Preg== X-Gm-Message-State: AMCzsaXtxEwRog3fpgNwTjVUojXbKGROEdPt/EdhsXpItbshSuoXDIF0 U6V2EHjMu1DGJciYwA7iCBln8OCwAz3MCxci/VPfag== X-Google-Smtp-Source: ABhQp+TrsNgVPcW7QRrOR8KO4DxQiKs2Pbm2fLz+XnpIAO0QD+QD/FG4Odq5eLNXN4g1TbOYznMcQkVZA7id/GvnX9o= X-Received: by 10.202.67.135 with SMTP id q129mr3416098oia.390.1509701326302; Fri, 03 Nov 2017 02:28:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Fri, 3 Nov 2017 02:28:45 -0700 (PDT) In-Reply-To: References: <4833b54e-880b-c2c4-99ed-4dde0c96fc5c@openssl.org> From: Martin Thomson Date: Fri, 3 Nov 2017 20:28:45 +1100 Message-ID: To: Matt Caswell Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 09:28:48 -0000 On Fri, Nov 3, 2017 at 8:15 PM, Matt Caswell wrote: > > It was my understanding that it is precisely this sort of problem that > this draft was attempting to address. Explicit marking would solve this. Yes, and the connection ID is that marking. The contention - I think - is what to do when there is a mix of marked connections and unmarked. From nobody Fri Nov 3 02:59:13 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30BD13FD39 for ; Fri, 3 Nov 2017 02:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 Cf434gVpZl8g for ; Fri, 3 Nov 2017 02:59:10 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10104.outbound.protection.outlook.com [40.107.1.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D90B513FD3A for ; Fri, 3 Nov 2017 02:59:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CqaWDw4IwWPSsw4bdStrvE0ARSd1irHVDFrKO6b0/QU=; b=DZUstemLpduZabRgKd8leuEJ8q/BliX9mmhSY6Qalin02gIr4R91eQhL89XGV5P9TtSoaFUiRnay02zfFX/k1xD9E+RhzpWeq4kt9AzeAGokOiXiiJR7ScyWJH1dRWMHJkaVgU5o0nEsskHODI/kp9Qz7Z3Cp6gnyC1QC0k2Bv8= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1104.eurprd07.prod.outlook.com (10.163.168.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.4; Fri, 3 Nov 2017 09:59:07 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::e157:80bf:7ba7:b2ed]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::e157:80bf:7ba7:b2ed%13]) with mapi id 15.20.0197.017; Fri, 3 Nov 2017 09:59:06 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: Martin Thomson , Matt Caswell CC: "tls@ietf.org" , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Thread-Topic: [TLS] Connection ID Draft Thread-Index: AQHTQ6/ei1Eh6DPTUUK7WLQddJSSYqLnKXUAgADEnwCAAKpMgIAY0IwAgAB11wCAAKJeAIAAA8mAgAAIewA= Date: Fri, 3 Nov 2017 09:59:06 +0000 Message-ID: <756DAAB1-83B9-4DC7-A05C-440175F6A0AA@nokia.com> References: <4833b54e-880b-c2c4-99ed-4dde0c96fc5c@openssl.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-originating-ip: [88.109.163.48] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1104; 6:bujBnMX9C/BGM46hSrMZ+J3yxNxeL2CJrFvHb9Y5Ww5gICWwKY0QYlnlEbxrimfRlIjTiUnXNrLTKadUJBrl2Ab8DGbEI+La+hyuIccZ48vcKMdDxjKYCxQyV0gqKwLsPqe/lWGrAa/tkAmRUIanBZP1EY9GpUgvnAJp6Nx9uaASxgFdrQsdAUkE+Tq9WrDFTAF4FgVNAcaKI5HaARw+8ZpRqVCkLBgbMpbvpzDJRwSt/YYWNrp9+4Y3/JuEZTckMIHr6nzFCpUZWlmYBPcW8GgSfMSIgJsiVN3vEb3DLymMp0At1py7UlwutJNbo7UI4CVpPomcT65xKN7ZLAlaCx0RqoPlFmTMOePKlLo2zws=; 5:tJwqnIPWQfqqGEziPACTmP99SjMO33Cg8uMS5gN3MbPZrtIwwXett5UvPRY2bGToqEtalfeBp9H6enYqeR/DiQkPT3INKEfxrjrt5QQkQ9s9caN1Cd3snTZMRmNbtTzZUmxNUPpq5tl3kVQqsWfPwjwQsVaTcTxSgUXMWDVvf7Q=; 24:RIYKeHIkiD8NY4EdvlH+ImMH2ZcY9Neh4pgicubq+0B6SeKz2xzZd6OhA4Yg/837xyl0am4JxoU/5CVeVRTVzAmKN4qrux4OLxUVhYeUbHw=; 7:UVL+XEAG/swChnHd7GUxBssQzW5w+flx/LyN0r0wbADRXZJz+A3E+GJ2/z/zpfR2gJkRF1Hled8HuJ0PCPCC7uIONYAFk4A0Z9SNOgCVmvrrZ8nElXlxdFn9wLSpqtMXojtjk5iFOIt96Y/NHlu21jSGh1mMRGe0fgmbxp2a+UXJ/bo88JIWccMaepUqPjBlyWCU4NwiOGfXQ7U4YJ+ouegnU0v4DDbUxGcVaFrWrBOeTSwxNrYWfsqWZZM6OFgp x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(189002)(199003)(24454002)(8936002)(99286004)(478600001)(7736002)(305945005)(14454004)(83506002)(36756003)(97736004)(189998001)(83716003)(68736007)(3280700002)(86362001)(3660700001)(5250100002)(53546010)(2900100001)(5660300001)(2906002)(25786009)(66066001)(54356999)(33656002)(229853002)(2950100002)(50986999)(76176999)(101416001)(316002)(6512007)(93886005)(53936002)(82746002)(102836003)(6116002)(107886003)(6506006)(6246003)(3846002)(8676002)(81166006)(81156014)(105586002)(4326008)(110136005)(39060400002)(58126008)(6436002)(106356001)(6486002)(54906003); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1104; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: b814a413-f080-4f69-c564-08d522a18558 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:VI1PR07MB1104; x-ms-traffictypediagnostic: VI1PR07MB1104: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231021)(100000703101)(100105400095)(6055026)(6041248)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB1104; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB1104; x-forefront-prvs: 0480A51D4A received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: b814a413-f080-4f69-c564-08d522a18558 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2017 09:59:06.4434 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1104 Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 09:59:12 -0000 T24gMDMvMTEvMjAxNywgMDk6MjgsICJUTFMgb24gYmVoYWxmIG9mIE1hcnRpbiBUaG9tc29uIiA8 dGxzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIG1hcnRpbi50aG9tc29uQGdtYWlsLmNv bT4gd3JvdGU6DQo+IE9uIEZyaSwgTm92IDMsIDIwMTcgYXQgODoxNSBQTSwgTWF0dCBDYXN3ZWxs IDxtYXR0QG9wZW5zc2wub3JnPiB3cm90ZToNCj4gPiBJdCB3YXMgbXkgdW5kZXJzdGFuZGluZyB0 aGF0IGl0IGlzIHByZWNpc2VseSB0aGlzIHNvcnQgb2YgcHJvYmxlbQ0KPiA+IHRoYXQgdGhpcyBk cmFmdCB3YXMgYXR0ZW1wdGluZyB0byBhZGRyZXNzLiBFeHBsaWNpdCBtYXJraW5nIHdvdWxkDQo+ ID4gc29sdmUgdGhpcy4NCj4gDQo+IFllcywgYW5kIHRoZSBjb25uZWN0aW9uIElEIGlzIHRoYXQg bWFya2luZy4gIFRoZSBjb250ZW50aW9uIC0gSSB0aGluaw0KPiAtIGlzIHdoYXQgdG8gZG8gd2hl biB0aGVyZSBpcyBhIG1peCBvZiBtYXJrZWQgY29ubmVjdGlvbnMgYW5kDQo+IHVubWFya2VkLg0K DQpTcGVjaWZpY2FsbHksIHRoZSB0d28gbGluZXMgb2YgY29udGVudGlvbiBzZWVtIHRvIGJlOg0K LSBPbiB0aGUgcmVjZWl2ZXIgc2lkZSwgd2hldGhlciB0byBmYXZvdXIgc3Vydml2YWwgb2YgQ0lE IHYgbm9uLUNJRA0KICBiZWFyaW5nIHNlc3Npb25zOw0KLSBQYWNrZXQgYW5hbHlzZXIgZnJpZW5k bGluZXNzIChpLmUuLCBiZWluZyBhYmxlIHRvIGNvcnJlY3RseSBwYXJzZQ0KICB0aGUgc3RyZWFt IHdpdGhvdXQgcmVxdWlyaW5nIGl0IHRvIGtlZXAgc3RhdGUuKQ0KDQpDaGVlcnMNCg0K From nobody Fri Nov 3 03:12:16 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5236013FD4F for ; Fri, 3 Nov 2017 03:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 qWudlRY1FJga for ; Fri, 3 Nov 2017 03:12:13 -0700 (PDT) Received: from mta.openssl.org (mta.openssl.org [IPv6:2001:608:c00:180::1:e6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F0D813FD3E for ; Fri, 3 Nov 2017 03:12:13 -0700 (PDT) Received: from [10.35.10.6] (unknown [104.238.169.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta.openssl.org (Postfix) with ESMTPSA id D7EDAE66C8; Fri, 3 Nov 2017 10:12:11 +0000 (UTC) To: Martin Thomson Cc: "tls@ietf.org" References: <4833b54e-880b-c2c4-99ed-4dde0c96fc5c@openssl.org> From: Matt Caswell Message-ID: <46a95f41-ee4a-dccc-b6f4-8b2bce6582d4@openssl.org> Date: Fri, 3 Nov 2017 10:12:11 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 10:12:14 -0000 On 03/11/17 09:28, Martin Thomson wrote: > On Fri, Nov 3, 2017 at 8:15 PM, Matt Caswell wrote: >> >> It was my understanding that it is precisely this sort of problem that >> this draft was attempting to address. Explicit marking would solve this. > > Yes, and the connection ID is that marking. The contention - I think > - is what to do when there is a mix of marked connections and > unmarked. Right - where you have a mix of packets with connection ID and no connection ID you don't know whether to look for one or not. IMO this draft won't really be addressing the issues unless it includes a mechanism for determining that. Matt From nobody Fri Nov 3 06:43:03 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAC513FC4D for ; Fri, 3 Nov 2017 06:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 JuBI5tyCFYJv for ; Fri, 3 Nov 2017 06:42:56 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (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 ADFEC13FD34 for ; Fri, 3 Nov 2017 06:42:55 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id f46so1949814uae.1 for ; Fri, 03 Nov 2017 06:42:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=Sqc5huYppxPkPVVVrZSvlK1i+y2cC+bpmMtU04g1Yxg=; b=Q2oPuepohIQeECwYxX7IZLPzaQ7KUtdSGF0Mjya2EjHrEC8VmjKjWcgltOmGJrgItN xZFJb2qOp9egwZ1gdGT2yRl1mUPJcib9JhCzxZazaGvRrGe1i7mCNs2NddHzFmhXzVmm 4XpIY0y+oEREmZvxsXzUs+BhQySKhYcXYndpXDHx/hj1HTnlOoLuc2hst9VNLa+SjUZo 8IFrNr7q2zRHaaaOD6tWzbqv300bliyK3wGaLU4Dr8VgeXarJOxNk5M6Q+uP7x5JSfac XTvo7FdCA5NnfGDoZVPynNflGdhUlBovKLUn/GHeYOKYxakazAH1P38TXgZtuIBFXBv1 zbww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=Sqc5huYppxPkPVVVrZSvlK1i+y2cC+bpmMtU04g1Yxg=; b=J+Xtdt3pCIOQLefA/Tz4O7LyGJeIGrN+k8puvizMh+kJJC19f20wBoQVhR5POwRyu0 HOQ/72QOBtwhVou6ytcTDkZTbVLIi8HbuL8cBD+CuxAYQ7B1j/HOOk1ZnM2k9onEFEEE tVb+qVpAXuHFbD4z9ItGgvDocFTnLqj2Q2iPAFR/qwSGYsl0zKod1vKW0c2Z9JG56c3T zMc9QKvB9CtEv9yLxDw9P6C+lZ5dqr7/M9VvkD2PHv5R8gXllviohMT2M7AX/dqTMD4Y FXndyHJcfWq/6w+DDF2wKi0gBjeRzs44egICODsfedGwq35QiW3xkRUrZ+35hLpQKLaS QvgQ== X-Gm-Message-State: AMCzsaWm1Mf3RBH1QPFRCxffXIJ+ggRyXuKuCxKoiLHXTzrJciqy+ybX /7eWTSw/XxC+MgoXDBKSAQHrJn4vbScH+zCrlllQ7CRS X-Google-Smtp-Source: ABhQp+Rc81bZ0R5vpCQ9OTp7A1y1VYimSSofUXf0ELLDC12nqMnAndgOzXTfs588QFQvMySfPPb14TCdwLYJeQelLTs= X-Received: by 10.159.32.133 with SMTP id 5mr6042763uaa.61.1509716574415; Fri, 03 Nov 2017 06:42:54 -0700 (PDT) MIME-Version: 1.0 Sender: cas.cremers@gmail.com Received: by 10.176.1.108 with HTTP; Fri, 3 Nov 2017 06:42:33 -0700 (PDT) From: Cas Cremers Date: Fri, 3 Nov 2017 13:42:33 +0000 X-Google-Sender-Auth: Gf3DmBtcm5BRdLDGjqql-_AXFcA Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0b6202212f66055d144854" Archived-At: Subject: [TLS] Technical comment on design draft-rhrd-tls-tls13-visibility-00: why also break integrity/authentication? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 13:43:00 -0000 --94eb2c0b6202212f66055d144854 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8BDisclaimer: I am not a proponent of the idea behind draft visibility/green/rhrd; I think such a mechanism should not be part of the TLS 1.3 standard. =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8BI have a technical problem with the current design, whose= goal is to allow eavesdropping for inspection, i.e., selectively decreasing confidentiality. =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8BHowever, the design in the draft also enables arbitrary t= raffic modification/insertion, additionally breaking all authentication and integrity guarantees. Once someone has the session keys, they can not only eavesdrop but can also start to insert/modify traffic. This additional decrease in security is entirely unmotivated by the cited use cases. =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8BIt is possible to offer authentication and integrity, whi= le selectively giving up confidentiality. For example, one could replace the AEAD by (i) a mechanism for authentication and (ii) a separate mechanism for confidentiality, and then possibly reveal the keys used for (ii), but make sure only the real endpoint has the keys for (i). That seems more rational to me, and may retain the authentication/integrity guarantees. However, it would require a much more invasive change. =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8BBest, =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8BCas --94eb2c0b6202212f66055d144854 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,
=E2=80=8B=E2=80=8B
=E2= =80=8B=E2=80=8BDisclaimer: I am not a proponent of the idea behind draft vi= sibility/green/rhrd; I think such a mechanism should not be part of the TLS= 1.3 standard.
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8BI h= ave a technical problem with the current design, whose goal is to allow eav= esdropping for inspection, i.e., selectively decreasing confidentiality.
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8BHowever, the design = in the draft also enables arbitrary traffic modification/insertion, additio= nally breaking all authentication and integrity guarantees. Once someone ha= s the session keys, they can not only eavesdrop but can also start to inser= t/modify traffic. This additional decrease in security is entirely unmotiva= ted by the cited use cases.
=E2=80=8B=E2=80=8B
=E2=80= =8B=E2=80=8BIt is possible to offer authentication and integrity, while sel= ectively giving up confidentiality. For example, one could replace the AEAD= by (i) a mechanism for authentication and (ii) a separate mechanism for co= nfidentiality, and then possibly reveal the keys used for (ii), but make su= re only the real endpoint has the keys for (i). That seems more rational to= me, and may retain the authentication/integrity guarantees. However, it wo= uld require a much more invasive change.
=E2=80=8B=E2=80=8B
=
=E2=80=8B=E2=80=8BBest,
=E2=80=8B=E2=80=8B
=E2=80= =8B=E2=80=8BCas

--94eb2c0b6202212f66055d144854-- From nobody Fri Nov 3 07:00:25 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A69413FAC5 for ; Fri, 3 Nov 2017 07:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com 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 jAPU6XwIqYQo for ; Fri, 3 Nov 2017 07:00:22 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 531F013FB6C for ; Fri, 3 Nov 2017 07:00:22 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id w105so2603258wrc.0 for ; Fri, 03 Nov 2017 07:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6dwvIL9Fs3qhDOinDBLLHzZf2dOdcJJ51QoldKWUNfQ=; b=PXy7vGDvDGbcE35opF7g4nEN1GGu/3OetN7QSP1zG0LeZInWigDMjGgpmy+jfdEV5N tOuAx35X8fOGkjdlNtMIC/qJ5kZ+uLhw3/WrE8YiETovjL4fn8cqCoVyAYXJsVsyKFSx GLF5hZ/iu22QmqoqGZnotCx0xlRnScHZWVPfsxY1IUgxbi6WsLVgi5hXafJxyroWZHtr NC81Ppg5qwTn96R2zTqfBxt2tsyP1iSPLsOxXpMiwHsGFbkcdX8WklOW/6o31ueEtWfc 5fzf5lHK6VtBSTlO5X99JhrhPE4DdBEmH5G8aTZAC+d2i8WI5wlv6+HCfTSmj3x0ulvN kUkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6dwvIL9Fs3qhDOinDBLLHzZf2dOdcJJ51QoldKWUNfQ=; b=PHsFvCAUlFMIvc2A3EZafm0ZQXzdf4rBpeNI1iZt2NfSbDXQsz0P4piL3oBs3in9li HQwJLJije4/XQfiDyrLC1G8SdEO2MdaNoM2xhKcf7E7Xzy/uQhIwG+qg3MUzVyJ1m+MC Iu5Iwqt5roFET3UzzWEXsMDvtzRTkIVEiEKDRqmSULtZVi3Y0HXspU+BLtjRvA+64GaT ZANNnJL2d2F966BfV0ny+J3TcHmCqIH+7LPyixzl5usx3MxuDlH00EAOTjYTr5dJXQtk TaFVdi6wwX+XsLB3An+kbY23JcvuXpbhypY4rN32tYCNpS8HlLf6/bNPDcOLKWh6wAv7 qL/Q== X-Gm-Message-State: AMCzsaVHLcmEnLTMelfC85LoEx+UwGupg13LNUuclxVtfO0VE0c8CK1X 5fHRAHXNrivM/RgAGztI9yXE43gm3ZPfUXvwpkBOXA== X-Google-Smtp-Source: ABhQp+Qg4Yw4as3BVQgCqRam4kr7A7vZLSqUpPh7XFica34MAgI6X+nMSVRCbKVicmpAqrHG+3Bc8PVRVSrWr7G2eCg= X-Received: by 10.223.196.156 with SMTP id m28mr6461506wrf.67.1509717620480; Fri, 03 Nov 2017 07:00:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Fri, 3 Nov 2017 07:00:19 -0700 (PDT) Received: by 10.28.174.81 with HTTP; Fri, 3 Nov 2017 07:00:19 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Fri, 3 Nov 2017 10:00:19 -0400 Message-ID: To: Cas Cremers Cc: "" Content-Type: multipart/alternative; boundary="f403045f54867aef7c055d14860c" Archived-At: Subject: Re: [TLS] Technical comment on design draft-rhrd-tls-tls13-visibility-00: why also break integrity/authentication? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 14:00:24 -0000 --f403045f54867aef7c055d14860c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey Cas, This question is a good one. Earlier I brought up mcTLS, which some folks have been working on to provide even more granular separations than you suggest: https://mctls.org/ I think the authors of draft-rhrd are trying for a more lightweight change to TLS. That said, there might be some intermediate points on the spectrum here. For example, you could define a TLS ciphersuite akin to what we defined in PERC when we wanted to break integrity partly and confidentiality not at all. https://tools.ietf.org/html/draft-ietf-perc-double-07 That would be less invasive than mcTLS, while still getting the properties you describe. --Richard On Nov 3, 2017 09:43, "Cas Cremers" wrote: Dear all, =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8BDisclaimer: I am not a proponent of the idea behind draft visibility/green/rhrd; I think such a mechanism should not be part of the TLS 1.3 standard. =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8BI have a technical problem with the current design, whose= goal is to allow eavesdropping for inspection, i.e., selectively decreasing confidentiality. =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8BHowever, the design in the draft also enables arbitrary t= raffic modification/insertion, additionally breaking all authentication and integrity guarantees. Once someone has the session keys, they can not only eavesdrop but can also start to insert/modify traffic. This additional decrease in security is entirely unmotivated by the cited use cases. =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8BIt is possible to offer authentication and integrity, whi= le selectively giving up confidentiality. For example, one could replace the AEAD by (i) a mechanism for authentication and (ii) a separate mechanism for confidentiality, and then possibly reveal the keys used for (ii), but make sure only the real endpoint has the keys for (i). That seems more rational to me, and may retain the authentication/integrity guarantees. However, it would require a much more invasive change. =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8BBest, =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8BCas _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --f403045f54867aef7c055d14860c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Cas,

Thi= s question is a good one.=C2=A0 Earlier I brought up mcTLS, which some folk= s have been working on to provide even more granular separations than you s= uggest:


=
I think the authors of draft-rhrd are trying for a more l= ightweight change to TLS.=C2=A0 That said, there might be some intermediate= points on the spectrum here.=C2=A0 For example, you could define a TLS cip= hersuite akin to what we defined in PERC when we wanted to break integrity = partly and confidentiality not at all.=C2=A0

https://tools.ietf.org/html/draft-ietf-perc-double-07

That would be less invasi= ve than mcTLS, while still getting the properties you describe.=C2=A0
=

--Richard


On Nov 3, 2017= 09:43, "Cas Cremers" <cas.cremers@cs.ox.ac.uk> wrote:
Dear all,
=E2=80=8B=E2=80= =8B
=E2=80=8B=E2=80=8BDisclaimer: I am not a proponent of the ide= a behind draft visibility/green/rhrd; I think such a mechanism should not b= e part of the TLS 1.3 standard.
=E2=80=8B=E2=80=8B
=E2= =80=8B=E2=80=8BI have a technical problem with the current design, whose go= al is to allow eavesdropping for inspection, i.e., selectively decreasing c= onfidentiality.
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8BHo= wever, the design in the draft also enables arbitrary traffic modification/= insertion, additionally breaking all authentication and integrity guarantee= s. Once someone has the session keys, they can not only eavesdrop but can a= lso start to insert/modify traffic. This additional decrease in security is= entirely unmotivated by the cited use cases.
=E2=80=8B=E2=80=8B<= /div>
=E2=80=8B=E2=80=8BIt is possible to offer authentication and inte= grity, while selectively giving up confidentiality. For example, one could = replace the AEAD by (i) a mechanism for authentication and (ii) a separate = mechanism for confidentiality, and then possibly reveal the keys used for (= ii), but make sure only the real endpoint has the keys for (i). That seems = more rational to me, and may retain the authentication/integrity guarantees= . However, it would require a much more invasive change.
=E2=80= =8B=E2=80=8B
=E2=80=8B=E2=80=8BBest,
=E2=80=8B=E2=80=8B=
=E2=80=8B=E2=80=8BCas


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


--f403045f54867aef7c055d14860c-- From nobody Fri Nov 3 07:41:43 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73BB613FD6C for ; Fri, 3 Nov 2017 07:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 bT8yVwmtx6wr for ; Fri, 3 Nov 2017 07:41:39 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 8EB5013FB55 for ; Fri, 3 Nov 2017 07:41:24 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id n70so1877982vkf.11 for ; Fri, 03 Nov 2017 07:41:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=6m7rAXcaPsTlkQO53Fd0WQuJJMh4z9WJYsNPxSLxmCE=; b=gbOZMKF++8Zq4cZqPgDYxAxR3YEjgzVvl/dYK7+D5IpeUH4Ou9ho3HnLNW86nc6uYA 7CWD//MfHTILt/XViHAqGNOyPDkAiOYBsknM/DC9HhURBGWkEu3uXCr9x3iQJfg9laPP qSkjm8mdzpEU+1xg7YJDsvUqoX4z9IRqaLe6ZDmETNIWhYxzznxR3kzF0eTVmry/m8Yx d35gqy2y9LajJx5OloGP3/FAlAxs/uX4ue8XFPtZzr3N8xWKjtHKYps7Tg5HPDjuCzj5 Pw65HhgaWdjuNc3JSgs/TmaHHHmRmki0L25NJEGg/m9o5habWlpW4R7o2k1RM0YNJblZ UFDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=6m7rAXcaPsTlkQO53Fd0WQuJJMh4z9WJYsNPxSLxmCE=; b=fR2Y+RvDO5JJNJhLxe3oVrCCQjWB+/4M9QDcwPSXm2GmO0Jb+n0M83grBzGjCLtTxw vXMqj6tv/fe4CoqzqwKWOyhOWxOTcw+XGWKbIT+3yXiatu88EUniOrxzqCTplbcjY8mX 6SlvE77gS76mAycCmFCubeKzD27q2g1wqt7Qbnw0tsxt41FuqHbGllAzlYUgvaOmrcin B57Lh5RFvI9W1oF80ERGsh3XsQtlZw+UiwJoP9O67WjIU1plkL1BdD2Us5ZUFOKexp7V mtNdC9IOJo9OFwOaHhZeDGhZ6T5nKPHfJKaQL4cQHyi0PVmeUVNLRZOB3sN7hQWG8aK1 vpqQ== X-Gm-Message-State: AMCzsaU691WrGn+/CM7TAtyjX2GiWjkAsKGrhn50M5l6NYPMkGk8u+Dr olSbr9SBf3cLVcY7co+ijysSK3fiajLfsbCLg8Qn3g== X-Google-Smtp-Source: ABhQp+T5va6ljCTBy+bixP2c72cfaO5Jx8NSTK+gkUq8aYbKPNSy8yXatgPfInEXW+k9mtaTDJgFbi+LPfX5vnDugLU= X-Received: by 10.31.234.131 with SMTP id i125mr5529910vkh.149.1509720083582; Fri, 03 Nov 2017 07:41:23 -0700 (PDT) MIME-Version: 1.0 Sender: cas.cremers@gmail.com Received: by 10.176.1.108 with HTTP; Fri, 3 Nov 2017 07:41:02 -0700 (PDT) In-Reply-To: References: From: Cas Cremers Date: Fri, 3 Nov 2017 14:41:02 +0000 X-Google-Sender-Auth: YzuHnfq2wbBOCnZXXp47rsV6Y3E Message-ID: To: Richard Barnes Cc: "" Content-Type: multipart/alternative; boundary="94eb2c0916904ad349055d151911" Archived-At: Subject: Re: [TLS] Technical comment on design draft-rhrd-tls-tls13-visibility-00: why also break integrity/authentication? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 14:41:41 -0000 --94eb2c0916904ad349055d151911 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Richard, Thanks for the pointer, I had missed your earlier observation of essentially the same thing in the large mail threads. Personally, I think it is a substantial and unmotivated loss in security to also give up authentication/integrity. Note that any changes towards PERC would require some significant changes in the security analyses; for mctls, I expect it would be a completely new analysis. (I haven't seen any analyses of rhrd, but of the three, it is of course closest to the current setup.) Best, Cas On Fri, Nov 3, 2017 at 2:00 PM, Richard Barnes wrote: > Hey Cas, > > This question is a good one. Earlier I brought up mcTLS, which some folk= s > have been working on to provide even more granular separations than you > suggest: > > https://mctls.org/ > > I think the authors of draft-rhrd are trying for a more lightweight chang= e > to TLS. That said, there might be some intermediate points on the spectr= um > here. For example, you could define a TLS ciphersuite akin to what we > defined in PERC when we wanted to break integrity partly and > confidentiality not at all. > > https://tools.ietf.org/html/draft-ietf-perc-double-07 > > That would be less invasive than mcTLS, while still getting the propertie= s > you describe. > > --Richard > > > On Nov 3, 2017 09:43, "Cas Cremers" wrote: > > Dear all, > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8BDisclaimer: I am not a proponent of the idea behind dra= ft > visibility/green/rhrd; I think such a mechanism should not be part of the > TLS 1.3 standard. > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8BI have a technical problem with the current design, who= se goal is to > allow eavesdropping for inspection, i.e., selectively decreasing > confidentiality. > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8BHowever, the design in the draft also enables arbitrary= traffic > modification/insertion, additionally breaking all authentication and > integrity guarantees. Once someone has the session keys, they can not onl= y > eavesdrop but can also start to insert/modify traffic. This additional > decrease in security is entirely unmotivated by the cited use cases. > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8BIt is possible to offer authentication and integrity, w= hile selectively > giving up confidentiality. For example, one could replace the AEAD by (i)= a > mechanism for authentication and (ii) a separate mechanism for > confidentiality, and then possibly reveal the keys used for (ii), but mak= e > sure only the real endpoint has the keys for (i). That seems more rationa= l > to me, and may retain the authentication/integrity guarantees. However, i= t > would require a much more invasive change. > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8BBest, > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8BCas > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > --94eb2c0916904ad349055d151911 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Richard,

Thanks for the pointer, I h= ad missed your earlier observation of essentially the same thing in the lar= ge mail threads.

Personally, I think it is a subst= antial and unmotivated loss in security to also give up authentication/inte= grity.

Note that any changes towards PERC would re= quire some significant changes in the security analyses; for mctls, I expec= t it would be a completely new analysis. (I haven't seen any analyses o= f rhrd, but of the three, it is of course closest to the current setup.)

Best,

Cas


On Fri, Nov 3, 2017 at 2:0= 0 PM, Richard Barnes <rlb@ipv.sx> wrote:
Hey Cas,

This question is a good one.=C2=A0 Earlier I brought up mcTLS, which s= ome folks have been working on to provide even more granular separations th= an you suggest:

<= div dir=3D"auto">
I think the authors of draft-r= hrd are trying for a more lightweight change to TLS.=C2=A0 That said, there= might be some intermediate points on the spectrum here.=C2=A0 For example,= you could define a TLS ciphersuite akin to what we defined in PERC when we= wanted to break integrity partly and confidentiality not at all.=C2=A0

That would be less invasive than mcTLS, while stil= l getting the properties you describe.=C2=A0

--Richard


On Nov 3, 2017 0= 9:43, "Cas Cremers" <cas.cremers@cs.ox.ac.uk> wrote:
Dear all,
=E2=80=8B=E2=80=8B=
=E2=80=8B=E2=80=8BDisclaimer: I am not a proponent of the idea b= ehind draft visibility/green/rhrd; I think such a mechanism should not be p= art of the TLS 1.3 standard.
=E2=80=8B=E2=80=8B
=E2=80= =8B=E2=80=8BI have a technical problem with the current design, whose goal = is to allow eavesdropping for inspection, i.e., selectively decreasing conf= identiality.
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8BHowev= er, the design in the draft also enables arbitrary traffic modification/ins= ertion, additionally breaking all authentication and integrity guarantees. = Once someone has the session keys, they can not only eavesdrop but can also= start to insert/modify traffic. This additional decrease in security is en= tirely unmotivated by the cited use cases.
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8BIt is possible to offer authentication and integri= ty, while selectively giving up confidentiality. For example, one could rep= lace the AEAD by (i) a mechanism for authentication and (ii) a separate mec= hanism for confidentiality, and then possibly reveal the keys used for (ii)= , but make sure only the real endpoint has the keys for (i). That seems mor= e rational to me, and may retain the authentication/integrity guarantees. H= owever, it would require a much more invasive change.
=E2=80=8B= =E2=80=8B
=E2=80=8B=E2=80=8BBest,
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8BCas

<= /font>

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



--94eb2c0916904ad349055d151911-- From nobody Fri Nov 3 13:34:30 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062F113FFB7 for ; Fri, 3 Nov 2017 13:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 MAHan-o0J7zq for ; Fri, 3 Nov 2017 13:34:27 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9816613FFB3 for ; Fri, 3 Nov 2017 13:34:27 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vA3KXBt5009610 for ; Fri, 3 Nov 2017 20:34:25 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=b6nKkj3ic0wfrPEiNANIM4Ak4UPaQVws7+4hfKrK6bg=; b=OoDg8t1Zez6HxFMVCxaMZ1eP89dSCgln0FLyNEI/Rlh9HpCZAxL5MTekYje30hRbogGk P/OSpvVPkW4010yR/eyKxpXkp9V0ggjAMtxX49z0MgrdRv+JhmWhT9Lw1JTNQNnpKxwW 4lZoDtle3eWUSV+bSJmk1PzrO64MR6/H/Nix5B4OfPwGnyAqyKn9TjSTcEBw57PJffH8 b0n6y1LXpzb5fw4eUWBNASF+1fvcWw/Ers/ADXdF+7umX8BdlmcHU2yvf01BdJSF2E/Z yEJCur16Zw1HvZ0gXRhy3VCEXRywlGldkH06UzaURteCVnH/rv8Jb8fxuauzUBY56vSa cg== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050096.ppops.net-00190b01. with ESMTP id 2dyu0d7092-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 03 Nov 2017 20:34:25 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vA3KVV4U020253 for ; Fri, 3 Nov 2017 16:34:24 -0400 Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint2.akamai.com with ESMTP id 2dvn7ub1rb-1 for ; Fri, 03 Nov 2017 16:34:24 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 44E0F211FC for ; Fri, 3 Nov 2017 20:34:24 +0000 (GMT) To: "tls@ietf.org" References: <8A5E441B-90B7-4DF4-BD45-7A33C165691B@gmail.com> <3BA34D7B-BB04-4A1F-B18A-B0AC25402C4B@gmail.com> <0f9073f5-271b-a741-1a1e-f20ebc506d61@nist.gov> <9E26AFA9-2E72-4E8C-B304-553A2C851DC4@gmail.com> <2d45c53b-cef3-7e86-3d6f-3d486b1342b8@nist.gov> <74265928-8252-4CA1-B6A4-45296F74637B@akamai.com> <5fd2adb6-ed9c-2368-34de-db0597727e68@nist.gov> <2419b509-c1a5-d867-92c9-f4713804af91@cs.tcd.ie> <003ff6b5-1e1b-17cf-8b45-3bdd8562b902@nist.gov> <49EFAAD0-8457-4775-AE21-1D270872CD56@akamai.com> From: Benjamin Kaduk Message-ID: <0d7d639e-dd4d-eb05-9d63-85e69b330714@akamai.com> Date: Fri, 3 Nov 2017 15:34:24 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-03_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711030248 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-03_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711030248 Archived-At: Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 20:34:29 -0000 Friday afternoon seems like a tolerable time to do something so questionably productive as mailing to this thread... On 10/25/2017 09:50 AM, David A. Cooper wrote: > This question is based on your that belief that this protocol will > "escape" onto the public Internet, that browsers and other clients > used by individuals will feel forced to implement it, and that clients > will then be forced to enable the extension in order to get through > middleboxes that would filter traffic based on whether or not the > extension is present in the ClientHello. I've already explained why I > believe that scenario will never happen, and so no I do not agree that > it is a "fundamental change." Not picking on David in particular, it just happened to be the first message I found going back through the thread that exhibited this phenomenon. Namely, I have seen a lot of reasoning along the lines of "this would never happen on the public internet because there are so many other, cheaper/more efficient/easier ways to do it".  I don't  find that line of reasoning very persuasive.  This is not necessarily because I disagree with the cheaper/more efficient/easier classification, but rather because it seems out of scope for us as a technology organization.  IMO, we ought to be considering all the potential ramifications of a protocol change, in all the environments where that protocol is or might be deployed, as a purely technological matter, so that we can understand its potential impacts.  Just because something is expensive or inefficient today does not mean that it is not a capability of the technology we are developing, and cost and efficiency can change over time.  In cryptanalysis, we do not discount attacks that require large amounts of storage, because they are still valid algorithmic attacks, and lo and behold, as storage gets cheaper, we find that these sorts of attacks do get used.  Similarly for protocol design/analysis, we should not discount a particular protocol interaction just because there are at present other ways to do a similar thing, and those other ways currently seem more attractive. -Ben From nobody Fri Nov 3 18:50:01 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B5513FAE2 for ; Fri, 3 Nov 2017 18:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 Crl8XLJ5GDai for ; Fri, 3 Nov 2017 18:49:57 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DF0713FAE1 for ; Fri, 3 Nov 2017 18:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5602; q=dns/txt; s=iport; t=1509760197; x=1510969797; h=from:to:subject:date:message-id:mime-version; bh=MoNNnVYQt7RcoZ3G403ekvmVZh17C+1NqorI83MGtGs=; b=iY7U+KXnL9kuhWxzsekYvdKldygTpWb95c87eOYdr82r2TEZsvpjX5nf nP6+uQ2w518GMrvVDIxWn4v3SmCwfPBNuxFMx5l325XahkpmaowdebjfM 7bZiK5RfARUlBZH+ZNGwVwM+KowG96p5Ao3jBttnJVallmpcrTPFvveas Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DeAADLG/1Z/5RdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgkRwZG4ug3aKH48bknuFRoIRCiOFNIQ9PxgBAQEBAQEBAQFrHQu?= =?us-ascii?q?FR2gBSgIEMCcELokkZBCnaoInJoprAQEBAQEBAQMBAQEBAQEBARsFgy6CB4Nli?= =?us-ascii?q?ycwgjIFog4Ch2SNFpM0jGGJCAIRGQGBOAEfOIFsehV2AYI3hF6NEYERAQEB?= X-IronPort-AV: E=Sophos; i="5.44,339,1505779200"; d="scan'208,217"; a="26020723" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Nov 2017 01:49:56 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vA41ntcg011266 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sat, 4 Nov 2017 01:49:55 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 3 Nov 2017 21:49:54 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Fri, 3 Nov 2017 21:49:54 -0400 From: "Nancy Cam-Winget (ncamwing)" To: "tls@ietf.org" Thread-Topic: network-based security solution use cases Thread-Index: AQHTVQ82KKjKBkAk5kyjDwLCBqb5Hw== Date: Sat, 4 Nov 2017 01:49:54 +0000 Message-ID: <895D1206-28D1-43AB-8A45-11DEEC86A71D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1a.0.160910 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.10.116] Content-Type: multipart/alternative; boundary="_000_895D120628D143AB8A4511DEEC86A71Dciscocom_" MIME-Version: 1.0 Archived-At: Subject: [TLS] network-based security solution use cases X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 01:49:59 -0000 --_000_895D120628D143AB8A4511DEEC86A71Dciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxsLA0KDQpASUVURjk5LCBhd2FyZW5lc3Mgd2FzIHJhaXNlZCB0byBzb21lIG9mIHRoZSBzZWN1 cml0eSBXR3MgKHRoYW5rcyBLYXRobGVlbiDimLopIHRoYXQgVExTIDEuMyB3aWxsIG9ic2N1cmUg dmlzaWJpbGl0eSBjdXJyZW50bHkgYWZmb3JkZWQgaW4gVExTIDEuMiBhbmQgYXNrZWQgd2hhdCB0 aGUgaW1wbGljYXRpb25zIHdvdWxkIGJlIGZvciB0aGUgc2VjdXJpdHkgc29sdXRpb25zIHRvZGF5 LiAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhbXdpbmdldC10bHMtdXNlLWNh c2VzLTAwIGlzIGFuIGluaXRpYWwgZHJhZnQgdG8gZGVzY3JpYmUgc29tZSBvZiB0aGUgaW1wYWN0 cyByZWxhdGluZyB0byBjdXJyZW50IG5ldHdvcmsgc2VjdXJpdHkgc29sdXRpb25zLiAgVGhlIGdv YWwgb2YgdGhlIGRyYWZ0IGlzIE5PVCB0byBwcm9wb3NlIGFueSBzb2x1dGlvbiBhcyBhIGZldyBo YXZlIGJlZW4gcHJvcG9zZWQsIGJ1dCByYXRoZXIgdG8gcmFpc2UgYXdhcmVuZXNzIHRvIGhvdyBj dXJyZW50IG5ldHdvcmstYmFzZWQgc2VjdXJpdHkgc29sdXRpb25zIHdvcmsgdG9kYXkgYW5kIHRo ZWlyIGltcGFjdCBvbiB0aGVtIGJhc2VkIG9uIHRoZSBjdXJyZW50IFRMUyAxLjMgc3BlY2lmaWNh dGlvbi4NCg0KUmVnYXJkcywgTmFuY3ksIEZsZW1taW5nIGFuZCBFcmljDQo= --_000_895D120628D143AB8A4511DEEC86A71Dciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <0B504E3730C9FB4097E2955333237B68@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCi8qIFN0eWxl IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt Y29tcG9zZTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bh bi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVk LXNwYWNlO30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1z by1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVh bDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LWZhbWlseTpDYWxpYnJpO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xv cj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPkFsbCwgPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5ASUVURjk5 LCBhd2FyZW5lc3Mgd2FzIHJhaXNlZCB0byBzb21lIG9mIHRoZSBzZWN1cml0eSBXR3MgKHRoYW5r cyBLYXRobGVlbg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O01TIE1pbmNobyZxdW90Oztjb2xvcjpibGFjayI+4pi6PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj4pIHRoYXQgVExTIDEuMyB3aWxsIG9i c2N1cmUgdmlzaWJpbGl0eSBjdXJyZW50bHkgYWZmb3JkZWQgaW4gVExTIDEuMiBhbmQgYXNrZWQg d2hhdCB0aGUgaW1wbGljYXRpb25zIHdvdWxkIGJlIGZvciB0aGUgc2VjdXJpdHkgc29sdXRpb25z DQogdG9kYXkuJm5ic3A7Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1jYW13aW5nZXQtdGxzLXVzZS1jYXNlcy0wMCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW13aW5n ZXQtdGxzLXVzZS1jYXNlcy0wMDwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5pcw0KIGFuIGluaXRpYWwg ZHJhZnQgdG8gZGVzY3JpYmUgc29tZSBvZiB0aGUgaW1wYWN0cyByZWxhdGluZyB0byBjdXJyZW50 IG5ldHdvcmsgc2VjdXJpdHkgc29sdXRpb25zLiZuYnNwOyZuYnNwO1RoZSBnb2FsIG9mIHRoZSBk cmFmdCBpcyBOT1QgdG8gcHJvcG9zZSBhbnkgc29sdXRpb24gYXMgYSBmZXcgaGF2ZSBiZWVuIHBy b3Bvc2VkLCBidXQgcmF0aGVyIHRvIHJhaXNlIGF3YXJlbmVzcyB0byBob3cgY3VycmVudCBuZXR3 b3JrLWJhc2VkIHNlY3VyaXR5IHNvbHV0aW9ucw0KIHdvcmsgdG9kYXkgYW5kIHRoZWlyIGltcGFj dCBvbiB0aGVtIGJhc2VkIG9uIHRoZSBjdXJyZW50IFRMUyAxLjMgc3BlY2lmaWNhdGlvbi48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlJlZ2FyZHMsIE5hbmN5LCBG bGVtbWluZyBhbmQgRXJpYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_895D120628D143AB8A4511DEEC86A71Dciscocom_-- From nobody Sat Nov 4 23:30:08 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1054F13FB48 for ; Sat, 4 Nov 2017 23:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.com 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 26xoY0jsQhW6 for ; Sat, 4 Nov 2017 23:30:05 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::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 D17E913FB47 for ; Sat, 4 Nov 2017 23:30:05 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id b192so5785842pga.2 for ; Sat, 04 Nov 2017 23:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=Wb+92NMGzNM2508t8IhpTAmghupuvklEQ9HdOQixisU=; b=oi3OHoUbpHPC/+UpaoB+0YS1fAOHScv1NnDZidqdDxsjS/tnkWC6zmuEUxSZkME9ma sdXQEW1/vvxXfrAWieMkka+4KrGnkI4hVP10l41s2Za05RWwCez3mf3oDoVuLMKo9+bZ 7o6qjLJSgufksjya2Z2zxsETmA7LIxDsC1jY+qccv2+BHmNu0qiFJiPHS/3+2Zujbx++ rEtatI87ouTENJea1H51OZgwXi5+rMU/jPxYkVLqWnZYSC1NKCTUO165bqBcrtfSeeK7 C8XmRU7ktTJJh6WPlJ7JADAOxI8N+d5+yuww9NmmIShDXoEmlcRcDCqMqKjHmrqH6c8m LQEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=Wb+92NMGzNM2508t8IhpTAmghupuvklEQ9HdOQixisU=; b=H+v5KqdayscAReyjkvHwXRbYiErZlBKYJ9EnjsiSoZxjSuIWa57a7US9YKoa4nF3VH nhQa4A7ws2dZQe0FYaW1G+GFnIRpeGs9e/hsRwOWCKIK/8YY2D/NsjkORk5Eh731kKf8 39RXBLy4LRM7VMwkhMoPUdx4tQ6ck1xtYuuB2wX5Vwn7EFDNDsyLWlicvwPrZ0ys6kV4 vYl+LBipyB+cYumaM9NEmyJIxxbXj45kRPIPTKPmFSO9cgnye7j/SO/1irxcEvPfEDSZ BMi5kw7KOBG+5SCB1/xCaV9XsqTxktnVIW9VqjNMQ+X/uKwMOQoqQkvZTxBsOv/qyEcd HudA== X-Gm-Message-State: AMCzsaVihYoo2cotzZ9IngTTZkLTvNbJmTqL4HAo8//9VfIAFhFwdgog EHo6HyQKapXDLG1D+qCQSWR466c= X-Google-Smtp-Source: ABhQp+QZrlMxWBWpJtMz7wSZgiHGdJ8cmCQ8YAmMZh1fZygfF1QQX51VD+hLmGJMc5zUPoWAL1VRAg== X-Received: by 10.84.234.9 with SMTP id m9mr9086061plk.3.1509863404746; Sat, 04 Nov 2017 23:30:04 -0700 (PDT) Received: from aspen.local (209-112-147-75-radius.dynamic.acsalaska.net. [209.112.147.75]) by smtp.gmail.com with ESMTPSA id j68sm15686491pgc.6.2017.11.04.23.30.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Nov 2017 23:30:04 -0700 (PDT) To: tls@ietf.org References: <732B27C6-817B-4F02-BF5D-0EDCBDB91793@sn3rd.com> <6B3ADE1C-1019-4C81-BA94-EA3737ADED1A@akamai.com> From: Melinda Shore Message-ID: Date: Sat, 4 Nov 2017 22:29:58 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <6B3ADE1C-1019-4C81-BA94-EA3737ADED1A@akamai.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wj2oEJR9e6wXbNNBgx0ciuFFN6hTMIee9" Archived-At: Subject: Re: [TLS] TLS@IETF100: Agenda Requests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 06:30:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wj2oEJR9e6wXbNNBgx0ciuFFN6hTMIee9 Content-Type: multipart/mixed; boundary="PwMVDWAxA9lluAKQ05eDbJI3txx9rwN7T"; protected-headers="v1" From: Melinda Shore To: tls@ietf.org Message-ID: Subject: Re: [TLS] TLS@IETF100: Agenda Requests References: <732B27C6-817B-4F02-BF5D-0EDCBDB91793@sn3rd.com> <6B3ADE1C-1019-4C81-BA94-EA3737ADED1A@akamai.com> In-Reply-To: <6B3ADE1C-1019-4C81-BA94-EA3737ADED1A@akamai.com> --PwMVDWAxA9lluAKQ05eDbJI3txx9rwN7T Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/2/17 8:40 AM, Salz, Rich wrote: >> Due to some unforeseen circumstances neither author of >> draft-rhrd-tls-tls13-visibility is able to attend IETF 100. As a >> result, they=E2=80=99ve withdrawn their request for agenda time. > I think it would still be worthwhile to have time for the WG to see > if it can come to consensus on whether or not to do anything in this > area at this time. Well ... Decisions are made on the mailing list, not at meetings. Either way, I don't think that it makes sense to try to come to a decision on this without its advocates present. I don't like this proposal, and few other people seem to, and it seems to me that a bunch of us sitting around telling each other that we don't like it is probably not a very good use of meeting time. Melinda --=20 Software longa, hardware brevis PGP fingerprint: 795A 714B CD08 F996 AEFE AB36 FE18 57E9 6B9D A293 --PwMVDWAxA9lluAKQ05eDbJI3txx9rwN7T-- --wj2oEJR9e6wXbNNBgx0ciuFFN6hTMIee9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZ/q/nAAoJELiGRpM6HoEuArEQAItfJkdcBOzAmziRecpWaMDY xfdGSl3c1usThlOrxM7I3UVY2wBaL6Fj9IDB0w6DSCqMEq9x/nQD9F1Y47vvuigt G1ly/+tNQshoNDNTJT7a83AJZ3XOnMz344+ee2PQh25kc0znM9uQSVpIIyJRPdyp xtQDWTROf8IMQDAfPrH7Vq5Jre4Se1oHs7djTsTdL5e9QnqdnUKA6tXajvQb/Ts7 CYADqOA2bS2bxNoAsCwcn8nvuczQvQvpJ48EULVRidfNb8H2QRRmz7+XY6zMw/J6 I9eaeN9F8P31+N+wExWm6kEEA5LEmvtibAAdfS/sHEKB2RfX9vq0KGF/d86nz900 8cOPeFw5mZMPxphYue8eylhSozJzeCuTkPYvxigvd5oHYc9rAwY2DAF8Dtw+ZMpr QgfhL49MSGMRpqBhCKMAd38jxOgKakelL32WB2nbBd0QRf7l0dgqY6ir3aFHMVaF wat7xbH7t3He2eShH3QhpdrefS7TDeIzs5wcjBReMq5JE83nar6yF90jT+AvfEIp 5OvwhSj35iPU7ksHOB5smLxuULUJW6xZ/JU0SmMPJ/JoP7++miyh+ROMBuAcvdq/ y/v+2qrbJ6+WXrqUN84vD3AU3/4vo1DaQO2yFqV42mXA6lvgz2s04ZZ3bBSXPMbV 0VmcnUr17ZaD8Qq0NwjP =CJa6 -----END PGP SIGNATURE----- --wj2oEJR9e6wXbNNBgx0ciuFFN6hTMIee9-- From nobody Sun Nov 5 05:03:38 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D600113FAEE for ; Sun, 5 Nov 2017 05:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 SDgJ_vODI-Wg for ; Sun, 5 Nov 2017 05:03:36 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E99A713FACD for ; Sun, 5 Nov 2017 05:03:35 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vA5D2gxR009338; Sun, 5 Nov 2017 13:03:34 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=WHmmfN5Hfi1UgFuzLMkrJ65inhMYzLGRXXN208Tqc7E=; b=I4yvIk9zQxVlZhFRw2x9bm3+FZSMYSvEN8yjkpGLq8IxeZe7XdAL4/1XN92NjheHAqoc Bi0WSyW8Tjee1WvwFZccyz4qmBgwE4UJpDnOLHABWExCu2CPXYRGcUsapHIrJAezwL44 kVDevwx1Hh3+5LFiuvjfT1g+rPlEHrm/OMuFvasU4+4yB/2nilrhAFkDhAKWPD96D6iv BCHqtGs2KshwJjL3BVKIMZWFUMfVUZGTF5UTjkjNDVNjj2r2o4RPGUEg42j2mnR3dLux 5lj1uh7si/lOdZr4IETpWTrf4q1QQIqZC19Vm4zE8F6i0yREz4Gu/Ntndpehc1B2dWcB cg== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050093.ppops.net-00190b01. with ESMTP id 2e15pqunp8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 05 Nov 2017 13:03:34 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vA5D0SYN019057; Sun, 5 Nov 2017 08:03:33 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2e18vu2fdj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 05 Nov 2017 08:03:32 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 5 Nov 2017 08:03:32 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Sun, 5 Nov 2017 08:03:32 -0500 From: "Salz, Rich" To: Melinda Shore , "tls@ietf.org" Thread-Topic: [TLS] TLS@IETF100: Agenda Requests Thread-Index: AQHTTOWwew2Q2aAdy06XmH3DbvIHJqMBmwaAgAAAv4CABB1BAIAAbfWA Date: Sun, 5 Nov 2017 13:03:32 +0000 Message-ID: <0A8DF483-9DAD-48CD-A1BE-A6FECE490C69@akamai.com> References: <732B27C6-817B-4F02-BF5D-0EDCBDB91793@sn3rd.com> <6B3ADE1C-1019-4C81-BA94-EA3737ADED1A@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.45] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-05_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711050188 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-05_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711050188 Archived-At: Subject: Re: [TLS] TLS@IETF100: Agenda Requests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 13:03:37 -0000 U28gaWYgdGhlIG9ubHkgcGVvcGxlIGluIGZhdm9yIG9mIGl0IGFyZSB0aGUgZHJhZnQgYXV0aG9y cywgdGhlbiB3ZSBoYXZlIGNvbnNlbnN1cywgcmlnaHQ/DQoNCg0KDQo= From nobody Sun Nov 5 05:09:43 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA1F13FB7F for ; Sun, 5 Nov 2017 05:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 FHY0DkhiCUZa for ; Sun, 5 Nov 2017 05:09:40 -0800 (PST) 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 A3B5513F3D5 for ; Sun, 5 Nov 2017 05:09:40 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id e89so12978733ioi.11 for ; Sun, 05 Nov 2017 05:09:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5eyMNTDdxJ7ynfEyFbC/AmoV1HyM1f8HgiMWvnw9ZpY=; b=AlRELAE1jreMkpCgwU6GYU79vexFJJBrZQGHoV6bQAhh2etiRLI8rcMPnYmrvMeBbG pGnkH42cXtKTo8DcROl2G6/phL1LOYLAOpg2lfrasAZZXdiRN4rg59VAb/60QAQHYQ5d EWly6ZL/vZ/seKO9Bb5ySOElhvjohnLo8+kGLTK0gMs/swpvexu4GF0JL9biwBHk10lw UzCce9KKp+tlypqIaqUx1EXo5D9W4Jl6k6rRbjMHbEUBnBtAJlooefIRZpoNLpi1p7BB 1OEB2EYBuFrCGRgsU7A3eakXGJwYpFvSkM52gKPB5w5Q3mMJHey0FZFVTsHiHO38nSLi mabg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5eyMNTDdxJ7ynfEyFbC/AmoV1HyM1f8HgiMWvnw9ZpY=; b=PZeAyQchMxMs49IIPNLEgNVNAtMOHfqNzB905JTsJsZ4X0I/pDKPVI5nZWRtPNcw1U dOQiz2+6raGElq3ZT3QL7UogJ1dU3P7e0ca/OcZDijlEMYW0vmp/ZfrHZ6YLgJUdWJm7 h2tgxMKSo0sPrsNDWRADuD+1YdGU91bfIdjkuboNdHR1TGqZu2vR/rihOOAfqW1xiqzy OS30cuKfCChRXrILBJxtuMuMgd0MLrW+GLwL1nkSKxLNZud0eBM9Z/rIkyoodjg6Lj2W 4YlomPZMFf9TDOIQieyItg2Xre7DKynNlYTTe6vXeKfh5MMhdiNtjJZoGwEzyp/SaIg4 6YXg== X-Gm-Message-State: AMCzsaWTyLvACt191oEQfZkrF5K+2uHR4vIZNnCNn73sFBL8gQ80/So8 MlYR9yjJpSPdL430WXgeXMSrEqYVj4tR68IYnevdFw== X-Google-Smtp-Source: ABhQp+S2ApXIpgKR0d85evDs+Uq0wK4Y6ydJgNegIaYy0pblr7qTYBmNZNgemOIqRh+ajzGMjn1OEyz8PcCUBx2+Kw0= X-Received: by 10.107.8.207 with SMTP id h76mr15073074ioi.270.1509887379962; Sun, 05 Nov 2017 05:09:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.200.204 with HTTP; Sun, 5 Nov 2017 05:09:39 -0800 (PST) Received: by 10.79.200.204 with HTTP; Sun, 5 Nov 2017 05:09:39 -0800 (PST) In-Reply-To: <0A8DF483-9DAD-48CD-A1BE-A6FECE490C69@akamai.com> References: <732B27C6-817B-4F02-BF5D-0EDCBDB91793@sn3rd.com> <6B3ADE1C-1019-4C81-BA94-EA3737ADED1A@akamai.com> <0A8DF483-9DAD-48CD-A1BE-A6FECE490C69@akamai.com> From: Ted Lemon Date: Sun, 5 Nov 2017 08:09:39 -0500 Message-ID: To: "Salz, Rich" Cc: Melinda Shore , "" Content-Type: multipart/alternative; boundary="001a113f9354ef0f32055d3c0cac" Archived-At: Subject: Re: [TLS] TLS@IETF100: Agenda Requests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 13:09:42 -0000 --001a113f9354ef0f32055d3c0cac Content-Type: text/plain; charset="UTF-8" Consensus isn't about number of votes. However, I think we can say that although there seems to be some interest in making sure this use case is addressed, there are known ways of addressing it, and little interest in inventing a new way that weakens a new feature of tls 1.3 On Nov 5, 2017 14:03, "Salz, Rich" wrote: > So if the only people in favor of it are the draft authors, then we have > consensus, right? > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113f9354ef0f32055d3c0cac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Consensus isn't about number of votes. However, I thi= nk we can say that although there seems to be some interest in making sure = this use case is addressed, there are known ways of addressing it, and litt= le interest in inventing a new way that weakens a new feature of tls 1.3

On Nov 5, 2017= 14:03, "Salz, Rich" <rsal= z@akamai.com> wrote:
So if the only people in favor of it are the draft authors, then we= have consensus, right?



_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a113f9354ef0f32055d3c0cac-- From nobody Sun Nov 5 06:13:32 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FCD13F920 for ; Sun, 5 Nov 2017 06:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 p7Bn3js2Sk1O for ; Sun, 5 Nov 2017 06:13:29 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E70713AF75 for ; Sun, 5 Nov 2017 06:13:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 271B1BDD8; Sun, 5 Nov 2017 14:13:26 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gw17c0e6uCqs; Sun, 5 Nov 2017 14:13:21 +0000 (GMT) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CF984BE24; Sun, 5 Nov 2017 14:13:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1509891201; bh=mZhCoVbVzGyZmUk/lJfFulMyahEkHMoBuCXOfnrBB2o=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=rC5o+2jIC6Zu2gZOpBY8oK6aCyEwrQz+/+Q139j0Z0KIX9CjblHE69OAaRW0pz0+x KlJsg0if4IBmfNNN3JR0qGSq2QAfzMunrv60hReVcvwaKxuq9eu4cCFfEqPGZ8f0Zn 5NwrUD/0Iplrz6EdB/Gm4mEYT94pFJtJctGm8/dc= To: Ted Lemon , "Salz, Rich" Cc: "" References: <732B27C6-817B-4F02-BF5D-0EDCBDB91793@sn3rd.com> <6B3ADE1C-1019-4C81-BA94-EA3737ADED1A@akamai.com> <0A8DF483-9DAD-48CD-A1BE-A6FECE490C69@akamai.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <78b3fc21-b9f2-5081-c1ee-268edbeccb53@cs.tcd.ie> Date: Sun, 5 Nov 2017 14:13:19 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="j0ojNVc5BscI6WwTOLLBQ949msEWbGhLn" Archived-At: Subject: Re: [TLS] TLS@IETF100: Agenda Requests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 14:13:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --j0ojNVc5BscI6WwTOLLBQ949msEWbGhLn Content-Type: multipart/mixed; boundary="0JeH99rPaq1v7WgC0fCoN1bv4hrtU6Cw5"; protected-headers="v1" From: Stephen Farrell To: Ted Lemon , "Salz, Rich" Cc: "" Message-ID: <78b3fc21-b9f2-5081-c1ee-268edbeccb53@cs.tcd.ie> Subject: Re: [TLS] TLS@IETF100: Agenda Requests References: <732B27C6-817B-4F02-BF5D-0EDCBDB91793@sn3rd.com> <6B3ADE1C-1019-4C81-BA94-EA3737ADED1A@akamai.com> <0A8DF483-9DAD-48CD-A1BE-A6FECE490C69@akamai.com> In-Reply-To: --0JeH99rPaq1v7WgC0fCoN1bv4hrtU6Cw5 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 05/11/17 13:09, Ted Lemon wrote: > Consensus isn't about number of votes. However, I think we can say that= > although there seems to be some interest in making sure this use case i= s > addressed, there are known ways of addressing it, and little interest i= n > inventing a new way that weakens a new feature of tls 1.3 Don't disagree. In addition there's always been folks in the rough when it comes to any security BCP or similar and ISTM that the breaking-TLS case is no different - there'll always be people who (mistakenly IMO) perceive that it'd be better to break TLS (and prioritise their particular concern) than it is do our best to improve Internet security and privacy overall. (That's one reason the chairs' question in Prague wasn't a good one - it will always be the case that there are IETFers who do want to break TLS and similar - we learned nothing from that hum at all.) As a meta-comment, I think it's really a pity that most or all such break-TLS proposals appear to be accompanied (not necessarily from draft authors) by bad argument, overstatement and ignoring the existence of downsides. (*) IMO that is yet another indicator that those arguing to break TLS know that they're likely to end up in the rough and hence at tempted to attempt the "hard-sell" (as you Ted I think called it, perhaps too generously) which is I think disruptive to WG progress. So I'd argue to not bother discussing this bad idea again at IETF-100 - it's consumed enough cycles already and we won't learn anything at all if we do waste time in that way yet again. S. (*) I fully admit to meeting such bad argument with robust argument and will continue doing so:-) >=20 > On Nov 5, 2017 14:03, "Salz, Rich" wrote: >=20 >> So if the only people in favor of it are the draft authors, then we ha= ve >> consensus, right? >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --0JeH99rPaq1v7WgC0fCoN1bv4hrtU6Cw5-- --j0ojNVc5BscI6WwTOLLBQ949msEWbGhLn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ/xyAAAoJEC88hzaAX42iIfcIALdgjd6TX7fP1DpNTMDWQ9hf yo5TBYl6fIiFvAHBCic5LhNtktv2YOmP9//7obXkBX9IfTCb02rO/IBSJk+bCIPK rAhnZUlXwP4DWbBgwY8iBKLK9bwrar61zw0+MleAqpDmGqVT0KRrRgU4cJCoVj/8 /07WsIOl3iZrSzoyfVVPfHL0IjdVmxt1Cf3ZVxVy+gNp4kD33Ck21r7xd/QDSSo1 a8CTn2UFNCcSx221icqfFQwOq64VJ9XsgNghDqJceXcLs5YZiEO+2xegfGTTPhR3 eAahgsVDpl/4CWaXvdc5nkZeCaf1DmQorbMzyl/n0L7+JvsT9fd4R5VrHaLAbDY= =bci3 -----END PGP SIGNATURE----- --j0ojNVc5BscI6WwTOLLBQ949msEWbGhLn-- From nobody Sun Nov 5 07:32:00 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21C113FB1D for ; Sun, 5 Nov 2017 07:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 9MB9XPItRISK for ; Sun, 5 Nov 2017 07:31:56 -0800 (PST) Received: from albireo.enyo.de (albireo.enyo.de [5.158.152.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE2E213FB1F for ; Sun, 5 Nov 2017 07:31:56 -0800 (PST) Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1eBMts-0004SO-Nx; Sun, 05 Nov 2017 15:31:52 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.89) (envelope-from ) id 1eBMts-00061W-Ie; Sun, 05 Nov 2017 16:31:52 +0100 From: Florian Weimer To: "Nancy Cam-Winget \(ncamwing\)" Cc: "tls\@ietf.org" References: <895D1206-28D1-43AB-8A45-11DEEC86A71D@cisco.com> Date: Sun, 05 Nov 2017 16:31:52 +0100 In-Reply-To: <895D1206-28D1-43AB-8A45-11DEEC86A71D@cisco.com> (Nancy Cam-Winget's message of "Sat, 4 Nov 2017 01:49:54 +0000") Message-ID: <874lq868t3.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] network-based security solution use cases X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 15:31:59 -0000 * Nancy Cam-Winget: > @IETF99, awareness was raised to some of the security WGs (thanks > Kathleen =E2=98=BA) that TLS 1.3 will obscure visibility currently afford= ed in > TLS 1.2 and asked what the implications would be for the security > solutions today. > https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00 is an > initial draft to describe some of the impacts relating to current > network security solutions. The goal of the draft is NOT to propose > any solution as a few have been proposed, but rather to raise > awareness to how current network-based security solutions work today > and their impact on them based on the current TLS 1.3 specification. I'm not sure if this approach is useful, I'm afraid. The draft is basically a collection of man-in-the-middle attacks many people would consider benign. It's unclear where the line is drawn: traffic optimization/compression and ad suppression/replacement aren't mentioned, for example, and I would expect both to be rather low on the scale of offensiveness. What the draft is essentially arguing is that many user cannot afford end-to-end encryption for various reasons, some legal, some technical, some political. But it seems to me that this is currently not a viewpoint shared by the IETF. From nobody Sun Nov 5 08:09:31 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B7913FC78 for ; Sun, 5 Nov 2017 08:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 sMfN2xwBO023 for ; Sun, 5 Nov 2017 08:09:28 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB3F113FAC5 for ; Sun, 5 Nov 2017 08:09:28 -0800 (PST) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vA5G85Cc021383; Sun, 5 Nov 2017 16:09:24 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=EeGDlM46EolVCMPPyPXN4tb6SDsqWr0T78ZBH+aAm8I=; b=c+S/KZ2BlRlIDY8cbTlwwJBuza3aFXhv7sVVvMBzsNA37xPYBvYg6C5VnhhJvvT71wZI 8dA68XkBbjfjUtKUFTdwWJm/NiVJTt3jkMZRLs2tRhOiVwkKkNDQF6cfnJaAob6k4Jiw pFlfJ9rbRAHHxSYCtjHjBOVO5WYkjjm/F1yPsVgMQ9WKH/wpO4op+3PNTPxLkB/CFbGb rq9CqjDJ+v4zxA3KciYm5bIDZwioxEnsS+M+kZ0+NZbgT1c55Uy6QBP5W4MJFLbJmzYn cM3DMTxUVgn6VfOyPILwS9IM2rPCB+5iGQ5O6v6uFdMz/xwglITfY0WZ18sctaUNtFdt IA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2e16fjkmgx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 05 Nov 2017 16:09:24 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vA5G722w007222; Sun, 5 Nov 2017 11:09:22 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2e18vu2r5v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 05 Nov 2017 11:09:22 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 5 Nov 2017 11:09:21 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Sun, 5 Nov 2017 11:09:21 -0500 From: "Salz, Rich" To: Ted Lemon CC: Melinda Shore , "" Thread-Topic: [TLS] TLS@IETF100: Agenda Requests Thread-Index: AQHTTOWwew2Q2aAdy06XmH3DbvIHJqMBmwaAgAAAv4CABB1BAIAAbfWAgAABt4CAADI1gA== Date: Sun, 5 Nov 2017 16:09:20 +0000 Message-ID: <376386A6-B12C-4C8B-92BA-7E187ED53DE3@akamai.com> References: <732B27C6-817B-4F02-BF5D-0EDCBDB91793@sn3rd.com> <6B3ADE1C-1019-4C81-BA94-EA3737ADED1A@akamai.com> <0A8DF483-9DAD-48CD-A1BE-A6FECE490C69@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.43.2] Content-Type: multipart/alternative; boundary="_000_376386A6B12C4C8B92BA7E187ED53DE3akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-05_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711050233 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-05_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711050233 Archived-At: Subject: Re: [TLS] TLS@IETF100: Agenda Requests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 16:09:30 -0000 --_000_376386A6B12C4C8B92BA7E187ED53DE3akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgQ29uc2Vuc3VzIGlzbid0IGFib3V0IG51bWJlciBvZiB2b3Rlcy4gSG93ZXZlciwgSSB0 aGluayB3ZSBjYW4gc2F5IHRoYXQgYWx0aG91Z2ggdGhlcmUgc2VlbXMgdG8gYmUgc29tZSBpbnRl cmVzdCBpbiBtYWtpbmcgc3VyZSB0aGlzIHVzZSBjYXNlIGlzIGFkZHJlc3NlZCwgdGhlcmUgYXJl IGtub3duIHdheXMgb2YgYWRkcmVzc2luZyBpdCwgYW5kIGxpdHRsZSBpbnRlcmVzdCBpbiBpbnZl bnRpbmcgYSBuZXcgd2F5IHRoYXQgd2Vha2VucyBhIG5ldyBmZWF0dXJlIG9mIHRscyAxLjMNCg0K SSBkaWRu4oCZdCBzYXkgdm90ZXMuDQo= --_000_376386A6B12C4C8B92BA7E187ED53DE3akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwg bGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXBy aW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2lu LWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1l OiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDox NDk2ODQ1NjAxOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czoyMTE3ODc1MTQwIC0xMzIzMjU5NTcwIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4 NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVs MQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJY29sb3I6YmxhY2s7DQoJbXNvLWFuc2ktZm9udC13ZWln aHQ6Ym9sZDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpA bGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9t OjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+Q29uc2Vuc3VzIGlzbid0IGFib3V0IG51bWJlciBvZiB2b3Rlcy4gSG93ZXZl ciwgSSB0aGluayB3ZSBjYW4gc2F5IHRoYXQgYWx0aG91Z2ggdGhlcmUgc2VlbXMgdG8gYmUgc29t ZSBpbnRlcmVzdCBpbiBtYWtpbmcgc3VyZSB0aGlzIHVzZSBjYXNlIGlzIGFkZHJlc3NlZCwgdGhl cmUgYXJlIGtub3duIHdheXMgb2YNCiBhZGRyZXNzaW5nIGl0LCBhbmQgbGl0dGxlIGludGVyZXN0 IGluIGludmVudGluZyBhIG5ldyB3YXkgdGhhdCB3ZWFrZW5zIGEgbmV3IGZlYXR1cmUgb2YgdGxz IDEuMzxvOnA+PC9vOnA+PC9saT48L3VsPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIGRpZG7igJl0IHNheSB2b3Rlcy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_376386A6B12C4C8B92BA7E187ED53DE3akamaicom_-- From nobody Sun Nov 5 08:14:48 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C0A13FC7E for ; Sun, 5 Nov 2017 08:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 KyKFov7yfp34 for ; Sun, 5 Nov 2017 08:14:45 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::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 2472613FB77 for ; Sun, 5 Nov 2017 08:14:45 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id b9so9826002wmh.0 for ; Sun, 05 Nov 2017 08:14:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0lrQhM/EbowcskotfUoD8eaPCCwlKOO/YFGf66FuCfE=; b=1sTKZ7Ls2jmOAuWv1krG6xPtbRzYJUOAAgizeH0AfE5c+267rJAHuV9H+EMe+g6YCI sI1zTipMHRR8hSisLoZ+07FjxXVrQb69CmWp9fygKuBr5vDEZUUWlKZ44Bfk46zftO/Q +PFrbwCOdFdUQDzrj6bV0vXP71j9aMmsD37wqjTDwmI2Cwbqbkvf6VSWfp6jg8zGRo6n UCv3RecobCWaygCo1gl1gjH28oS1RXMKjbq1Cr01kNq53qLrEUkRnVC/3K16UAU4YbRI 6b86fW+fE3LCWfwbrzAquNIDG14ToX5HmgMOYaC6eahE5BQ+9xPuNEZ5qZzUDUjVGTYW Qgaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0lrQhM/EbowcskotfUoD8eaPCCwlKOO/YFGf66FuCfE=; b=gisVmKKzkXsSe1mOltsRZyORwSMkSpTxcb3os4cg+SHCN96MjYnEolGXHQ1sFZLhr5 OWFi70E7+P0cw2X4fDcNlo4SXCAMwnjZ4CMJhrcSSOSL2c2bpZgi63B4xVBYvCbkzvjM 3jDy92flCE3oWRM1EkmCwd/+XMLx4wsJ8m7101R73mc3vZTGHBeS7HojjkXEr1gylxww YVRTLO8QC7whY3k1y7TCo1bLYyR9di6o5rBaWl4/4qhZx1Sj/00RwuNNQUNDFyqWuRUz PRqMpto2iCkRdsbIyi8gKkwCXQuGOmRblc/lFpe5+q1dOdxoIw23eZy0KTQ7a7UfNwWC qCHw== X-Gm-Message-State: AJaThX7OJ1yH4YQQf/+H0lWzdahxla2hcaW5blCqJuu2H11bWGLg7tHV jlPBGPiWEP268Axa5nHBSDfTbg== X-Google-Smtp-Source: ABhQp+RBwVgjs1Df2AaAOsvwfEckUtIAXMXWnWH9Qh8u7p8zk/XkagNKckIENmlyTe7bW+hOVSHiQQ== X-Received: by 10.28.143.212 with SMTP id r203mr3272397wmd.44.1509898483550; Sun, 05 Nov 2017 08:14:43 -0800 (PST) Received: from [192.168.1.51] (195.red-81-36-149.dynamicip.rima-tde.net. [81.36.149.195]) by smtp.gmail.com with ESMTPSA id l3sm2817742wml.38.2017.11.05.08.14.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Nov 2017 08:14:42 -0800 (PST) From: Ted Lemon Message-Id: <2F651580-211E-44F0-A3A8-A873B016E03D@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BFD8CD28-90B4-4A8E-8CBE-1871F9A44697" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 5 Nov 2017 17:14:42 +0100 In-Reply-To: <376386A6-B12C-4C8B-92BA-7E187ED53DE3@akamai.com> Cc: Melinda Shore , "" To: "Salz, Rich" References: <732B27C6-817B-4F02-BF5D-0EDCBDB91793@sn3rd.com> <6B3ADE1C-1019-4C81-BA94-EA3737ADED1A@akamai.com> <0A8DF483-9DAD-48CD-A1BE-A6FECE490C69@akamai.com> <376386A6-B12C-4C8B-92BA-7E187ED53DE3@akamai.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] TLS@IETF100: Agenda Requests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 16:14:47 -0000 --Apple-Mail=_BFD8CD28-90B4-4A8E-8CBE-1871F9A44697 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 5, 2017, at 5:09 PM, Salz, Rich wrote: > I didn=E2=80=99t say votes. Sure, but you did say "only the authors are interested" which to me = seems to imply a comparison of numbers. Sometimes everybody who's = interested in an idea is an author; that doesn't mean it's a bad idea. = There have been cases when very good ideas have been squashed because = the working group chair believed that a document needed more than just = the authors to support it. So over the years I guess I will admit to = having developed a bit of a knee-jerk reaction to this argument=E2=80=94so= rry about that! My point here is that that's not the reason to reject the document. = The reason in this case is that there already exist better ways to solve = the problem, and the proposal would clearly make TLS 1.3 worse, even = though there is disagreement about how much worse it would make it. --Apple-Mail=_BFD8CD28-90B4-4A8E-8CBE-1871F9A44697 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Nov 5, 2017, at 5:09 PM, Salz, Rich <rsalz@akamai.com> = wrote:
I= didn=E2=80=99t say votes.

Sure, but you did say "only the authors are = interested" which to me seems to imply a comparison of numbers.   = Sometimes everybody who's interested in an idea is an author; that = doesn't mean it's a bad idea.   There have been cases when very = good ideas have been squashed because the working group chair believed = that a document needed more than just the authors to support it.   = So over the years I guess I will admit to having developed a bit of a = knee-jerk reaction to this argument=E2=80=94sorry about that!

My point here is that = that's not the reason to reject the document.   The reason in this = case is that there already exist better ways to solve the problem, and = the proposal would clearly make TLS 1.3 worse, even though there is = disagreement about how much worse it would make = it.

= --Apple-Mail=_BFD8CD28-90B4-4A8E-8CBE-1871F9A44697-- From nobody Sun Nov 5 11:02:22 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD7413FCCC for ; Sun, 5 Nov 2017 11:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.com 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 xwpPoAYNRYOd for ; Sun, 5 Nov 2017 11:02:19 -0800 (PST) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 82B0713F963 for ; Sun, 5 Nov 2017 11:02:19 -0800 (PST) Received: by mail-pf0-x235.google.com with SMTP id b79so6085898pfk.5 for ; Sun, 05 Nov 2017 11:02:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=8iOm45vEQ9Lk0OLdL71bSzvq/jt/mgTuSqEfTxAB45Y=; b=hp/Pa4gchrY3bZUG/oEIX9lRxReFrPCsihiSVfwOi77m2lowN0BRsKhmbdywRZVoM/ WJrd8paa6/0bYpfze01RgXK9WiDemsyleBHVCjxYjlckyYO2D2+vKhND9X9R3xdrdvba 3vBWC3WO+dMFq7tD6YuCWX7J71eHNKZ5SqaQHM6EGRZfAe7EBaCZvvwYR48CQ7vcQpW/ 9HJcX++TZaBKflxsWAtGvpIVeoclGOQjmcge9J0DjKIyBU8OrMLqJYdIfW2E3do2Y31D EzyKfqJHZvQHbu/suV4q95P93ToTPQpfig93QoMk0bJJHr84b4PUrwvMvMs0nTT/KLyc fZwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=8iOm45vEQ9Lk0OLdL71bSzvq/jt/mgTuSqEfTxAB45Y=; b=nDcu+6euC0RwaHzJa/jb92Mzo0AMpg9hJjG0AEit2gHdkd0E1VOZZaXviVbnoLcedg gMLWcf5RTA6vdOSBcp3QXE1UdqyponQir0zbqeyuFRbGz97+U9bAn8ZXI8xwr3SJU+o6 uRQ+2s13/ayj6+7J9EjDIsoq8UFYlA1QhHIq0bmlOszEEWWY9q3RcTNszovJx8Sorvbw 6SgX60AbH9rfIKjWbGb0uYxcsQAwRVPDlvmiqJSsiuCAGAuWPLvlEw/wYgFbxj8Ck5zv soCpUa2xunj6Bnzf/noxosLz36rR9xBQS59Rsr+d0tf925AlBBA76LB9w/Jc70C7t8LT g4aQ== X-Gm-Message-State: AMCzsaV2SwwWtTkI8cV6syekF2U2d4E79JJof9wBOPvRaEvMRIB0jkjh HgXMmo4ixcIc6M1isUfFqrOmodQ= X-Google-Smtp-Source: ABhQp+QirlhecxbOs3Nnp+bQ8UAME9DCaSRkplPuIZl/FRHnWKN1V0Di+2Gm226zJobfod38rXPsGg== X-Received: by 10.99.120.7 with SMTP id t7mr12770925pgc.360.1509908538428; Sun, 05 Nov 2017 11:02:18 -0800 (PST) Received: from aspen.local (209-112-147-75-radius.dynamic.acsalaska.net. [209.112.147.75]) by smtp.gmail.com with ESMTPSA id d8sm19733610pfh.178.2017.11.05.11.02.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Nov 2017 11:02:17 -0800 (PST) To: Ted Lemon , "Salz, Rich" Cc: "" References: <732B27C6-817B-4F02-BF5D-0EDCBDB91793@sn3rd.com> <6B3ADE1C-1019-4C81-BA94-EA3737ADED1A@akamai.com> <0A8DF483-9DAD-48CD-A1BE-A6FECE490C69@akamai.com> <376386A6-B12C-4C8B-92BA-7E187ED53DE3@akamai.com> <2F651580-211E-44F0-A3A8-A873B016E03D@fugue.com> From: Melinda Shore Message-ID: Date: Sun, 5 Nov 2017 10:02:12 -0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <2F651580-211E-44F0-A3A8-A873B016E03D@fugue.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0Si0CC5O4OCLQ8WswTt364qjMemUNdge6" Archived-At: Subject: Re: [TLS] TLS@IETF100: Agenda Requests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 19:02:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0Si0CC5O4OCLQ8WswTt364qjMemUNdge6 Content-Type: multipart/mixed; boundary="qagBdHvNX4HCWa4bfspv29xQhIVFijOPx"; protected-headers="v1" From: Melinda Shore To: Ted Lemon , "Salz, Rich" Cc: "" Message-ID: Subject: Re: [TLS] TLS@IETF100: Agenda Requests References: <732B27C6-817B-4F02-BF5D-0EDCBDB91793@sn3rd.com> <6B3ADE1C-1019-4C81-BA94-EA3737ADED1A@akamai.com> <0A8DF483-9DAD-48CD-A1BE-A6FECE490C69@akamai.com> <376386A6-B12C-4C8B-92BA-7E187ED53DE3@akamai.com> <2F651580-211E-44F0-A3A8-A873B016E03D@fugue.com> In-Reply-To: <2F651580-211E-44F0-A3A8-A873B016E03D@fugue.com> --qagBdHvNX4HCWa4bfspv29xQhIVFijOPx Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/5/17 7:14 AM, Ted Lemon wrote: > My point here is that that's not the reason to reject the document. =C2= =A0 > The reason in this case is that there already exist better ways to solv= e > the problem, and the proposal would clearly make TLS 1.3 worse, even > though there is disagreement about how /much/=C2=A0worse it would make = it. Right, the question is about the technical merits of the proposal. If I'm recalling correctly the widespread view of STUN when it was first brought in was that it was revolting. That may continue to be the most widely-held view, but unlike the rhrd draft there was no other workable solution at the time to an extremely pressing problem. Anyway there's precedent for something most people don't like moving forward and eventually being published as a standard if the technical arguments are sound. At any rate, the discussion of the proposal, if there is to be one, belongs on the mailing list. Having the discussion and coming to a conclusion 1) during a meeting 2) where none of the proponents is present seems like an abuse of process to me (not to mention a waste of meeting time). Furthermore it seems like the technical merits of the rhrd proposal are thin enough that it's unlikely to progress, anyway. Melinda --=20 Software longa, hardware brevis PGP fingerprint: 795A 714B CD08 F996 AEFE AB36 FE18 57E9 6B9D A293 --qagBdHvNX4HCWa4bfspv29xQhIVFijOPx-- --0Si0CC5O4OCLQ8WswTt364qjMemUNdge6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZ/2A1AAoJELiGRpM6HoEuLfIP/ArJHpEUGZ2NApv/RD2mBq1u yOQbgKBZusZFvgxOA92J6kvMuQZekB6KNJVk2md0bnXgJqz0iiHhKV3U8wLPcJu6 7qbUXHy4FRfmQaLwmleU9k2EjNNuf9Z3SPqczv9j27YNZqo3leKxSEzhDWMZUtjh 1Sw3r4vNH8bAHicu8tCAK1FHZTcrTxpcx+MIK2LOQGZR03NXBxistnWvlMq1DvJ2 ZiVOevv3hr42GPAr4MFMW7UjrNaO2UvwYqpH6fPOKst0F/m8Pyu8GT2QTtbVnHq9 ym1cZnf9VbfLrPNcXkA8S/ISGIT3uWAJoha8YRUASpfMxgX/5ppUVUQ3YtLdvEFe WIqPS7nlr1lvdcS30787oFOMeULSNgDxMhG2dxTrLOQo6AyuAU99mJ6BFWgKi2oI qY2T7w4Jr84tSoEMGb9jHW0NSeiwGtM9zjSCMuhS6XpIHBVCFhqNfbg5pJkX+jbx B+Lm5owzv7kvG9OqdWAvI+fqGFZmq9XixLmjbvr7g6bAeWqXPwkFCGmV2sPUVpYX exXUk0RxLUn/kBuQGyVaw0dCz5af/Ck6X0z7Lda4IVwoT8bQ19Db4Wf5YJQrnY0o TM2fdwUSQi+i3vqeCqpDZrh9uc8IMwmsDNVW2Qt4Cn95M2gHzyZCIxdPsO6w+afL 4H6crVW7yb20rtuu25PP =thRS -----END PGP SIGNATURE----- --0Si0CC5O4OCLQ8WswTt364qjMemUNdge6-- From nobody Sun Nov 5 11:05:10 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C0A13FACD for ; Sun, 5 Nov 2017 11:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 UwIaHP5YOsYp for ; Sun, 5 Nov 2017 11:05:02 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9262113F963 for ; Sun, 5 Nov 2017 11:05:02 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vA5J2UK5000340; Sun, 5 Nov 2017 19:04:58 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=TgstMqKTCTylPgdr9UMI48QItBtq06tHaMFX2+by0ok=; b=HKHcM6IAIggWPS3sotRHtJODHg3NTMULqDEQNG36akdtSySaMVkbotcvmer7JSRJdXd1 vWYZyijTEa9pDWecI2WXqNDRrhfN4c1sRCoZegp1HzUVPwxu0oO5zpgBoMwSnSYDimqB kpPnRZEbcfwugPPvhF1UAqn3TGDhoSTrZ6LCA4G07i8AlvkFnAqMUNN0KQyrpAT3XKpC BTmu76/cN2Y7Z1uY0vrnKsw09ot4jGutq2HYCZGdz0yCT1AQcpyeau/mvh+Kt89IlZsa dpj/8XtXE4vXpPLwdsjSKUozCqicirW07K/bjGjAeizN4Tm4NK+EbNNcfQZAMOyT/rX8 0A== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050102.ppops.net-00190b01. with ESMTP id 2e13ggcfpe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 05 Nov 2017 19:04:57 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vA5J0wGB022382; Sun, 5 Nov 2017 14:04:57 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2e18vu30n8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 05 Nov 2017 14:04:57 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 5 Nov 2017 14:04:56 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Sun, 5 Nov 2017 14:04:56 -0500 From: "Salz, Rich" To: Melinda Shore , Ted Lemon CC: "" Thread-Topic: [TLS] TLS@IETF100: Agenda Requests Thread-Index: AQHTTOWwew2Q2aAdy06XmH3DbvIHJqMBmwaAgAAAv4CABB1BAIAAbfWAgAABt4CAADI1gIAAAX8AgAAuzACAAADEAA== Date: Sun, 5 Nov 2017 19:04:55 +0000 Message-ID: <793608D3-3BAA-40A4-8B9A-FBF861580FF1@akamai.com> References: <732B27C6-817B-4F02-BF5D-0EDCBDB91793@sn3rd.com> <6B3ADE1C-1019-4C81-BA94-EA3737ADED1A@akamai.com> <0A8DF483-9DAD-48CD-A1BE-A6FECE490C69@akamai.com> <376386A6-B12C-4C8B-92BA-7E187ED53DE3@akamai.com> <2F651580-211E-44F0-A3A8-A873B016E03D@fugue.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.42.251] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-05_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711050275 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-05_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711050275 Archived-At: Subject: Re: [TLS] TLS@IETF100: Agenda Requests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 19:05:08 -0000 4p6iIEF0IGFueSByYXRlLCB0aGUgZGlzY3Vzc2lvbiBvZiB0aGUgcHJvcG9zYWwsIGlmIHRoZXJl IGlzIHRvIGJlIG9uZSwNCiAgICBiZWxvbmdzIG9uIHRoZSBtYWlsaW5nIGxpc3QuICBIYXZpbmcg dGhlIGRpc2N1c3Npb24gYW5kIGNvbWluZyB0bw0KICAgIGEgY29uY2x1c2lvbiAxKSBkdXJpbmcg YSBtZWV0aW5nIDIpIHdoZXJlIG5vbmUgb2YgdGhlIHByb3BvbmVudHMNCiAgICBpcyBwcmVzZW50 IHNlZW1zIGxpa2UgYW4gYWJ1c2Ugb2YgcHJvY2VzcyB0byBtZQ0KDQpJIGFza2VkIGZvciB0aW1l IHNvIHRoYXQgd2UgY291bGQgZGlzY3VzcyBpdC4gIE9mIGNvdXJzZSwgYWxsIGRlY2lzaW9ucyBh cmUgY29uZmlybWVkIG9uIHRoZSBtYWlsaW5nIGxpc3QgYW5kIEkgbmV2ZXIgbWVhbnQgb3RoZXJ3 aXNlLiAgU29ycnkgZm9yIGFzc3VtaW5nIGV2ZXJ5b25lIHVuZGVyc3Rvb2QuDQoNCg0KDQoNCg== From nobody Sun Nov 5 17:57:26 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7547C13FA27 for ; Sun, 5 Nov 2017 17:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com 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 cWTKXa9wNx_d for ; Sun, 5 Nov 2017 17:57:21 -0800 (PST) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 CFE6A13F88D for ; Sun, 5 Nov 2017 17:57:21 -0800 (PST) Received: by mail-pf0-x230.google.com with SMTP id a8so6584699pfc.0 for ; Sun, 05 Nov 2017 17:57:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pITbxZYiVBNG+xjzAhiH0wZlRIabJuols+DJe6inHHc=; b=a4dHmyn95teSXNDgrFFiWrWTRkQVcQV3NCMurAR8I1r4GfG49Br8AmzkP01T4dxS8I xJsUi7IuDUjZ9MeYqBXXDsU3RRbK8cmDJmD3QhyLR/5jJlEJ+r7AK5gER4pO+Flo/Ktg jbYaUgktBoY0Xtzhv7pq7OPXoZPqXTEjjnMx+Dd5AfYair5m0Ack/s99bT6jkJk76mzT lhRK06eDDxgCQ/MPRL042Qa+ajfCi+XL0o73/2xLQZJEVhogJhm16ZAhOu+DK42htHYs PequXV4kCh7vfqZx/Naxxsww4ZxksH/zVudCG9X70BQwNXFtB29FW78bYXtv98hkFCri NZtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pITbxZYiVBNG+xjzAhiH0wZlRIabJuols+DJe6inHHc=; b=UkbLOgMxpjtV5oHp0nAejzpa46U08PyyjLGIEmOuzR4de0e9CiNJjeJf50LNwaRent 5A/3Akz6b0sYExEGprkmd413StnJ9I9LSjN4NSHqlbTaAa8qc5UCRzV1NX3Iv8RqVmM8 YRfReaY4tp/V9Som798hiPgokQW/uZ5iGpPeHcWOnLhgYaXlNRUxMDlorxsYdMZ8aRsH 0Gwf6unDch5QcXvGUVOHdgPuyAaljhJotQrYt1dkcgv/fZpN6uxlgJi5sd5+Htid+7mx MzIUmUXM6UwqOsgDx8sO1jDBaqx1LFHq3SLk7cVUOfxSy3Colu7goZqOAhL6rgeNYyAz x89w== X-Gm-Message-State: AMCzsaV3ovStQqxJ2CQ3AacCmnrkCm1w0xxYddwvssS6fB7UyU2ffzXR xUrRIk7k3E/9x9g9yQGYd8QC995LqkbNcuOlssBlUcdn X-Google-Smtp-Source: ABhQp+QZzudcNMIGcYp3W6TGWlRjnxoA9yliLdiqBXjlscUY1ICvvR76NVhzueEWoiEMfFn5O6neCpZHVz7vj8wgmLQ= X-Received: by 10.99.185.79 with SMTP id v15mr13851863pgo.258.1509933441291; Sun, 05 Nov 2017 17:57:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.218.165 with HTTP; Sun, 5 Nov 2017 17:57:00 -0800 (PST) In-Reply-To: References: From: Joseph Salowey Date: Sun, 5 Nov 2017 17:57:00 -0800 Message-ID: To: Cas Cremers Cc: Richard Barnes , "" Content-Type: multipart/alternative; boundary="94eb2c1bae06673541055d46c699" Archived-At: Subject: Re: [TLS] Technical comment on design draft-rhrd-tls-tls13-visibility-00: why also break integrity/authentication? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 01:57:24 -0000 --94eb2c1bae06673541055d46c699 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm not sure what use cases you are targeting, but this type of solution can be dangerous for application security. Most application security models assume that TLS will provide both confidentiality and authenticity. Breaking confidentiality will often expose vulnerabilities that can result in escalation of privilege or spoofing resulting in a loss of integrity/authenticity in the application. For example, the use bearer tokens such as passwords or session cookies is widespread. It will take much more work to make applications resilient to loss of confidentiality. There may be use cases where confidentiality compromise is limited to just confidentiality, but I think these are in the minority. Joe On Fri, Nov 3, 2017 at 7:41 AM, Cas Cremers wrote= : > Hi Richard, > > Thanks for the pointer, I had missed your earlier observation of > essentially the same thing in the large mail threads. > > Personally, I think it is a substantial and unmotivated loss in security > to also give up authentication/integrity. > > Note that any changes towards PERC would require some significant changes > in the security analyses; for mctls, I expect it would be a completely ne= w > analysis. (I haven't seen any analyses of rhrd, but of the three, it is o= f > course closest to the current setup.) > > Best, > > Cas > > > On Fri, Nov 3, 2017 at 2:00 PM, Richard Barnes wrote: > >> Hey Cas, >> >> This question is a good one. Earlier I brought up mcTLS, which some >> folks have been working on to provide even more granular separations tha= n >> you suggest: >> >> https://mctls.org/ >> >> I think the authors of draft-rhrd are trying for a more lightweight >> change to TLS. That said, there might be some intermediate points on th= e >> spectrum here. For example, you could define a TLS ciphersuite akin to >> what we defined in PERC when we wanted to break integrity partly and >> confidentiality not at all. >> >> https://tools.ietf.org/html/draft-ietf-perc-double-07 >> >> That would be less invasive than mcTLS, while still getting the >> properties you describe. >> >> --Richard >> >> >> On Nov 3, 2017 09:43, "Cas Cremers" wrote: >> >> Dear all, >> =E2=80=8B=E2=80=8B >> =E2=80=8B=E2=80=8BDisclaimer: I am not a proponent of the idea behind dr= aft >> visibility/green/rhrd; I think such a mechanism should not be part of th= e >> TLS 1.3 standard. >> =E2=80=8B=E2=80=8B >> =E2=80=8B=E2=80=8BI have a technical problem with the current design, wh= ose goal is to >> allow eavesdropping for inspection, i.e., selectively decreasing >> confidentiality. >> =E2=80=8B=E2=80=8B >> =E2=80=8B=E2=80=8BHowever, the design in the draft also enables arbitrar= y traffic >> modification/insertion, additionally breaking all authentication and >> integrity guarantees. Once someone has the session keys, they can not on= ly >> eavesdrop but can also start to insert/modify traffic. This additional >> decrease in security is entirely unmotivated by the cited use cases. >> =E2=80=8B=E2=80=8B >> =E2=80=8B=E2=80=8BIt is possible to offer authentication and integrity, = while selectively >> giving up confidentiality. For example, one could replace the AEAD by (i= ) a >> mechanism for authentication and (ii) a separate mechanism for >> confidentiality, and then possibly reveal the keys used for (ii), but ma= ke >> sure only the real endpoint has the keys for (i). That seems more ration= al >> to me, and may retain the authentication/integrity guarantees. However, = it >> would require a much more invasive change. >> =E2=80=8B=E2=80=8B >> =E2=80=8B=E2=80=8BBest, >> =E2=80=8B=E2=80=8B >> =E2=80=8B=E2=80=8BCas >> >> >> _______________________________________________ >> 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 > > --94eb2c1bae06673541055d46c699 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not sure what use cases you are targeting, but thi= s type of solution can be dangerous for application security. Most applicat= ion security models assume that TLS will provide both confidentiality and a= uthenticity. Breaking confidentiality will often expose vulnerabilities tha= t can result in escalation of privilege or spoofing resulting in a loss of = integrity/authenticity in the application. For example, the use bearer toke= ns such as passwords or session cookies is widespread. It will take much mo= re work to make applications resilient to loss of confidentiality. There ma= y be use cases where confidentiality compromise is limited to just confiden= tiality, but I think these are in the minority.=C2=A0=C2=A0

<= div>Joe

On Fri, Nov 3, 2017 at 7:41 AM, Cas Cremers <cas.cremers@cs.ox.ac.= uk> wrote:
Hi Richard,

Thanks for the pointer, I had missed your e= arlier observation of essentially the same thing in the large mail threads.=

Personally, I think it is a substantial and unmot= ivated loss in security to also give up authentication/integrity.

Note that any changes towards PERC would require some signi= ficant changes in the security analyses; for mctls, I expect it would be a = completely new analysis. (I haven't seen any analyses of rhrd, but of t= he three, it is of course closest to the current setup.)

Best,

Cas


On= Fri, Nov 3, 2017 at 2:00 PM, Richard Barnes <rlb@ipv.sx> wrote:
Hey Cas,

This question is a good one.=C2=A0 Earlier I = brought up mcTLS, which some folks have been working on to provide even mor= e granular separations than you suggest:

<= div dir=3D"auto">https://m= ctls.org/

I thin= k the authors of draft-rhrd are trying for a more lightweight change to TLS= .=C2=A0 That said, there might be some intermediate points on the spectrum = here.=C2=A0 For example, you could define a TLS ciphersuite akin to what we= defined in PERC when we wanted to break integrity partly and confidentiali= ty not at all.=C2=A0

https://tools.ietf.org/html/draft-ietf-perc-double-07

That would be less invasiv= e than mcTLS, while still getting the properties you describe.=C2=A0
<= div dir=3D"auto">
--Richard


On Nov 3, 2017 09:43, "Cas Cremers" = <cas.cremer= s@cs.ox.ac.uk> wrote:
Dear all,
=E2=80= =8B=E2=80=8B
=E2=80=8B=E2=80=8BDisclaimer: I am not a proponent o= f the idea behind draft visibility/green/rhrd; I think such a mechanism sho= uld not be part of the TLS 1.3 standard.
=E2=80=8B=E2=80=8B
=
=E2=80=8B=E2=80=8BI have a technical problem with the current design, = whose goal is to allow eavesdropping for inspection, i.e., selectively decr= easing confidentiality.
=E2=80=8B=E2=80=8B
=E2=80=8B=E2= =80=8BHowever, the design in the draft also enables arbitrary traffic modif= ication/insertion, additionally breaking all authentication and integrity g= uarantees. Once someone has the session keys, they can not only eavesdrop b= ut can also start to insert/modify traffic. This additional decrease in sec= urity is entirely unmotivated by the cited use cases.
=E2=80=8B= =E2=80=8B
=E2=80=8B=E2=80=8BIt is possible to offer authenticatio= n and integrity, while selectively giving up confidentiality. For example, = one could replace the AEAD by (i) a mechanism for authentication and (ii) a= separate mechanism for confidentiality, and then possibly reveal the keys = used for (ii), but make sure only the real endpoint has the keys for (i). T= hat seems more rational to me, and may retain the authentication/integrity = guarantees. However, it would require a much more invasive change.
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8BBest,
=E2=80=8B= =E2=80=8B
=E2=80=8B=E2=80=8BCas


_______________________________________________
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


--94eb2c1bae06673541055d46c699-- From nobody Sun Nov 5 18:05:22 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B33913FAD7 for ; Sun, 5 Nov 2017 18:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 xrEax7o9gjD4 for ; Sun, 5 Nov 2017 18:05:19 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8200C13F88D for ; Sun, 5 Nov 2017 18:05:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 471A0BE2E; Mon, 6 Nov 2017 02:05:17 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ND7p1PSIFNgR; Mon, 6 Nov 2017 02:05:15 +0000 (GMT) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1EB54BE24; Mon, 6 Nov 2017 02:05:15 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1509933915; bh=TqSQCujArm9dDirMawbH1NCFXbKRhO6zXctxfexROyA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=CwmWc/EggQY2Nf5bTwUTLhyHzhXSnWQH0g65wG41haDcLZVuedizNes+BTxfpUmUb 6tSk1USUDzRqrpXn+9wL+sgSyAa5fH14K6Wv9weU1IfCokoRbO2ZxFWKvHWoM9BsrG zCBwxVi7ZA+BiY3u9U+r2PS1f4UiLibxuGqMGUJo= To: Joseph Salowey , Cas Cremers Cc: "" References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Mon, 6 Nov 2017 02:05:14 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Blp2gLBUKEq1WomUmlU1v2Tg58uRG9IHN" Archived-At: Subject: Re: [TLS] Technical comment on design draft-rhrd-tls-tls13-visibility-00: why also break integrity/authentication? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 02:05:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Blp2gLBUKEq1WomUmlU1v2Tg58uRG9IHN Content-Type: multipart/mixed; boundary="1g2K1x67pjqaQkEJ5jleWNLSSI18iwxSj"; protected-headers="v1" From: Stephen Farrell To: Joseph Salowey , Cas Cremers Cc: "" Message-ID: Subject: Re: [TLS] Technical comment on design draft-rhrd-tls-tls13-visibility-00: why also break integrity/authentication? References: In-Reply-To: --1g2K1x67pjqaQkEJ5jleWNLSSI18iwxSj Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hi Joe, On 06/11/17 01:57, Joseph Salowey wrote: > I'm not sure what use cases you are targeting, but this type of solutio= n > can be dangerous for application security. Most application security mo= dels > assume that TLS will provide both confidentiality and authenticity. > Breaking confidentiality will often expose vulnerabilities that can res= ult > in escalation of privilege or spoofing resulting in a loss of > integrity/authenticity in the application. For example, the use bearer > tokens such as passwords or session cookies is widespread. It will take= > much more work to make applications resilient to loss of confidentialit= y. > There may be use cases where confidentiality compromise is limited to j= ust > confidentiality, but I think these are in the minority. I kind-of agree but not fully. Where we agree is that any change to the basic security services offered by TLS affect the interface between the TLS layer and the application. Ans any changes caused by breaking-TLS will break applications, as the existing APIs will no longer match whatever security model was in the application developer's mind when code was written. We also have real-world measurements that show that TLS APIs are frequently misused by developers in any case, so there is little hope that some more complex API that does reflect broken-TLS can ever be effective. Bottom line: breaking TLS will break many applications, regardless of how one chooses to break TLS, partly at least because the interfaces between TLS and applications do not envisage broken-TLS. S. >=20 > Joe >=20 > On Fri, Nov 3, 2017 at 7:41 AM, Cas Cremers w= rote: >=20 >> Hi Richard, >> >> Thanks for the pointer, I had missed your earlier observation of >> essentially the same thing in the large mail threads. >> >> Personally, I think it is a substantial and unmotivated loss in securi= ty >> to also give up authentication/integrity. >> >> Note that any changes towards PERC would require some significant chan= ges >> in the security analyses; for mctls, I expect it would be a completely= new >> analysis. (I haven't seen any analyses of rhrd, but of the three, it i= s of >> course closest to the current setup.) >> >> Best, >> >> Cas >> >> >> On Fri, Nov 3, 2017 at 2:00 PM, Richard Barnes wrote: >> >>> Hey Cas, >>> >>> This question is a good one. Earlier I brought up mcTLS, which some >>> folks have been working on to provide even more granular separations = than >>> you suggest: >>> >>> https://mctls.org/ >>> >>> I think the authors of draft-rhrd are trying for a more lightweight >>> change to TLS. That said, there might be some intermediate points on= the >>> spectrum here. For example, you could define a TLS ciphersuite akin = to >>> what we defined in PERC when we wanted to break integrity partly and >>> confidentiality not at all. >>> >>> https://tools.ietf.org/html/draft-ietf-perc-double-07 >>> >>> That would be less invasive than mcTLS, while still getting the >>> properties you describe. >>> >>> --Richard >>> >>> >>> On Nov 3, 2017 09:43, "Cas Cremers" wrote: >>> >>> Dear all, >>> =E2=80=8B=E2=80=8B >>> =E2=80=8B=E2=80=8BDisclaimer: I am not a proponent of the idea behind= draft >>> visibility/green/rhrd; I think such a mechanism should not be part of= the >>> TLS 1.3 standard. >>> =E2=80=8B=E2=80=8B >>> =E2=80=8B=E2=80=8BI have a technical problem with the current design,= whose goal is to >>> allow eavesdropping for inspection, i.e., selectively decreasing >>> confidentiality. >>> =E2=80=8B=E2=80=8B >>> =E2=80=8B=E2=80=8BHowever, the design in the draft also enables arbit= rary traffic >>> modification/insertion, additionally breaking all authentication and >>> integrity guarantees. Once someone has the session keys, they can not= only >>> eavesdrop but can also start to insert/modify traffic. This additiona= l >>> decrease in security is entirely unmotivated by the cited use cases. >>> =E2=80=8B=E2=80=8B >>> =E2=80=8B=E2=80=8BIt is possible to offer authentication and integrit= y, while selectively >>> giving up confidentiality. For example, one could replace the AEAD by= (i) a >>> mechanism for authentication and (ii) a separate mechanism for >>> confidentiality, and then possibly reveal the keys used for (ii), but= make >>> sure only the real endpoint has the keys for (i). That seems more rat= ional >>> to me, and may retain the authentication/integrity guarantees. Howeve= r, it >>> would require a much more invasive change. >>> =E2=80=8B=E2=80=8B >>> =E2=80=8B=E2=80=8BBest, >>> =E2=80=8B=E2=80=8B >>> =E2=80=8B=E2=80=8BCas >>> >>> >>> _______________________________________________ >>> 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 >> >> >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --1g2K1x67pjqaQkEJ5jleWNLSSI18iwxSj-- --Blp2gLBUKEq1WomUmlU1v2Tg58uRG9IHN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZ/8NaAAoJEC88hzaAX42iiZsIAI0ga/tOPkeznul8z16Jz2Jh q8Qwsb4UePxYlkoruk9X9KQKK1XT9JcI5iOJYOzZCwMC0HC68lgI/LZARmjLDN8h js/UYlk7D+OE70QoYY8V12Dl7IPpyeLG+eDZYfTZFP1kBH4rx0TMB/Ha5pEDhQn6 M+ndL/YWhPuSGqrNoDWgHeufIZUtXAEP1Cmqh5GaKsaQieLHNt0fxqKfx5wjosK1 YYlumY09CsOWB/8PUMghW9ubG7ZEHHiPQTdMLsrt+o+48ICEzzJN148PH4g2Jv2/ UnluxWq3V3YXaqi6hMDYu67vyc+b8EUUbbHBopFthXRo3joYlSf9cTX4iUFEBO0= =jpXz -----END PGP SIGNATURE----- --Blp2gLBUKEq1WomUmlU1v2Tg58uRG9IHN-- From nobody Sun Nov 5 19:38:43 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E175B13FAE2 for ; Sun, 5 Nov 2017 19:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com 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 OgoLiwrDgLAA for ; Sun, 5 Nov 2017 19:38:39 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::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 3F27813FAD8 for ; Sun, 5 Nov 2017 19:38:39 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id r196so11361020wmf.2 for ; Sun, 05 Nov 2017 19:38:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=A/0KzB0f3ceh1ytx+EQg1khgB04Gd64K1stVrweCiTs=; b=wNbM6ET5Es6Gi3fi7grnbpXnWK9jKrDArZ1En7gvGr0QS5Qo3UKWnEm62UDXjlYvft rNB6taQzgaoLzU70byLKwICvdDTiOUkD80W6ryGx8dRg3mc/IMJaxqCPKBTY3KSZAPVv DCT9bMLZt2OvW3IPvOUgpjytB6QsgG5ZGPHQwrjirHrIjdaCrmrAUAQIn6istwqv78hi uPkN3qfE3NHSXScqzbgTW1kAflwKB+edpDgT5HJDpsgrJlORqGghDPVr8KCz+62Rcg7O U/3JER10PyKPJJ2fOu/Vxjno4iUrKEXy6M18BTfa2fuqGbGtdayRAIXfHC0Khh0oQP/n Ed/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=A/0KzB0f3ceh1ytx+EQg1khgB04Gd64K1stVrweCiTs=; b=qSbtxf1qYO3c2wW16n34Y0YnbUWFQ7eCiz64ffGkvjvNe8Tu2ke9bWQ6462YEjuejA cllSXESKjdn2PR+r4/zoohHQXyISh2kHsP+H3YL2VIwrgI+kefWCEbbZvhaVCE+W0eTM tf5Z2LuHV5w1GrR0EFaEnTuUpdQteELLO5WE48+UPcEZM2GL+VG8kgpvJs+zC1547VUW YPYixhGMs8tbSeswx0KRNlZhioomcmrhnyXh4nBNGkAQD7vetVt24K34yQILFXO3aTL2 aYgUBfKYOGtVMnE2FuRMLNgjF/viFSfbbHYMjokRYJSSliPBOzWXjznUaG+osK5fbUih 3uJw== X-Gm-Message-State: AJaThX46ev9HlxRBeS5NNMawveTYcZww/Q4eG3LcXlVSUYYssz+n0AEI jmDZ/XzMl8WXzY9tkCXIZIB8AdSSt2RO2tnCq9fLGw== X-Google-Smtp-Source: ABhQp+QK8CdBP06GTcrNAur+ntTl12t1XDvtTSypCY3EfYj/bcx9hlOHPOFlO6IauFzo5z2bOVcnaIhE+xZ2wyrrRtU= X-Received: by 10.28.192.25 with SMTP id q25mr3844005wmf.98.1509939517348; Sun, 05 Nov 2017 19:38:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.174.81 with HTTP; Sun, 5 Nov 2017 19:38:36 -0800 (PST) In-Reply-To: References: From: Richard Barnes Date: Sun, 5 Nov 2017 22:38:36 -0500 Message-ID: To: Joseph Salowey Cc: Cas Cremers , "" Content-Type: multipart/alternative; boundary="089e082fa15c907084055d4830bc" Archived-At: Subject: Re: [TLS] Technical comment on design draft-rhrd-tls-tls13-visibility-00: why also break integrity/authentication? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 03:38:42 -0000 --089e082fa15c907084055d4830bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I understood Cas to be observing that you could in principle remove confidentiality with regard to the third party to whom keys are being exfiltrated, without also removing integrity and authenticity. So the third party could observe application traffic, but not modify or inject. The solution in draft-rhrd removes all three properties with regard to the third party (all still of course hold with regard to all other attackers). So you would still have a risk of violating applications' assumptions with regard to confidentiality, but only with regard to confidentiality, and only relative to the chosen third party. To Stephen's point, though, this is of course a pretty subtle point for application developers to understand= . --Richard On Sun, Nov 5, 2017 at 8:57 PM, Joseph Salowey wrote: > I'm not sure what use cases you are targeting, but this type of solution > can be dangerous for application security. Most application security mode= ls > assume that TLS will provide both confidentiality and authenticity. > Breaking confidentiality will often expose vulnerabilities that can resul= t > in escalation of privilege or spoofing resulting in a loss of > integrity/authenticity in the application. For example, the use bearer > tokens such as passwords or session cookies is widespread. It will take > much more work to make applications resilient to loss of confidentiality. > There may be use cases where confidentiality compromise is limited to jus= t > confidentiality, but I think these are in the minority. > > Joe > > On Fri, Nov 3, 2017 at 7:41 AM, Cas Cremers > wrote: > >> Hi Richard, >> >> Thanks for the pointer, I had missed your earlier observation of >> essentially the same thing in the large mail threads. >> >> Personally, I think it is a substantial and unmotivated loss in security >> to also give up authentication/integrity. >> >> Note that any changes towards PERC would require some significant change= s >> in the security analyses; for mctls, I expect it would be a completely n= ew >> analysis. (I haven't seen any analyses of rhrd, but of the three, it is = of >> course closest to the current setup.) >> >> Best, >> >> Cas >> >> >> On Fri, Nov 3, 2017 at 2:00 PM, Richard Barnes wrote: >> >>> Hey Cas, >>> >>> This question is a good one. Earlier I brought up mcTLS, which some >>> folks have been working on to provide even more granular separations th= an >>> you suggest: >>> >>> https://mctls.org/ >>> >>> I think the authors of draft-rhrd are trying for a more lightweight >>> change to TLS. That said, there might be some intermediate points on t= he >>> spectrum here. For example, you could define a TLS ciphersuite akin to >>> what we defined in PERC when we wanted to break integrity partly and >>> confidentiality not at all. >>> >>> https://tools.ietf.org/html/draft-ietf-perc-double-07 >>> >>> That would be less invasive than mcTLS, while still getting the >>> properties you describe. >>> >>> --Richard >>> >>> >>> On Nov 3, 2017 09:43, "Cas Cremers" wrote: >>> >>> Dear all, >>> =E2=80=8B=E2=80=8B >>> =E2=80=8B=E2=80=8BDisclaimer: I am not a proponent of the idea behind d= raft >>> visibility/green/rhrd; I think such a mechanism should not be part of t= he >>> TLS 1.3 standard. >>> =E2=80=8B=E2=80=8B >>> =E2=80=8B=E2=80=8BI have a technical problem with the current design, w= hose goal is to >>> allow eavesdropping for inspection, i.e., selectively decreasing >>> confidentiality. >>> =E2=80=8B=E2=80=8B >>> =E2=80=8B=E2=80=8BHowever, the design in the draft also enables arbitra= ry traffic >>> modification/insertion, additionally breaking all authentication and >>> integrity guarantees. Once someone has the session keys, they can not o= nly >>> eavesdrop but can also start to insert/modify traffic. This additional >>> decrease in security is entirely unmotivated by the cited use cases. >>> =E2=80=8B=E2=80=8B >>> =E2=80=8B=E2=80=8BIt is possible to offer authentication and integrity,= while >>> selectively giving up confidentiality. For example, one could replace t= he >>> AEAD by (i) a mechanism for authentication and (ii) a separate mechanis= m >>> for confidentiality, and then possibly reveal the keys used for (ii), b= ut >>> make sure only the real endpoint has the keys for (i). That seems more >>> rational to me, and may retain the authentication/integrity guarantees. >>> However, it would require a much more invasive change. >>> =E2=80=8B=E2=80=8B >>> =E2=80=8B=E2=80=8BBest, >>> =E2=80=8B=E2=80=8B >>> =E2=80=8B=E2=80=8BCas >>> >>> >>> _______________________________________________ >>> 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 >> >> > --089e082fa15c907084055d4830bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I understood Cas to be observing that you could in pr= inciple remove confidentiality with regard to the third party to whom keys = are being exfiltrated, without also removing integrity and authenticity.=C2= =A0 So the third party could observe application traffic, but not modify or= inject.=C2=A0 The solution in draft-rhrd removes all three properties with= regard to the third party (all still of course hold with regard to all oth= er attackers).

So you would still have a risk = of violating applications' assumptions with regard to confidentiality, = but only with regard to confidentiality, and only relative to the chosen th= ird party.=C2=A0=C2=A0 To Stephen's point, though, this is of course a = pretty subtle point for application developers to understand.
--Richard


On Sun, Nov 5, 2017 at 8:57 PM, Joseph Salowey <joe@= salowey.net> wrote:
I'm not sure what use cases you are targeting, but this type = of solution can be dangerous for application security. Most application sec= urity models assume that TLS will provide both confidentiality and authenti= city. Breaking confidentiality will often expose vulnerabilities that can r= esult in escalation of privilege or spoofing resulting in a loss of integri= ty/authenticity in the application. For example, the use bearer tokens such= as passwords or session cookies is widespread. It will take much more work= to make applications resilient to loss of confidentiality. There may be us= e cases where confidentiality compromise is limited to just confidentiality= , but I think these are in the minority.=C2=A0=C2=A0

Joe=

On Fri, Nov 3, 2017 at 7:41 AM, Cas Crem= ers <cas.cremers@cs.ox.ac.uk> wrote:
Hi Richard,

Thanks for= the pointer, I had missed your earlier observation of essentially the same= thing in the large mail threads.

Personally, I th= ink it is a substantial and unmotivated loss in security to also give up au= thentication/integrity.

Note that any changes towa= rds PERC would require some significant changes in the security analyses; f= or mctls, I expect it would be a completely new analysis. (I haven't se= en any analyses of rhrd, but of the three, it is of course closest to the c= urrent setup.)

Best,

Cas


= On Fri, Nov 3, 2017 at 2:00 PM, Richard Barnes <rlb@ipv.sx> wrote:<= br>
Hey Cas,

This question is a good one.=C2=A0 Earlier I= brought up mcTLS, which some folks have been working on to provide even mo= re granular separations than you suggest:

=

I thi= nk the authors of draft-rhrd are trying for a more lightweight change to TL= S.=C2=A0 That said, there might be some intermediate points on the spectrum= here.=C2=A0 For example, you could define a TLS ciphersuite akin to what w= e defined in PERC when we wanted to break integrity partly and confidential= ity not at all.=C2=A0

https://tools.ietf.org/html/draft-ietf-perc-double-07

That would be less invasi= ve than mcTLS, while still getting the properties you describe.=C2=A0
=

--Richard


On Nov 3, 2017 09:43, &q= uot;Cas Cremers" <cas.cremers@cs.ox.ac.uk> wrote:
=
Dear all,
=E2=80=8B=E2=80= =8B
=E2=80=8B=E2=80=8BDisclaimer: I am not a proponent of the ide= a behind draft visibility/green/rhrd; I think such a mechanism should not b= e part of the TLS 1.3 standard.
=E2=80=8B=E2=80=8B
=E2= =80=8B=E2=80=8BI have a technical problem with the current design, whose go= al is to allow eavesdropping for inspection, i.e., selectively decreasing c= onfidentiality.
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8BHo= wever, the design in the draft also enables arbitrary traffic modification/= insertion, additionally breaking all authentication and integrity guarantee= s. Once someone has the session keys, they can not only eavesdrop but can a= lso start to insert/modify traffic. This additional decrease in security is= entirely unmotivated by the cited use cases.
=E2=80=8B=E2=80=8B<= /div>
=E2=80=8B=E2=80=8BIt is possible to offer authentication and inte= grity, while selectively giving up confidentiality. For example, one could = replace the AEAD by (i) a mechanism for authentication and (ii) a separate = mechanism for confidentiality, and then possibly reveal the keys used for (= ii), but make sure only the real endpoint has the keys for (i). That seems = more rational to me, and may retain the authentication/integrity guarantees= . However, it would require a much more invasive change.
=E2=80= =8B=E2=80=8B
=E2=80=8B=E2=80=8BBest,
=E2=80=8B=E2=80=8B=
=E2=80=8B=E2=80=8BCas


_______________________________________________
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



--089e082fa15c907084055d4830bc-- From nobody Sun Nov 5 20:39:57 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90BBD13FAFB for ; Sun, 5 Nov 2017 20:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com 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 VKsovbM03FbY for ; Sun, 5 Nov 2017 20:39:53 -0800 (PST) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (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 65F5F13FAE0 for ; Sun, 5 Nov 2017 20:39:53 -0800 (PST) Received: by mail-pg0-x236.google.com with SMTP id b192so7287851pga.2 for ; Sun, 05 Nov 2017 20:39:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oyWO9FOZldKC/i1/ANDCz2cL0bNlEP55QqpuX7QqUUg=; b=mrHBfjSBEA5zkJQbumx9iIzMqF2jt5xtB9POTpwqdXjHWtZpFlm8uU7IconHiZSQ5O Fqb5g3Vjyc8KGyfNnwit6/MsfKkPONS135sUcV/Rd/yBbbITA4iP9CQxZTaTKgkHq+4M KDa5dkczRdX3Jvt5fLkNIaKcyOqWYk9uHneiu1uTWhOgCVrLsO1CjbNYiVMPxINrBLIC 5oaOXbCtovOI0vYwJCYdCqceiLtNEoJLnRJDQ9pcjL2cXWCqzM9mq6qwUPAF+JKb+WrQ PH/OtvvEKRf427I9adrqOZGavql8tqd6blyMWUlWSezo7ScmuAHJ8NDNNxqdlDK4OCMA eyow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oyWO9FOZldKC/i1/ANDCz2cL0bNlEP55QqpuX7QqUUg=; b=OJi6GLoC3Rnlc8iSzfT/6zHcej+yTCJQwZBgD2Hdr32WotUHDSeKeJK7pnsQz5yhUv zTNN204BsW2oCluHeUkwpgC2UwQz4kGYLvGd2V/4nlXGF1pjWrwqFtUESzlPVhmqV2BS 4q/rP4skOVW3W/qsG9VcEvt51AUdjR3ukNowKf4V+gksGB3Ofe4rVAgijDfo/bsR96G/ +EEYqroojjj/S8ZOZP0haQeSyVowbVfvlt4Gy3yhWfRfOQgCjJttEiWni/oC0q45izpK LAg4T836ecqmxnI6FDE40OkbKXQB4QVYbhxgmoJqgUG1Er0WiRFINVLrvAYuPeDkNymS C/FA== X-Gm-Message-State: AMCzsaWExE083inewsondW6DvEYJGJp+fnzfhAP+MYlNtIhcu6PMfnUD pueZ0qOCd3S57BWq+ajnpZIRdrCz8gyAm4NoKtXgfQ== X-Google-Smtp-Source: ABhQp+RKidXs0OBqjRCcZDJr3HlwP0Qlab8qH7deZxEyqlvHdNPpxcIy/RmbIVuckxVd9eq0lD1jYJhtnYCmaDDGYU8= X-Received: by 10.84.143.195 with SMTP id 61mr13625717plz.357.1509943192814; Sun, 05 Nov 2017 20:39:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.218.165 with HTTP; Sun, 5 Nov 2017 20:39:32 -0800 (PST) In-Reply-To: References: From: Joseph Salowey Date: Sun, 5 Nov 2017 20:39:32 -0800 Message-ID: To: Richard Barnes Cc: Cas Cremers , "" Content-Type: multipart/alternative; boundary="94eb2c11a2a8a39b5f055d490bc5" Archived-At: Subject: Re: [TLS] Technical comment on design draft-rhrd-tls-tls13-visibility-00: why also break integrity/authentication? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 04:39:55 -0000 --94eb2c11a2a8a39b5f055d490bc5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm in agreement with Stephen. If you compromise TLS confidentiality you are going to break application security. For most applications a loss in confidentiality in TLS will have an impact in other aspects of security. The third-party will often be able to inject application traffic, although it may need to do this over a separate connection. On Sun, Nov 5, 2017 at 7:38 PM, Richard Barnes wrote: > I understood Cas to be observing that you could in principle remove > confidentiality with regard to the third party to whom keys are being > exfiltrated, without also removing integrity and authenticity. So the > third party could observe application traffic, but not modify or inject. > The solution in draft-rhrd removes all three properties with regard to th= e > third party (all still of course hold with regard to all other attackers)= . > > So you would still have a risk of violating applications' assumptions wit= h > regard to confidentiality, but only with regard to confidentiality, and > only relative to the chosen third party. To Stephen's point, though, th= is > is of course a pretty subtle point for application developers to understa= nd. > > --Richard > > > On Sun, Nov 5, 2017 at 8:57 PM, Joseph Salowey wrote: > >> I'm not sure what use cases you are targeting, but this type of solution >> can be dangerous for application security. Most application security mod= els >> assume that TLS will provide both confidentiality and authenticity. >> Breaking confidentiality will often expose vulnerabilities that can resu= lt >> in escalation of privilege or spoofing resulting in a loss of >> integrity/authenticity in the application. For example, the use bearer >> tokens such as passwords or session cookies is widespread. It will take >> much more work to make applications resilient to loss of confidentiality= . >> There may be use cases where confidentiality compromise is limited to ju= st >> confidentiality, but I think these are in the minority. >> >> Joe >> >> On Fri, Nov 3, 2017 at 7:41 AM, Cas Cremers >> wrote: >> >>> Hi Richard, >>> >>> Thanks for the pointer, I had missed your earlier observation of >>> essentially the same thing in the large mail threads. >>> >>> Personally, I think it is a substantial and unmotivated loss in securit= y >>> to also give up authentication/integrity. >>> >>> Note that any changes towards PERC would require some significant >>> changes in the security analyses; for mctls, I expect it would be a >>> completely new analysis. (I haven't seen any analyses of rhrd, but of t= he >>> three, it is of course closest to the current setup.) >>> >>> Best, >>> >>> Cas >>> >>> >>> On Fri, Nov 3, 2017 at 2:00 PM, Richard Barnes wrote: >>> >>>> Hey Cas, >>>> >>>> This question is a good one. Earlier I brought up mcTLS, which some >>>> folks have been working on to provide even more granular separations t= han >>>> you suggest: >>>> >>>> https://mctls.org/ >>>> >>>> I think the authors of draft-rhrd are trying for a more lightweight >>>> change to TLS. That said, there might be some intermediate points on = the >>>> spectrum here. For example, you could define a TLS ciphersuite akin t= o >>>> what we defined in PERC when we wanted to break integrity partly and >>>> confidentiality not at all. >>>> >>>> https://tools.ietf.org/html/draft-ietf-perc-double-07 >>>> >>>> That would be less invasive than mcTLS, while still getting the >>>> properties you describe. >>>> >>>> --Richard >>>> >>>> >>>> On Nov 3, 2017 09:43, "Cas Cremers" wrote: >>>> >>>> Dear all, >>>> =E2=80=8B=E2=80=8B >>>> =E2=80=8B=E2=80=8BDisclaimer: I am not a proponent of the idea behind = draft >>>> visibility/green/rhrd; I think such a mechanism should not be part of = the >>>> TLS 1.3 standard. >>>> =E2=80=8B=E2=80=8B >>>> =E2=80=8B=E2=80=8BI have a technical problem with the current design, = whose goal is to >>>> allow eavesdropping for inspection, i.e., selectively decreasing >>>> confidentiality. >>>> =E2=80=8B=E2=80=8B >>>> =E2=80=8B=E2=80=8BHowever, the design in the draft also enables arbitr= ary traffic >>>> modification/insertion, additionally breaking all authentication and >>>> integrity guarantees. Once someone has the session keys, they can not = only >>>> eavesdrop but can also start to insert/modify traffic. This additional >>>> decrease in security is entirely unmotivated by the cited use cases. >>>> =E2=80=8B=E2=80=8B >>>> =E2=80=8B=E2=80=8BIt is possible to offer authentication and integrity= , while >>>> selectively giving up confidentiality. For example, one could replace = the >>>> AEAD by (i) a mechanism for authentication and (ii) a separate mechani= sm >>>> for confidentiality, and then possibly reveal the keys used for (ii), = but >>>> make sure only the real endpoint has the keys for (i). That seems more >>>> rational to me, and may retain the authentication/integrity guarantees= . >>>> However, it would require a much more invasive change. >>>> =E2=80=8B=E2=80=8B >>>> =E2=80=8B=E2=80=8BBest, >>>> =E2=80=8B=E2=80=8B >>>> =E2=80=8B=E2=80=8BCas >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> > --94eb2c11a2a8a39b5f055d490bc5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm in agreement with Stephen.=C2=A0 If you compromise= TLS confidentiality you are going to break application security. For most = applications a loss in confidentiality in TLS will have an impact in other = aspects of security.=C2=A0 =C2=A0The third-party will often be able to inje= ct application traffic, although it may need to do this over a separate con= nection.=C2=A0

On Sun, Nov 5, 2017 at 7:38 PM, Richard Barnes <rlb@ipv.sx> wrot= e:
I understood Cas= to be observing that you could in principle remove confidentiality with re= gard to the third party to whom keys are being exfiltrated, without also re= moving integrity and authenticity.=C2=A0 So the third party could observe a= pplication traffic, but not modify or inject.=C2=A0 The solution in draft-r= hrd removes all three properties with regard to the third party (all still = of course hold with regard to all other attackers).

So you would still have a risk of violating applications' assumpt= ions with regard to confidentiality, but only with regard to confidentialit= y, and only relative to the chosen third party.=C2=A0=C2=A0 To Stephen'= s point, though, this is of course a pretty subtle point for application de= velopers to understand.

--Richard


On Sun, Nov 5, 2017 at 8:57 PM, Joseph Salowey <joe@salowey.net= > wrote:
I= 'm not sure what use cases you are targeting, but this type of solution= can be dangerous for application security. Most application security model= s assume that TLS will provide both confidentiality and authenticity. Break= ing confidentiality will often expose vulnerabilities that can result in es= calation of privilege or spoofing resulting in a loss of integrity/authenti= city in the application. For example, the use bearer tokens such as passwor= ds or session cookies is widespread. It will take much more work to make ap= plications resilient to loss of confidentiality. There may be use cases whe= re confidentiality compromise is limited to just confidentiality, but I thi= nk these are in the minority.=C2=A0=C2=A0

Joe

On Fri, N= ov 3, 2017 at 7:41 AM, Cas Cremers <cas.cremers@cs.ox.ac.uk><= /span> wrote:
Hi Richard= ,

Thanks for the pointer, I had missed your earlier obse= rvation of essentially the same thing in the large mail threads.
=
Personally, I think it is a substantial and unmotivated loss= in security to also give up authentication/integrity.

=
Note that any changes towards PERC would require some significant chan= ges in the security analyses; for mctls, I expect it would be a completely = new analysis. (I haven't seen any analyses of rhrd, but of the three, i= t is of course closest to the current setup.)

Best= ,

Cas


On= Fri, Nov 3, 2017 at 2:00 PM, Richard Barnes <rlb@ipv.sx> wrote:
Hey Cas,

This question is a good one.=C2=A0 Earlier I = brought up mcTLS, which some folks have been working on to provide even mor= e granular separations than you suggest:

<= div dir=3D"auto">https://m= ctls.org/

I thin= k the authors of draft-rhrd are trying for a more lightweight change to TLS= .=C2=A0 That said, there might be some intermediate points on the spectrum = here.=C2=A0 For example, you could define a TLS ciphersuite akin to what we= defined in PERC when we wanted to break integrity partly and confidentiali= ty not at all.=C2=A0

https://tools.ietf.org/html/draft-ietf-perc-double-07

That would be less invasiv= e than mcTLS, while still getting the properties you describe.=C2=A0
<= div dir=3D"auto">
--Richard


On = Nov 3, 2017 09:43, "Cas Cremers" <cas.cremers@cs.ox.ac.uk> wrote:
Dear all,
=E2=80=8B=E2=80=8B
= =E2=80=8B=E2=80=8BDisclaimer: I am not a proponent of the idea behind draft= visibility/green/rhrd; I think such a mechanism should not be part of the = TLS 1.3 standard.
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B= I have a technical problem with the current design, whose goal is to allow = eavesdropping for inspection, i.e., selectively decreasing confidentiality.=
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8BHowever, the desi= gn in the draft also enables arbitrary traffic modification/insertion, addi= tionally breaking all authentication and integrity guarantees. Once someone= has the session keys, they can not only eavesdrop but can also start to in= sert/modify traffic. This additional decrease in security is entirely unmot= ivated by the cited use cases.
=E2=80=8B=E2=80=8B
=E2= =80=8B=E2=80=8BIt is possible to offer authentication and integrity, while = selectively giving up confidentiality. For example, one could replace the A= EAD by (i) a mechanism for authentication and (ii) a separate mechanism for= confidentiality, and then possibly reveal the keys used for (ii), but make= sure only the real endpoint has the keys for (i). That seems more rational= to me, and may retain the authentication/integrity guarantees. However, it= would require a much more invasive change.
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8BBest,
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8BCas


_______________________________________________
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




--94eb2c11a2a8a39b5f055d490bc5-- From nobody Sun Nov 5 22:38:57 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F23013FB15 for ; Sun, 5 Nov 2017 22:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 68jvyL1ZxUz5 for ; Sun, 5 Nov 2017 22:38:53 -0800 (PST) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (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 045FC13FAD3 for ; Sun, 5 Nov 2017 22:38:53 -0800 (PST) Received: by mail-wr0-x22c.google.com with SMTP id j23so3348796wra.9 for ; Sun, 05 Nov 2017 22:38:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Gz1sjukK3KQOUMQdVt12c9o3wXjghdjx+sjTBMD7U1k=; b=tT4RiHcwYspeau512x1aAIuwqHrq/eXfznV8wuRlMf0evsTtXWNqECpkkiMkln/3Sc Hg6PWLyN/M8WFmwOQqh8xYEhdI0up3GUHOpLUXRvKM1Lqznj/xnDXxqAqgxmEJslEUqH KrjNvW5et4w0hEKXO/3dAvCqXf6ZWZUEssVOkSZY9TYtieZeA99G4nwx/6XGaHM5rFVI NNsKsayOY5Rcb8RLuKHYvTdEigH43ZC1RSnogT5+Jy2pzbnuwlrJze6AibCs1KhXSghR Lr89mrErTpcIwiUfNffIMqU85yjiMrL+2L3JZ+fKens8MczZdlhPa8UsKGheWq+XpO9s 2Bcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Gz1sjukK3KQOUMQdVt12c9o3wXjghdjx+sjTBMD7U1k=; b=K99OCFsobNy3Hr+reKMn86FT8wrHribzsS/0m4LHg8EbAWQfqrUCb9txooiRw6D65V 9lcTfcUhYeQ89TGINBmeu/mr94gajVoGHmeTuVZt26Rvr0PrqEOlLKvhjuClwKpyg5iW bWWrhnYkEfyrW/+46gBYBuKBuLlJq7kbHlHXhN9KjHD8PFK80guDXuBUxmFtRpKITJ+C 80zZbZtbElhVw31HSdv5+5Zn3LCghz97+gAck/ygo6F/GRo9bw4a2h97skltIN81FcV3 B2nm3LqlPrAK22AJwjD/9sOawNMBRGye+SAo3vtkoohOv9WyNjSuC6UwRCsHx4sep+ud xw7Q== X-Gm-Message-State: AMCzsaUg5ONM0ily7STZfLWTbiOfB3q3b+SV4M0isZl5kMVERxpCpPzC giH4cuqeE6uY6ojfGbNSPks= X-Google-Smtp-Source: ABhQp+TqBEygqlqQK4x9myvxn3/AXLF/rh+kpG7EFi/HRDwwKqkGd9xmENLzeEcm1HMQvTBW2K1mZw== X-Received: by 10.223.171.236 with SMTP id s99mr12571212wrc.145.1509950331421; Sun, 05 Nov 2017 22:38:51 -0800 (PST) Received: from [192.168.0.51] (ip-16.net-89-3-97.rev.numericable.fr. [89.3.97.16]) by smtp.gmail.com with ESMTPSA id 89sm3342566wro.25.2017.11.05.22.38.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Nov 2017 22:38:50 -0800 (PST) From: Karthikeyan Bhargavan Message-Id: <70496A24-F4C2-466E-9522-1832DCD134D1@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_2987D9FD-B1E1-4C24-8B35-26115584E9F3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Mon, 6 Nov 2017 07:38:48 +0100 In-Reply-To: Cc: Richard Barnes , Cas Cremers , "" To: Joseph Salowey References: X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [TLS] Technical comment on design draft-rhrd-tls-tls13-visibility-00: why also break integrity/authentication? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 06:38:56 -0000 --Apple-Mail=_2987D9FD-B1E1-4C24-8B35-26115584E9F3 Content-Type: multipart/alternative; boundary="Apple-Mail=_26C57447-C650-4E3F-8A04-DA018E3E6246" --Apple-Mail=_26C57447-C650-4E3F-8A04-DA018E3E6246 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Visibility goes both ways. The discussion so far has been primarily = about making end-to-end data visible to middleboxes. It would less concerning to do it the other way round, where middleboxes = are made visible to the endpoints, and proxying/visbility decisions are = made at the endpoints. Indeed, this is one of the main ideas behind mcTLS: middleboxes don=E2=80=99= t get to transparently inject themselves into a TLS channel, they must = be authorized by *both* endpoints. But even a careful design like mcTLS ends up losing significant = authentication and integrity properties, both in the handshake and the = record layer. (If someone is interested, send me email, and I can give = you details.) So, I really don=E2=80=99t recommend any change to the TLS 1.3 design to = accomplish any of this, it is more likely that the change will break = =E2=80=9Cnormal=E2=80=9D TLS connections. If visibility is needed in some scenario, then I would prefer that it be = done at the application layer, by a proxy that is visible to and = authorized by at least one endpoint, if not both. -Karthik > On 6 Nov 2017, at 05:39, Joseph Salowey wrote: >=20 > I'm in agreement with Stephen. If you compromise TLS confidentiality = you are going to break application security. For most applications a = loss in confidentiality in TLS will have an impact in other aspects of = security. The third-party will often be able to inject application = traffic, although it may need to do this over a separate connection. >=20 > On Sun, Nov 5, 2017 at 7:38 PM, Richard Barnes > wrote: > I understood Cas to be observing that you could in principle remove = confidentiality with regard to the third party to whom keys are being = exfiltrated, without also removing integrity and authenticity. So the = third party could observe application traffic, but not modify or inject. = The solution in draft-rhrd removes all three properties with regard to = the third party (all still of course hold with regard to all other = attackers). >=20 > So you would still have a risk of violating applications' assumptions = with regard to confidentiality, but only with regard to confidentiality, = and only relative to the chosen third party. To Stephen's point, = though, this is of course a pretty subtle point for application = developers to understand. >=20 > --Richard >=20 >=20 > On Sun, Nov 5, 2017 at 8:57 PM, Joseph Salowey > wrote: > I'm not sure what use cases you are targeting, but this type of = solution can be dangerous for application security. Most application = security models assume that TLS will provide both confidentiality and = authenticity. Breaking confidentiality will often expose vulnerabilities = that can result in escalation of privilege or spoofing resulting in a = loss of integrity/authenticity in the application. For example, the use = bearer tokens such as passwords or session cookies is widespread. It = will take much more work to make applications resilient to loss of = confidentiality. There may be use cases where confidentiality compromise = is limited to just confidentiality, but I think these are in the = minority. >=20 > Joe >=20 > On Fri, Nov 3, 2017 at 7:41 AM, Cas Cremers > wrote: > Hi Richard, >=20 > Thanks for the pointer, I had missed your earlier observation of = essentially the same thing in the large mail threads. >=20 > Personally, I think it is a substantial and unmotivated loss in = security to also give up authentication/integrity. >=20 > Note that any changes towards PERC would require some significant = changes in the security analyses; for mctls, I expect it would be a = completely new analysis. (I haven't seen any analyses of rhrd, but of = the three, it is of course closest to the current setup.) >=20 > Best, >=20 > Cas >=20 >=20 > On Fri, Nov 3, 2017 at 2:00 PM, Richard Barnes > wrote: > Hey Cas, >=20 > This question is a good one. Earlier I brought up mcTLS, which some = folks have been working on to provide even more granular separations = than you suggest: >=20 > https://mctls.org/ >=20 > I think the authors of draft-rhrd are trying for a more lightweight = change to TLS. That said, there might be some intermediate points on = the spectrum here. For example, you could define a TLS ciphersuite akin = to what we defined in PERC when we wanted to break integrity partly and = confidentiality not at all. >=20 > https://tools.ietf.org/html/draft-ietf-perc-double-07 = >=20 > That would be less invasive than mcTLS, while still getting the = properties you describe. >=20 > --Richard >=20 >=20 > On Nov 3, 2017 09:43, "Cas Cremers" > wrote: > Dear all, > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8BDisclaimer: I am not a proponent of the idea behind = draft visibility/green/rhrd; I think such a mechanism should not be part = of the TLS 1.3 standard. > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8BI have a technical problem with the current design, = whose goal is to allow eavesdropping for inspection, i.e., selectively = decreasing confidentiality. > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8BHowever, the design in the draft also enables = arbitrary traffic modification/insertion, additionally breaking all = authentication and integrity guarantees. Once someone has the session = keys, they can not only eavesdrop but can also start to insert/modify = traffic. This additional decrease in security is entirely unmotivated by = the cited use cases. > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8BIt is possible to offer authentication and = integrity, while selectively giving up confidentiality. For example, one = could replace the AEAD by (i) a mechanism for authentication and (ii) a = separate mechanism for confidentiality, and then possibly reveal the = keys used for (ii), but make sure only the real endpoint has the keys = for (i). That seems more rational to me, and may retain the = authentication/integrity guarantees. However, it would require a much = more invasive change. > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8BBest, > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8BCas >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls = >=20 >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls = >=20 >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_26C57447-C650-4E3F-8A04-DA018E3E6246 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Visibility goes both ways. The discussion so far has been = primarily about making end-to-end data visible to middleboxes.
It would less concerning to do it the other = way round, where middleboxes are made visible to the endpoints, and = proxying/visbility decisions are made at the endpoints.
Indeed, this is one of the main ideas behind mcTLS: = middleboxes don=E2=80=99t get to transparently inject themselves into a = TLS channel, they must be authorized by *both* endpoints.

But even = a careful design like mcTLS ends up losing significant authentication = and integrity properties, both in the handshake and the record layer. = (If someone is interested, send me email, and I can give you = details.)
So, I really don=E2=80=99t = recommend any change to the TLS 1.3 design to accomplish any of this, it = is more likely that the change will break =E2=80=9Cnormal=E2=80=9D TLS = connections.

If = visibility is needed in some scenario, then I would prefer that it be = done at the application layer, by a proxy that is visible to and = authorized by at least one endpoint, if not both.
-Karthik



On 6 Nov = 2017, at 05:39, Joseph Salowey <joe@salowey.net> wrote:

I'm in agreement with Stephen.  If you compromise TLS = confidentiality you are going to break application security. For most = applications a loss in confidentiality in TLS will have an impact in = other aspects of security.   The third-party will often be = able to inject application traffic, although it may need to do this over = a separate connection. 

On Sun, Nov 5, 2017 at 7:38 PM, = Richard Barnes <rlb@ipv.sx> wrote:
I = understood Cas to be observing that you could in principle remove = confidentiality with regard to the third party to whom keys are being = exfiltrated, without also removing integrity and authenticity.  So = the third party could observe application traffic, but not modify or = inject.  The solution in draft-rhrd removes all three properties = with regard to the third party (all still of course hold with regard to = all other attackers).

So you would still have a risk of = violating applications' assumptions with regard to confidentiality, but = only with regard to confidentiality, and only relative to the chosen = third party.   To Stephen's point, though, this is of course a = pretty subtle point for application developers to understand.

--Richard


On Sun, Nov 5, 2017 at 8:57 PM, Joseph Salowey = <joe@salowey.net> wrote:
I'm not sure what use cases you are targeting, but this type = of solution can be dangerous for application security. Most application = security models assume that TLS will provide both confidentiality and = authenticity. Breaking confidentiality will often expose vulnerabilities = that can result in escalation of privilege or spoofing resulting in a = loss of integrity/authenticity in the application. For example, the use = bearer tokens such as passwords or session cookies is widespread. It = will take much more work to make applications resilient to loss of = confidentiality. There may be use cases where confidentiality compromise = is limited to just confidentiality, but I think these are in the = minority.  

Joe

On Fri, Nov 3, 2017 at 7:41 AM, = Cas Cremers <cas.cremers@cs.ox.ac.uk> wrote:
Hi Richard,

Thanks for the pointer, I had missed your earlier observation = of essentially the same thing in the large mail threads.

Personally, I think it = is a substantial and unmotivated loss in security to also give up = authentication/integrity.

Note that any changes towards PERC would require some = significant changes in the security analyses; for mctls, I expect it = would be a completely new analysis. (I haven't seen any analyses of = rhrd, but of the three, it is of course closest to the current = setup.)

Best,
Cas


On Fri, = Nov 3, 2017 at 2:00 PM, Richard Barnes <rlb@ipv.sx> wrote:
Hey Cas,

This question is a good one.  Earlier I brought up = mcTLS, which some folks have been working on to provide even more = granular separations than you suggest:

https://mctls.org/

I think the = authors of draft-rhrd are trying for a more lightweight change to = TLS.  That said, there might be some intermediate points on the = spectrum here.  For example, you could define a TLS ciphersuite = akin to what we defined in PERC when we wanted to break integrity partly = and confidentiality not at all. 

https://tools.ietf.org/html/draft-ietf-perc-double-07

That would be less invasive than mcTLS, while still getting = the properties you describe. 

--Richard


On Nov 3, 2017 09:43, "Cas Cremers" <cas.cremers@cs.ox.ac.uk> wrote:
Dear all,
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8BDiscl= aimer: I am not a proponent of the idea behind draft = visibility/green/rhrd; I think such a mechanism should not be part of = the TLS 1.3 standard.
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8BI have a technical problem with the current = design, whose goal is to allow eavesdropping for inspection, i.e., = selectively decreasing confidentiality.
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8BHowev= er, the design in the draft also enables arbitrary traffic = modification/insertion, additionally breaking all authentication and = integrity guarantees. Once someone has the session keys, they can not = only eavesdrop but can also start to insert/modify traffic. This = additional decrease in security is entirely unmotivated by the cited use = cases.
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8BIt is possible to offer authentication and = integrity, while selectively giving up confidentiality. For example, one = could replace the AEAD by (i) a mechanism for authentication and (ii) a = separate mechanism for confidentiality, and then possibly reveal the = keys used for (ii), but make sure only the real endpoint has the keys = for (i). That seems more rational to me, and may retain the = authentication/integrity guarantees. However, it would require a much = more invasive change.
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8BBest,
=E2=80=8B=E2=80=8B=
=E2=80=8B=E2=80=8BCas


_______________________________________________
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




_______________________________________________
TLS = mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

= --Apple-Mail=_26C57447-C650-4E3F-8A04-DA018E3E6246-- --Apple-Mail=_2987D9FD-B1E1-4C24-8B35-26115584E9F3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEy8eMbg8+Acz/UBck+vEitl5TKpkFAloAA3gACgkQ+vEitl5T KplPkA//bbuCuXVrDKItdTMu3Heykg2JcUt7cd0FcswZfDzskDijD2brQpaVqSIa llSo+Bz6Y9ytmRSdq5ynixkCm1L+/tnbnfzAe2LCT7jAypZG12cYm99cScmGB2Z0 hhEEuqZiepemEB6vdjyTcGC/1T1/i4dt73bZrOtKSPCx/UBo77kY0t3sqr63GWMS 9hzObh8jOHEkLfocV9tFt4/hTEVH/A/eAenccHAUjhmIX2TQzc4kZTgVA2wupDNL EDknrKFO93oKZxLRwkofc3jvpvgw/A7O0RQ7LiDdKDKc/iWzk9BdJ9yZKNbsRaR/ OHMA2XDSkspuOp26n58dmMvLxBe4y5n2PgFPE/VneA7RhvWRhf8RXq52agNp5zV3 XYGxTcMB80QB7M7vtBKjpuAj57j6z27OM0n6kgMEgLRlbma5KziLJkpgDfKdHaR0 me4j2cRLC1Sa9mE9N608Ms47IYah/H+GzkzKKFRRjTwV9LwFZf3PIvEZ+yiooBhF A5EVPqerzjSGVgH4kEvWie0V+FIVylW/8GpqMjyZVUXEkUtYDtRzwYKfYfwEia/9 YWLeExKNPScXoUER2R/qeBYLL8Cwhd3KyuH253pnQeBNk6mQuliTFpIKdwIWI3x7 Tcgbw+p0+QGQDS4p36hHI+TAzW6YBmrfu5W5LrfLLIWXmZqOqc8= =ncYI -----END PGP SIGNATURE----- --Apple-Mail=_2987D9FD-B1E1-4C24-8B35-26115584E9F3-- From nobody Mon Nov 6 04:18:14 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAABD13FBA4 for ; Mon, 6 Nov 2017 04:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 egWS2I60oc5U for ; Mon, 6 Nov 2017 04:18:10 -0800 (PST) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (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 37E4513FB57 for ; Mon, 6 Nov 2017 04:18:10 -0800 (PST) Received: by mail-ua0-x229.google.com with SMTP id i35so6230922uah.9 for ; Mon, 06 Nov 2017 04:18:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=7wUwN/rNV85NPgzDo+kzbT00xpU1KFF29eECYQScTlc=; b=CrJKeLdBvf2uHpDi0Hqn6jVkzqeNx7UR0zpuQLCxrHsQGNbEGAHM/4asZEi+HLTnf9 1yF3tI/tn5SL3dusaP3DDGEgYxo9KS73BbZOtvZhh8bIbUYuKMXWWWIqpqOOm+RcjVBb DpW5Wae2ZiXWwVBgwda4lArz0ezHh8YdgDBHDYuUGN7XvSn+0ZrMnCcAQQ8cI746vft1 Cz72jH0A8IUQ8j0TXYbTv2NlRNB4n7Kp/EOgbIL8Z/GiMc7m27UW1xpNB8T7kvntpYwG TSe6mwOI1pALsX8cRSr10SzflK5ZLPnINAkNhpCVpGmGDoWuR816hGWb2k9OBPkGPsP0 zffA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=7wUwN/rNV85NPgzDo+kzbT00xpU1KFF29eECYQScTlc=; b=KslCK81L2IIXUkxNot6nR/pGRxtK+5PMobGr59b2C1eQT2oGngRhcdHql2CglEXfbK oGIk3WNFRVmRhg1qrK5rx71HaLj1H43XTWQ0IW5xL2S6Qprppjhqi2Wj/YbNomMCRoFI T/DZVmY+98MxanH135Bw/AlHXDjGf7PWToJvl921Yq7qcqnYugJ8CHo4SEyxv7ZjgvJ9 dtZ7GfZLXUC7s109Txy6DT/HXDvyTGwkPlBo97dGXunntJOVQqkhrHgBjlw8U6fG18iN YMk2zbYrXt2tnKX4p2WAJPWR3amuDDHKXpcN7MOOIwv4JAZKqFKqqvELD/Dm5ilcL4nG nf1Q== X-Gm-Message-State: AMCzsaWEWPQKORAGrWTvdgzJwMQ5+ZMu+aZxMzwsZFVB0IIS6n5ufcsm CJnozeZ1eGsHxBZjl7d+y6cVylS2mNmciTiuU14= X-Google-Smtp-Source: ABhQp+SBySaquZebCQI/iQ2g6Xm9BnBv9zeynuj7ZA4Ia02MNib3lkdvqoy8AOi8KvlZ+noLp/AugvIw2aDDrK07K5g= X-Received: by 10.176.10.148 with SMTP id d20mr12968397uak.118.1509970689186; Mon, 06 Nov 2017 04:18:09 -0800 (PST) MIME-Version: 1.0 Sender: cas.cremers@gmail.com Received: by 10.176.1.108 with HTTP; Mon, 6 Nov 2017 04:17:48 -0800 (PST) In-Reply-To: <70496A24-F4C2-466E-9522-1832DCD134D1@gmail.com> References: <70496A24-F4C2-466E-9522-1832DCD134D1@gmail.com> From: Cas Cremers Date: Mon, 6 Nov 2017 12:17:48 +0000 X-Google-Sender-Auth: sj5uA9tTvQjCkzouAzycocV1QBI Message-ID: To: Karthikeyan Bhargavan Cc: Joseph Salowey , Richard Barnes , "" Content-Type: multipart/alternative; boundary="089e0826e4fc8ce233055d4f72a9" Archived-At: Subject: Re: [TLS] Technical comment on design draft-rhrd-tls-tls13-visibility-00: why also break integrity/authentication? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 12:18:13 -0000 --089e0826e4fc8ce233055d4f72a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with most of the above; my point was not to propose another mechanism, but just to make explicit (as Richard had indicated earlier) that the current design gives up much more security than it strictly seems to need for its claimed use cases. I'm not recommending any changes to the TLS 1.3 design, and agree that it is very likely that many more things would be broken in the process. Indeed, giving up confidentiality of the channel but retaining channel authentication does not ensure authentication at the application layer, because most application-level security guarantees rely on the confidentiality of the channel. However, I don't find that a great argument to immediately give up on authentication/integrity of the channel. Best, Cas On Mon, Nov 6, 2017 at 6:38 AM, Karthikeyan Bhargavan < karthik.bhargavan@gmail.com> wrote: > Visibility goes both ways. The discussion so far has been primarily about > making end-to-end data visible to middleboxes. > It would less concerning to do it the other way round, where middleboxes > are made visible to the endpoints, and proxying/visbility decisions are > made at the endpoints. > Indeed, this is one of the main ideas behind mcTLS: middleboxes don=E2=80= =99t get > to transparently inject themselves into a TLS channel, they must be > authorized by *both* endpoints. > > But even a careful design like mcTLS ends up losing significant > authentication and integrity properties, both in the handshake and the > record layer. (If someone is interested, send me email, and I can give yo= u > details.) > So, I really don=E2=80=99t recommend any change to the TLS 1.3 design to > accomplish any of this, it is more likely that the change will break > =E2=80=9Cnormal=E2=80=9D TLS connections. > > If visibility is needed in some scenario, then I would prefer that it be > done at the application layer, by a proxy that is visible to and authoriz= ed > by at least one endpoint, if not both. > > -Karthik > > > > On 6 Nov 2017, at 05:39, Joseph Salowey wrote: > > I'm in agreement with Stephen. If you compromise TLS confidentiality you > are going to break application security. For most applications a loss in > confidentiality in TLS will have an impact in other aspects of security. > The third-party will often be able to inject application traffic, althou= gh > it may need to do this over a separate connection. > > On Sun, Nov 5, 2017 at 7:38 PM, Richard Barnes wrote: > >> I understood Cas to be observing that you could in principle remove >> confidentiality with regard to the third party to whom keys are being >> exfiltrated, without also removing integrity and authenticity. So the >> third party could observe application traffic, but not modify or inject. >> The solution in draft-rhrd removes all three properties with regard to t= he >> third party (all still of course hold with regard to all other attackers= ). >> >> So you would still have a risk of violating applications' assumptions >> with regard to confidentiality, but only with regard to confidentiality, >> and only relative to the chosen third party. To Stephen's point, thoug= h, >> this is of course a pretty subtle point for application developers to >> understand. >> >> --Richard >> >> >> On Sun, Nov 5, 2017 at 8:57 PM, Joseph Salowey wrote: >> >>> I'm not sure what use cases you are targeting, but this type of solutio= n >>> can be dangerous for application security. Most application security mo= dels >>> assume that TLS will provide both confidentiality and authenticity. >>> Breaking confidentiality will often expose vulnerabilities that can res= ult >>> in escalation of privilege or spoofing resulting in a loss of >>> integrity/authenticity in the application. For example, the use bearer >>> tokens such as passwords or session cookies is widespread. It will take >>> much more work to make applications resilient to loss of confidentialit= y. >>> There may be use cases where confidentiality compromise is limited to j= ust >>> confidentiality, but I think these are in the minority. >>> >>> Joe >>> >>> On Fri, Nov 3, 2017 at 7:41 AM, Cas Cremers >>> wrote: >>> >>>> Hi Richard, >>>> >>>> Thanks for the pointer, I had missed your earlier observation of >>>> essentially the same thing in the large mail threads. >>>> >>>> Personally, I think it is a substantial and unmotivated loss in >>>> security to also give up authentication/integrity. >>>> >>>> Note that any changes towards PERC would require some significant >>>> changes in the security analyses; for mctls, I expect it would be a >>>> completely new analysis. (I haven't seen any analyses of rhrd, but of = the >>>> three, it is of course closest to the current setup.) >>>> >>>> Best, >>>> >>>> Cas >>>> >>>> >>>> On Fri, Nov 3, 2017 at 2:00 PM, Richard Barnes wrote: >>>> >>>>> Hey Cas, >>>>> >>>>> This question is a good one. Earlier I brought up mcTLS, which some >>>>> folks have been working on to provide even more granular separations = than >>>>> you suggest: >>>>> >>>>> https://mctls.org/ >>>>> >>>>> I think the authors of draft-rhrd are trying for a more lightweight >>>>> change to TLS. That said, there might be some intermediate points on= the >>>>> spectrum here. For example, you could define a TLS ciphersuite akin = to >>>>> what we defined in PERC when we wanted to break integrity partly and >>>>> confidentiality not at all. >>>>> >>>>> https://tools.ietf.org/html/draft-ietf-perc-double-07 >>>>> >>>>> That would be less invasive than mcTLS, while still getting the >>>>> properties you describe. >>>>> >>>>> --Richard >>>>> >>>>> >>>>> On Nov 3, 2017 09:43, "Cas Cremers" wrote: >>>>> >>>>> Dear all, >>>>> =E2=80=8B=E2=80=8B >>>>> =E2=80=8B=E2=80=8BDisclaimer: I am not a proponent of the idea behind= draft >>>>> visibility/green/rhrd; I think such a mechanism should not be part of= the >>>>> TLS 1.3 standard. >>>>> =E2=80=8B=E2=80=8B >>>>> =E2=80=8B=E2=80=8BI have a technical problem with the current design,= whose goal is to >>>>> allow eavesdropping for inspection, i.e., selectively decreasing >>>>> confidentiality. >>>>> =E2=80=8B=E2=80=8B >>>>> =E2=80=8B=E2=80=8BHowever, the design in the draft also enables arbit= rary traffic >>>>> modification/insertion, additionally breaking all authentication and >>>>> integrity guarantees. Once someone has the session keys, they can not= only >>>>> eavesdrop but can also start to insert/modify traffic. This additiona= l >>>>> decrease in security is entirely unmotivated by the cited use cases. >>>>> =E2=80=8B=E2=80=8B >>>>> =E2=80=8B=E2=80=8BIt is possible to offer authentication and integrit= y, while >>>>> selectively giving up confidentiality. For example, one could replace= the >>>>> AEAD by (i) a mechanism for authentication and (ii) a separate mechan= ism >>>>> for confidentiality, and then possibly reveal the keys used for (ii),= but >>>>> make sure only the real endpoint has the keys for (i). That seems mor= e >>>>> rational to me, and may retain the authentication/integrity guarantee= s. >>>>> However, it would require a much more invasive change. >>>>> =E2=80=8B=E2=80=8B >>>>> =E2=80=8B=E2=80=8BBest, >>>>> =E2=80=8B=E2=80=8B >>>>> =E2=80=8B=E2=80=8BCas >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > --089e0826e4fc8ce233055d4f72a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with most of the above; my point was not to propos= e another mechanism, but just to make explicit (as Richard had indicated ea= rlier) that the current design gives up much more security than it strictly= seems to need for its claimed use cases.

I'm not re= commending any changes to the TLS 1.3 design, and agree that it is very lik= ely that many more things would be broken in the process.

Indeed, giving up confidentiality of the channel but retaining chan= nel authentication does not ensure authentication at the application layer,= because most application-level security guarantees rely on the confidentia= lity of the channel. However, I don't find that a great argument to imm= ediately give up on authentication/integrity of the channel.

=
Best,

Cas


=



On Mon, Nov 6, 2017 at 6:38 AM, Karthik= eyan Bhargavan <karthik.bhargavan@gmail.com> wrote= :
Visibility goes both ways. The discussion so far = has been primarily about making end-to-end data visible to middleboxes.
It would less concerning to do it the other way round, where middlebo= xes are made visible to the endpoints, and proxying/visbility decisions are= made at the endpoints.
Indeed, this is one of the main ideas beh= ind mcTLS: middleboxes don=E2=80=99t get to transparently inject themselves= into a TLS channel, they must be authorized by *both* endpoints.

But even a careful design like mcTLS ends up losing si= gnificant authentication and integrity properties, both in the handshake an= d the record layer. (If someone is interested, send me email, and I can giv= e you details.)
So, I really don=E2=80=99t recommend any ch= ange to the TLS 1.3 design to accomplish any of this, it is more likely tha= t the change will break =E2=80=9Cnormal=E2=80=9D TLS connections.

If visibility is needed in some scenario, then I would pref= er that it be done at the application layer, by a proxy that is visible to = and authorized by at least one endpoint, if not both.

<= div>-Karthik


=
On 6 Nov 2017, at 05:39, Joseph Salowey = <joe@salowey.net> wrote:

I'm in agreement with Stephen.=C2=A0 If you = compromise TLS confidentiality you are going to break application security.= For most applications a loss in confidentiality in TLS will have an impact= in other aspects of security.=C2=A0 =C2=A0The third-party will often be ab= le to inject application traffic, although it may need to do this over a se= parate connection.=C2=A0

On Sun, Nov 5, 2017 at 7:38 PM, Richard Barnes <rlb@ipv.sx> wrote:
I unde= rstood Cas to be observing that you could in principle remove confidentiali= ty with regard to the third party to whom keys are being exfiltrated, witho= ut also removing integrity and authenticity.=C2=A0 So the third party could= observe application traffic, but not modify or inject.=C2=A0 The solution = in draft-rhrd removes all three properties with regard to the third party (= all still of course hold with regard to all other attackers).

So you would still have a risk of violating applications= 9; assumptions with regard to confidentiality, but only with regard to conf= identiality, and only relative to the chosen third party.=C2=A0=C2=A0 To St= ephen's point, though, this is of course a pretty subtle point for appl= ication developers to understand.

--Richard

On Sun, Nov 5, 2017 at 8:57 PM, Joseph Salowey <joe@salowey.net= > wrote:
I= 'm not sure what use cases you are targeting, but this type of solution= can be dangerous for application security. Most application security model= s assume that TLS will provide both confidentiality and authenticity. Break= ing confidentiality will often expose vulnerabilities that can result in es= calation of privilege or spoofing resulting in a loss of integrity/authenti= city in the application. For example, the use bearer tokens such as passwor= ds or session cookies is widespread. It will take much more work to make ap= plications resilient to loss of confidentiality. There may be use cases whe= re confidentiality compromise is limited to just confidentiality, but I thi= nk these are in the minority.=C2=A0=C2=A0

Joe

On Fri, Nov 3, 2017 at 7:41 AM, Cas Crem= ers <cas.cremers@cs.ox.ac.uk> wrote:
Hi Richard,

Thanks for= the pointer, I had missed your earlier observation of essentially the same= thing in the large mail threads.

Personally, I th= ink it is a substantial and unmotivated loss in security to also give up au= thentication/integrity.

Note that any changes towa= rds PERC would require some significant changes in the security analyses; f= or mctls, I expect it would be a completely new analysis. (I haven't se= en any analyses of rhrd, but of the three, it is of course closest to the c= urrent setup.)

Best,

Cas


On Fri, Nov 3, 2017 at 2:00 PM, Richard Barnes <rlb@ipv.sx> wrote:
Hey Cas,
This question is a good one.=C2= =A0 Earlier I brought up mcTLS, which some folks have been working on to pr= ovide even more granular separations than you suggest:


I think the authors of draft-rhrd are trying for a more lightweig= ht change to TLS.=C2=A0 That said, there might be some intermediate points = on the spectrum here.=C2=A0 For example, you could define a TLS ciphersuite= akin to what we defined in PERC when we wanted to break integrity partly a= nd confidentiality not at all.=C2=A0


That would= be less invasive than mcTLS, while still getting the properties you descri= be.=C2=A0

--Richard

On Nov 3, 2017 09:43, "Cas Cremers&q= uot; <cas.c= remers@cs.ox.ac.uk> wrote:
Dear all,
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8BDisclaimer: I am not a proponent of the idea behind= draft visibility/green/rhrd; I think such a mechanism should not be part o= f the TLS 1.3 standard.
=E2=80=8B=E2=80=8B
=E2=80=8B=E2= =80=8BI have a technical problem with the current design, whose goal is to = allow eavesdropping for inspection, i.e., selectively decreasing confidenti= ality.
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8BHowever, th= e design in the draft also enables arbitrary traffic modification/insertion= , additionally breaking all authentication and integrity guarantees. Once s= omeone has the session keys, they can not only eavesdrop but can also start= to insert/modify traffic. This additional decrease in security is entirely= unmotivated by the cited use cases.
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8BIt is possible to offer authentication and integrity, wh= ile selectively giving up confidentiality. For example, one could replace t= he AEAD by (i) a mechanism for authentication and (ii) a separate mechanism= for confidentiality, and then possibly reveal the keys used for (ii), but = make sure only the real endpoint has the keys for (i). That seems more rati= onal to me, and may retain the authentication/integrity guarantees. However= , it would require a much more invasive change.
=E2=80=8B=E2=80= =8B
=E2=80=8B=E2=80=8BBest,
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8BCas

=

_______________________________________________
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




_______________________________________________
TLS mailing listTLS@ietf.org
https:/= /www.ietf.org/mailman/listinfo/tls

--089e0826e4fc8ce233055d4f72a9-- From nobody Mon Nov 6 06:31:38 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B3813FC21 for ; Mon, 6 Nov 2017 06:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 q9Wmyj_l_TAh for ; Mon, 6 Nov 2017 06:31:35 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 65B1913F3D5 for ; Mon, 6 Nov 2017 06:31:35 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id k40so10715326lfi.4 for ; Mon, 06 Nov 2017 06:31:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6VcX6SJdhad6FDJsfkqAs/kD78c1ZV7Y2U/9zBMtxXo=; b=WA5bvLACt9sEsQrxUgSypq617Pg45ibrzgSWtZnHLLl5N15nIB04VV5qaMwqCHAVoI 4tuQ4ApVJvimsVkoo+A6oz+crZ1JENeSdWYmccEzjzPJ9SeMIsWjonBAdppccw/pW45O vzF0nL9DpiNyIeeiO4J25RjitXFzO/DKEE9/z1RgY9vm+672z0c0QS0/3Vl+Hcapoy3o mFeCz/lyxrFXkueozk+76/NnsZlsD7RmOLITTcdUkR8N4dMQM0be3rHymMxf/TeYYQhs NmLXrfMjPtQD325oiiXvWi6w+ULiWDh0Yd7BNvBVqxJrZ7r5HV8OySAgD+QYKIcHnwjb uxoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=6VcX6SJdhad6FDJsfkqAs/kD78c1ZV7Y2U/9zBMtxXo=; b=S8LETdwh3G0jRLF+Y2wxFJM2TMIR1wRzFM2WBPGlekZAL8q1z0vXF3YWt9SkJVwYBD N4Gtiuj/vlzIHuNBCRmgsunp9sVdQoLP9aVACoZukX+CUsWLS1LuiGDX7i9hvD+GAbVN K7fO38Q9xuGnr3+IQHLQuCfsyPU8IsmVxHMuKRvvgNVtmCZO6az9CdQKRzDP2FdxAqxI sS6m2Jj2cZxhbNFwv1Vw+EpXTg1UUAkwPC2MOiiszk+UrBu8DSqe5Mk1gCKaByG+NQD0 GlZJ3xpCmQk+IcI2D7OMb/fOSXHUAkfD77i22e9OWf7j5JkNZSFQIlHpbx4HnWJPu6o8 EKHg== X-Gm-Message-State: AJaThX7OX4eZbsqPp4rjYwI54/dfRH8TjtyOXDwv3EDGxpo4xs7R8RoC jJR8NUPCAYkkhBGt9YkzjFp02vdA4LAHIE4vZOEB7w== X-Google-Smtp-Source: ABhQp+QmfKbek6VlMd5y3G6w7kRrA8C4Y1Kx1PG1UdQIs3obgV4m2AyyMrIe5KOd4GTc315e0vM6Opd1tWEeD/hwnxA= X-Received: by 10.25.78.89 with SMTP id c86mr5304801lfb.1.1509978693562; Mon, 06 Nov 2017 06:31:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.64.76 with HTTP; Mon, 6 Nov 2017 06:31:32 -0800 (PST) In-Reply-To: References: From: Loganaden Velvindron Date: Mon, 6 Nov 2017 18:31:32 +0400 Message-ID: To: Eric Rescorla Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 14:31:37 -0000 On Sat, Oct 7, 2017 at 12:16 AM, Eric Rescorla wrote: > Hi folks, > > In Prague I mentioned that we were seeing evidence of increased > failures with TLS 1.3 which we believed were due to middleboxes. In > the meantime, several of us have done experiments on this, and I > wanted to provide an update. > > The high-order bit is that *negotiating* TLS 1.3 seems to cause > increased failures with a variety of middleboxes (it=E2=80=99s generally = safe > to offer TLS 1.3 to servers which don=E2=80=99t support it). The measured > incremental error rates vary quite a bit, ranging from minimal > (Facebook) to ~1.5% (Firefox) and ~3.4% (Chrome). Each of us is using > a slightly different methodology (organic versus forced traffic) and > different populations (mobile, desktop, enterprise, etc), but it does > seem like there is a nontrivial failure rate. At this point, we have > two options: > > - Fall back to TLS 1.2 (as we have unfortunately done for previous releas= es) > - Try to make small adaptations to TLS 1.3 to make it work better with > middleboxes. > We (hackers.mu) ran tests across different Mobile & FTTH providers, and large wifi hotspot vendors across the island of Mauritius: Mauritius Telecom FTTH: no issues with TLS 1.3 Emtel (mobile): no issues with TLS 1.3 Mauritius Telecom (mobile): no issues with TLS 1.3 AlwaysOn: Gateway has issues with TLS 1.3 (draft-18), when forcing all HTTPS traffic to their HTTPS web-based portal. Before authentication via SSL/TLS: ./bin/openssl s_client -connect tls13.crypto.mozilla.org:443 -tls1_3 -CApath=3D/etc/ssl/certs/ CONNECTED(00000003) 140130750743872:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1471:SSL alert number 40 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 184 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent SSL-Session: Protocol : TLSv1.3 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1509976305 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no --- I'm reaching out to the AlwaysOn service, which appears to be quite well popular in South Africa as well. //Logan C-x-C-c From nobody Mon Nov 6 06:37:59 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A5113FC2B for ; Mon, 6 Nov 2017 06:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=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 Xky9FyTP8L2Z for ; Mon, 6 Nov 2017 06:37:56 -0800 (PST) Received: from mta.openssl.org (mta.openssl.org [IPv6:2001:608:c00:180::1:e6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2C7B13FC28 for ; Mon, 6 Nov 2017 06:37:55 -0800 (PST) Received: from [10.33.10.6] (unknown [104.238.169.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta.openssl.org (Postfix) with ESMTPSA id EEB83E65C5 for ; Mon, 6 Nov 2017 14:37:53 +0000 (UTC) To: tls@ietf.org References: From: Matt Caswell Message-ID: <10e57e9d-af2a-0d6c-9e43-95afb5604e37@openssl.org> Date: Mon, 6 Nov 2017 14:37:53 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Update on TLS 1.3 Middlebox Issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 14:37:58 -0000 On 06/11/17 14:31, Loganaden Velvindron wrote: > On Sat, Oct 7, 2017 at 12:16 AM, Eric Rescorla wrote: >> Hi folks, >> >> In Prague I mentioned that we were seeing evidence of increased >> failures with TLS 1.3 which we believed were due to middleboxes. In >> the meantime, several of us have done experiments on this, and I >> wanted to provide an update. >> >> The high-order bit is that *negotiating* TLS 1.3 seems to cause >> increased failures with a variety of middleboxes (it’s generally safe >> to offer TLS 1.3 to servers which don’t support it). The measured >> incremental error rates vary quite a bit, ranging from minimal >> (Facebook) to ~1.5% (Firefox) and ~3.4% (Chrome). Each of us is using >> a slightly different methodology (organic versus forced traffic) and >> different populations (mobile, desktop, enterprise, etc), but it does >> seem like there is a nontrivial failure rate. At this point, we have >> two options: >> >> - Fall back to TLS 1.2 (as we have unfortunately done for previous releases) >> - Try to make small adaptations to TLS 1.3 to make it work better with >> middleboxes. >> > > We (hackers.mu) ran tests across different Mobile & FTTH providers, > and large wifi hotspot vendors across the island of Mauritius: > > Mauritius Telecom FTTH: no issues with TLS 1.3 > Emtel (mobile): no issues with TLS 1.3 > Mauritius Telecom (mobile): no issues with TLS 1.3 > AlwaysOn: Gateway has issues with TLS 1.3 (draft-18), when forcing all > HTTPS traffic to their HTTPS web-based portal. > > Before authentication via SSL/TLS: > > > ./bin/openssl s_client -connect tls13.crypto.mozilla.org:443 -tls1_3 > -CApath=/etc/ssl/certs/ Note that the "-tls1_3" option to s_client forces *only* TLSv1.3 to be negotiated. Therefore, if the web based portal doesn't also support TLSv1.3 then this will fail. Matt > CONNECTED(00000003) > 140130750743872:error:14094410:SSL routines:ssl3_read_bytes:sslv3 > alert handshake failure:ssl/record/rec_layer_s3.c:1471:SSL alert > number 40 > --- > no peer certificate available > --- > No client certificate CA names sent > --- > SSL handshake has read 7 bytes and written 184 bytes > Verification: OK > --- > New, (NONE), Cipher is (NONE) > Secure Renegotiation IS NOT supported > Compression: NONE > Expansion: NONE > No ALPN negotiated > Early data was not sent > SSL-Session: > Protocol : TLSv1.3 > Cipher : 0000 > Session-ID: > Session-ID-ctx: > Master-Key: > PSK identity: None > PSK identity hint: None > SRP username: None > Start Time: 1509976305 > Timeout : 7200 (sec) > Verify return code: 0 (ok) > Extended master secret: no > --- > > I'm reaching out to the AlwaysOn service, which appears to be quite > well popular in South Africa as well. > > //Logan > C-x-C-c > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Mon Nov 6 09:44:38 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A109913FBA8 for ; Mon, 6 Nov 2017 09:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 KWkm-zfGdHks for ; Mon, 6 Nov 2017 09:44:34 -0800 (PST) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 4DFB313FAF7 for ; Mon, 6 Nov 2017 09:44:34 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id i196so537656ywc.2 for ; Mon, 06 Nov 2017 09:44:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ovkEDSdltTnfsRd50HePFBRYPhp1aQ20h+QHsTh3h/Q=; b=JbWqJfxAUijN9yeDHUFi+5+9bn0IGQK0VuW61zgS9b0xPc637M/qdAcAhEIgI8D8C/ vUJRrmHvgbmtBUyJ3JR/354KwfAAnmCvhMxWY5dXeDJUj5ieIVM/ijLHlVDA8g7Euzdx PBOFV039PnYtOV8RAIHNulPiU9MSL9MKb4efX+FyG7ZxK9YQjihnwSe6IpdB7YSC2UXO NTnkJQM0UdgNn9ufxn3Eq9qpy0gk6LjjqPzHCvWsSCWPVxboOo7WOLuq2E21VdjxPJkz PyczvpZcUoBaL+B7FP42C+My6zDymKeUbdirKbmK96uoO0zMRK8Ex3DEqWKS9VtO4UQJ 68tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ovkEDSdltTnfsRd50HePFBRYPhp1aQ20h+QHsTh3h/Q=; b=uBS9Zhic1Df5isLBzmux5BYKvqGOFUsYL2hJacgd9+G48htfqFVHbJRgPsCDDOaWye /VEw68vuMJUDue15L5EdeCtHtpkiFXE4oUzHqwEX9KF6Knd9OaQuMsNU7mBhKyc6HQOK 7fjxO1wuMtjkJsRshUEUhazZ/mbUubGHdHDXvbybd0j08oZDxNlJUVjdTi+sGVflsauN waPWX8QBTlj++lJ6ZYKdshqo+THCcTODeXiEzlvkyCWCOaW92ZIZUoyENMTB/ukTEEaP ZfiB4klzoM5NHJibS56j+2OHiqWTLHFhuxxdN+pa26kXNypeJLv+UMdkPfEqkZH3d39l zX8Q== X-Gm-Message-State: AMCzsaWRiCxdmuRGA/54WEK7jm4Of1Hcg2iZyAG3Wn7u/oy6BZfAtQoh NZPw8YgOB4GF+OfrlrXAd1DPRY+/4ykmLE5BpEBPcw== X-Google-Smtp-Source: ABhQp+RTJUeTwqSoJYROT/bjE/awDFyn39hujOkke0zgq4kgAzqL3ilN4AZakrdJnsJ1BgzbbA4BI7goYjyes+RgFpQ= X-Received: by 10.37.44.141 with SMTP id s135mr9681851ybs.400.1509990273251; Mon, 06 Nov 2017 09:44:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.61.12 with HTTP; Mon, 6 Nov 2017 09:43:52 -0800 (PST) In-Reply-To: <895D1206-28D1-43AB-8A45-11DEEC86A71D@cisco.com> References: <895D1206-28D1-43AB-8A45-11DEEC86A71D@cisco.com> From: Eric Rescorla Date: Mon, 6 Nov 2017 09:43:52 -0800 Message-ID: To: "Nancy Cam-Winget (ncamwing)" Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a11431c64da123f055d5401e6" Archived-At: Subject: Re: [TLS] network-based security solution use cases X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 17:44:38 -0000 --001a11431c64da123f055d5401e6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I took a look at this. Without getting into the question of whether the types of middleboxes you describe here provide a security benefit, there are several points in the document that are either wrong or at least misleading/confusing. - Key Synchronization This document notes that in TLS 1.2, it is possible for a middlebox that traffic keys match on both sides of the connection it is proxying, but in TLS 1.3 it is not: There are several techniques that can be utilized. Those techniques function with TLS 1.2 and earlier versions but not with TLS 1.3. One technique is for the middlebox to negotiate the same master secret with the original TLS client and server, as if the two endpoints handshake directly. This is also known as "Triple Handshake" used by legitimate middleboxes. [BreakTLS] describes the methods with RSA and DH key exchanges. When the proxy session keys are the same as for a direct handshake, the middlebox is able to "cut-through" the two TLS proxy sessions when it finishes the security inspection. This technique is not functional with TLS 1.3 since the transcript hash over the handshake messages is part of the key derivation procedure. First, I would note that this property of TLS 1.2 is bad, as it leads to Unknown Key Share (UKS) attacks, which can be the basis of real attacks on TLS 1.2 as fielded. It is for this reason that the TLS WG published RFC 7627. Second, this property is really only available with RSA. Although it is possible for an attacker to synchronize DH keys by generating bogus DH parameters, the technique described by Bhargavan et al results in an insecure MS (i.e., the server's public DH share). [See Section V-B of https://www.mitls.org/downloads/tlsauth.pdf] Any middlebox doing this, therefore, has completely broken TLS for the endpoints on both sides of it. Your document suggests that people do use this technique: I sincerely hope not. In short, this property of TLS 1.3 is really a property of the use of (EC)DHE [0], the use of which is important for security even in TLS 1.2 (hence the rapid increase in the use of ECDHE and the corresponding decline in static RSA). Even if TLS 1.3 were never deployed, the continued use of static RSA is going to be come increasingly nonviable. Finally, you note several times in the document (e.g., S 4.5), that with key synchronization, the middlebox can perform the handshake and then disengage from the connection. However, the cases you mention (e.g.., detecting exploit attempts) ultimately require examining all traffic in the connection. - PSK and resumption You write: In TLS 1.3, the above mechanism is replaced by Pre-Shared Keys (PSK), which can be negotiated as part of an initial handshake and then used in a subsequent handshake to perform resumption using the PSK. TLS 1.3 states that the client SHOULD include a "key_share" extension to enable the server to decline resumption and fall back to a full handshake, however it is not an absolute requirement. Example scenarios that are impacted by this are middleboxes that were not part of the initial handshake, and hence do not know the PSK. If the client does not include the "key_share" extension, the middlebox cannot force a fallback to the full handshake. If the middlebox policy requires it to inspect the session, it will have to fail the connection instead. In TLS 1.3, PSKs and session resumption are basically the same and have the same properties. While I concede that the document does not require the client to offer key_shares, as a practical matter it is very unlikely that a client will act in such a way that failure to retain the PSK causes a hard failure, for two reasons: (a) In every version of TLS, the ticket lifetime is just a hint, and the server can forget it at any time (https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#NSTMessag= e). Thus, a client which does not allow a full handshake will often find itself unable to connect. (b) The relevant question is not whether the client offers a key share extension but whether it advertises any DH groups. If the client sends a group but not a key share, the server can send HelloRetryRequest to force the client to send a key share. For these reasons, as far as I know, every client (and at least every browser client) should allow a full handshake even when trying to resume. - Server Certificate Concealment You note that in TLS 1.2 the middlebox can examine both the SNI and the server's certificate in order to decide whether to MITM the connection, but that in TLS 1.3, the middlebox cannot guarantee that the SNI in uses is correct: In TLS 1.2, the ClientHello, ServerHello and Certificate messages are all sent in clear-text, however in TLS 1.3, the Certificate message is encrypted thereby hiding the server identity from any intermediary. Note that even _if_ the SNI is provided (in cleartext) by the client, there is no guarantee that the actual server responding is the one indicated in the SNI from the client. In this case, it's important to distinguish between conformant and nonconformant clients. In the former case -- as when the user is not attempting to evade inspection -- the SNI will reflect the identity that the client expects and therefore will compare the certificate against. Of course, in the case where the client is attempting to evade inspection, the certificate might not match. However, in this scenario, the client and server are colluding and so there are a variety of ways to avoid inspection, even when doing TLS 1.2. For example: 1. The client and server can share a prearranged public key and then negotiate static RSA. The client sends an innocuous SNI and the server can simply send the certificate of the corresponding server, captured by connecting to that server. The client then enciphers the PMS under the server's prearranged key and continues with TLS as usual. This cannot be detected by the middlebox without decrypting the EPMS. 2. If an (EC)DHE cipher suite must be negotiated, then the attack described above does not work directly because the server's signature over the ServerKeyExchange can be validated, and of course the attacker server does not have the legitimate server's key. However, the server can forward the ClientHello to the legitimate server, capture the Certificate and ServerKeyExchange and the proxy those to the client. This looks legitimate to the inspection device and then the client can simply send the Encrypted PMS in the first chunk of data that is apparently encrypted under the server's key. For these reasons, being able to see the server's certificate provides a false sense of security, as this check is easily bypassed. -Ekr [0] Note: the use of static DH is very rare. On Fri, Nov 3, 2017 at 6:49 PM, Nancy Cam-Winget (ncamwing) < ncamwing@cisco.com> wrote: > All, > > > > @IETF99, awareness was raised to some of the security WGs (thanks Kathlee= n > =E2=98=BA) that TLS 1.3 will obscure visibility currently afforded in TLS= 1.2 and > asked what the implications would be for the security solutions today. > https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00 is an > initial draft to describe some of the impacts relating to current network > security solutions. The goal of the draft is NOT to propose any solution > as a few have been proposed, but rather to raise awareness to how current > network-based security solutions work today and their impact on them base= d > on the current TLS 1.3 specification. > > > > Regards, Nancy, Flemming and Eric > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11431c64da123f055d5401e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
--001a114476081c843c055d6119b4-- From nobody Tue Nov 7 02:24:04 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAA313FD49 for ; Tue, 7 Nov 2017 02:24:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.899 X-Spam-Level: X-Spam-Status: No, score=-4.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 IRtX9l06uZsA for ; Tue, 7 Nov 2017 02:24:00 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 4B6BA13FB7A for ; Tue, 7 Nov 2017 02:24:00 -0800 (PST) Received: from [192.168.91.204] ([80.92.118.86]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M9bYB-1eOQAU0Jah-00D1zd; Tue, 07 Nov 2017 11:23:57 +0100 To: Alex C , Richard Barnes Cc: "" References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Tue, 7 Nov 2017 11:23:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:Iue3iM184M1Tal3ETVfdecz9SQ6U7ZvfIObUi2FSsuv/v12ocw5 pMH1TL1G47Bu1yCTpsacqIfh6xa/pB9EIfGkA0FAvW+QZI5aPKX5QOp3w9VkHZ0Zr2T4X8q DX1cgM98epjwCDDNo9zGIprVt6qeDY0X36a1BNZz5+/iIhLEKyyLN8V+zIjjYcZH0fhjEuH QanNzW0m+YlOMVpl/nV/Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:foVVMFzv0hQ=:rsXahaKXjCXatHRGTtp/lG vzMgZFL0pjzY3JdXwiNaoPd+U35SO19kFteq+KRF1LCuCaDZoy/x1wr1AwS18qFpupT0ksrKW ZBWq65rKnJUqc1yZKT0MWCX+FHHU777BBMZQAa9iI+IcjhB+X0GPUYxU0IEN7Y4jDnIzfUCKe mfTEUmLLibyEfhCLX2HSS4a1t2lQ/VGLgnD9H+w5t7QlWH8UWBGz62DHTsVcAxIFyvw6uTKGR 1GxixlfqqOQb5rBkOwprYaV/6QPbcPMmEcUXAmDK8YOn5RSQ7DNX8tRnkSDEgL3/bPcl49CB/ vRy1GpAQHloeKLilcFeH61wMvRTbZ7XvO0hZ6/1nDkJGgHo9tg550G3wkNurGV+XSoBtlL/bj i3DlWecYzV3mraFziRi5SwXzuNluKsKJMKb4LOBebeSQaKmPPgOMbxmGK5KvPRoCY6xKPWzMq fRA0tnbZu9C+eyjTczXwxn9gqpXYR0NsSH/7Qy47vbWFYp/LS6pGKJsEHAfSujNkzg0pyTcSI El8E/xByTwKeqJ2+KaRLY3zDOquUAzhtJ+jRZo1L0sjPC8uqmEce9n8MSV/jdAEphWGxfLZBi ayIBkMGHh+kedS8K+2K5jXMHC2ed5Iuo7vmridvtMR9nOcMde1u2kFAv0RNmBx3fUfvxNkKJz w7HRJnoEaUSYKRXm+X1Oc/urkld9SmRpJDHXvWPZ64zHnM2HbidabYqrQGrrh3brMTQOU/lRw RBogbuUd91bC+qxwKinRUNNQBJOkl0YSyIsUc3BEzCuAawnw7tpd9phFobL0rncjKdfxpwobI ogu8skCw9ZD+J2rNv4yWzYnnGYnw3na0xyBnoOJefYMDAN+UKM= Archived-At: Subject: [TLS] Layered TLS ... was Re: New Version Notification for draft-friel-tls-over-http-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 10:24:03 -0000 This is interesting since Mark Baugher and myself have also been working on the use of TLS at the application layer and we did some implementation work with mbed TLS (with TLS 1.3) and OpenSSL. Our work was motivated by the discussions in the IoT groups about re-inventing the TLS handshake at the application layer. Our document can be found here: https://tools.ietf.org/html/draft-tschofenig-layered-tls-00 Ciao Hannes On 11/07/2017 10:21 AM, Alex C wrote: > What exactly is the threat model here? > > Are you trying to hide a connection from a reverse proxy at the server > end? If so, the server operator should not have deployed a reverse proxy > in the first place. > > Are you trying to hide from a MITM proxy that supplies its own > certificate? If so, then what prevents the proxy from doing the same to > the tunnelled session? > When MITM proxies learn to do that, will we create another tunnelling > protocol inside this one? > > This is a cat-and-mouse game with middleboxes (much like the version > negotiation problem, but in a different way). Keep playing and everyone > loses. > > On Tue, Oct 31, 2017 at 11:17 AM, Richard Barnes > wrote: > > Hey TLS folks, > > Owen, Max, and I have been kicking around some ideas for how to make > secure connections in environments where HTTPS is subject to MitM / > proxying. > > The below draft lays out a way to tunnel TLS over HTTPS, in hopes of > creating a channel you could use when you really need things to be > private, even from the local MitM.  > > Feedback obviously very welcome.  Interested in whether folks think > this is a useful area in which to develop an RFC, and any thoughts > on how to do this better. > > Thanks, > --Richard > > > On Mon, Oct 30, 2017 at 3:47 PM, > wrote: > > > A new version of I-D, draft-friel-tls-over-http-00.txt > has been successfully submitted by Owen Friel and posted to the > IETF repository. > > Name:           draft-friel-tls-over-http > Revision:       00 > Title:          Application-Layer TLS > Document date:  2017-10-30 > Group:          Individual Submission > Pages:          20 > URL:            > https://www.ietf.org/internet-drafts/draft-friel-tls-over-http-00.txt > > Status:        >  https://datatracker.ietf.org/doc/draft-friel-tls-over-http/ > > Htmlized:      >  https://tools.ietf.org/html/draft-friel-tls-over-http-00 > > Htmlized:      >  https://datatracker.ietf.org/doc/html/draft-friel-tls-over-http-00 > > > > Abstract: >    Many clients need to establish secure connections to application >    services but face challenges establishing these connections > due to >    the presence of middleboxes that terminate TLS connections > from the >    client and restablish new TLS connections to the service.  This >    document defines a mechanism for transporting TLS records in HTTP >    message bodies between clients and services.  This enables > clients >    and services to establish secure connections using TLS at the >    application layer, and treat any middleboxes that are > intercepting >    traffic at the network layer as untrusted transport.  In > short, this >    mechanism moves the TLS handshake up the OSI stack to the > application >    layer. > > > > > Please note that it may take a couple of minutes from the time > of submission > until the htmlized version and diff are available at > tools.ietf.org . > > The IETF Secretariat > > > > _______________________________________________ > 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 > From nobody Tue Nov 7 04:21:07 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD7B13FB9D for ; Tue, 7 Nov 2017 04:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 o3NOeuON1vki for ; Tue, 7 Nov 2017 04:21:04 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E54E13FB31 for ; Tue, 7 Nov 2017 04:21:04 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vA7CH5nV019197; Tue, 7 Nov 2017 12:20:58 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=zRFZ+poXMLCaWxcqc3inGlZ8JWlW3hdOcnJzmX36axU=; b=kAB3HqORgwb7ZldioEdO395UxbNzZqQ0diwDvnOG3YwXEpHfbxKMa5J+aN7SWno5/dw/ Ww1kG01Cnkio5HgpwavkorRhJUYQo24xCy9vbLlz2vye6tMQ7APVsrROrmAQB4b6PeIv Ffoh+IWXdrLqYL3zJhq/vcl3hnI1Nae5PhZkDWqugqpJQxkKHCg56gU29sBQocnD3siC lw/a6bjt+dQzUnkC8duujKPGO3e/tz8RV5pSif8uK0GHYEx2H0qEtzxZwLOujn2qHndv fl5pNT8Gw+ZS2+Mg/hObc8e83nHSpMWyKVW/px5O4DqgfXfDmom+2qBIv8fPlvXHQ0VI hw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050102.ppops.net-00190b01. with ESMTP id 2e13ggj741-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Nov 2017 12:20:58 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vA7CFnHW025127; Tue, 7 Nov 2017 07:20:57 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2e18vu8gg0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 07 Nov 2017 07:20:57 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 7 Nov 2017 07:20:56 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 7 Nov 2017 07:20:56 -0500 From: "Salz, Rich" To: Hannes Tschofenig , Alex C , Richard Barnes CC: "" Thread-Topic: [TLS] Layered TLS ... was Re: New Version Notification for draft-friel-tls-over-http-00.txt Thread-Index: AQHTV7KNQ3yByf+yI0u21pfZwxewj6MJKiUA Date: Tue, 7 Nov 2017 12:20:56 +0000 Message-ID: References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.159] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-07_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711070171 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-07_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711070171 Archived-At: Subject: Re: [TLS] Layered TLS ... was Re: New Version Notification for draft-friel-tls-over-http-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 12:21:06 -0000 DQrinqIgICAgIE91ciB3b3JrIHdhcyBtb3RpdmF0ZWQgYnkgdGhlIGRpc2N1c3Npb25zIGluIHRo ZSBJb1QgZ3JvdXBzIGFib3V0DQogICAgcmUtaW52ZW50aW5nIHRoZSBUTFMgaGFuZHNoYWtlIGF0 IHRoZSBhcHBsaWNhdGlvbiBsYXllci4NCiAgICANCiBJc27igJl0IHRoYXQgd2hhdCBRVUlDIGRv ZXMgKHRvIGEgZ29vZCBlbm91Z2ggYXBwcm94aW1hdGlvbik/DQoNCg== From nobody Tue Nov 7 05:01:37 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A0913FE53 for ; Tue, 7 Nov 2017 05:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 df3QExO6T3lJ for ; Tue, 7 Nov 2017 05:01:34 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 E854A13FB18 for ; Tue, 7 Nov 2017 05:01:33 -0800 (PST) Received: from [192.168.91.204] ([80.92.118.86]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LvzF3-1fIyhb2JRt-017kiJ; Tue, 07 Nov 2017 14:01:25 +0100 To: "Salz, Rich" , Alex C , Richard Barnes Cc: "" References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Tue, 7 Nov 2017 14:01:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:WgxaKK4D/R99ZDHzo7hpNnAXKLrKOTmSn9BSzpURsLiSZheYNPa 5XuQ9hCO1NgQzyIdTVgz4WDCgK0HgGLx5yEpxPnyi+YOSmtlHsPMdprgQ3wBAaW1n5Bn9rD 2URs46czqHaBMz/LaqDk6XA2vaGMG/t5Wndjpevv1nVJv4XwZiLg/T87l620t3t77aNCjIX DT4iyaKG+LAJ/d+g3/evw== X-UI-Out-Filterresults: notjunk:1;V01:K0:LhlWr1rkH3Q=:iGi1jZRgKVTj6n1tQvcd8f nbnMvxs8zYwysaP+5d7dTt+IxpNjnioEh9jjTXZEEFL52L1kjh8HSGNNrvEb+uZEecyB+PNkZ O/aHYNuAnuBrZ9GMbJ8U3UdsCDvZACpervRMgOI2JKaKVXQJ2wUJShQWJlANfyxhj1iR52652 3B2K/SoCx2YYwOtc/X5qSsXco10V/6IaRydbuzCv8rhojJe8QOZbxSzZYw0zIMT+mom+0KERI fTu5rsAUOgObdpiREx0skE4U0aIQsOHO8BEGvPLXW1yltnLBzGRyHwXX0kc8kMXEgrFq/hXTp CaOhc7cz6qeYt7Tmm9OM2Zyac+0TklY7I5wpNpaXWEBSWuDMV2oNmLFbmFniLyfaNamLdtR94 qhQrtCd54Qjok8dkXJiOW5EfKxQEwYZ3SdJDDdJfLCsiT9Oh0/q8CS835NIXi9HeAvDSFg/bz /eWtTxgwKp2HqlJEiQnzUK6SnkTSxn51eiKnS/JS49fQ7Xiouhrugs+RtilDfdUyl/Hy7rgLJ RJVXBLfbBbkGOr6a4DcAA+IJgFAc3ynDz/5EN80CiaYANI/m7l4Nbj73H3wIw4Xa3VDE0psqI IbUM0LcMkMrNyO9TjB4GxoV/lrb5gtNkf0SqiLwa/BnbV3C1f0H9J4HR+bzTI5Tgx24B5mJJR 7UDpp6d3nbqUieuzhu/ROKvZDBzdjagxKWNnz3a6hGRmoRcEBBshfIIoDStFhR20uyEOzhMzo zHFwNce5HNKolKA6+FjoTAkN5b9WuZ3c3TiCKwy0EHw8wTDMc3y8pM4MKfdg05DZ9x8hhvmYd vQwqpUdx6AZiUDxZkrUP6eMpLlxYJnwxLoDzGzUGTXjKINeeg8= Archived-At: Subject: Re: [TLS] Layered TLS ... was Re: New Version Notification for draft-friel-tls-over-http-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 13:01:35 -0000 On 11/07/2017 01:20 PM, Salz, Rich wrote: > > ➢ Our work was motivated by the discussions in the IoT groups about > re-inventing the TLS handshake at the application layer. > > Isn’t that what QUIC does (to a good enough approximation)? > I see QUIC more as a new transport layer. From nobody Tue Nov 7 07:22:29 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E3613FF13 for ; Tue, 7 Nov 2017 07:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 wo8ZXE3KxUiq for ; Tue, 7 Nov 2017 07:22:23 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 23DC413FFBF for ; Tue, 7 Nov 2017 07:15:06 -0800 (PST) Received: from [192.168.91.204] ([80.92.118.86]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LhCDT-1ezlrs1c4l-00oZr0; Tue, 07 Nov 2017 16:15:03 +0100 To: Alex C , Richard Barnes Cc: "" References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: Date: Tue, 7 Nov 2017 16:15:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:UQC3Jc8mItn2+jZpXZO+tojfSBdgOM4zRMQEWh6+vLIsUFZA32k ZPbLA9pYoWiF/0NzAi9dQsT6UOkPh4SsJ7/ksAUScHwPcGtc7whU2cKa85S7Jlj3ahqnSJ+ K0KMVWkw1MbzZyIAPhcGkvEbV7+VZZVgCcPZd+MrI/TYMgMEBpdpRYoDPHTqZFkLHi4BZXI 6xOxkjPP+3YW9KpGNNhbA== X-UI-Out-Filterresults: notjunk:1;V01:K0:AfThMHehCK4=:u1s4R4YeJwJ0yMgzwPDyTa fVt6+iy8Vfsw3mv+cdm76+ZXPuO5wozH9ASnCFFnC7LlEe1aMxUae7jpe5UifHaBQy1DGML0i f/pi1BBBDchJtYkU6rhgXr0vhkAvPIM5d/kEZtfOTWX4QR0RaTPW5k5cIRWQXbjSj2Qr03OUZ ikv6AfGQM8aCiXXeqZsm5TAHiw/OAg91a329wOwXpe5X8Q6FUaJDsT+ZNreXWhtsy0trguv1p TYM8wSfl4fjJmWxAvebEYCQKLyzKiqo643Whs1nJ/u3XgEn8lP/2v2mmW5/t6352V/FNer621 QtkLdSay8L+FcJ6LU64+2dantRbpNKP6nTsQsQw5H74K2VpzIDsOTuNGVOr0QPetwFhnBiPx8 OnhQzRK8A7F09Qq4r5rxHayga4xpM45X9Ei06MJyxN4nZV9ZNBlU3JH7SjXntM/jwIzl8sI5M cHRfbEXIPlpTFsg/9BPFATY7oa7fsbvPuhLdg/Sf0nXBII804wfeTVWKGHWX9rcihECxEg5MK SQY16/kgdY1o5OYDyB1fapq20sF0/XJNjBJB7cJ5KKApeWXGl82bZhVlJcvXqTMhvrMm+/+N2 IcBIiOCNAmxYE6DdtExMEHtCJc01sjapWylqeQS50LSgC27UPgDwZ2h1dt6Fs3PTknRGVOXbm 7jivkeav9TnleVqShp6lLO7Ui25AMHltFST91Nsd+JcrvuwvM+S0Est4nRfQQ3jk0uiBfVwUF PYgg1C8GhCLNrrmpvZ5wKeLCmqdhIMnPz6ol8xbau7GhWQAB8djtSF9NnwSB+yrZaB+8VoIaa 9giH5zCQVEbGEY/g4T9291M8CQcMAl0z+wG6XV0oCDEd2XT79g= Archived-At: Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 15:22:25 -0000 FWIW: I can tell you what the threat model was with the layered TLS work. Let me give you a very specific example. Imagine a Bluetooth Low Energy device that communicates via a phone to a cloud-based service. The communication from the phone to the cloud uses HTTPS. The communication from the BLE device to the phone uses ordinary BLE services/characteristics. The Layered TLS/application layer TLS would in this case run from the BLE device all the way to the cloud-based service at the application layer. This allows us to provide end-to-end security across a proxy (in this case the phone) and independent of the underlying protocols. Does this make sense? Ciao Hannes On 11/07/2017 10:21 AM, Alex C wrote: > What exactly is the threat model here? > > Are you trying to hide a connection from a reverse proxy at the server > end? If so, the server operator should not have deployed a reverse proxy > in the first place. > > Are you trying to hide from a MITM proxy that supplies its own > certificate? If so, then what prevents the proxy from doing the same to > the tunnelled session? > When MITM proxies learn to do that, will we create another tunnelling > protocol inside this one? > > This is a cat-and-mouse game with middleboxes (much like the version > negotiation problem, but in a different way). Keep playing and everyone > loses. > > On Tue, Oct 31, 2017 at 11:17 AM, Richard Barnes > wrote: > > Hey TLS folks, > > Owen, Max, and I have been kicking around some ideas for how to make > secure connections in environments where HTTPS is subject to MitM / > proxying. > > The below draft lays out a way to tunnel TLS over HTTPS, in hopes of > creating a channel you could use when you really need things to be > private, even from the local MitM.  > > Feedback obviously very welcome.  Interested in whether folks think > this is a useful area in which to develop an RFC, and any thoughts > on how to do this better. > > Thanks, > --Richard > > > On Mon, Oct 30, 2017 at 3:47 PM, > wrote: > > > A new version of I-D, draft-friel-tls-over-http-00.txt > has been successfully submitted by Owen Friel and posted to the > IETF repository. > > Name:           draft-friel-tls-over-http > Revision:       00 > Title:          Application-Layer TLS > Document date:  2017-10-30 > Group:          Individual Submission > Pages:          20 > URL:            > https://www.ietf.org/internet-drafts/draft-friel-tls-over-http-00.txt > > Status:        >  https://datatracker.ietf.org/doc/draft-friel-tls-over-http/ > > Htmlized:      >  https://tools.ietf.org/html/draft-friel-tls-over-http-00 > > Htmlized:      >  https://datatracker.ietf.org/doc/html/draft-friel-tls-over-http-00 > > > > Abstract: >    Many clients need to establish secure connections to application >    services but face challenges establishing these connections > due to >    the presence of middleboxes that terminate TLS connections > from the >    client and restablish new TLS connections to the service.  This >    document defines a mechanism for transporting TLS records in HTTP >    message bodies between clients and services.  This enables > clients >    and services to establish secure connections using TLS at the >    application layer, and treat any middleboxes that are > intercepting >    traffic at the network layer as untrusted transport.  In > short, this >    mechanism moves the TLS handshake up the OSI stack to the > application >    layer. > > > > > Please note that it may take a couple of minutes from the time > of submission > until the htmlized version and diff are available at > tools.ietf.org . > > The IETF Secretariat > > > > _______________________________________________ > 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 > From nobody Tue Nov 7 07:49:41 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9532213401E for ; Tue, 7 Nov 2017 07:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 0t-skS1DIlrN for ; Tue, 7 Nov 2017 07:49:37 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 13A0A13FFB6 for ; Tue, 7 Nov 2017 07:43:31 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id t139so4848359wmt.1 for ; Tue, 07 Nov 2017 07:43:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7T8sKyXZPg5++o6jgL7rP80pNP9pm1DlW5x8H1GiS2Y=; b=vKpNu4TresyZsdMyRVgbQc989fbDjbyMSw/grfjYqzt3XjL2v9ej0lCXxrkvRHiiTb hYKm6mU7FfYDjb+42QaewdElA6SB9ehjVdFQLjTWAnER1fKDlqTJCb26HnAjCS2aDrbp 9gU7YQ7rqYLMWl7EZ3S55f9lkjxzVtnHeUCxkFXfWAVNSH0pKYmFyFPVDiRoYTEsZvFl RjZYxApubpun5eo+WjeVeG/bvO227VBKdCK19EzPP4C7pf5UIheXhxFxxYJ2f6Pvivh/ Zhh4+VlUvwUvL3qllOlPpQ1hE9M96w7hKxROipAiL3g5jXc5w+ojkp2MdeaMO9SNH+MW Mgig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7T8sKyXZPg5++o6jgL7rP80pNP9pm1DlW5x8H1GiS2Y=; b=Apz5NOdEcyqm4R5giDWQJXW5eT5cRubKKw3keZ5DozdRAoYZExd3EoK1r8UEdvBgAV LpAdiIKsQ0yaPhZgWOMGxHWKSh6V32Hv173khVm2dxZtOglwBwVqVF1BxahlKp4JEg+P GfVAs58VRVipXj8efX9oPhgoOcgtG/Wtu1D3+To/flQHsSPdjuNFkC7x7+akfYgcQTBm 9JkCfuZKxTEWV8h+QeSbbLO38a7/HN2sm9Gcr6hEmrWxbqag7J+yfRP/kj2Mj7MF0kbo fXTh1njPUNCBWROEgZpU+DhSx9OcSUKC3AH81rCgZ1EItThhFHnq5lTXbP0ojiRzD9Fv izxQ== X-Gm-Message-State: AJaThX4z5eaecKZ9Igx4dGOhhlN0U5VYUK369r6KgT164LFAoGi90yS9 gkiqxhMZfKhXunMZIFe5Lxg= X-Google-Smtp-Source: ABhQp+Q0GEutTEsqkNowpupGDYElcxB5fyB334uxKFPrQxiiPLbMZD9OSA79M5z8N3HqAkE/qMyrnQ== X-Received: by 10.28.18.144 with SMTP id 138mr1607143wms.135.1510068984831; Tue, 07 Nov 2017 07:36:24 -0800 (PST) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id p79sm2899286wmf.43.2017.11.07.07.36.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Nov 2017 07:36:24 -0800 (PST) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_16B1CC4F-EDCC-4C02-AF6A-FB7830FF6ED1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Tue, 7 Nov 2017 17:36:21 +0200 In-Reply-To: Cc: Alex C , Richard Barnes , "" To: Hannes Tschofenig References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 15:49:40 -0000 --Apple-Mail=_16B1CC4F-EDCC-4C02-AF6A-FB7830FF6ED1 Content-Type: multipart/alternative; boundary="Apple-Mail=_C1B3AAED-7D71-4D98-8E9C-77F97B88254C" --Apple-Mail=_C1B3AAED-7D71-4D98-8E9C-77F97B88254C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Hannes. I think it makes sense if the middlebox (whether a TLS proxy or a phone) = cannot perform a MitM attack against the internal TLS. This can be = achieved by having separate trust anchors for the application vs the = ones used for HTTPS, specifically not including any =E2=80=9Cproxy CA = certificate=E2=80=9D. Yoav > On 7 Nov 2017, at 17:15, Hannes Tschofenig = wrote: >=20 > FWIW: I can tell you what the threat model was with the layered TLS = work. >=20 > Let me give you a very specific example. Imagine a Bluetooth Low = Energy > device that communicates via a phone to a cloud-based service. The > communication from the phone to the cloud uses HTTPS. The = communication > from the BLE device to the phone uses ordinary BLE > services/characteristics. >=20 > The Layered TLS/application layer TLS would in this case run from the > BLE device all the way to the cloud-based service at the application = layer. >=20 > This allows us to provide end-to-end security across a proxy (in this > case the phone) and independent of the underlying protocols. >=20 > Does this make sense? >=20 > Ciao > Hannes >=20 >=20 > On 11/07/2017 10:21 AM, Alex C wrote: >> What exactly is the threat model here? >>=20 >> Are you trying to hide a connection from a reverse proxy at the = server >> end? If so, the server operator should not have deployed a reverse = proxy >> in the first place. >>=20 >> Are you trying to hide from a MITM proxy that supplies its own >> certificate? If so, then what prevents the proxy from doing the same = to >> the tunnelled session? >> When MITM proxies learn to do that, will we create another tunnelling >> protocol inside this one? >>=20 >> This is a cat-and-mouse game with middleboxes (much like the version >> negotiation problem, but in a different way). Keep playing and = everyone >> loses. >>=20 >> On Tue, Oct 31, 2017 at 11:17 AM, Richard Barnes > >> wrote: >>=20 >> Hey TLS folks, >>=20 >> Owen, Max, and I have been kicking around some ideas for how to = make >> secure connections in environments where HTTPS is subject to MitM = / >> proxying. >>=20 >> The below draft lays out a way to tunnel TLS over HTTPS, in hopes = of >> creating a channel you could use when you really need things to be >> private, even from the local MitM. >>=20 >> Feedback obviously very welcome. Interested in whether folks = think >> this is a useful area in which to develop an RFC, and any thoughts >> on how to do this better. >>=20 >> Thanks, >> --Richard >>=20 >>=20 >> On Mon, Oct 30, 2017 at 3:47 PM, >> >> wrote: >>=20 >>=20 >> A new version of I-D, draft-friel-tls-over-http-00.txt >> has been successfully submitted by Owen Friel and posted to = the >> IETF repository. >>=20 >> Name: draft-friel-tls-over-http >> Revision: 00 >> Title: Application-Layer TLS >> Document date: 2017-10-30 >> Group: Individual Submission >> Pages: 20 >> URL: >> = https://www.ietf.org/internet-drafts/draft-friel-tls-over-http-00.txt = >> = > >> Status: >> https://datatracker.ietf.org/doc/draft-friel-tls-over-http/ = >> > >> Htmlized: >> https://tools.ietf.org/html/draft-friel-tls-over-http-00 = >> > >> Htmlized: >> = https://datatracker.ietf.org/doc/html/draft-friel-tls-over-http-00 = >> = > >>=20 >>=20 >> Abstract: >> Many clients need to establish secure connections to = application >> services but face challenges establishing these connections >> due to >> the presence of middleboxes that terminate TLS connections >> from the >> client and restablish new TLS connections to the service. = This >> document defines a mechanism for transporting TLS records = in HTTP >> message bodies between clients and services. This enables >> clients >> and services to establish secure connections using TLS at = the >> application layer, and treat any middleboxes that are >> intercepting >> traffic at the network layer as untrusted transport. In >> short, this >> mechanism moves the TLS handshake up the OSI stack to the >> application >> layer. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time >> of submission >> until the htmlized version and diff are available at >> tools.ietf.org >. >>=20 >> The IETF Secretariat >>=20 >>=20 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls = >> > >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls = >>=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls = --Apple-Mail=_C1B3AAED-7D71-4D98-8E9C-77F97B88254C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = Hannes.

I think it = makes sense if the middlebox (whether a TLS proxy or a phone) cannot = perform a MitM attack against the internal TLS. This can be achieved by = having separate trust anchors for the application vs the ones used for = HTTPS, specifically not including any =E2=80=9Cproxy CA = certificate=E2=80=9D.

Yoav

On 7 Nov 2017, at 17:15, Hannes = Tschofenig <hannes.tschofenig@gmx.net> wrote:

FWIW: I can tell you what the = threat model was with the layered TLS work.
Let me give you a very specific example. Imagine = a Bluetooth Low Energy
device that communicates via a = phone to a cloud-based service. The
communication from the phone to = the cloud uses HTTPS. The communication
from the BLE device to the phone = uses ordinary BLE
services/characteristics.
The Layered TLS/application layer TLS would in = this case run from the
BLE device all the way to the = cloud-based service at the application layer.
This allows us to provide end-to-end security = across a proxy (in this
case the phone) and independent = of the underlying protocols.

Does this make sense?
Ciao
Hannes
On 11/07/2017 10:21 AM, Alex C wrote:
What exactly is the threat = model here?

Are you trying to hide a = connection from a reverse proxy at the server
end? If so, = the server operator should not have deployed a reverse proxy
in the first place.

Are you = trying to hide from a MITM proxy that supplies its own
certificate? If so, then what prevents the proxy from doing = the same to
the tunnelled session?
When MITM = proxies learn to do that, will we create another tunnelling
protocol inside this one?

This = is a cat-and-mouse game with middleboxes (much like the version
negotiation problem, but in a different way). Keep playing = and everyone
loses.

On Tue, = Oct 31, 2017 at 11:17 AM, Richard Barnes <rlb@ipv.sx
<mailto:rlb@ipv.sx>> wrote:

   Hey TLS folks,

   Owen, Max, and I have been kicking around = some ideas for how to make
   secure = connections in environments where HTTPS is subject to MitM /
   proxying.

   The below draft lays out a way to tunnel = TLS over HTTPS, in hopes of
   creating a = channel you could use when you really need things to be
   private, even from the local MitM. 

   Feedback obviously very = welcome.  Interested in whether folks think
   this is a useful area in which to develop = an RFC, and any thoughts
   on how to do = this better.

   Thanks,
   --Richard


   On Mon, Oct 30, 2017 at 3:47 PM, <internet-drafts@ietf.org
   <mailto:internet-drafts@ietf.org>> wrote:


       A new version of = I-D, draft-friel-tls-over-http-00.txt
       has been = successfully submitted by Owen Friel and posted to the
       IETF repository.

       Name:    =        draft-friel-tls-over-http
       Revision:  =      00
       Title:    =       Application-Layer TLS
       Document = date:  2017-10-30
       Group:    =       Individual Submission
       Pages:    =       20
       URL:    =        
       https://www.ietf.org/internet-drafts/draft-friel-tls-over-http-= 00.txt
       <https://www.ietf.org/internet-drafts/draft-friel-tls-over-http-= 00.txt>
       Status:  =      
        https://datatracker.ietf.org/doc/draft-friel-tls-over-http/=
       <https://datatracker.ietf.org/doc/draft-friel-tls-over-http/= >
       Htmlized:  =    
        https://tools.ietf.org/html/draft-friel-tls-over-http-00       <https://tools.ietf.org/html/draft-friel-tls-over-http-00>= ;
       Htmlized:  =    
        https://datatracker.ietf.org/doc/html/draft-friel-tls-over-http= -00
       <https://datatracker.ietf.org/doc/html/draft-friel-tls-over-http= -00>


       Abstract:
          Many = clients need to establish secure connections to application
         =  services but face challenges establishing these connections
       due to
          the = presence of middleboxes that terminate TLS connections
       from the
          client = and restablish new TLS connections to the service.  This
         =  document defines a mechanism for transporting TLS records in = HTTP
         =  message bodies between clients and services.  This enables
       clients
          and = services to establish secure connections using TLS at the
         =  application layer, and treat any middleboxes that are
       intercepting
         =  traffic at the network layer as untrusted transport.  In
       short, this
         =  mechanism moves the TLS handshake up the OSI stack to the
       application
         =  layer.




       Please= note that it may take a couple of minutes from the time
       of submission
       until the htmlized = version and diff are available at
       tools.ietf.org <http://tools.ietf.org>.

       The IETF = Secretariat



   _____________________________________________= __
   TLS mailing list
   TLS@ietf.org <mailto:TLS@ietf.org>
   https://www.ietf.org/mailman/listinfo/tls
   <https://www.ietf.org/mailman/listinfo/tls>




_______________________________________________
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

= --Apple-Mail=_C1B3AAED-7D71-4D98-8E9C-77F97B88254C-- --Apple-Mail=_16B1CC4F-EDCC-4C02-AF6A-FB7830FF6ED1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAloB0vUACgkQuEkLFQpY zJnuugf+O/4bBp3EobYZqN73/6LdrzT2Q26Q2ALch9ptrpSIKpdZ7EahCjCRrM8U hxOMkW4xhOL3Oqh7CR4J6tzwDzfPUbfWqeQAs1pxa+aEk2fRuy0KPFGL2mEklvgf sy0tNVuTEnUuXFVPWA0NRKelyrBkECX8DEl550/KL5pzAAQq8YYJlu4cBCoW3Rfv kaBFC+l1AZX0CwvzTrmfH8FxdzsgGgkE7kd+Y538/uxMoKG1rR0hg5yN2hH/cSbJ uybMFg8Rha65iVvPjas0Eg9P+u0TLMopHGu9CzIMUhkqe4OevHtnYp/9Fogk7emp Tpo2y0XkmreJGMXZpIVbD+ky0aZQNA== =F1dy -----END PGP SIGNATURE----- --Apple-Mail=_16B1CC4F-EDCC-4C02-AF6A-FB7830FF6ED1-- From nobody Tue Nov 7 07:53:39 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74EAE133894 for ; Tue, 7 Nov 2017 07:53:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 13GzAXaCdtIk for ; Tue, 7 Nov 2017 07:53:35 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43CC713388A for ; Tue, 7 Nov 2017 07:46:55 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 04B435D9E5; Tue, 7 Nov 2017 15:39:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 04B435D9E5 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hkario@redhat.com Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 87F275D731; Tue, 7 Nov 2017 15:39:31 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Tue, 07 Nov 2017 16:39:25 +0100 Message-ID: <4406543.RZChgRkkf9@pintsize.usersys.redhat.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1838363.0DTLoLDyBu"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 07 Nov 2017 15:39:32 +0000 (UTC) Archived-At: Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 15:53:37 -0000 --nextPart1838363.0DTLoLDyBu Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" In general +1, I like to see TLS 1.3 deployed ASAP and making the spurious= =20 failures as rare as possible is a good way to make that happen. that being said, I have few comments: On Monday, 6 November 2017 19:19:01 CET Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/pull/1091 >=20 > As I mentioned a while back, we've been seeing evidence of middlebox > intolerance. I just posted PR 1091, which is based on a bunch of work > by the BoringSSL team and an original suggestion by Kyle Nekritz that > should significantly decrease the rate of these errors. >=20 > The general idea here is to make TLS 1.3 look more like TLS 1.2 > resumption. The major changes are: >=20 > - Move version negotiation entirely into "supported_versions", and hence > ServerHello.version =3D=3D 0x0303 (TLS 1.2) > - Restore the missing session_id and compression fields in ServerHello less special cases in parser code - big +1 > - The client sends a fake session_id and the server echoes it > - The server sends ChangeCipherSpec messages after > ServerHello/HelloRetryRequest > (so that the middlebox ignores any "encrypted" data afterwards), > and the client sends ChangeCipherSpec after ClientHello. Either > side has to ignore ChangeCipherSpec during the handshake. That's the part I have a bit of a problem with. If the CCS is necessary to make middleboxes work, and given that lack-of-CC= S- intolerance is not something that we can detect reliably (not in a way that= =20 can be simulated by an attacker), I think the CCS should be baked in the TL= S=20 1.3 as deep as it was baked into TLS 1.2. That is, the standard should make it a mandatory message to send, fully par= sed=20 and validated, requiring aborting connection if it is received at any=20 unexpected moment, in duplicate, omitted or malformed. Not only as part of = the=20 "compatibility mode". > - Merge HRR and ServerHello into a single message with the semantics > distinguished by a special ServerHello.Random value. > - Switch the record layer version to 0x0303 for post-ClientHello > messages to match ServerHello. >=20 > Once you do this, the middleboxes seem to mostly ignore everything > after the CCS, so the rest of the handshake proceeds smoothly. So I have this crazy idea... What happens if the first message sent by clie= nt=20 and server is the CCS? =20 > This is all a bit nasty, but none of it changes the cryptographic > computations or the state machine (because you just ignore CCS). > Several of the most unpleasant changes (sending fake session id and > sending ChangeCipherSpec), are only needed in compatibility mode, > and if you don't have to worry about middleboxes, you can just > omit them. >=20 > There are implementations of these changes (except for HRR) in both > BoringSSL and NSS, and Google has preliminary measurements with these > changes that show comparable error rates to TLS 1.2 (I expect them to > publish those shortly). We expect to have further measurements from > Chrome as well as from Firefox by the WG meeting. >=20 > Please take a look and hopefully we can close on this in Singapore. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart1838363.0DTLoLDyBu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJaAdOtAAoJEJKo0bgB0vX1hyEQAIozQtN0JLILEwpw3RxzNsI9 syDJHwD5Ioig7eC5gSWZI/on6/GFI4KApcKYgbRaFBUtSR8iy28h2QrOIGyfa9Uy uf30aIoJUPthcHFiamsASd8YGW0eggZmKw/+tX2xG7Oc/W10EuYxT1uMlgLJboal tOl7NSRpAyzibL1YdSSbkOyIWsDyVqvNXOa5BHxdKGe6grfDSUV8ro9pL3k2Jato lGQ0w8xIaJDTenzvAq8zr5dhx1/RaprSyoe6FofGSbtUP65mgR+H3aIPlHs+GGlG AwwGO3qCFCv+jffw4PIYYrjIaHiDswb/wqTqpHjlDJpAapYyyDG9U4MsAx9uzQ78 xfmXAdjB3e0p6Sc5IwodwbVVSelE/shgWTydqwJtMwbEwS0eG7VQBA6v61scnAuq dLIObH1HfFZFJbwwku4eilI+lvOdaKAAUGm2BambNvbOkCrTyebMQ039sTisax1K 1H+bNKjjLMyqykdlWdkKl4Zd6WsYtIWRepzHwMfe/PF5MhQbo7UUnnWnwsi5sGFM VEKmBQOq6avcaDlsgWzWRbarSBjQMbLSjn0D+VSpNlOSI033RWJcaxniVqC7PyMD PWRV541yoNJy3GBVlkKHnP+2SQLXLREGLGsr8P8WyEMUy+0L4G2cWqfKWJpsDCqm eyf+mgvljm6k511LyqHF =Knlp -----END PGP SIGNATURE----- --nextPart1838363.0DTLoLDyBu-- From nobody Tue Nov 7 08:04:57 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96496133B7C for ; Tue, 7 Nov 2017 08:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 mwTuJP5hMbXc for ; Tue, 7 Nov 2017 08:04:54 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B078134886 for ; Tue, 7 Nov 2017 07:55:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29503; q=dns/txt; s=iport; t=1510070145; x=1511279745; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=vclKDDqoxmUOFMjmPR4/Wlh7jH/Y9tl84YkhAI0KHm0=; b=fp3Axdj/pZhP4OYgABn0btb54twcJm3zhXST0918WIT0NQfK4IfATtPQ 29KcsKyHWKUCJgsBN6qnllliWDak2wlHmHMPrQEl2MRKJ293RjRBUv+ZD 4BDFT3HIrTrX2UKERGAuHzFz7UPYfSGj1H7GnoTI3k18VwLPRKmbXL9ib k=; X-IronPort-AV: E=Sophos; i="5.44,359,1505779200"; d="scan'208,217"; a="99644972" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Nov 2017 15:55:45 +0000 Received: from [10.118.10.19] (rtp-fandreas-2-8812.cisco.com [10.118.10.19]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id vA7Fti6w002833; Tue, 7 Nov 2017 15:55:44 GMT To: Eric Rescorla , "Nancy Cam-Winget (ncamwing)" Cc: "tls@ietf.org" References: <895D1206-28D1-43AB-8A45-11DEEC86A71D@cisco.com> From: Flemming Andreasen Message-ID: Date: Tue, 7 Nov 2017 10:56:35 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6E9D2C40B121A87BD6D49D8A" Content-Language: en-US Archived-At: Subject: Re: [TLS] network-based security solution use cases X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 16:04:57 -0000 This is a multi-part message in MIME format. --------------6E9D2C40B121A87BD6D49D8A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thank you for the feedback Ekr - please see below for responses On 11/6/17 12:43 PM, Eric Rescorla wrote: > I took a look at this. > > Without getting into the question of whether the types of middleboxes > you describe here provide a security benefit, there are several points > in the document that are either wrong or at least misleading/confusing. > > - Key Synchronization > This document notes that in TLS 1.2, it is possible for a middlebox > that traffic keys match on both sides of the connection it is proxying, > but in TLS 1.3 it is not: > >    There are several techniques that can be utilized. Those techniques >    function with TLS 1.2 and earlier versions but not with TLS 1.3. > >    One technique is for the middlebox to negotiate the same master >    secret with the original TLS client and server, as if the two >    endpoints handshake directly.  This is also known as "Triple >    Handshake" used by legitimate middleboxes.  [BreakTLS] describes the >    methods with RSA and DH key exchanges.  When the proxy session keys >    are the same as for a direct handshake, the middlebox is able to >    "cut-through" the two TLS proxy sessions when it finishes the >    security inspection. > >    This technique is not functional with TLS 1.3 since the transcript >    hash over the handshake messages is part of the key derivation >    procedure. > > First, I would note that this property of TLS 1.2 is bad, as it leads > to Unknown Key Share (UKS) attacks, which can be the basis of real > attacks on TLS 1.2 as fielded. It is for this reason that the TLS > WG published RFC 7627. > Thanks for the bringing that one up - we will make sure to include that in the next version. Understood - it is nevertheless a change from TLS 1.2. In TLS 1.3, it's an integral part of the protocol that cannot be disabled. The TLS 1.2 extension does not share that property. > Second, this property is really only available with RSA. Although > it is possible for an attacker to synchronize DH keys by generating > bogus DH parameters, the technique described by Bhargavan et al > results in an insecure MS (i.e., the server's public DH share). > [See Section V-B of https://www.mitls.org/downloads/tlsauth.pdf] > Any middlebox doing this, therefore, has completely broken TLS > for the endpoints on both sides of it. Your document suggests > that people do use this technique: I sincerely hope not. > I'm not aware of actual implementations doing this with DH. > In short, this property of TLS 1.3 is really a property of the use > of (EC)DHE [0], the use of which is important for security even in TLS 1.2 > (hence the rapid increase in the use of ECDHE and the corresponding > decline in static RSA). Even if TLS 1.3 were never deployed, the > continued use of static RSA is going to be come increasingly > nonviable. > Fair point. > Finally, you note several times in the document (e.g., S 4.5), that > with key synchronization, the middlebox can perform the handshake and > then disengage from the connection. However, the cases you mention > (e.g.., detecting exploit attempts) ultimately require examining > all traffic in the connection. > We have several different use case scenarios in there, and I agree with the observation that they cannot all be satisfied at the same time. For example, we cannot scan for malware in an encrypted stream to a financial institution that we are not allowed to decrypt. That doesn't mean either use case is invalid. Customers do both in real-life (just not at the same time). > > - PSK and resumption > You write: > >    In TLS 1.3, the above mechanism is replaced by Pre-Shared Keys (PSK), >    which can be negotiated as part of an initial handshake and then used >    in a subsequent handshake to perform resumption using the PSK.  TLS >    1.3 states that the client SHOULD include a "key_share" extension to >    enable the server to decline resumption and fall back to a full >    handshake, however it is not an absolute requirement. > >    Example scenarios that are impacted by this are middleboxes that were >    not part of the initial handshake, and hence do not know the PSK.  If >    the client does not include the "key_share" extension, the middlebox >    cannot force a fallback to the full handshake.  If the middlebox >    policy requires it to inspect the session, it will have to fail the >    connection instead. > > In TLS 1.3, PSKs and session resumption are basically the same and > have the same properties. While I concede that the document does > not require the client to offer key_shares, as a practical matter > it is very unlikely that a client will act in such a way that > failure to retain the PSK causes a hard failure, for two reasons: > > (a) In every version of TLS, the ticket lifetime is just a hint, and >     the server can forget it at any time >     > (https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#NSTMessage > ). > Thus, >     a client which does not allow a full handshake will often >     find itself unable to connect. > > (b) The relevant question is not whether the client offers a key share >     extension but whether it advertises any DH groups. If the client sends >     a group but not a key share, the server can send HelloRetryRequest >     to force the client to send a key share. > > For these reasons, as far as I know, every client (and at least every > browser client) should allow a full handshake even when trying to resume. > If that is indeed the case, then I would suggest changing the spec language to a MUST here instead so we can guarantee it. > > - Server Certificate Concealment > You note that in TLS 1.2 the middlebox can examine both the SNI and the > server's certificate in order to decide whether to MITM the connection, > but that in TLS 1.3, the middlebox cannot guarantee that the SNI in > uses is correct: > >    In TLS 1.2, the ClientHello, ServerHello and Certificate messages are >    all sent in clear-text, however in TLS 1.3, the Certificate message >    is encrypted thereby hiding the server identity from any >    intermediary.  Note that even _if_ the SNI is provided (in cleartext) >    by the client, there is no guarantee that the actual server >    responding is the one indicated in the SNI from the client. > > In this case, it's important to distinguish between conformant and > nonconformant clients. In the former case -- as when the user is > not attempting to evade inspection -- the SNI will reflect the > identity that the client expects and therefore will compare the > certificate against. > > Of course, in the case where the client is attempting to evade > inspection, the certificate might not match. However, in this > scenario, the client and server are colluding and so there are > a variety of ways to avoid inspection, even when doing TLS 1.2. > > For example: > > 1. The client and server can share a prearranged public key and then > negotiate static RSA. The client sends an innocuous SNI and the server > can simply send the certificate of the corresponding server, captured > by connecting to that server. The client then enciphers the PMS > under the server's prearranged key and continues with TLS as usual. > This cannot be detected by the middlebox without decrypting the EPMS. > > 2. If an (EC)DHE cipher suite must be negotiated, then the attack > described above does not work directly because the server's signature > over the ServerKeyExchange can be validated, and of course the > attacker server does not have the legitimate server's key. However, > the server can forward the ClientHello to the legitimate server, > capture the Certificate and ServerKeyExchange and the proxy those to > the client. This looks legitimate to the inspection device and then > the client can simply send the Encrypted PMS in the first chunk of > data that is apparently encrypted under the server's key. > > For these reasons, being able to see the server's certificate provides > a false sense of security, as this check is easily bypassed. I agree we should distinguish between between conformant and non-comformant. For the conformant case, I do not know to what extent we can rely on the client always sending the SNI, but even if it is always sent, there are still use case scenarios around certificate audit, etc. that cannot be satisified in TLS 1.3 without becoming an active MITM. With the recently adopted proposal around SNI encryption, there are more use cases that cannot be satisfied without becoming an active MITM. For the non-conformant case, you bring up some good points. We can reduce the set of bypass scenarios there, but we cannot eliminate them. Thanks again for the feedback - we will update accordingly in the next version of the draft. -- Flemming > > -Ekr > > > [0] Note: the use of static DH is very rare. > > > On Fri, Nov 3, 2017 at 6:49 PM, Nancy Cam-Winget (ncamwing) > > wrote: > > All, > > @IETF99, awareness was raised to some of the security WGs (thanks > Kathleen ☺) that TLS 1.3 will obscure visibility currently > afforded in TLS 1.2 and asked what the implications would be for > the security solutions today. > https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00 > is > an initial draft to describe some of the impacts relating to > current network security solutions.  The goal of the draft is NOT > to propose any solution as a few have been proposed, but rather to > raise awareness to how current network-based security solutions > work today and their impact on them based on the current TLS 1.3 > specification. > > Regards, Nancy, Flemming and Eric > > > _______________________________________________ > 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 --------------6E9D2C40B121A87BD6D49D8A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Thank you for the feedback Ekr - please see below for responses

On 11/6/17 12:43 PM, Eric Rescorla wrote:
I took a look at this.

Without getting into the question of whether the types of middleboxes
you describe here provide a security benefit, there are several points
in the document that are either wrong or at least misleading/confusing.

- Key Synchronization
This document notes that in TLS 1.2, it is possible for a middlebox
that traffic keys match on both sides of the connection it is proxying,
but in TLS 1.3 it is not:

   There are several techniques that can be utilized.  Those techniques
   function with TLS 1.2 and earlier versions but not with TLS 1.3.

   One technique is for the middlebox to negotiate the same master
   secret with the original TLS client and server, as if the two
   endpoints handshake directly.  This is also known as "Triple
   Handshake" used by legitimate middleboxes.  [BreakTLS] describes the
   methods with RSA and DH key exchanges.  When the proxy session keys
   are the same as for a direct handshake, the middlebox is able to
   "cut-through" the two TLS proxy sessions when it finishes the
   security inspection.

   This technique is not functional with TLS 1.3 since the transcript
   hash over the handshake messages is part of the key derivation
   procedure.

First, I would note that this property of TLS 1.2 is bad, as it leads
to Unknown Key Share (UKS) attacks, which can be the basis of real
attacks on TLS 1.2 as fielded. It is for this reason that the TLS
WG published RFC 7627.

Thanks for the bringing that one up - we will make sure to include that in the next version.

Understood - it is nevertheless a change from TLS 1.2. In TLS 1.3, it's an integral part of the protocol that cannot be disabled. The TLS 1.2 extension does not share that property.

Second, this property is really only available with RSA. Although
it is possible for an attacker to synchronize DH keys by generating
bogus DH parameters, the technique described by Bhargavan et al
results in an insecure MS (i.e., the server's public DH share).
Any middlebox doing this, therefore, has completely broken TLS
for the endpoints on both sides of it. Your document suggests
that people do use this technique: I sincerely hope not.

I'm not aware of actual implementations doing this with DH.


In short, this property of TLS 1.3 is really a property of the use
of (EC)DHE [0], the use of which is important for security even in TLS 1.2
(hence the rapid increase in the use of ECDHE and the corresponding
decline in static RSA). Even if TLS 1.3 were never deployed, the
continued use of static RSA is going to be come increasingly
nonviable.

Fair point.


Finally, you note several times in the document (e.g., S 4.5), that
with key synchronization, the middlebox can perform the handshake and
then disengage from the connection. However, the cases you mention
(e.g.., detecting exploit attempts) ultimately require examining
all traffic in the connection.

We have several different use case scenarios in there, and I agree with the observation that they cannot all be satisfied at the same time. For example, we cannot scan for malware in an encrypted stream to a financial institution that we are not allowed to decrypt. That doesn't mean either use case is invalid. Customers do both in real-life (just not at the same time).


- PSK and resumption
You write:

   In TLS 1.3, the above mechanism is replaced by Pre-Shared Keys (PSK),
   which can be negotiated as part of an initial handshake and then used
   in a subsequent handshake to perform resumption using the PSK.  TLS
   1.3 states that the client SHOULD include a "key_share" extension to
   enable the server to decline resumption and fall back to a full
   handshake, however it is not an absolute requirement.

   Example scenarios that are impacted by this are middleboxes that were
   not part of the initial handshake, and hence do not know the PSK.  If
   the client does not include the "key_share" extension, the middlebox
   cannot force a fallback to the full handshake.  If the middlebox
   policy requires it to inspect the session, it will have to fail the
   connection instead.

In TLS 1.3, PSKs and session resumption are basically the same and
have the same properties. While I concede that the document does
not require the client to offer key_shares, as a practical matter
it is very unlikely that a client will act in such a way that
failure to retain the PSK causes a hard failure, for two reasons:

(a) In every version of TLS, the ticket lifetime is just a hint, and
    the server can forget it at any time
    a client which does not allow a full handshake will often
    find itself unable to connect.

(b) The relevant question is not whether the client offers a key share
    extension but whether it advertises any DH groups. If the client sends
    a group but not a key share, the server can send HelloRetryRequest
    to force the client to send a key share.

For these reasons, as far as I know, every client (and at least every
browser client) should allow a full handshake even when trying to resume.

If that is indeed the case, then I would suggest changing the spec language to a MUST here instead so we can guarantee it.


- Server Certificate Concealment
You note that in TLS 1.2 the middlebox can examine both the SNI and the
server's certificate in order to decide whether to MITM the connection,
but that in TLS 1.3, the middlebox cannot guarantee that the SNI in
uses is correct:

   In TLS 1.2, the ClientHello, ServerHello and Certificate messages are
   all sent in clear-text, however in TLS 1.3, the Certificate message
   is encrypted thereby hiding the server identity from any
   intermediary.  Note that even _if_ the SNI is provided (in cleartext)
   by the client, there is no guarantee that the actual server
   responding is the one indicated in the SNI from the client.

In this case, it's important to distinguish between conformant and
nonconformant clients. In the former case -- as when the user is
not attempting to evade inspection -- the SNI will reflect the
identity that the client expects and therefore will compare the
certificate against.

Of course, in the case where the client is attempting to evade
inspection, the certificate might not match. However, in this
scenario, the client and server are colluding and so there are
a variety of ways to avoid inspection, even when doing TLS 1.2.

For example:

1. The client and server can share a prearranged public key and then
negotiate static RSA. The client sends an innocuous SNI and the server
can simply send the certificate of the corresponding server, captured
by connecting to that server. The client then enciphers the PMS
under the server's prearranged key and continues with TLS as usual.
This cannot be detected by the middlebox without decrypting the EPMS.

2. If an (EC)DHE cipher suite must be negotiated, then the attack
described above does not work directly because the server's signature
over the ServerKeyExchange can be validated, and of course the
attacker server does not have the legitimate server's key. However,
the server can forward the ClientHello to the legitimate server,
capture the Certificate and ServerKeyExchange and the proxy those to
the client. This looks legitimate to the inspection device and then
the client can simply send the Encrypted PMS in the first chunk of
data that is apparently encrypted under the server's key.

For these reasons, being able to see the server's certificate provides
a false sense of security, as this check is easily bypassed.
I agree we should distinguish between between conformant and non-comformant.

For the conformant case, I do not know to what extent we can rely on the client always sending the SNI, but even if it is always sent, there are still use case scenarios around certificate audit, etc. that cannot be satisified in TLS 1.3 without becoming an active MITM. With the recently adopted proposal around SNI encryption, there are more use cases that cannot be satisfied without becoming an active MITM.  

For the non-conformant case, you bring up some good points. We can reduce the set of bypass scenarios there, but we cannot eliminate them.


Thanks again for the feedback - we will update accordingly in the next version of the draft.

-- Flemming



-Ekr


[0] Note: the use of static DH is very rare.


On Fri, Nov 3, 2017 at 6:49 PM, Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com> wrote:

All,

 

@IETF99, awareness was raised to some of the security WGs (thanks Kathleen ☺) that TLS 1.3 will obscure visibility currently afforded in TLS 1.2 and asked what the implications would be for the security solutions today.  https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00 is an initial draft to describe some of the impacts relating to current network security solutions.  The goal of the draft is NOT to propose any solution as a few have been proposed, but rather to raise awareness to how current network-based security solutions work today and their impact on them based on the current TLS 1.3 specification.

 

Regards, Nancy, Flemming and Eric


_______________________________________________
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

--------------6E9D2C40B121A87BD6D49D8A-- From nobody Tue Nov 7 08:25:50 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3A61241F3 for ; Tue, 7 Nov 2017 08:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=oWFFmaco; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PZch/7Jz 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 G_ohjXZj2JX0 for ; Tue, 7 Nov 2017 08:25:48 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19F713380C for ; Tue, 7 Nov 2017 08:21:47 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 4435A20D67; Tue, 7 Nov 2017 11:21:47 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 07 Nov 2017 11:21:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=agQgpEwS5vO9tLTT924scXFd6LtyPbVr8g8nd5Ja5w4=; b=oWFFmaco cMnhG1xIkGbsy8mhSGaw06Hwif6tSuO7mmr6kMSwtAVZw0BqTYl+al4eakuAuwQ4 jEk+CZTrffVW/6Z0AIkzEkriwXyc5dqHe4elB6hF3fXVwKokbgOMceohQiRlCJiG 3/j5pSSEzOtI90/dXCjA4c7XjIx1Wpq7Q/MHKVoNtziJimdWdy6L55uu77M5PV2T hZBGKgTKTgbx4qBmL+0kRj6O6DM+9rdsUuOTXbnDp5P+PES84fFrmnwS2IbV/Ssj n7ujhVA3Rzeq36LXBHWxO87IFZqwrLsv+hBKfp4Rk681GUV+FLPeNRL10ZHqnDJ4 cw9lvZoM95X+og== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=agQgpEwS5vO9tLTT924scXFd6LtyP bVr8g8nd5Ja5w4=; b=PZch/7JzdDXobvdbmYp0DUERnSJ+GI96bvN7M2klLiJjL Vth/+GcPWG4BDVPgt2JxJE3iQDdXYD1hKOsKCqbSlmr79z9akqQjThuX+/h5LP5W EgGgc0XSxoVjH4ypqtj+S8mxe7Zauc3WOUljfa5apLhVTdshTDqNCxzOSNXOetUb Helrla+Yx7iXWmGrxXpMgtI1M6vED2tsRxUzNQ1/uuhfhco2cwI4t5Dl5IIJyqC3 sPbCZuGcrFMOOwFJ0MIccQuVuFDgUYYms4V7HiRkFyZ3xlobIkxvjax2/HXPQWPk F5Pqftjbk/7y8fkzF/Oi4YPExQsuoqIaEL1r0P3Sw== X-ME-Sender: Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id BD7477FADE; Tue, 7 Nov 2017 11:21:46 -0500 (EST) To: tls@ietf.org References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> From: Peter Saint-Andre Message-ID: Date: Tue, 7 Nov 2017 09:21:45 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7pouqj6CIrJWAwvQ9O9Uf8rX4blhWGISR" Archived-At: Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 16:25:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7pouqj6CIrJWAwvQ9O9Uf8rX4blhWGISR Content-Type: multipart/mixed; boundary="ciMmlPPqpeDNo5rAF6xq9CD6qkweGUhAM"; protected-headers="v1" From: Peter Saint-Andre To: tls@ietf.org Message-ID: Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> In-Reply-To: --ciMmlPPqpeDNo5rAF6xq9CD6qkweGUhAM Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/7/17 8:15 AM, Hannes Tschofenig wrote: > FWIW: I can tell you what the threat model was with the layered TLS wor= k. >=20 > Let me give you a very specific example. Imagine a Bluetooth Low Energy= > device that communicates via a phone to a cloud-based service. The > communication from the phone to the cloud uses HTTPS. The communication= > from the BLE device to the phone uses ordinary BLE > services/characteristics. >=20 > The Layered TLS/application layer TLS would in this case run from the > BLE device all the way to the cloud-based service at the application la= yer. >=20 > This allows us to provide end-to-end security across a proxy (in this > case the phone) and independent of the underlying protocols. >=20 > Does this make sense? Given your assumptions, yes. Although IMHO there's got to be a better way to accomplish the goal of end-to-end security here. If I were going to IETF 100, I'd propose getting together for a beer to discuss... Peter --ciMmlPPqpeDNo5rAF6xq9CD6qkweGUhAM-- --7pouqj6CIrJWAwvQ9O9Uf8rX4blhWGISR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEO1gGYnPG8aeH+JR96gakkSvFrakFAloB3ZkACgkQ6gakkSvF ramSXhAAllMQHyBaV9A5brp0rx/znraqWiW0uUmNYl5gQjqVTtus432wWPV0WU9V R5g6ndMy2Ln5A6nR7uT/TfJXYTstcYWVU1anb673WYKrAm7C2jqYhN92mUy+2tlV ukC4AkMt2SOfhJteKmROA0rOscsd3s5Uj9VTKTUtq4r0W84I+9+OWnh2rvTsHcx8 lEQ308CUrF0hw/AmHwY80u9oB1X0vW+3ipyH8hHw7cAnBzrFuhVNNf7QT0LzRPcS Nlm/4laSsO6Z9k62o+8Jrs7RUALsfxfP8lkVmXsls5kXEzE8n8oIKLuW29agtWFe biYql6EBYpTMvJQUG8af6yoCrC/KFZ839AIS4/dQVQ4CsJWMB4fPP+ZpQ+oUwya4 uO/M550V6MqMRtYUFV7CUmkODQgFm83CSzWbW3HA7PpQsaV4NOqxrqsjklCoLkX3 kvLe49/osJSYwj50nVqgoJOrHzMB+Px3PcuXjKavUKGA4JE93U57XRhQHeX7hbdU cdpmzgM9X+jpWSw674KAbXEC5FwOvhFT1ZScigX3yqmuWwzZt48TmcWGM5h0TKcr Y+g+f7xb3PIBRAMUGuwEan9efLj0ZNNW2QchPUOMzsJ5DTw+In1iDkg/+SXr1s2X n3oMoO0qiod2OGj15K9iCjxMcT2wxu0gT1MyMC/pg+s6RNPYhIM= =HhSW -----END PGP SIGNATURE----- --7pouqj6CIrJWAwvQ9O9Uf8rX4blhWGISR-- From nobody Tue Nov 7 08:59:38 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23CD8132D41 for ; Tue, 7 Nov 2017 08:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 TSeuh0FJ5GAl for ; Tue, 7 Nov 2017 08:59:35 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 0136313295C for ; Tue, 7 Nov 2017 08:59:34 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id k31so16051660qta.6 for ; Tue, 07 Nov 2017 08:59:34 -0800 (PST) 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 :cc; bh=u2NryuciW4MxfWUlvGpB8bsFD+P2RpVCyP5jXj2vsY8=; b=loWYDD3IoAgzN9oocE7/lnno3ouGtYXGaNN07dKjE3idt6TcvEC6xwVq/9rdIW5KwD nqJf2fswCYtrpq+A93h5M0eQT/zRj2nqMSmF2IJVnxH6I766BJXJfHhsWeUIUj+IYywu NZNUzVa/zNo5QZbOcsJla+Qsfg1IVj24G6qh0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=u2NryuciW4MxfWUlvGpB8bsFD+P2RpVCyP5jXj2vsY8=; b=DnIc1H6DAGMdV8VJtxXC2OKv+GA9fs99zLPJaqguJsRp1cg4Gd/UHIjgvz3QVZTudi l9Qs0SIHtZrRTD5/14ZBSIJ9geLsWWECf9nGZmX4/D/4dEcd1+6SaUgrG+BGx5kX47D1 IbbK5lzcBpLOG7MPvCSLj8nhH7vJH4dp/w1xR8X+DsK42GeaPGqg0EJHDINwcQh1ilzD aAa8kGIWDaMyhEA3Hm88+And6J0rml5jbYx9CvbsqvjnZB5HWYQWzwzpsK5cp+s1dIvr mkZAcdzwhD5NzWqZS+lBzRNAN64HX7gz6aAHQuU2GR5dtBDdcZEovMIEuOLaV8jnfi37 eqxQ== X-Gm-Message-State: AJaThX7Exw2u/GH5SpCxRi4KtYrz4J5C1apwcyYHEz0Aueo5y+1vnhBI Da1079NDwdGjPkhYWV1e0fFUpXt9NkNkSjE8J97s X-Google-Smtp-Source: ABhQp+SKquxDsl0KFFm5XmkXnpbskHWwywv/BOAkPUky3VumURKcCEULZ57UU/EJ/GbaOVlI/6MSf7sbgMnVi/6Xrc4= X-Received: by 10.200.57.86 with SMTP id t22mr30097722qtb.117.1510073973934; Tue, 07 Nov 2017 08:59:33 -0800 (PST) MIME-Version: 1.0 References: <4406543.RZChgRkkf9@pintsize.usersys.redhat.com> In-Reply-To: <4406543.RZChgRkkf9@pintsize.usersys.redhat.com> From: David Benjamin Date: Tue, 07 Nov 2017 16:59:21 +0000 Message-ID: To: Hubert Kario Cc: tls@ietf.org Content-Type: multipart/alternative; boundary="001a113b908ecd94fe055d677e38" Archived-At: Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 16:59:37 -0000 --001a113b908ecd94fe055d677e38 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 7, 2017 at 10:53 AM Hubert Kario wrote: > In general +1, I like to see TLS 1.3 deployed ASAP and making the spuriou= s > failures as rare as possible is a good way to make that happen. > > that being said, I have few comments: > > On Monday, 6 November 2017 19:19:01 CET Eric Rescorla wrote: > > https://github.com/tlswg/tls13-spec/pull/1091 > > > > As I mentioned a while back, we've been seeing evidence of middlebox > > intolerance. I just posted PR 1091, which is based on a bunch of work > > by the BoringSSL team and an original suggestion by Kyle Nekritz that > > should significantly decrease the rate of these errors. > > > > The general idea here is to make TLS 1.3 look more like TLS 1.2 > > resumption. The major changes are: > > > > - Move version negotiation entirely into "supported_versions", and henc= e > > ServerHello.version =3D=3D 0x0303 (TLS 1.2) > > - Restore the missing session_id and compression fields in ServerHello > > less special cases in parser code - big +1 > > > - The client sends a fake session_id and the server echoes it > > - The server sends ChangeCipherSpec messages after > > ServerHello/HelloRetryRequest > > (so that the middlebox ignores any "encrypted" data afterwards), > > and the client sends ChangeCipherSpec after ClientHello. Either > > side has to ignore ChangeCipherSpec during the handshake. > > That's the part I have a bit of a problem with. > If the CCS is necessary to make middleboxes work, and given that > lack-of-CCS- > intolerance is not something that we can detect reliably (not in a way th= at > can be simulated by an attacker), I think the CCS should be baked in the > TLS > 1.3 as deep as it was baked into TLS 1.2. > > That is, the standard should make it a mandatory message to send, fully > parsed > and validated, requiring aborting connection if it is received at any > unexpected moment, in duplicate, omitted or malformed. Not only as part o= f > the > "compatibility mode". > Having the receiver check would work for us (it's what our prototypes do). And it's true that, were receivers to enforce this, it would be more likely that implementations reliably work in these environments despite not testing against them directly. But we got feedback that this would be too much complexity for some folks. Getting CCS/handshake synchronization right is a little subtle. And indeed, I think CCS in TLS 1.2 was generally considered to have been a mistake. Having the receiver ignore CCS also allows use cases without this kind of baggage (consider QUIC's embedding of TLS 1.3) to unilaterally disable this compatibility mode. So I think I prefer the formulation in the PR. > > - Merge HRR and ServerHello into a single message with the semantics > > distinguished by a special ServerHello.Random value. > > - Switch the record layer version to 0x0303 for post-ClientHello > > messages to match ServerHello. > > > > Once you do this, the middleboxes seem to mostly ignore everything > > after the CCS, so the rest of the handshake proceeds smoothly. > > So I have this crazy idea... What happens if the first message sent by > client > and server is the CCS? > We didn't test that variant, but we did try turning off the client-generated session ID to see if that was necessary and it was if I recall, the failure rate without that was comparable to draft-18 if not higher. Additionally, we know that making the record layer say TLS 1.2 was necessary once we made ServerHello.version say TLS 1.2. (We'd have had a proposal for the working group sooner had we not missed that difference first time around! :-( ) This makes me doubt just sticking a CCS in front would suffice. It suggests that middleboxes are actually parsing out TLS more deeply than that. Which is also what one can expect. I think the clear conclusion one can draw from this issue and similar elsewhere is that every reliably observable property of network traffic will, over time, become ossified. The Internet is very change-averse, and TLS 1.2 gave it far too many bits to latch onto. > > This is all a bit nasty, but none of it changes the cryptographic > > computations or the state machine (because you just ignore CCS). > > Several of the most unpleasant changes (sending fake session id and > > sending ChangeCipherSpec), are only needed in compatibility mode, > > and if you don't have to worry about middleboxes, you can just > > omit them. > > > > There are implementations of these changes (except for HRR) in both > > BoringSSL and NSS, and Google has preliminary measurements with these > > changes that show comparable error rates to TLS 1.2 (I expect them to > > publish those shortly). We expect to have further measurements from > > Chrome as well as from Firefox by the WG meeting. > > > > Please take a look and hopefully we can close on this in Singapore. > > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech > Republic_______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113b908ecd94fe055d677e38 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 7,= 2017 at 10:53 AM Hubert Kario <hkario@redhat.com> wrote:
In general +1, I like to see TLS 1.3 deployed ASAP and making= the spurious
failures as rare as possible is a good way to make that happen.

that being said, I have few comments:

On Monday, 6 November 2017 19:19:01 CET Eric Rescorla wrote:
> https://github.com/tlswg/tls13-spec/pull/1091<= br> >
> As I mentioned a while back, we've been seeing evidence of middleb= ox
> intolerance. I just posted PR 1091, which is based on a bunch of work<= br> > by the BoringSSL team and an original suggestion by Kyle Nekritz that<= br> > should significantly decrease the rate of these errors.
>
> The general idea here is to make TLS 1.3 look more like TLS 1.2
> resumption. The major changes are:
>
> - Move version negotiation entirely into "supported_versions"= ;, and hence
>=C2=A0 =C2=A0ServerHello.version =3D=3D 0x0303 (TLS 1.2)
> - Restore the missing session_id and compression fields in ServerHello=

less special cases in parser code - big +1

> - The client sends a fake session_id and the server echoes it
> - The server sends ChangeCipherSpec messages after
> ServerHello/HelloRetryRequest
>=C2=A0 =C2=A0(so that the middlebox ignores any "encrypted" d= ata afterwards),
>=C2=A0 =C2=A0and the client sends ChangeCipherSpec after ClientHello. E= ither
>=C2=A0 =C2=A0side has to ignore ChangeCipherSpec during the handshake.<= br>
That's the part I have a bit of a problem with.
If the CCS is necessary to make middleboxes work, and given that lack-of-CC= S-
intolerance is not something that we can detect reliably (not in a way that=
can be simulated by an attacker), I think the CCS should be baked in the TL= S
1.3 as deep as it was baked into TLS 1.2.

That is, the standard should make it a mandatory message to send, fully par= sed
and validated, requiring aborting connection if it is received at any
unexpected moment, in duplicate, omitted or malformed. Not only as part of = the
"compatibility mode".

Having the receiver check would = work for us (it's what our prototypes do). And it's true that, were= receivers to enforce this, it would be more likely that implementations re= liably work in these environments despite not testing against them directly= .

But we got feedback that this would be too much = complexity for some folks. Getting CCS/handshake synchronization right is a= little subtle. And indeed, I think CCS in TLS 1.2 was generally considered= to have been a mistake. Having the receiver ignore CCS also allows use cas= es without this kind of baggage (consider QUIC's embedding of TLS 1.3) = to unilaterally disable this compatibility mode.

S= o I think I prefer the formulation in the PR.
=C2=A0
> - Merge HRR and ServerHello into a single message with the semantics >=C2=A0 =C2=A0distinguished by a special ServerHello.Random value.
> - Switch the record layer version to 0x0303 for post-ClientHello
>=C2=A0 =C2=A0messages to match ServerHello.
>
> Once you do this, the middleboxes seem to mostly ignore everything
> after the CCS, so the rest of the handshake proceeds smoothly.

So I have this crazy idea... What happens if the first message sent by clie= nt
and server is the CCS?

We didn't test that variant, b= ut we did try turning off the client-generated session ID to see if that wa= s necessary and it was if I recall, the failure rate without that was compa= rable to draft-18 if not higher. Additionally, we know that making the reco= rd layer say TLS 1.2 was necessary once we made ServerHello.version say TLS= 1.2. (We'd have had a proposal for the working group sooner had we not= missed that difference first time around! :-( )

T= his makes me doubt just sticking a CCS in front would suffice. It suggests = that middleboxes are actually parsing out TLS more deeply than that. Which = is also what one can expect. I think the clear conclusion one can draw from= this issue and similar elsewhere is that every reliably observable propert= y of network traffic will, over time, become ossified. The Internet is very= change-averse, and TLS 1.2 gave it far too many bits to latch onto.
<= /div>
=C2=A0
> This is all a bit nasty, but none of it changes the cryptographic
> computations or the state machine (because you just ignore CCS).
> Several of the most unpleasant changes (sending fake session id and > sending ChangeCipherSpec), are only needed in compatibility mode,
> and if you don't have to worry about middleboxes, you can just
> omit them.
>
> There are implementations of these changes (except for HRR) in both > BoringSSL and NSS, and Google has preliminary measurements with these<= br> > changes that show comparable error rates to TLS 1.2 (I expect them to<= br> > publish those shortly). We expect to have further measurements from > Chrome as well as from Firefox by the WG meeting.
>
> Please take a look and hopefully we can close on this in Singapore.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech Republic= _______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a113b908ecd94fe055d677e38-- From nobody Tue Nov 7 09:18:19 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6A2120724 for ; Tue, 7 Nov 2017 09:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 JoIb1N7bamxd for ; Tue, 7 Nov 2017 09:18:15 -0800 (PST) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 C4046132A1A for ; Tue, 7 Nov 2017 09:18:14 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id q1so11527703ywh.5 for ; Tue, 07 Nov 2017 09:18:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SkGEt2CvOUSK8IDrXHp9+g+Jxpky+t7NyXoGm53KP4k=; b=k+bFTfIOK0juKNC9Z32O1me/kyEFEBpnwtBphiCxANDwJC1uLjxfMbNpSiB7iNbha8 Pcx0ZttZyS7o4Vu2fd8exXQHJSsGrmTX9h5rztwvMKYwKH8UZogGhLCoMG9vHAHLh43D P6zrSuW0PH3K7E0gUWeY58ENd5dh8ZwdXwOpKXfp+6nPlq8cU+bM3lsrTQ7QjL+eosoe VHln408eX6nUQ/0naVZT9/+/TFoC7v9da2RuY3Er4H216miZ4gkwAzlmq+Y41xk+9Hym fifn6obOh7U9LpAF5I/PNLP6g/Q6Bjn0oc5qUBf8wpzlc8vUwmtuJmwvAkZnIulk0cIX dK2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SkGEt2CvOUSK8IDrXHp9+g+Jxpky+t7NyXoGm53KP4k=; b=Xv1IDNuOKk0qY59akmA+RGMOPL82S+S1Z3/Wsfqdo3LdD1n4kl5EdjhsD5UmNxqI6a 5xclj0aJF9hFKzKg51G0oLIsNEwBxDC4mC3aEMnxzZXnlw3LaieAXIpXQhLpXH3PVio2 8wiYaKUI7o1a0TgVOJTDkkj7TofTM5qYpeUPgaRituVLmLZbfO6sDO6kCwt4YXr7O+DU 7vNL/xM+2gsHvksSy0p+GMnrfRcfK4FEmJOH45zv0OqIF2W6Y7Divfe+e4VwZ70ytWZt 5G8hIdu3nDUquDg5ETE2TSu20ncxr1iyGmUKJHwT6JaiC3fXAW0DumUz9jh3YKoCmKX2 xeHA== X-Gm-Message-State: AMCzsaUo/P0cfTq61Vj3mQFG0KJbzdFRxwLtYZeFYojz0VLvFa9u5KdJ Buu00cPAdZ8KLgI6txyt+T6miDNoXSa5KNOpQnuvbwlS X-Google-Smtp-Source: ABhQp+TuBq/g3O/Zsr/4HPwA+PaCs5vvLUygI3RSdW2EV2mnfe3siVS9uRfIB0EEtb87yVqq1qoMJDjyDsMjlWmRPFA= X-Received: by 10.37.188.18 with SMTP id i18mr11717046ybh.419.1510075094063; Tue, 07 Nov 2017 09:18:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.61.12 with HTTP; Tue, 7 Nov 2017 09:17:33 -0800 (PST) In-Reply-To: <4406543.RZChgRkkf9@pintsize.usersys.redhat.com> References: <4406543.RZChgRkkf9@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Tue, 7 Nov 2017 09:17:33 -0800 Message-ID: To: Hubert Kario Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="089e08247eb490f315055d67c11c" Archived-At: Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 17:18:17 -0000 --089e08247eb490f315055d67c11c Content-Type: text/plain; charset="UTF-8" On Tue, Nov 7, 2017 at 7:39 AM, Hubert Kario wrote: > In general +1, I like to see TLS 1.3 deployed ASAP and making the spurious > failures as rare as possible is a good way to make that happen. > > that being said, I have few comments: > > On Monday, 6 November 2017 19:19:01 CET Eric Rescorla wrote: > > https://github.com/tlswg/tls13-spec/pull/1091 > > > > As I mentioned a while back, we've been seeing evidence of middlebox > > intolerance. I just posted PR 1091, which is based on a bunch of work > > by the BoringSSL team and an original suggestion by Kyle Nekritz that > > should significantly decrease the rate of these errors. > > > > The general idea here is to make TLS 1.3 look more like TLS 1.2 > > resumption. The major changes are: > > > > - Move version negotiation entirely into "supported_versions", and hence > > ServerHello.version == 0x0303 (TLS 1.2) > > - Restore the missing session_id and compression fields in ServerHello > > less special cases in parser code - big +1 > > > - The client sends a fake session_id and the server echoes it > > - The server sends ChangeCipherSpec messages after > > ServerHello/HelloRetryRequest > > (so that the middlebox ignores any "encrypted" data afterwards), > > and the client sends ChangeCipherSpec after ClientHello. Either > > side has to ignore ChangeCipherSpec during the handshake. > > That's the part I have a bit of a problem with. > If the CCS is necessary to make middleboxes work, and given that > lack-of-CCS- > intolerance is not something that we can detect reliably (not in a way that > can be simulated by an attacker), I think the CCS should be baked in the > TLS > 1.3 as deep as it was baked into TLS 1.2. > You don't detect it on an individualized basis. Rather, you measure whether it's necessary and if/when the necessary level of CCS becomes low enough, you just stop sending it ever. That is, the standard should make it a mandatory message to send, fully > parsed > and validated, requiring aborting connection if it is received at any > unexpected moment, in duplicate, omitted or malformed. Not only as part of > the > "compatibility mode". > Yeah, I'm not enthusiastic about this. It's more stuff in the state machine that we hope to eventually eliminate. And as David says, it's totally unnecessary for QUIC and DTLS -Ekr --089e08247eb490f315055d67c11c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Nov 7, 2017 at 7:39 AM, Hubert Kario <hkario@redhat.com>= ; wrote:
In general +1, I like to = see TLS 1.3 deployed ASAP and making the spurious
failures as rare as possible is a good way to make that happen.

that being said, I have few comments:

On Monday, 6 November 2017 19:19:01 CET Eric Rescorla wrote:
> https://github.com/tlswg/tls13-spec/pull/1091=
>
> As I mentioned a while back, we've been seeing evidence of middleb= ox
> intolerance. I just posted PR 1091, which is based on a bunch of work<= br> > by the BoringSSL team and an original suggestion by Kyle Nekritz that<= br> > should significantly decrease the rate of these errors.
>
> The general idea here is to make TLS 1.3 look more like TLS 1.2
> resumption. The major changes are:
>
> - Move version negotiation entirely into "supported_versions"= ;, and hence
>=C2=A0 =C2=A0ServerHello.version =3D=3D 0x0303 (TLS 1.2)
> - Restore the missing session_id and compression fields in ServerHello=

less special cases in parser code - big +1

> - The client sends a fake session_id and the server echoes it
> - The server sends ChangeCipherSpec messages after
> ServerHello/HelloRetryRequest
>=C2=A0 =C2=A0(so that the middlebox ignores any "encrypted" d= ata afterwards),
>=C2=A0 =C2=A0and the client sends ChangeCipherSpec after ClientHello. E= ither
>=C2=A0 =C2=A0side has to ignore ChangeCipherSpec during the handshake.<= br>
That's the part I have a bit of a problem with.
If the CCS is necessary to make middleboxes work, and given that lack-of-CC= S-
intolerance is not something that we can detect reliably (not in a way that=
can be simulated by an attacker), I think the CCS should be baked in the TL= S
1.3 as deep as it was baked into TLS 1.2.

You don't detect it on an individualized basis. Rather, you measure = whether it's
necessary and if/when the necessary level of CCS= becomes low enough, you
just stop sending it ever.

That is, the standard should make it a mandatory message to send, fully par= sed
and validated, requiring aborting connection if it is received at any
unexpected moment, in duplicate, omitted or malformed. Not only as part of = the
"compatibility mode".

Yeah, I= 'm not enthusiastic about this. It's more stuff in the state machin= e that
we hope to eventually eliminate. And as David says, it'= ;s totally unnecessary
for QUIC and DTLS

-Ekr


--089e08247eb490f315055d67c11c-- From nobody Tue Nov 7 09:24:04 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24AE5132C32 for ; Tue, 7 Nov 2017 09:24:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 Ev_JYlgAgjCn for ; Tue, 7 Nov 2017 09:23:59 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 16A9C132A1A for ; Tue, 7 Nov 2017 09:23:59 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id t11so11511379ywg.12 for ; Tue, 07 Nov 2017 09:23:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zW/S0UXZq+W7BHg6I//+lo5xxUtjzx8zrHR0D/DH/gA=; b=I5svJPgSCmIdL+MXylehvO7caCvaMT6E9yPqX/KMoxbdPbClbcsyxWBj9yiSF1KCxW tABn0WWqY3II8FYGRiXm+dqDa+0nU5NRNAgCiOYqlGxBY0gwjy/5AZ5g8R/UF2fuAhtg cRUL1df9e+h8+PCUlK/UlwYsDSKoOuobR5LwGnuLjSTctIoYd7+zaz3aNnIRLMbL16nU rcGMelpZMuXy2ljoiB6YBQRD/4g2HrW1Ia3namMHMQC92gmT/8632+Yt/f1abjIs9MsH c6eWgl93KutCe/wJHKdkwOyyAy38ynbPyaroh2C4ZowhbjJPBn8KOVN+cfGBTE34KlLt 1r7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zW/S0UXZq+W7BHg6I//+lo5xxUtjzx8zrHR0D/DH/gA=; b=LtduChZ/Xd0OCfmBjaC5cUO+NSsSeDOPUFec6+yafPOwzRmpRV7Q5HCXQHwiN57k68 SnRvDRcb1U2ZBnOZofPDREczL/gMHkB7Wb2aAIUnUsIhABbfPlh61xwOqfyerBYvKA+F HlcgER6iDm4ToXQdorcaRaODcL74pippYUOH5VMHvEMiF07lGtgw9d5IGnxto7mxyGrU PDCF5WOEaTxXsV9w58nLco9RfnxHyUoTFUQmVXeaqOksv4MFWsbt4oLnTP46t4azsFmz GJfh1UbEnrbOyM9JE91kli/GFvm7Tno6Nbfj3iUKPWBr4XoWjUXAxeyMxSZx98kG2Hdz 53nw== X-Gm-Message-State: AMCzsaWpU7VJfjH15WrcnWLICtXyvJ3FDOw023zEuYvmGdLneQRJ7TAg tpI2bv4r3COtLuI0NWNZE4ZU19EXMz1cel+U8upARg== X-Google-Smtp-Source: ABhQp+TKMOg3GAAk5bVwPO4TB6OWzfpvcGp6vdMjO0k/erRul0iyTNOdmhts7hzV/41g2pk6UUUIORKazYo5rdgGAhc= X-Received: by 10.37.195.65 with SMTP id t62mr12016569ybf.71.1510075438238; Tue, 07 Nov 2017 09:23:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.61.12 with HTTP; Tue, 7 Nov 2017 09:23:17 -0800 (PST) In-Reply-To: References: <895D1206-28D1-43AB-8A45-11DEEC86A71D@cisco.com> From: Eric Rescorla Date: Tue, 7 Nov 2017 09:23:17 -0800 Message-ID: To: Flemming Andreasen Cc: "Nancy Cam-Winget (ncamwing)" , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114d7db214a19b055d67d6d2" Archived-At: Subject: Re: [TLS] network-based security solution use cases X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 17:24:03 -0000 --001a114d7db214a19b055d67d6d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 7, 2017 at 7:56 AM, Flemming Andreasen wrote: > Thank you for the feedback Ekr - please see below for responses > > > On 11/6/17 12:43 PM, Eric Rescorla wrote: > > I took a look at this. > > Without getting into the question of whether the types of middleboxes > you describe here provide a security benefit, there are several points > in the document that are either wrong or at least misleading/confusing. > > - Key Synchronization > This document notes that in TLS 1.2, it is possible for a middlebox > that traffic keys match on both sides of the connection it is proxying, > but in TLS 1.3 it is not: > > There are several techniques that can be utilized. Those techniques > function with TLS 1.2 and earlier versions but not with TLS 1.3. > > One technique is for the middlebox to negotiate the same master > secret with the original TLS client and server, as if the two > endpoints handshake directly. This is also known as "Triple > Handshake" used by legitimate middleboxes. [BreakTLS] describes the > methods with RSA and DH key exchanges. When the proxy session keys > are the same as for a direct handshake, the middlebox is able to > "cut-through" the two TLS proxy sessions when it finishes the > security inspection. > > This technique is not functional with TLS 1.3 since the transcript > hash over the handshake messages is part of the key derivation > procedure. > > First, I would note that this property of TLS 1.2 is bad, as it leads > to Unknown Key Share (UKS) attacks, which can be the basis of real > attacks on TLS 1.2 as fielded. It is for this reason that the TLS > WG published RFC 7627. > > Thanks for the bringing that one up - we will make sure to include that i= n > the next version. > > Understood - it is nevertheless a change from TLS 1.2. In TLS 1.3, it's a= n > integral part of the protocol that cannot be disabled. The TLS 1.2 > extension does not share that property. > It seems like an odd complaint that we are making protection against Unknown Key Shares an integral part of the protocol > Finally, you note several times in the document (e.g., S 4.5), that > with key synchronization, the middlebox can perform the handshake and > then disengage from the connection. However, the cases you mention > (e.g.., detecting exploit attempts) ultimately require examining > all traffic in the connection. > > We have several different use case scenarios in there, and I agree with > the observation that they cannot all be satisfied at the same time. For > example, we cannot scan for malware in an encrypted stream to a financial > institution that we are not allowed to decrypt. That doesn't mean either > use case is invalid. Customers do both in real-life (just not at the same > time). > I'm finding it a bit puzzling what you claim customers do. Specifically, you seem to be saying that customers examine the beginning of the connection and then stop. What are they scanning for and what makes them stop? > - PSK and resumption > You write: > > In TLS 1.3, the above mechanism is replaced by Pre-Shared Keys (PSK), > which can be negotiated as part of an initial handshake and then used > in a subsequent handshake to perform resumption using the PSK. TLS > 1.3 states that the client SHOULD include a "key_share" extension to > enable the server to decline resumption and fall back to a full > handshake, however it is not an absolute requirement. > > Example scenarios that are impacted by this are middleboxes that were > not part of the initial handshake, and hence do not know the PSK. If > the client does not include the "key_share" extension, the middlebox > cannot force a fallback to the full handshake. If the middlebox > policy requires it to inspect the session, it will have to fail the > connection instead. > > In TLS 1.3, PSKs and session resumption are basically the same and > have the same properties. While I concede that the document does > not require the client to offer key_shares, as a practical matter > it is very unlikely that a client will act in such a way that > failure to retain the PSK causes a hard failure, for two reasons: > > (a) In every version of TLS, the ticket lifetime is just a hint, and > the server can forget it at any time > (https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13. > html#NSTMessage). Thus, > a client which does not allow a full handshake will often > find itself unable to connect. > > (b) The relevant question is not whether the client offers a key share > extension but whether it advertises any DH groups. If the client send= s > a group but not a key share, the server can send HelloRetryRequest > to force the client to send a key share. > > For these reasons, as far as I know, every client (and at least every > browser client) should allow a full handshake even when trying to resume. > > If that is indeed the case, then I would suggest changing the spec > language to a MUST here instead so we can guarantee it. > I don't believe this is necessary. There are certainly reasons why you would want to do PSK w/o (EC)DHE (e.g., you are really PSK only). - Server Certificate Concealment > You note that in TLS 1.2 the middlebox can examine both the SNI and the > server's certificate in order to decide whether to MITM the connection, > but that in TLS 1.3, the middlebox cannot guarantee that the SNI in > uses is correct: > > In TLS 1.2, the ClientHello, ServerHello and Certificate messages are > all sent in clear-text, however in TLS 1.3, the Certificate message > is encrypted thereby hiding the server identity from any > intermediary. Note that even _if_ the SNI is provided (in cleartext) > by the client, there is no guarantee that the actual server > responding is the one indicated in the SNI from the client. > > In this case, it's important to distinguish between conformant and > nonconformant clients. In the former case -- as when the user is > not attempting to evade inspection -- the SNI will reflect the > identity that the client expects and therefore will compare the > certificate against. > > Of course, in the case where the client is attempting to evade > inspection, the certificate might not match. However, in this > scenario, the client and server are colluding and so there are > a variety of ways to avoid inspection, even when doing TLS 1.2. > > For example: > > 1. The client and server can share a prearranged public key and then > negotiate static RSA. The client sends an innocuous SNI and the server > can simply send the certificate of the corresponding server, captured > by connecting to that server. The client then enciphers the PMS > under the server's prearranged key and continues with TLS as usual. > This cannot be detected by the middlebox without decrypting the EPMS. > > 2. If an (EC)DHE cipher suite must be negotiated, then the attack > described above does not work directly because the server's signature > over the ServerKeyExchange can be validated, and of course the > attacker server does not have the legitimate server's key. However, > the server can forward the ClientHello to the legitimate server, > capture the Certificate and ServerKeyExchange and the proxy those to > the client. This looks legitimate to the inspection device and then > the client can simply send the Encrypted PMS in the first chunk of > data that is apparently encrypted under the server's key. > > For these reasons, being able to see the server's certificate provides > a false sense of security, as this check is easily bypassed. > > I agree we should distinguish between between conformant and > non-comformant. > > For the conformant case, I do not know to what extent we can rely on the > client always sending the SNI, but even if it is always sent, there are > still use case scenarios around certificate audit, etc. that cannot be > satisified in TLS 1.3 without becoming an active MITM. > You can do certificate audit by making an independent connection and eliciting the certificate. > With the recently adopted proposal around SNI encryption, there are more > use cases that cannot be satisfied without becoming an active MITM. > Yes, I agree with that. For the non-conformant case, you bring up some good points. We can reduce > the set of bypass scenarios there, but we cannot eliminate them. > I'm not persuaded that you can meaningfully reduce them. What technical approach do you believe would do so? -Ekr > > > Thanks again for the feedback - we will update accordingly in the next > version of the draft. > > -- Flemming > > > > -Ekr > > > [0] Note: the use of static DH is very rare. > > > On Fri, Nov 3, 2017 at 6:49 PM, Nancy Cam-Winget (ncamwing) < > ncamwing@cisco.com> wrote: > >> All, >> >> >> >> @IETF99, awareness was raised to some of the security WGs (thanks >> Kathleen =E2=98=BA) that TLS 1.3 will obscure visibility currently affor= ded in >> TLS 1.2 and asked what the implications would be for the security soluti= ons >> today. https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00 is >> an initial draft to describe some of the impacts relating to current >> network security solutions. The goal of the draft is NOT to propose any >> solution as a few have been proposed, but rather to raise awareness to h= ow >> current network-based security solutions work today and their impact on >> them based on the current TLS 1.3 specification. >> >> >> >> Regards, Nancy, Flemming and Eric >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > > > _______________________________________________ > TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls > > > --001a114d7db214a19b055d67d6d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Nov 7, 2017 at 7:56 AM, Flemming Andreasen &l= t;fandreas@cisco.co= m> wrote:
=20 =20 =20
Thank you for the feedback Ekr - please see below for responses


On 11/6/17 12:43 PM= , Eric Rescorla wrote:
=20
I took a look at this.

Without getting into the question of whether the types of middleboxes
you describe here provide a security benefit, there are several points
in the document that are either wrong or at least misleading/confusing.

- Key Synchronization
This document notes that in TLS 1.2, it is possible for a middlebox
that traffic keys match on both sides of the connection it is proxying,
but in TLS 1.3 it is not:

=C2=A0 =C2=A0There are several techniques that can be utilized= .=C2=A0 Those techniques
=C2=A0 =C2=A0function with TLS 1.2 and earlier versions but no= t with TLS 1.3.

=C2=A0 =C2=A0One technique is for the middlebox to negotiate t= he same master
=C2=A0 =C2=A0secret with the original TLS client and server, a= s if the two
=C2=A0 =C2=A0endpoints handshake directly.=C2=A0 This is also = known as "Triple
=C2=A0 =C2=A0Handshake" used by legitimate middleboxes.= =C2=A0 [BreakTLS] describes the
=C2=A0 =C2=A0methods with RSA and DH key exchanges.=C2=A0 When= the proxy session keys
=C2=A0 =C2=A0are the same as for a direct handshake, the middl= ebox is able to
=C2=A0 =C2=A0"cut-through" the two TLS proxy session= s when it finishes the
=C2=A0 =C2=A0security inspection.

=C2=A0 =C2=A0This technique is not functional with TLS 1.3 sin= ce the transcript
=C2=A0 =C2=A0hash over the handshake messages is part of the k= ey derivation
=C2=A0 =C2=A0procedure.

First, I would note that this property of TLS 1.2 is bad, as it leads
to Unknown Key Share (UKS) attacks, which can be the basis of real
attacks on TLS 1.2 as fielded. It is for this reason that the TLS
WG published RFC 7627.

Thanks for the bringing that one up - we will make sure to include that in the next version.

Understood - it is nevertheless a change from TLS 1.2. In TLS 1.3, it's an integral part of the protocol that cannot be disabled. The TLS 1.2 extension does not share that property.
=

It seems like an odd complaint that we are making prote= ction against Unknown Key Shares an integral part of the protocol

=C2=A0
Finally, you note several times in the document (e.g., S 4.5), that
with key synchronization, the middlebox can perform the handshake and
then disengage from the connection. However, the cases you mention
(e.g.., detecting exploit attempts) ultimately require examining
all traffic in the connection.

 We have several different use case scenarios in there, and I agree with the observation that they cannot all be satisfied at the same time. For example, we cannot scan for malware in an encrypted stream to a financial institution that we are not allowed to decrypt. That doesn't mean either use case is invalid. Customers do both in real-life (just not at the same time).

=
I'm finding it a bit puzzling what you claim customers do. S= pecifically, you seem to be saying that customers examine the beginning of = the connection and then stop. What are they scanning for and what makes the= m stop?

=C2=A0
=20
- PSK and resumption
You write:

=C2=A0 =C2=A0In TLS 1.3, the above mechanism is replaced by Pre-Shared Keys (PSK),
=C2=A0 =C2=A0which can be negotiated as part of an initial han= dshake and then used
=C2=A0 =C2=A0in a subsequent handshake to perform resumption u= sing the PSK.=C2=A0 TLS
=C2=A0 =C2=A01.3 states that the client SHOULD include a "= ;key_share" extension to
=C2=A0 =C2=A0enable the server to decline resumption and fall = back to a full
=C2=A0 =C2=A0handshake, however it is not an absolute requirem= ent.

=C2=A0 =C2=A0Example scenarios that are impacted by this are middleboxes that were
=C2=A0 =C2=A0not part of the initial handshake, and hence do n= ot know the PSK.=C2=A0 If
=C2=A0 =C2=A0the client does not include the "key_share&q= uot; extension, the middlebox
=C2=A0 =C2=A0cannot force a fallback to the full handshake.=C2= =A0 If the middlebox
=C2=A0 =C2=A0policy requires it to inspect the session, it wil= l have to fail the
=C2=A0 =C2=A0connection instead.

In TLS 1.3, PSKs and session resumption are basically the same and
have the same properties. While I concede that the document does
not require the client to offer key_shares, as a practical matter
it is very unlikely that a client will act in such a way that
failure to retain the PSK causes a hard failure, for two reasons:

(a) In every version of TLS, the ticket lifetime is just a hint, and
=C2=A0 =C2=A0 the server can forget it at any time
=C2=A0 =C2=A0 a client which does not allow a full handshake w= ill often
=C2=A0 =C2=A0 find itself unable to connect.

(b) The relevant question is not whether the client offers a key share
=C2=A0 =C2=A0 extension but whether it advertises any DH group= s. If the client sends
=C2=A0 =C2=A0 a group but not a key share, the server can send HelloRetryRequest
=C2=A0 =C2=A0 to force the client to send a key share.

For these reasons, as far as I know, every client (and at least every
browser client) should allow a full handshake even when trying to resume.

If that is indeed the case, then I would suggest changing the spec language to a MUST here instead so we can guarantee it.

I don't believe this is necessary. There ar= e certainly reasons why you would want to do PSK w/o (EC)DHE (e.g., you are= really PSK only).


=
=20
- Server Certificate Concealment
You note that in TLS 1.2 the middlebox can examine both the SNI and the
server's certificate in order to decide whether to MITM th= e connection,
but that in TLS 1.3, the middlebox cannot guarantee that the SNI in
uses is correct:

=C2=A0 =C2=A0In TLS 1.2, the ClientHello, ServerHello and Cert= ificate messages are
=C2=A0 =C2=A0all sent in clear-text, however in TLS 1.3, the Certificate message
=C2=A0 =C2=A0is encrypted thereby hiding the server identity f= rom any
=C2=A0 =C2=A0intermediary.=C2=A0 Note that even _if_ the SNI i= s provided (in cleartext)
=C2=A0 =C2=A0by the client, there is no guarantee that the act= ual server
=C2=A0 =C2=A0responding is the one indicated in the SNI from t= he client.

In this case, it's important to distinguish between conformant and
nonconformant clients. In the former case -- as when the user is
not attempting to evade inspection -- the SNI will reflect the
identity that the client expects and therefore will compare the
certificate against.

Of course, in the case where the client is attempting to evade
inspection, the certificate might not match. However, in this
scenario, the client and server are colluding and so there are
a variety of ways to avoid inspection, even when doing TLS 1.2.

For example:

1. The client and server can share a prearranged public key and then
negotiate static RSA. The client sends an innocuous SNI and the server
can simply send the certificate of the corresponding server, captured
by connecting to that server. The client then enciphers the PMS
under the server's prearranged key and continues with TLS as usual.
This cannot be detected by the middlebox without decrypting the EPMS.

2. If an (EC)DHE cipher suite must be negotiated, then the attack
described above does not work directly because the server'= s signature
over the ServerKeyExchange can be validated, and of course the
attacker server does not have the legitimate server's key. However,
the server can forward the ClientHello to the legitimate server,
capture the Certificate and ServerKeyExchange and the proxy those to
the client. This looks legitimate to the inspection device and then
the client can simply send the Encrypted PMS in the first chunk of
data that is apparently encrypted under the server's key.<= /div>

For these reasons, being able to see the server's certificate provides
a false sense of security, as this check is easily bypassed.
I agree we should distinguish between between conformant and non-comformant.

For the conformant case, I do not know to what extent we can rely on the client always sending the SNI, but even if it is always sent, there are still use case scenarios around certificate audit, etc. that cannot be satisified in TLS 1.3 without becoming an active MITM.

You can do certificate audi= t by making an independent connection and eliciting the certificate.
<= div>
=C2=A0
With the recently adopted proposal around SNI= encryption, there are more use cases that cannot be satisfied without becoming an active MITM.=C2=A0=C2=A0

Y= es, I agree with that.


For the non-conformant case, you bring up some good points. We can reduce the set of bypass scenarios there, but we cannot eliminate them.

I'm not persuaded = that you can meaningfully reduce them. What technical approach do you belie= ve would do so?

-Ekr
=C2=A0


Thanks again for the feedback - we will update accordingly in the next version of the draft.

-- Flemming



-Ekr


[0] Note: the use of static DH is very rare.


On Fri, Nov 3, 2017 at 6:49 PM, Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com> wrote:

All,

=C2=A0

@IETF99, awareness was raised to some of the security WGs (thanks Kathleen =E2=98=BA) that TLS 1.3 will obscure visibility currently afforded in TLS 1.2 and asked what the implications would be for the security solutions today.=C2=A0=C2=A0https://tools.ietf.org/html/draf= t-camwinget-tls-use-cases-00=C2=A0is an in= itial draft to describe some of the impacts relating to current network security solutions.=C2=A0=C2=A0The goal= of the draft is NOT to propose any solution as a few have been proposed, but rather to raise awareness to how current network-based security solutions work today and their impact on them based on the current TLS 1.3 specification.

=C2= =A0

Reg= ards, Nancy, Flemming and Eric


_______________________________________________
TLS mailing list
TLS@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/tls<= /a>




_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mail=
man/listinfo/tls


--001a114d7db214a19b055d67d6d2-- From giluxonchik@gmail.com Tue Nov 7 06:15:45 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF9913FB96 for ; Tue, 7 Nov 2017 06:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 AnNx3p5SYPGx for ; Tue, 7 Nov 2017 06:15:44 -0800 (PST) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::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 AC40113FB17 for ; Tue, 7 Nov 2017 06:15:43 -0800 (PST) Received: by mail-ot0-x22f.google.com with SMTP id n74so12114254ota.8 for ; Tue, 07 Nov 2017 06:15:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=nrnSSUpLxKY7Z/JKw8fDcBrAIulWE4GoOvIQNrSBv88=; b=FlI/BmTjF6qtUpc8Q9tg/EsxmCk+Kh1onSlaYZ4TJkFg4q3r9s/p6JkWzYyIMQQNVh kupa4O11n+FL2WK8MklLaKql6Tml8WeGUFvAxuBUlM7jp5bnKMxcpxPgFKpri8Ru6bBv jfgGIuq04tkICWEX+UvvAswFj1jskfqootby4e7r/pRe/WOHIqNkLHL3U8sbPd5cgVr/ s2JkccBEH7VRF5XzpC2aLJbWksxXWBb22rbk7sfyNW1y1wnPlewNwV8xrtidvS4I6l2L SLL9nwjtBhEowSktKCZnbn379u++hEYXTGgPPIxgdaHFJTo3tUqeEXYSlJiD3bXiFvn5 uhyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nrnSSUpLxKY7Z/JKw8fDcBrAIulWE4GoOvIQNrSBv88=; b=sNsrvGBBKUAyn5i9BPjwqWwK5ZoVygO6T6giTaA82cvcoXZF/wzKA2PJX+whL2k1dv BHn+xcyFq/Tt3trp5l42Fs0Ed0tA/3V5Q0I5qB37jOshbBV1bi/Mq1+pJVXP+fjYcOTe EpBdnb+iDxJNE9ANaubVRA7T1/rVlkqZel1+s8j2Eq3pnjtyGbPstwbGKUv4GI7P6hCz gXwG+RfzgKkrj7GCbKRPZYhOAmJ5mA1SASPKywmKR+9SRmfn6q2gsfjvuG+ufnV40oEk sIFJx4mDknWRmDrYYMVR99YtTjOoFKrpLosqdtt6NYe+FkZC84T1F06M2BVg7fDwCzmH EquA== X-Gm-Message-State: AJaThX58Oai+LtkXF/h2Nsx566k3X0q5++fV2SK/vQnPEUzaGGn7sqxw DOBi8MYxMUTRy1nPda4sFjQNye8LZm/rZuvqDt0VgA== X-Google-Smtp-Source: ABhQp+T4jh9KxDmeGjl5tPvvxStk8MvMwgeXgHekZVEZwp2mSvdBHqvjVje5vKBneqjVKrLmCFjnaWcxzRUkg+12roE= X-Received: by 10.157.64.8 with SMTP id m8mr12637180ote.387.1510064142782; Tue, 07 Nov 2017 06:15:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.168.183.193 with HTTP; Tue, 7 Nov 2017 06:15:42 -0800 (PST) From: Illya Gerasymchuk Date: Tue, 7 Nov 2017 14:15:42 +0000 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary="f403043e1568d196d9055d65341f" Archived-At: X-Mailman-Approved-At: Tue, 07 Nov 2017 09:47:27 -0800 Subject: [TLS] TLS Extensions: Omitting Handshake Messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 14:17:11 -0000 --f403043e1568d196d9055d65341f Content-Type: text/plain; charset="UTF-8" Greetings, I've been reading though various RFCs and couldn't find a definite answer to my question: can a negotiated TLS extension skip some of the TLS Handshake messages and still be compliant with the TLS specification? My goal is to develop a new version of TLS (as part of my Master Thesis work), while preferably, staying backwards-compatible. Here, I will be specifically talking about TLS 1.2, defined in RFC 5246. Below is a message flow for the full handshake (taken directly from RFC 5246): Client Server ------ ------ ClientHello --------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data * (asterisk) Indicates optional or situation-dependent messages that are not always sent. Now, I do know that it's perfect legal for a TLS extension to modify the structure of some message or add a new message, but I'm not sure if one of the messages, not defined as optional/situation-dependent can be omitted. Let me give you a concrete example. Let's say I create a new extension called *XYZ*. The client and the server negotiate that extension in the their extended hello messages. Would it be legal for the *XYZ* extension to mandate the server not to send the *ServerHelloDone* message? As far as I understood, this is not legal. RFC 5245 Section 4.4.1.4 states that: "it would be technically possible to use extensions to change major aspects of the design of TLS; for example the design of cipher suite negotiation. This is not recommended; it would be more appropriate to define a new version of TLS -- particularly since the TLS handshake algorithms have specific protection against version rollback attacks based on the version number, and the possibility of version rollback should be a significant consideration in any major design change" I would assume, however, that those major aspects do no include omitting messages not marked as optional/situation-dependent in the spec. Both, TLS 1.2 and TLS 1.3 draft specs mention REQUIRED/MUST in the section describing the ClientHello. There are no REQUIRED mentions in other messages though. You do have the following for the Finished: "A Finished message is always sent immediately after a change cipher spec message to verify that the key exchange and authentication processes were successful." , so things like these lead me to believe that the messages not explicitly marked as optional, are in fact, required. Thank you. --f403043e1568d196d9055d65341f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greetings,

I've been reading though various RFCs and couldn't find a defini= te answer to my question: can a negotiated TLS extension skip some of the T= LS Handshake messages and still be compliant with the TLS specification? My= goal is to develop a new version of TLS (as part of my Master Thesis work)= , while preferably, staying backwards-compatible.
<= br>
Here, I will be specifically talking about TLS 1.2,= defined in RFC 5246. Below is a message flow for the full handshake (taken= directly from RFC 5246):

=C2= =A0 Client =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Server
=C2=A0 ------ =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0------ =C2=A0 =C2=A0 =C2=A0=

=C2=A0 ClientHello =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------->
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ServerHello
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Certific= ate*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 S= erverKeyExchange*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 CertificateRequest*
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <-------- =C2=A0 =C2=A0 =C2=A0Ser= verHelloDone
=C2=A0 Certificate*
= =C2=A0 ClientKeyExchange
=C2=A0 CertificateVerify*
=C2=A0 [ChangeCipherSpec]
=C2=A0 Finish= ed =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 -------->
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 [ChangeCipherSpec]
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <-------- =C2=A0 =C2=A0 = =C2=A0 =C2=A0Finished
=C2=A0 Application Data =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0<-------> =C2=A0 =C2=A0 =C2=A0 Application= Data

=
* (asterisk) Indicates opt= ional or situation-dependent messages that are not always sent.
<= /div>
Now, I do know that it's perfect legal for a TLS extension= to modify the structure of some message or add a new message, but I'm = not sure if one of the messages, not defined as optional/situation-dependen= t can be omitted.

Let me give = you a concrete example. Let's say I create a new extension called XY= Z. The client and the server negotiate that extension in the their exte= nded hello messages. Would it be legal for the XYZ extension to mand= ate the server not to send the ServerHelloDone message? As far as I = understood, this is not legal.

RFC 5245 Section 4.4.1.4 states that:

"it would be technically possible to use extensions to change= major aspects of the design of TLS; for = example the design of cipher=C2=A0suite n= egotiation.=C2=A0 This is not recommended; it would be more appropriate to define a new version of TLS -- particular= ly since=C2=A0the TLS handshake algorithm= s have specific protection against=C2=A0v= ersion rollback attacks based on the version number, and the possibility of version rollback should be a significant= =C2=A0consideration in any major design c= hange"=C2=A0

I would assume, however, that those maj= or aspects do no include omitting messages not marked as optional/situation= -dependent in the spec.

Both, TLS 1.2 an= d TLS 1.3 draft specs mention REQUIRED/MUST in the section describing the C= lientHello. There are no REQUIRED mentions in other messages though. You do= have the following for the Finished: "A Finished message is always se= nt immediately after a change cipher spec message to verify that the key ex= change and authentication processes were successful." , so things like= these lead me to believe that the messages not explicitly marked as option= al, are in fact, required.

Thank you.

--f403043e1568d196d9055d65341f-- From nobody Tue Nov 7 09:57:33 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43C7126B71 for ; Tue, 7 Nov 2017 09:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 40y8doXysOgN for ; Tue, 7 Nov 2017 09:57:30 -0800 (PST) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 BE0D9126DFE for ; Tue, 7 Nov 2017 09:57:29 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id t11so27541ywg.12 for ; Tue, 07 Nov 2017 09:57:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VyRCLC49bp+o26gkX9IrtYAQFqjl5lucTsfcMXvNOtE=; b=dazepYBWxxBc89aTt72SSHO5nBR+OH0x+1M71ubQR8CZpdXW6HBuWMXwo3UzqAfig3 VL77Q5XguPQ2o7e3ULbKIicutACJ51ZQnDYGRDFLzMi1UeXjOB75dA6KazRtzXZupvNU aDakHpkvfk36sGKV5ZZ8KX4wYVWrpSQVOG313UNp+XPksnW0w8IOvIVZv4xNBsebMbx4 hW1MkdjuAJz3Lmahlxq5vygiBLIgNI7mu2GwOlyyrPFRowV3tzCPu8kz6PDkaGhvqv2T gUg2GfqmcySA4phEo5DYP4a9wWq5kYrX1fJLx/QcOyxKJ6uTRgQCDbnzzFyPqK7GULNa rcOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VyRCLC49bp+o26gkX9IrtYAQFqjl5lucTsfcMXvNOtE=; b=Wbi/2CH2SYx6ES5Fgg/+AodLvSQo4q5auH+0VYs8WbXFocnSUtKkDrtdiemyIGTXrg Rtvmp/FZ6CPXESoW4ucqdxqpJEP+lBIR7tOkkTqtWF7X3WRy145dXI2iocCLm/JLRvzd LtdqrdWiH7/b7a8qpQOWQxfgjr8petXPHU54Oeov/SBigrheDnncb09WdUBv9UoJ8CpM jX36WCoF0uXVATWTWoon0Hg5/lRT3HvYi3PNmsLCzddrlixmqo3b9CA/PecOek5WTQ+i s30nfi1MBtA607gP3A4KaLSyJoO+PSG32fzCa4H3fWDDYGuGoElxyupXxrREfObX1/dF 8HUw== X-Gm-Message-State: AMCzsaUztLQUFoKMNsYqrRgO6V/xyQSLTH9HBwC9NPy3/etq0GrpN+g9 7ZkAaBuMk2bdApB+4lmb3l+9ss+UrtBh2bl1tMA0iQ== X-Google-Smtp-Source: ABhQp+QsmIZLwLVqOomJ3ePH3cSUYVgMoh8lFeQ9pqTQCHPpQDX7yUE7gaOGqPdCRoZO+8FIqadRgCsgE+LzQ0q5jyw= X-Received: by 10.13.192.196 with SMTP id b187mr12752589ywd.416.1510077448995; Tue, 07 Nov 2017 09:57:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.61.12 with HTTP; Tue, 7 Nov 2017 09:56:48 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 7 Nov 2017 09:56:48 -0800 Message-ID: To: Illya Gerasymchuk Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114edd48ee5d78055d684d26" Archived-At: Subject: Re: [TLS] TLS Extensions: Omitting Handshake Messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 17:57:33 -0000 --001a114edd48ee5d78055d684d26 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 7, 2017 at 6:15 AM, Illya Gerasymchuk wrote: > Greetings, > > I've been reading though various RFCs and couldn't find a definite answer > to my question: can a negotiated TLS extension skip some of the TLS > Handshake messages and still be compliant with the TLS specification? My > goal is to develop a new version of TLS (as part of my Master Thesis work), > while preferably, staying backwards-compatible. > > Here, I will be specifically talking about TLS 1.2, defined in RFC 5246. > Below is a message flow for the full handshake (taken directly from RFC > 5246): > > Client Server > ------ ------ > > ClientHello --------> > ServerHello > Certificate* > ServerKeyExchange* > CertificateRequest* > <-------- ServerHelloDone > Certificate* > ClientKeyExchange > CertificateVerify* > [ChangeCipherSpec] > Finished --------> > > [ChangeCipherSpec] > <-------- Finished > Application Data <-------> Application Data > > > * (asterisk) Indicates optional or situation-dependent messages that are > not always sent. > Now, I do know that it's perfect legal for a TLS extension to modify the > structure of some message or add a new message, but I'm not sure if one of > the messages, not defined as optional/situation-dependent can be omitted. > > Let me give you a concrete example. Let's say I create a new extension > called *XYZ*. The client and the server negotiate that extension in the > their extended hello messages. Would it be legal for the *XYZ* extension > to mandate the server not to send the *ServerHelloDone* message? As far > as I understood, this is not legal. > You certainly can use extensions to indicate that a new message is to be sent, so I don't think it would be necessarily be prohibited to have it remove a message, though I can't offhand think of an example of where we do so. RFC 5245 Section 4.4.1.4 states that: > > "it would be technically possible to use extensions to change major aspects > of the design of TLS; for example the design of cipher suite > negotiation. This is not recommended; it would be more appropriate to > define a new version of TLS -- particularly since the TLS handshake > algorithms have specific protection against version rollback attacks > based on the version number, and the possibility of version rollback > should be a significant consideration in any major design change" > To be honest, this mostly seems aspirational :) I would assume, however, that those major aspects do no include omitting > messages not marked as optional/situation-dependent in the spec. > > Both, TLS 1.2 and TLS 1.3 draft specs mention REQUIRED/MUST in the section > describing the ClientHello. There are no REQUIRED mentions in other > messages though. You do have the following for the Finished: "A Finished > message is always sent immediately after a change cipher spec message to > verify that the key exchange and authentication processes were successful." > , so things like these lead me to believe that the messages not explicitly > marked as optional, are in fact, required. > They're required absent some extension and you would have to be pretty careful with changes which moved them. -Ekr > > > Thank you. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114edd48ee5d78055d684d26 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Nov 7, 2017 at 6:15 AM, Illya Gerasymchuk <= ;giluxonchik@gma= il.com> wrote:
Greetings,

I've = been reading though various RFCs and couldn't find a definite answer to= my question: can a negotiated TLS extension skip some of the TLS Handshake= messages and still be compliant with the TLS specification? My goal is to = develop a new version of TLS (as part of my Master Thesis work), while pref= erably, staying backwards-compatible.

Here, I will be specifically talking about TLS 1.2, defined in = RFC 5246. Below is a message flow for the full handshake (taken directly fr= om RFC 5246):

=C2=A0 Client = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Se= rver
=C2=A0 ------ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0------ =C2=A0 =C2=A0 =C2=A0

=C2=A0 ClientHello =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------->
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ServerHello
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Certificate*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ServerKeyExchan= ge*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 C= ertificateRequest*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 <-------- =C2=A0 =C2=A0 =C2=A0ServerHelloDone
=C2=A0 Certificate*
=C2=A0 ClientKey= Exchange
=C2=A0 CertificateVerify*
= =C2=A0 [ChangeCipherSpec]
=C2=A0 Finished =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -------->= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 [ChangeCipherSpec]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 <-------- =C2=A0 =C2=A0 =C2=A0 =C2=A0Finishe= d
=C2=A0 Application Data =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0<-------> =C2=A0 =C2=A0 =C2=A0 Application Data


* (asterisk) Indicates optional or situation-de= pendent messages that are not always sent.
Now, I d= o know that it's perfect legal for a TLS extension to modify the struct= ure of some message or add a new message, but I'm not sure if one of th= e messages, not defined as optional/situation-dependent can be omitted.

Let me give you a concrete exampl= e. Let's say I create a new extension called XYZ. The client and= the server negotiate that extension in the their extended hello messages. = Would it be legal for the XYZ extension to mandate the server not to= send the ServerHelloDone message? As far as I understood, this is n= ot legal.

You certainly = can use extensions to indicate that a new message is to be sent, so I don&#= 39;t think it would be necessarily be prohibited to have it remove a messag= e, though I can't offhand think of an example of where we do so.
<= div>

RFC 5245 Section 4.4.1.4 states that:

"it would be technically possible to use extensions = to change major aspects of the design of = TLS; for example the design of cipher=C2=A0appropriate to define a new version of TLS -- p= articularly since=C2=A0the TLS handshake = algorithms have specific protection against=C2=A0version rollback attacks based on the version number, and the possibility of version rollback should be a si= gnificant=C2=A0consideration in any major= design change"=C2=A0

To be honest, this mostly seems aspirational :)


I would assume, however, that those major aspects do no inc= lude omitting messages not marked as optional/situation-dependent in the sp= ec.

Both, TLS 1.2 and TLS 1.3 draft spec= s mention REQUIRED/MUST in the section describing the ClientHello. There ar= e no REQUIRED mentions in other messages though. You do have the following = for the Finished: "A Finished message is always sent immediately after= a change cipher spec message to verify that the key exchange and authentic= ation processes were successful." , so things like these lead me to be= lieve that the messages not explicitly marked as optional, are in fact, req= uired.

They're requi= red absent some extension and you would have to be pretty careful with chan= ges which moved them.

-Ekr
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">


<= /font>
Thank you.


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


--001a114edd48ee5d78055d684d26-- From nobody Tue Nov 7 10:11:29 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7B6132939 for ; Tue, 7 Nov 2017 10:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 6mAqTEooUqFY for ; Tue, 7 Nov 2017 10:11:26 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9B85126B6D for ; Tue, 7 Nov 2017 10:11:25 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7360EC04AC49; Tue, 7 Nov 2017 18:11:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 7360EC04AC49 Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hkario@redhat.com Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1B85E60BF2; Tue, 7 Nov 2017 18:11:25 +0000 (UTC) From: Hubert Kario To: Eric Rescorla Cc: "tls@ietf.org" Date: Tue, 07 Nov 2017 19:11:17 +0100 Message-ID: <6818962.9GzJR6rN5C@pintsize.usersys.redhat.com> In-Reply-To: References: <4406543.RZChgRkkf9@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7419152.k1SlU32ZQM"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Tue, 07 Nov 2017 18:11:25 +0000 (UTC) Archived-At: Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 18:11:28 -0000 --nextPart7419152.k1SlU32ZQM Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 7 November 2017 18:17:33 CET Eric Rescorla wrote: > On Tue, Nov 7, 2017 at 7:39 AM, Hubert Kario wrote: > > In general +1, I like to see TLS 1.3 deployed ASAP and making the spuri= ous > > failures as rare as possible is a good way to make that happen. > >=20 > > that being said, I have few comments: > >=20 > > On Monday, 6 November 2017 19:19:01 CET Eric Rescorla wrote: > > > https://github.com/tlswg/tls13-spec/pull/1091 > > >=20 > > > As I mentioned a while back, we've been seeing evidence of middlebox > > > intolerance. I just posted PR 1091, which is based on a bunch of work > > > by the BoringSSL team and an original suggestion by Kyle Nekritz that > > > should significantly decrease the rate of these errors. > > >=20 > > > The general idea here is to make TLS 1.3 look more like TLS 1.2 > > > resumption. The major changes are: > > >=20 > > > - Move version negotiation entirely into "supported_versions", and he= nce > > >=20 > > > ServerHello.version =3D=3D 0x0303 (TLS 1.2) > > >=20 > > > - Restore the missing session_id and compression fields in ServerHello > >=20 > > less special cases in parser code - big +1 > >=20 > > > - The client sends a fake session_id and the server echoes it > > > - The server sends ChangeCipherSpec messages after > > > ServerHello/HelloRetryRequest > > >=20 > > > (so that the middlebox ignores any "encrypted" data afterwards), > > > and the client sends ChangeCipherSpec after ClientHello. Either > > > side has to ignore ChangeCipherSpec during the handshake. > >=20 > > That's the part I have a bit of a problem with. > > If the CCS is necessary to make middleboxes work, and given that > > lack-of-CCS- > > intolerance is not something that we can detect reliably (not in a way > > that > > can be simulated by an attacker), I think the CCS should be baked in the > > TLS > > 1.3 as deep as it was baked into TLS 1.2. >=20 > You don't detect it on an individualized basis. Rather, you measure wheth= er > it's > necessary and if/when the necessary level of CCS becomes low enough, you > just stop sending it ever. > > > That is, the standard should make it a mandatory message to send, fully > > parsed > > and validated, requiring aborting connection if it is received at any > > unexpected moment, in duplicate, omitted or malformed. Not only as part= of > > the > > "compatibility mode". >=20 > Yeah, I'm not enthusiastic about this. It's more stuff in the state machi= ne > that > we hope to eventually eliminate. And as David says, it's totally unnecess= ary > for QUIC and DTLS >=20 > -Ekr what I was getting at is that if you want to be compatible with middleboxes= ,=20 you send that CCS always, as you never know what thing will be between you = and=20 the peer that means that all the large implementations will be sending them always that means that new middleboxes will likely end up expecting it either way = and=20 existing ones won't have much incentive to update/fix secondly, if we allow for sending CCS at any point, we will end up with the= =20 same bug as the Alert processing DoS there was in some implementations =E2= =80=94 one=20 that allowed the peer to send unlimited amount of warning alerts so even if we mark it as optional, I still think we should allow for it to = be=20 sent at only very specific moments and only once per side =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart7419152.k1SlU32ZQM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIbBAABCgAGBQJaAfdFAAoJEJKo0bgB0vX1wk8P+IGKC++Yvpk4DtkJdTrRi68H 2Fo1YV9d5ER+POJ+G4+A8NCXV+0zC38RMZ+6UV41jRPbpWG3GeFd1xdQfg6XgzB5 jt9bUzgG8Jan3EVj2sv3gX1iKx0tn3dWAtb3MPumJnAQt9rHV1HL4OoKTqc/xFf2 PxMCMNnmVGxBD81CEh06FjYd0yVuChH3Xq3iKzAVLtmVjukmrMDlrPOWKRsyA8dU EhBUw9YJBehdqmZLYj9t4WB7tri9W3jO3inq21jG41LERCxHQwgsl9a/kzwghvcO Bv4ERYlFBJx57hkiLi359JAq8RK6+sfKNN2+C9kcpUV4A0mhofbnhX7iHhdELmT6 vU5fHstPC46UmCkWsDSV+bKmw2VmpH0JhaCvAki9vh603fUFr5ebWD2agk7dkDAd i/T1VhOi3H9r9WtoYD3g42kG8wYGriLfcekgCEdfhbEqMamgsyW/K+QwcAnCnHbv pE2McL5xmIsUHPRVOmdU5reho1rWC+pz+6nPo8iXjNgxYF7CRstm27ObcA2l3pBp +HpLZfWmCjSxjLVH6YkoZUWkHI7hnMr5w8lK8go4RGL42kWoVnfh1m19rOx63VnO DZT2LMOaTZVPP2vLXwTadmhg7olQtP3MAgnRfIY0lU3L0kF458sjuF475bFk/KnL pbfPlfsp2zTM6dxcOGI= =xpiK -----END PGP SIGNATURE----- --nextPart7419152.k1SlU32ZQM-- From nobody Tue Nov 7 10:32:08 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E656132355 for ; Tue, 7 Nov 2017 10:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 a9NkaZRuqOlI for ; Tue, 7 Nov 2017 10:32:05 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 B44241320DC for ; Tue, 7 Nov 2017 10:32:04 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id k11so158693ywh.1 for ; Tue, 07 Nov 2017 10:32:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3BwWvIHlVFPT5uyJB1FLGUAtE8g9eGTN6gD+jG1Rf6Y=; b=ztFYE4zF1b17toHKyKxGidgkwtOYDnQmKrWROP8+RHFR5DREfYDhiJilce6jBeWLes qPNNavA5YQK9OXvsBGbsjkJxZloNGMft6qUylnU4oL5ICVgS5WPMa+a8QNYY1zmXFGXj rxh9AsCNUkXgxfNy9hDhXHY3rt8XDd/beZBpN+rN1o8gZ1ZoJf3YgnFasXDWxuyqrlCo xAPvgaa5ZKY4eiAzN63oaj7sQSPz95x6TNlUnqSf9s5whphaL3bTXjWM61dP5gL2LApy pt5sEV2fudKUrGk+ZLclC8Jy6cPsWI12XU95mYmGhghGiKGigE+6vA44/IG9W40LZdn2 NviQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3BwWvIHlVFPT5uyJB1FLGUAtE8g9eGTN6gD+jG1Rf6Y=; b=DQpPDrzJfhtlPbzKZY2ch0+5GYoDo0Rz5uL0WgOpC3LMo6mwifxi6awvDezVJ89G/O L58re7VJ+5roq60ARr2SQ69+XCrCzG28yN5DZ0VEpiMv4bQhXO2W1cX8WKw1VtFQfZYp FkQ0a+sixJn9qIQwGe068X8c7mDOccVsnKHRPd8+hbzACsw4p3DQRIaeWlczM/oVM60K Gk2Ylv+/JkIkhPAU0OFDmq7BymhcO7uPF6F3w5bIzFOp0WAxoWBcoJt0hAOShadFbdZw UvDk6EuwsCC8syEzghRFlHrUDkqvMbvFM4MbWVjteXZLzimeqNAG1aobAnmRTi7hUXH2 /gyw== X-Gm-Message-State: AMCzsaWmm4ej5FWy1tTWvnqXYVJGjjUQ1kimihXtZJaNIt78P8SwJh2j 4A4xiP4BzEDewy85eP001YPUUxTcE/7C+cotuJbaDq2x X-Google-Smtp-Source: ABhQp+Q0oNplqLGHS16gE+3o5DeO8y8oGKmyE/UqFzjILi0D/CrL+aqRCNaa8ldD/z5AqB+xgLNqEXh9JFtb/q3Nuso= X-Received: by 10.37.195.65 with SMTP id t62mr12153053ybf.71.1510079523997; Tue, 07 Nov 2017 10:32:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.61.12 with HTTP; Tue, 7 Nov 2017 10:31:23 -0800 (PST) In-Reply-To: <6818962.9GzJR6rN5C@pintsize.usersys.redhat.com> References: <4406543.RZChgRkkf9@pintsize.usersys.redhat.com> <6818962.9GzJR6rN5C@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Tue, 7 Nov 2017 10:31:23 -0800 Message-ID: To: Hubert Kario Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114d7db29c5b79055d68c97e" Archived-At: Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 18:32:07 -0000 --001a114d7db29c5b79055d68c97e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 7, 2017 at 10:11 AM, Hubert Kario wrote: > On Tuesday, 7 November 2017 18:17:33 CET Eric Rescorla wrote: > > On Tue, Nov 7, 2017 at 7:39 AM, Hubert Kario wrote: > > > In general +1, I like to see TLS 1.3 deployed ASAP and making the > spurious > > > failures as rare as possible is a good way to make that happen. > > > > > > that being said, I have few comments: > > > > > > On Monday, 6 November 2017 19:19:01 CET Eric Rescorla wrote: > > > > https://github.com/tlswg/tls13-spec/pull/1091 > > > > > > > > As I mentioned a while back, we've been seeing evidence of middlebo= x > > > > intolerance. I just posted PR 1091, which is based on a bunch of wo= rk > > > > by the BoringSSL team and an original suggestion by Kyle Nekritz th= at > > > > should significantly decrease the rate of these errors. > > > > > > > > The general idea here is to make TLS 1.3 look more like TLS 1.2 > > > > resumption. The major changes are: > > > > > > > > - Move version negotiation entirely into "supported_versions", and > hence > > > > > > > > ServerHello.version =3D=3D 0x0303 (TLS 1.2) > > > > > > > > - Restore the missing session_id and compression fields in > ServerHello > > > > > > less special cases in parser code - big +1 > > > > > > > - The client sends a fake session_id and the server echoes it > > > > - The server sends ChangeCipherSpec messages after > > > > ServerHello/HelloRetryRequest > > > > > > > > (so that the middlebox ignores any "encrypted" data afterwards), > > > > and the client sends ChangeCipherSpec after ClientHello. Either > > > > side has to ignore ChangeCipherSpec during the handshake. > > > > > > That's the part I have a bit of a problem with. > > > If the CCS is necessary to make middleboxes work, and given that > > > lack-of-CCS- > > > intolerance is not something that we can detect reliably (not in a wa= y > > > that > > > can be simulated by an attacker), I think the CCS should be baked in > the > > > TLS > > > 1.3 as deep as it was baked into TLS 1.2. > > > > You don't detect it on an individualized basis. Rather, you measure > whether > > it's > > necessary and if/when the necessary level of CCS becomes low enough, yo= u > > just stop sending it ever. > > > > > That is, the standard should make it a mandatory message to send, ful= ly > > > parsed > > > and validated, requiring aborting connection if it is received at any > > > unexpected moment, in duplicate, omitted or malformed. Not only as > part of > > > the > > > "compatibility mode". > > > > Yeah, I'm not enthusiastic about this. It's more stuff in the state > machine > > that > > we hope to eventually eliminate. And as David says, it's totally > unnecessary > > for QUIC and DTLS > > > > -Ekr > > what I was getting at is that if you want to be compatible with > middleboxes, > you send that CCS always, as you never know what thing will be between yo= u > and > the peer > > that means that all the large implementations will be sending them always > > that means that new middleboxes will likely end up expecting it either wa= y > and > existing ones won't have much incentive to update/fix > > secondly, if we allow for sending CCS at any point, we will end up with t= he > same bug as the Alert processing DoS there was in some implementations = =E2=80=94 > one > that allowed the peer to send unlimited amount of warning alerts Given that this is (a) not encrypted (b) just discarded and (c) only allowed during the handshake, this doesn't seem like much of a DoS. so even if we mark it as optional, I still think we should allow for it to > be > sent at only very specific moments and only once per side > I might be fine if it were required in this way, but not fine if it was required that one enforce it. -Ekr > > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic > --001a114d7db29c5b79055d68c97e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Nov 7, 2017 at 10:11 AM, Hubert Kario <hkario@redhat.com&g= t; wrote:
On Tuesday, 7 November 2017 18:17:33 CET Eric Rescorla wrot= e:
> On Tue, Nov 7, 2017 at 7:39 AM, Hubert Kario <hkario@redhat.com> wrote:
> > In general +1, I like to see TLS 1.3 deployed ASAP and making the= spurious
> > failures as rare as possible is a good way to make that happen. > >
> > that being said, I have few comments:
> >
> > On Monday, 6 November 2017 19:19:01 CET Eric Rescorla wrote:
> > > https://github.com/tlswg/tls13-spec= /pull/1091
> > >
> > > As I mentioned a while back, we've been seeing evidence = of middlebox
> > > intolerance. I just posted PR 1091, which is based on a bunc= h of work
> > > by the BoringSSL team and an original suggestion by Kyle Nek= ritz that
> > > should significantly decrease the rate of these errors.
> > >
> > > The general idea here is to make TLS 1.3 look more like TLS = 1.2
> > > resumption. The major changes are:
> > >
> > > - Move version negotiation entirely into "supported_ver= sions", and hence
> > >
> > >=C2=A0 =C2=A0ServerHello.version =3D=3D 0x0303 (TLS 1.2)
> > >
> > > - Restore the missing session_id and compression fields in S= erverHello
> >
> > less special cases in parser code - big +1
> >
> > > - The client sends a fake session_id and the server echoes i= t
> > > - The server sends ChangeCipherSpec messages after
> > > ServerHello/HelloRetryRequest
> > >
> > >=C2=A0 =C2=A0(so that the middlebox ignores any "encrypt= ed" data afterwards),
> > >=C2=A0 =C2=A0and the client sends ChangeCipherSpec after Clie= ntHello. Either
> > >=C2=A0 =C2=A0side has to ignore ChangeCipherSpec during the h= andshake.
> >
> > That's the part I have a bit of a problem with.
> > If the CCS is necessary to make middleboxes work, and given that<= br> > > lack-of-CCS-
> > intolerance is not something that we can detect reliably (not in = a way
> > that
> > can be simulated by an attacker), I think the CCS should be baked= in the
> > TLS
> > 1.3 as deep as it was baked into TLS 1.2.
>
> You don't detect it on an individualized basis. Rather, you measur= e whether
> it's
> necessary and if/when the necessary level of CCS becomes low enough, y= ou
> just stop sending it ever.
>
> > That is, the standard should make it a mandatory message to send,= fully
> > parsed
> > and validated, requiring aborting connection if it is received at= any
> > unexpected moment, in duplicate, omitted or malformed. Not only a= s part of
> > the
> > "compatibility mode".
>
> Yeah, I'm not enthusiastic about this. It's more stuff in the = state machine
> that
> we hope to eventually eliminate. And as David says, it's totally u= nnecessary
> for QUIC and DTLS
>
> -Ekr

what I was getting at is that if you want to be compatible with= middleboxes,
you send that CCS always, as you never know what thing will be between you = and
the peer

that means that all the large implementations will be sending them always
that means that new middleboxes will likely end up expecting it either way = and
existing ones won't have much incentive to update/fix

secondly, if we allow for sending CCS at any point, we will end up with the=
same bug as the Alert processing DoS there was in some implementations =E2= =80=94 one
that allowed the peer to send unlimited amount of warning alerts

Given that this is (a) not encrypted (b) just discard= ed and (c) only allowed during the handshake, this
doesn't se= em like much of a DoS.


so even if we mark it as optional, I still think we should allow for it to = be
sent at only very specific moments and only once per side
<= div>
I might be fine if it were required in this way, but not= fine if it was required that one enforce it.

-Ekr=

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech Republic=

--001a114d7db29c5b79055d68c97e-- From nobody Tue Nov 7 12:23:57 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A186B1241F5 for ; Tue, 7 Nov 2017 12:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 o-JSoZHsrNLc for ; Tue, 7 Nov 2017 12:23:53 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78FE31200C5 for ; Tue, 7 Nov 2017 12:23:53 -0800 (PST) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vA7KMWDX030506; Tue, 7 Nov 2017 20:23:52 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Ay54hpkKbMcQUJ8jwtejHS4Vg1152pO8UMdkDmja8uA=; b=WSRnVxLzwCSVygHwBgin2d4HsocLXVmYJv239AbxQLzaAuJcoOAnVOvp/gET6c8sVEPG 8kfdHmGeQG48tG2OY4bFb8wAMx3odsQ0/7cQx/4/7fo7jzdnYIuof3Sq5jhIv7Iz21he V6txH4xytcF9wGJhuI99h8LKBlIm5mvkMHsCA2B3n6c9BIV2tcvr1jUJpBdei+GYe2PZ qptqlsucWFUpywCDnnmiImmnM60D5uNOSUnH4rtE6FIrB9JIuLwiDdgfJexHr0JF1bzi J8rewQ0hDGD9BnS9VLt1AAJVgT/cYTebt2dTIxYz+jtLvtjWqeK/DE4C9Hu+E0sYYF66 yg== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2e16fjupvu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Nov 2017 20:23:51 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vA7KLXRT011727; Tue, 7 Nov 2017 15:23:50 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2e18vuafd3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 07 Nov 2017 15:23:50 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 7 Nov 2017 15:23:49 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 7 Nov 2017 15:23:49 -0500 From: "Salz, Rich" To: Hubert Kario , Eric Rescorla CC: "tls@ietf.org" Thread-Topic: [TLS] PR#1091: Changes to provide middlebox robustness Thread-Index: AQHTVyvYee7TW4xp9E6OP50HN76KZ6MJYqeAgAAba4CAAA8EgIAAJQeA Date: Tue, 7 Nov 2017 20:23:49 +0000 Message-ID: <965B995B-A5B3-4322-B13A-A2D82AFD2743@akamai.com> References: <4406543.RZChgRkkf9@pintsize.usersys.redhat.com> <6818962.9GzJR6rN5C@pintsize.usersys.redhat.com> In-Reply-To: <6818962.9GzJR6rN5C@pintsize.usersys.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.217] Content-Type: text/plain; charset="utf-8" Content-ID: <513712CBED193447A96C5C296A0D6044@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-07_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711070266 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-07_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711070266 Archived-At: Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 20:23:55 -0000 SSB0aGluayBIdWJlcnQgbWFrZXMgZXhjZWxsZW50IHBvaW50cy4NCg0K4oCcV2UgY2FuIHJlbW92 ZSBpdCB3aGVuIG1pZGRsZWJveGVzIGFyZW7igJl0IGEgcHJvYmxlbS7igJ0gIFRhbGsgYWJvdXQg YXNwaXJhdGlvbmFsICgNCg0K From nobody Tue Nov 7 12:53:19 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E29B12751F for ; Tue, 7 Nov 2017 12:53:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 PvClObE1Mp9c for ; Tue, 7 Nov 2017 12:53:15 -0800 (PST) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 0EC3C126D85 for ; Tue, 7 Nov 2017 12:53:15 -0800 (PST) Received: by mail-vk0-x229.google.com with SMTP id h142so374199vkf.7 for ; Tue, 07 Nov 2017 12:53:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PPmdYl6x4XyZcPjiDeN3CaEvZ5nDG4Kqyty7BqU7hpo=; b=dSFzAp4klF0GF8UDOK/Z70g/f6OuRWVW0tCF0oippe1Hp8GO706zH6Ptc4/oHu+x9A GHRzL9J+MgiCGTxyzwAmeX4AY52IjdDA2VoBNKtmv296V4gHLZ/QkB/lTmFQPGgm3F/3 olwZe6VP7cs6oaVmIy+tdDFaf7RPoHAio2m0x2eEqXeUTG3TBZ/M0taTQv1/W4bqo/HU AU/v19PUPyCUvF2nlQvtpmHhUi0EPalX13RwU3QLMuHnWvwMaz9n5ffVlc+bu1qnts2a k/sT4D7IP/z6NE3ji9qcwcYBep3d9MURuRqGzYzisgQcIjsWiBKDHBoI7Iqmk24mMEHi n23Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PPmdYl6x4XyZcPjiDeN3CaEvZ5nDG4Kqyty7BqU7hpo=; b=bD8CYZY0+eGqhWvsu/1XtcUFD8z63DXq4Jj86GdKnsaDnI+vX26gG7dVHcFC1t2b1y 18QgrmbmoPTZ+QaaAnSH6VjxUBSHLHEyMwkrC/jFfqOzGn0yoknrtexO9A+w7oIvRH+d R4itI0XoRnYW0Ea7kUStP2UoRcuogNoBXd/E/Dy/2DFHRSEqu8LO3XOO11sDFHFfgk4G erlwU5cJXqkGjvWySJETYzl9586o4c+cbxtvDKRM8kdnGQmWBL0ejK9zE6S2BvO6JgMB xlZBh6cDYr1W4E8/aFKHw61ik73CtHRQ/n+bZhE4z2G7+2bwe/NQ1MoLXySEW7NoDkdx qjLQ== X-Gm-Message-State: AJaThX7awaRQ1eZIjIOR1sKjOOL5RKFT6YHYTk6PXizULBKgN33N1RvG KPIFJQXk/lEExw+UIP/6+arFQmMnjMCkGOJe8UA= X-Google-Smtp-Source: ABhQp+QIEpqRJp3exNiFqR4rplHSVLf9m55CNvQFssSJFUHidOnH+6eqaMtUHrNEK/ODzKN+swhSkt4YkCR2/JZtbro= X-Received: by 10.31.188.71 with SMTP id m68mr33240vkf.180.1510087994013; Tue, 07 Nov 2017 12:53:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.34.67 with HTTP; Tue, 7 Nov 2017 12:53:13 -0800 (PST) In-Reply-To: References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> From: Alex C Date: Wed, 8 Nov 2017 09:53:13 +1300 Message-ID: To: Hannes Tschofenig Cc: Richard Barnes , "" Content-Type: multipart/alternative; boundary="001a1143aa4a767e32055d6ac20d" Archived-At: Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 20:53:17 -0000 --001a1143aa4a767e32055d6ac20d Content-Type: text/plain; charset="UTF-8" If the embedded device is capable of running TLS anyway (e.g. fast enough to do RSA) why not have the phone act as a dumb proxy? However I see the draft has some additional scenarios where it makes sense, such as where the device must work with an off-the-shelf proxy that only speaks HTTP. On Wed, Nov 8, 2017 at 4:15 AM, Hannes Tschofenig wrote: > FWIW: I can tell you what the threat model was with the layered TLS work. > > Let me give you a very specific example. Imagine a Bluetooth Low Energy > device that communicates via a phone to a cloud-based service. The > communication from the phone to the cloud uses HTTPS. The communication > from the BLE device to the phone uses ordinary BLE > services/characteristics. > > The Layered TLS/application layer TLS would in this case run from the > BLE device all the way to the cloud-based service at the application layer. > > This allows us to provide end-to-end security across a proxy (in this > case the phone) and independent of the underlying protocols. > > Does this make sense? > > Ciao > Hannes > > > On 11/07/2017 10:21 AM, Alex C wrote: > > What exactly is the threat model here? > > > > Are you trying to hide a connection from a reverse proxy at the server > > end? If so, the server operator should not have deployed a reverse proxy > > in the first place. > > > > Are you trying to hide from a MITM proxy that supplies its own > > certificate? If so, then what prevents the proxy from doing the same to > > the tunnelled session? > > When MITM proxies learn to do that, will we create another tunnelling > > protocol inside this one? > > > > This is a cat-and-mouse game with middleboxes (much like the version > > negotiation problem, but in a different way). Keep playing and everyone > > loses. > > > > On Tue, Oct 31, 2017 at 11:17 AM, Richard Barnes > > wrote: > > > > Hey TLS folks, > > > > Owen, Max, and I have been kicking around some ideas for how to make > > secure connections in environments where HTTPS is subject to MitM / > > proxying. > > > > The below draft lays out a way to tunnel TLS over HTTPS, in hopes of > > creating a channel you could use when you really need things to be > > private, even from the local MitM. > > > > Feedback obviously very welcome. Interested in whether folks think > > this is a useful area in which to develop an RFC, and any thoughts > > on how to do this better. > > > > Thanks, > > --Richard > > > > > > On Mon, Oct 30, 2017 at 3:47 PM, > > wrote: > > > > > > A new version of I-D, draft-friel-tls-over-http-00.txt > > has been successfully submitted by Owen Friel and posted to the > > IETF repository. > > > > Name: draft-friel-tls-over-http > > Revision: 00 > > Title: Application-Layer TLS > > Document date: 2017-10-30 > > Group: Individual Submission > > Pages: 20 > > URL: > > https://www.ietf.org/internet-drafts/draft-friel-tls-over- > http-00.txt > > tls-over-http-00.txt> > > Status: > > https://datatracker.ietf.org/doc/draft-friel-tls-over-http/ > > > > Htmlized: > > https://tools.ietf.org/html/draft-friel-tls-over-http-00 > > > > Htmlized: > > https://datatracker.ietf.org/doc/html/draft-friel-tls-over- > http-00 > > http-00> > > > > > > Abstract: > > Many clients need to establish secure connections to > application > > services but face challenges establishing these connections > > due to > > the presence of middleboxes that terminate TLS connections > > from the > > client and restablish new TLS connections to the service. > This > > document defines a mechanism for transporting TLS records in > HTTP > > message bodies between clients and services. This enables > > clients > > and services to establish secure connections using TLS at the > > application layer, and treat any middleboxes that are > > intercepting > > traffic at the network layer as untrusted transport. In > > short, this > > mechanism moves the TLS handshake up the OSI stack to the > > application > > layer. > > > > > > > > > > Please note that it may take a couple of minutes from the time > > of submission > > until the htmlized version and diff are available at > > tools.ietf.org . > > > > The IETF Secretariat > > > > > > > > _______________________________________________ > > 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 > > > --001a1143aa4a767e32055d6ac20d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If the embedded device is capable of running TLS anyw= ay (e.g. fast enough to do RSA) why not have the phone act as a dumb proxy?=

However I see the draft has some additional scenarios where i= t makes sense, such as where the device must work with an off-the-shelf pro= xy that only speaks HTTP.

On Wed, Nov 8, 2017 at 4:15 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
FWIW: I can tell you what the threat model was with the layered T= LS work.

Let me give you a very specific example. Imagine a Bluetooth Low Energy
device that communicates via a phone to a cloud-based service. The
communication from the phone to the cloud uses HTTPS. The communication
from the BLE device to the phone uses ordinary BLE
services/characteristics.

The Layered TLS/application layer TLS would in this case run from the
BLE device all the way to the cloud-based service at the application layer.=

This allows us to provide end-to-end security across a proxy (in this
case the phone) and independent of the underlying protocols.

Does this make sense?

Ciao
Hannes


On 11/07/2017 10:21 AM, Alex C wrote:
> What exactly is the threat model here?
>
> Are you trying to hide a connection from a reverse proxy at the server=
> end? If so, the server operator should not have deployed a reverse pro= xy
> in the first place.
>
> Are you trying to hide from a MITM proxy that supplies its own
> certificate? If so, then what prevents the proxy from doing the same t= o
> the tunnelled session?
> When MITM proxies learn to do that, will we create another tunnelling<= br> > protocol inside this one?
>
> This is a cat-and-mouse game with middleboxes (much like the version > negotiation problem, but in a different way). Keep playing and everyon= e
> loses.
>
> On Tue, Oct 31, 2017 at 11:17 AM, Richard Barnes <rlb@ipv.sx
> <mailto:rlb@i= pv.sx>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hey TLS folks,
>
>=C2=A0 =C2=A0 =C2=A0Owen, Max, and I have been kicking around some idea= s for how to make
>=C2=A0 =C2=A0 =C2=A0secure connections in environments where HTTPS is s= ubject to MitM /
>=C2=A0 =C2=A0 =C2=A0proxying.
>
>=C2=A0 =C2=A0 =C2=A0The below draft lays out a way to tunnel TLS over H= TTPS, in hopes of
>=C2=A0 =C2=A0 =C2=A0creating a channel you could use when you really ne= ed things to be
>=C2=A0 =C2=A0 =C2=A0private, even from the local MitM.=C2=A0
>
>=C2=A0 =C2=A0 =C2=A0Feedback obviously very welcome.=C2=A0 Interested i= n whether folks think
>=C2=A0 =C2=A0 =C2=A0this is a useful area in which to develop an RFC, a= nd any thoughts
>=C2=A0 =C2=A0 =C2=A0on how to do this better.
>
>=C2=A0 =C2=A0 =C2=A0Thanks,
>=C2=A0 =C2=A0 =C2=A0--Richard
>
>
>=C2=A0 =C2=A0 =C2=A0On Mon, Oct 30, 2017 at 3:47 PM, <internet-drafts@ietf.org
>=C2=A0 =C2=A0 =C2=A0<mailto:internet-drafts@ietf.org>>= wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A new version of I-D, draft-friel-tls= -over-http-00.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0has been successfully submitted by Ow= en Friel and posted to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IETF repository.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0draft-friel-tls-over-http
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A00= 0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Application-Layer TLS
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Document date:=C2=A0 2017-10-30
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Individual Submission
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 20
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/internet-drafts/draft-friel-tls-over-= http-00.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/internet-drafts/draft-friel-tls-= over-http-00.txt>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0https://datatracker.ietf.org/doc/draft-friel-tls-over-http/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://datatracker.ietf.org/doc/draft-friel-tls-over-http/&= gt;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Htmlized:=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0= https://tools.ietf.org/html/draft-friel-tls-over-http-00
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<ht= tps://tools.ietf.org/html/draft-friel-tls-over-http-00>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Htmlized:=C2=A0 =C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0https://datatracker.ietf.org/doc/html/draft-friel-tls-over= -http-00
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://datatracker.ietf.org/doc/html/draft-friel-tls-over-http-00>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Abstract:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Many clients need to est= ablish secure connections to application
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0services but face challe= nges establishing these connections
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0due to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0the presence of middlebo= xes that terminate TLS connections
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0from the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0client and restablish ne= w TLS connections to the service.=C2=A0 This
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0document defines a mecha= nism for transporting TLS records in HTTP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0message bodies between c= lients and services.=C2=A0 This enables
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0clients
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0and services to establis= h secure connections using TLS at the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0application layer, and t= reat any middleboxes that are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0intercepting
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0traffic at the network l= ayer as untrusted transport.=C2=A0 In
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0short, this
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0mechanism moves the TLS = handshake up the OSI stack to the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0application
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0layer.
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Please note that it may take a couple= of minutes from the time
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of submission
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0until the htmlized version and diff a= re available at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tools.ietf.org <http://too= ls.ietf.org>.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The IETF Secretariat
>
>
>
>=C2=A0 =C2=A0 =C2=A0______________________________________________= _
>=C2=A0 =C2=A0 =C2=A0TLS mailing list
>=C2=A0 =C2=A0 =C2=A0TLS@ietf.org= <mailto:TLS@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/l= istinfo/tls
>=C2=A0 =C2=A0 =C2=A0<https://www.ietf.org/mailman/listinfo/tls>
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--001a1143aa4a767e32055d6ac20d-- From nobody Tue Nov 7 14:02:41 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572ED128B51 for ; Tue, 7 Nov 2017 14:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Rq4hXenR-Oje for ; Tue, 7 Nov 2017 14:02:38 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 22BB9126C19 for ; Tue, 7 Nov 2017 14:02:38 -0800 (PST) Received: by mail-oi0-x230.google.com with SMTP id j126so555622oib.8 for ; Tue, 07 Nov 2017 14:02:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CPkxK3LrQrYgJG8QcKwiR+idjEwagBjg7so0m17whY8=; b=SrezUiVkwZs4/teJoR3yfPtmvLpiWuXyJdHKu7xohyKYYPKSExOSDbBziqcqgLB1VF cZDGcm4UCiissKoVI57KPbmAlaFMNmvRc7fStEoXnZR+EO53CZKZS+Ny1phvomxmP2Ne RPHyimA/YH1PwN8KgK6eSzVE/MjyyyOpMAoanqa7IUObxgHr5PCtYF6fk6hBdtOzi5M4 Q5eCnjIvZ5hlJXzhSxXMk6jwbamhAHAK9KJTu/VzeSiSpXbELRlWFQpBA4NAg8DKuxHa bFC9/MGdEWxepIDKbD6LJU0VIxfa6IOb2KWrthPzDrqvjQqF53+w/VwV3fqgM01qTs6Q EthQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=CPkxK3LrQrYgJG8QcKwiR+idjEwagBjg7so0m17whY8=; b=dtzzFgpOYQ++D1+tPh4dZ84n5h4JTuiMu055u78h50UuX5/Bw5D+T+beW5TNefWf1X N8nG3RvNdrfYQIV6nmLfBPomg0fofO2VARJoZlv98+HLsf39SqLNFNkNaYwUMqZamQSI dHHyCGyy+w7O8iAeHrYSuLieVhc2w79l+mBSPmdPmWd4jifTMvCI8dglB4u+9dKBQk71 hFfhiDLRLvD4J58z4aEPVrPfmASCh07rcONyEeKt8BKaDpVUdt3LUG8IehlodAIB/2kJ /hBQ9fv1braiIbXQ5wCo8TMUlw3RIeQG+qRsyxrDDc5iPnHO1N7kqB/k12zCPDHSglqB nJzg== X-Gm-Message-State: AJaThX6pxJWK1O8cmn58/EdftHwuYWc+tV5WuFPQA8KKWQNlYLv5nfE7 nDY0EJFRc7svaF7BORzGfnyZDOY1YZ/CfFkP9Hf+/g== X-Google-Smtp-Source: ABhQp+Q0O70UwLI1//M36WSSy5Ww1mllWwHbCpnnNEeSxwa+4eIpCBX3ZTPGIXILFT0hj892zLt4pQJyT/wSjLhuXUc= X-Received: by 10.202.75.216 with SMTP id y207mr131734oia.282.1510092157423; Tue, 07 Nov 2017 14:02:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.15.155 with HTTP; Tue, 7 Nov 2017 14:02:36 -0800 (PST) In-Reply-To: <965B995B-A5B3-4322-B13A-A2D82AFD2743@akamai.com> References: <4406543.RZChgRkkf9@pintsize.usersys.redhat.com> <6818962.9GzJR6rN5C@pintsize.usersys.redhat.com> <965B995B-A5B3-4322-B13A-A2D82AFD2743@akamai.com> From: Martin Thomson Date: Wed, 8 Nov 2017 09:02:36 +1100 Message-ID: To: "Salz, Rich" Cc: Hubert Kario , Eric Rescorla , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 22:02:39 -0000 On Wed, Nov 8, 2017 at 7:23 AM, Salz, Rich wrote: > =E2=80=9CWe can remove it when middleboxes aren=E2=80=99t a problem.=E2= =80=9D Talk about aspirational ( Given that we're almost there, and that only really browsers are asking for these hacks, and that even some of those were almost ready to ship without these hacks, I don't think that this is entirely unrealistic as an aspiration. From nobody Tue Nov 7 14:40:22 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0768C1294BC for ; Tue, 7 Nov 2017 14:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 4Kn2JhGY0loX for ; Tue, 7 Nov 2017 14:40:17 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 A30B31294B9 for ; Tue, 7 Nov 2017 14:40:17 -0800 (PST) Received: by mail-oi0-x22d.google.com with SMTP id f66so635083oib.2 for ; Tue, 07 Nov 2017 14:40:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZDpIKM88jbym5TT9+Mij0joLlj8pz1rV/eEx7iYaIxc=; b=dPeKzOyFiHLjJ4551fvYiRlWTRkLVn9K4yiQOOi7Vgkyg0EdJ/zqrm4Hsi/bF+dfWC flRiLOdGMy/eKODpeM55X3OzjgHcgUiBX6+GoDSd+UIXZjVUSndtJSTvJh+157y4vLSX erWypg2EBnRRXpchFo/Yo6+4gFGSk7wMXk0YQD5ksec9yJ14LuM+N/zPlAtGhdWAoc0Q aSPqaZst9uA0A0ju0XIs3P6m0gG/8qjrvRTbfMae7FQEmklp3JAdOZNsL70X8MOnsq8D qqMIfANLrCJ04g3CP0KN0LDNZ4fxhoSeMVzs3e5Uj5E9ZhS0pvdSKnXH8NnZQBCEoLbN N6LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZDpIKM88jbym5TT9+Mij0joLlj8pz1rV/eEx7iYaIxc=; b=Hwa0jfdQg2ee73fnsff0WPmVb/Jba//dT5ppdpwpEihRYnyWd9Q4bsrNlfAzBslKLg ok4zl7z4h9Tv0x1y9e6P+u5I7TB9mQun4HlHlvjxtO2EChPm3ZMWvIoEknXXR3JZ+R2z dCVRIa8wyhzh/b3bgaCF3aPOOkGyp3PlS3u9d0A6G/NxtY7+RvnqnTvjg1h7gP20vBD9 J8TwhjhLbKbFdW9rlyG5vQueKoU2V5LhgIvFKvPvfRdJel7o2kPSRTfS9guHRg3Gfojp 2z/41VOp3fzRcvfyFW18k1roq3jiqcKe5LPYvkqJtCYAQFXCby+5IV4RNPZHa7DykfAT 60lQ== X-Gm-Message-State: AJaThX5gz+RL6OXXRq+ufIVzNWOinIGRJQVCsktpwqojgMwdxmOYtAje viYtwsEmMLNFs2/mMz4Yg3sY/S5O6LFwxfX6Mr8= X-Google-Smtp-Source: ABhQp+TLHzQbtIuwecHD+pqd9gB0/+hnVBo99udTJdob77muRrf8Znmv6RIDzEkVuU/K/aitAnC3VEA7h+VZaNdi0zE= X-Received: by 10.202.108.201 with SMTP id h192mr168508oic.378.1510094416872; Tue, 07 Nov 2017 14:40:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.168.183.193 with HTTP; Tue, 7 Nov 2017 14:40:16 -0800 (PST) In-Reply-To: References: From: Illya Gerasymchuk Date: Tue, 7 Nov 2017 22:40:16 +0000 Message-ID: To: Eric Rescorla Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1142dd2e4b89b0055d6c4136" Archived-At: Subject: Re: [TLS] TLS Extensions: Omitting Handshake Messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 22:40:21 -0000 --001a1142dd2e4b89b0055d6c4136 Content-Type: text/plain; charset="UTF-8" Thank you very much for your answer. So just to be clear, hypothetically, it would be possible to define an extension for TLS 1.2 that *converts it to TLS 1.3 completely*, correct? For example, would it be possible, to have an extension called *TLS_1.2_TO_TLS_1.3 *that would define the full handshake to be the following, *and still be TLS 1.2 compliant?* (I just copied the full hadshake from the TLS 1.3 draft and added the text in bold): *Client* *Server* ClientHello* + TLS_1.2_TO_TLS_1.3* + key_share --------> <-------- HelloRetryRequest *+ TLS_1.2_TO_TLS_1.3* + key_share ClientHello + key_share --------> ServerHello + key_share {EncryptedExtensions} {CertificateRequest*} {Certificate*} {CertificateVerify*} {Finished} <-------- [Application Data*] {Certificate*} {CertificateVerify*} {Finished} --------> [Application Data] <--------------------------------------> [Application Data] To give you a little more background for my motivation behind this, the topic for my master thesis is "TLS For IOT", the goal of which is to define a new version of TLS protocol, which would be usable on low-power, low-energy devices, *while remaining backwards compatible with regular TLS. *My idea is to define this new protocol through various extensions (even though I had't had a chance to discuss this with my supervisors, since they seem to be away). Considering the extension above, I know that I could easily define a new protocol that would do something like: > > > *if TLS_1.2_TO_TLS_1.3 extension present in ClientHello: use my custom > protocol (with new messages and some omitted)else: use regular TLS 1.2* But would that still be considered *TLS Extension Compliant*? (if I can remove some of the messages not marked as optional in the spec, such as *ServerHelloDone*, then the answer would be yes). The answer to this question conditions whether I would need to define 2 separate protocols: one for TLS 1.2, one for TLS 1.3 or if I potentially can just define the same protocol that could be used by clients and servers supporting both: TLS 1.2 and TLS 1.3, by the means of an extension. My main goals would be to limit the number of messages sent, the amount of transmitted data, as well as use lighter algorithms. Quite a few of the ideas I had initially are already implemented in TLS 1.3, so I wanted to migrate a lot of those to clients and servers that only support TLS 1.2. I've been reading a lot of RFC's and papers about the work done on this topic, but I haven't found any of them that does such a thing specifically (removing any of the messages not marked as optional). I'm well aware that I need to be extremely careful when removing messages or making any significant changes to the protocol. Thank you, - Illya On Tue, Nov 7, 2017 at 5:56 PM, Eric Rescorla wrote: > > > On Tue, Nov 7, 2017 at 6:15 AM, Illya Gerasymchuk > wrote: > >> Greetings, >> >> I've been reading though various RFCs and couldn't find a definite answer >> to my question: can a negotiated TLS extension skip some of the TLS >> Handshake messages and still be compliant with the TLS specification? My >> goal is to develop a new version of TLS (as part of my Master Thesis work), >> while preferably, staying backwards-compatible. >> >> Here, I will be specifically talking about TLS 1.2, defined in RFC 5246. >> Below is a message flow for the full handshake (taken directly from RFC >> 5246): >> >> Client Server >> ------ ------ >> >> ClientHello --------> >> ServerHello >> Certificate* >> ServerKeyExchange* >> >> CertificateRequest* >> <-------- ServerHelloDone >> Certificate* >> ClientKeyExchange >> CertificateVerify* >> [ChangeCipherSpec] >> Finished --------> >> >> [ChangeCipherSpec] >> <-------- Finished >> Application Data <-------> Application Data >> >> >> * (asterisk) Indicates optional or situation-dependent messages that are >> not always sent. >> Now, I do know that it's perfect legal for a TLS extension to modify the >> structure of some message or add a new message, but I'm not sure if one of >> the messages, not defined as optional/situation-dependent can be omitted. >> >> Let me give you a concrete example. Let's say I create a new extension >> called *XYZ*. The client and the server negotiate that extension in the >> their extended hello messages. Would it be legal for the *XYZ* extension >> to mandate the server not to send the *ServerHelloDone* message? As far >> as I understood, this is not legal. >> > > You certainly can use extensions to indicate that a new message is to be > sent, so I don't think it would be necessarily be prohibited to have it > remove a message, though I can't offhand think of an example of where we do > so. > > > RFC 5245 Section 4.4.1.4 states that: >> >> "it would be technically possible to use extensions to change major aspects >> of the design of TLS; for example the design of cipher suite >> negotiation. This is not recommended; it would be more appropriate to >> define a new version of TLS -- particularly since the TLS handshake >> algorithms have specific protection against version rollback attacks >> based on the version number, and the possibility of version rollback >> should be a significant consideration in any major design change" >> > > To be honest, this mostly seems aspirational :) > > > I would assume, however, that those major aspects do no include omitting >> messages not marked as optional/situation-dependent in the spec. >> >> Both, TLS 1.2 and TLS 1.3 draft specs mention REQUIRED/MUST in the >> section describing the ClientHello. There are no REQUIRED mentions in other >> messages though. You do have the following for the Finished: "A Finished >> message is always sent immediately after a change cipher spec message to >> verify that the key exchange and authentication processes were successful." >> , so things like these lead me to believe that the messages not explicitly >> marked as optional, are in fact, required. >> > > They're required absent some extension and you would have to be pretty > careful with changes which moved them. > > -Ekr > > >> >> >> Thank you. >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > --001a1142dd2e4b89b0055d6c4136 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you very much for your answer. So just to be clear, = hypothetically, it would be possible to define an extension for TLS 1.2 tha= t converts it=C2=A0to TLS 1.3=C2=A0completely, correct? For example,= would it be possible, to have an extension called=C2=A0TLS_1.2_TO_TLS_1= .3 that would define the full handshake to be the following, and sti= ll be TLS 1.2 compliant?=C2=A0(I just copied the full hadshake from the= TLS 1.3 draft and added the text in bold):

            Client                                 =
              Server

            ClientHello
            + TLS_1.2_TO_TLS_1.3
            + key_share             -------->
                                    <--------         HelloRetryRequest
                                                            + TLS_1.2_TO_TLS_1.3
                                                            + key_share

            ClientHello
            + key_share             -------->
                                                            ServerHello
                                                            + key_share
                                                  {EncryptedExtensions}
                                                  {CertificateRequest*}
                                                         {Certificate*}
                                                   {CertificateVerify*}
                                                             {Finished}
                                    <--------       [Application Data*]
            {Certificate*}
            {CertificateVerify*}
            {Finished}              -------->=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Applicat= ion Data] =C2=A0 =C2=A0 =C2=A0 <--------------------------------------&g= t; =C2=A0 [Application Data]=C2=A0

To give = you a little more background for my motivation behind this, the topic for m= y master thesis is "TLS For IOT", the goal of which is to define = a new version of TLS protocol, which would be usable on low-power, low-ener= gy devices, while remaining backwards compatible with regular TLS. M= y idea is to define this new protocol through various extensions (even thou= gh I had't had a chance to discuss this with my supervisors, since they= seem to be away). Considering the extension above, I know that I could eas= ily define a new protocol that would do something like:

if TLS_1.2_TO_TLS_= 1.3=C2=A0extension present in ClientHello:
=C2=A0 =C2=A0 use my cust= om protocol (with new messages and some omitted)
else:
=C2=A0 =C2=A0 = use regular TLS 1.2
=C2=A0
But would that st= ill be considered TLS Extension=C2=A0Compliant?=C2=A0(if I ca= n remove some of the messages not marked as optional in the spec, such as <= i>ServerHelloDone, then the answer would be yes). The answer to this qu= estion conditions whether I would need to define 2 separate protocols: one = for TLS 1.2, one for TLS 1.3 or if I potentially can just define the same p= rotocol that could be used by clients and servers supporting both: TLS 1.2 = and TLS 1.3, by the means of an extension. My main goals would be to limit = the number of messages sent, the amount of transmitted data, as well as use= lighter algorithms. Quite a few of the ideas I had initially are already i= mplemented in TLS 1.3, so I wanted to migrate a lot of those to clients and= servers that only support TLS 1.2. I've been reading a lot of RFC'= s and papers about the work done on this topic, but I haven't found any= of them that does such a thing specifically (removing any of the messages = not marked as optional).

I'm well aware that I= need to be extremely careful when removing messages or making any signific= ant changes to the protocol.

Thank you,
=
- Illya

<= div class=3D"gmail_quote">On Tue, Nov 7, 2017 at 5:56 PM, Eric Rescorla <ekr@rt= fm.com> wrote:


On Tue, Nov 7, 2017 at 6:15 AM, Illya Ger= asymchuk <giluxonchik@gmail.com> wrote:
Greetings,

I've been reading though variou= s RFCs and couldn't find a definite answer to my question: can a negoti= ated TLS extension skip some of the TLS Handshake messages and still be com= pliant with the TLS specification? My goal is to develop a new version of T= LS (as part of my Master Thesis work), while preferably, staying backwards-= compatible.

Here, I will b= e specifically talking about TLS 1.2, defined in RFC 5246. Below is a messa= ge flow for the full handshake (taken directly from RFC 5246):
=

=C2=A0 Client =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Server
=C2= =A0 ------ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0------ =C2=A0 =C2=A0 =C2=A0

=
=C2=A0 ClientHello =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0-------->
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 ServerHello
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 Certificate*
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ServerKeyExchange*
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CertificateRequest*=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &= lt;-------- =C2=A0 =C2=A0 =C2=A0ServerHelloDone
=C2=A0 = Certificate*
=C2=A0 ClientKeyExchange
= =C2=A0 CertificateVerify*
=C2=A0 [ChangeCipherSpec]=
=C2=A0 Finished =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -------->
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ChangeCipherSpec]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 <-------- =C2=A0 =C2=A0 =C2=A0 =C2=A0Finished
= =C2=A0 Application Data =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<-------> = =C2=A0 =C2=A0 =C2=A0 Application Data

=

* (asterisk) Indicates optional or situation-dependent messages that = are not always sent.
Now, I do know that it's p= erfect legal for a TLS extension to modify the structure of some message or= add a new message, but I'm not sure if one of the messages, not define= d as optional/situation-dependent can be omitted.

<= /font>
Let me give you a concrete example. Let's say I cre= ate a new extension called XYZ. The client and the server negotiate = that extension in the their extended hello messages. Would it be legal for = the XYZ extension to mandate the server not to send the ServerHel= loDone message? As far as I understood, this is not legal.
=

You certainly can use extensi= ons to indicate that a new message is to be sent, so I don't think it w= ould be necessarily be prohibited to have it remove a message, though I can= 't offhand think of an example of where we do so.


RFC 5245 Section 4.4.1.4 states that:<= /font>

"it would be technically = possible to use extensions to change major suite negotiation.=C2=A0 This is not recommend= ed; it would be more appropriate to defin= e a new version of TLS -- particularly since=C2=A0the TLS handshake algorithms have specific protection against=C2= =A0version rollback attacks based on the = version number, and the possibility of ve= rsion rollback should be a significant=C2=A0consideration in any major design change"=C2=A0
<= /blockquote>

To be honest, this mostly seems aspi= rational :)


I would assume, however, that those major aspects do no = include omitting messages not marked as optional/situation-dependent in the= spec.

Both, TLS 1.2 and TLS 1.3 draft s= pecs mention REQUIRED/MUST in the section describing the ClientHello. There= are no REQUIRED mentions in other messages though. You do have the followi= ng for the Finished: "A Finished message is always sent immediately af= ter a change cipher spec message to verify that the key exchange and authen= tication processes were successful." , so things like these lead me to= believe that the messages not explicitly marked as optional, are in fact, = required.

They= 9;re required absent some extension and you would have to be pretty careful= with changes which moved them.

-Ekr
=C2= =A0


Thank you.


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



--001a1142dd2e4b89b0055d6c4136-- From nobody Tue Nov 7 14:47:24 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838AB1294BC for ; Tue, 7 Nov 2017 14:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 EsdAWZsiEJBP for ; Tue, 7 Nov 2017 14:47:19 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 3F1361294E8 for ; Tue, 7 Nov 2017 14:47:19 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id t11so745285ywg.12 for ; Tue, 07 Nov 2017 14:47:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3Dl+tOszhkxkZ4khgr7OQ4Oo71qTaBVxQ/3PETQ3rBA=; b=ZOcn79n1MJrmNnDB44vGlhXROVe/sHWJEt8RPDHZkryUpDO3KuY+dCcEWFi7Meh+Ja MvDRUbbMtwfw84zrjcJktiVT+UOYqmi5YRFqHuksXZoCp6DIKScyT5w7phzr2+oImMFJ oKUpuFCV6xsebUadinfu8HaTACMdRTgdDvqCQJjoWpOhtY6y3GwKV5X+eeRc+2gw5ZBq //xw0r/9wOnpQyePWG9HsVFz7JOia68s8cytgY/RW73RO04NCFZzplEGEKQe4DGK8POR C3/owBQZlC/HLRGocbrQ54DMrV9Wy+MRh/HPioIciPGyWqBgWVfSwWowBxl1+L0l/dMK Ghyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3Dl+tOszhkxkZ4khgr7OQ4Oo71qTaBVxQ/3PETQ3rBA=; b=uHGyM6rtFF0NsfZsNWhQrdNr5/wHcQhq+qdLqQQn6wMxVphUlbBEdJcE/lLzTiA7Xt Qc2h82WluJTLdd+B2RfMdLmfiBuwJp2VfxAm8Sk/rWHSAl25ltA31gCivQrjg/zQPX/Q b2vdEyKK3JVKppMdswRLsaaxmRjCq2zlbYJ6fNBlaIwx85T+ITagGHq5U3A5jYP+DKRH mlT+xXbJ+HKNmrJTyOrEA1mVTys70/m2yU771MGgTiF1TgPBj5M0CLQoAWmo+z/f7Lcg V4fhcVa+MwkZpd76faYOnXvCbNwHIej9gdvnEIJVzedoP6Uucuvn+UoRtKOuzv3nIQ18 Rg/Q== X-Gm-Message-State: AJaThX6rRa5Rzl5eSpQ7+9he1Q8f9uFsc9pnrDJ/xQNx/ykkUBZSrApY PcLXSM+LfgknoIoa+qF5L93MrDdhHofOFelZZh7+XhCZ X-Google-Smtp-Source: ABhQp+QdyV6feUQ2aUYq8R/yNdeoSB7bXIXJTBISmElDwmndJxNxzT3TZ6sxXqXMcuY8+Rf4bRH6I1k8k/hoQKN1wnc= X-Received: by 10.129.36.1 with SMTP id k1mr184362ywk.485.1510094838500; Tue, 07 Nov 2017 14:47:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.61.12 with HTTP; Tue, 7 Nov 2017 14:46:37 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 7 Nov 2017 14:46:37 -0800 Message-ID: To: Illya Gerasymchuk Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1142e4cc6d2417055d6c5a95" Archived-At: Subject: Re: [TLS] TLS Extensions: Omitting Handshake Messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 22:47:22 -0000 --001a1142e4cc6d2417055d6c5a95 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 7, 2017 at 2:40 PM, Illya Gerasymchuk wrote: > Thank you very much for your answer. So just to be clear, hypothetically, > it would be possible to define an extension for TLS 1.2 that *converts > it to TLS 1.3 completely*, correct? > Well, this is effectively the syntax that TLS 1.3 with PR 1091 uses, except that it's called "supported_versions". > For example, would it be possible, to have an extension called *TLS_1.2_TO_TLS_1.3 > *that would define the full handshake to be the following, *and still be > TLS 1.2 compliant?* (I just copied the full hadshake from the TLS 1.3 > draft and added the text in bold): > This seems like a philosophical question. > To give you a little more background for my motivation behind this, the > topic for my master thesis is "TLS For IOT", the goal of which is to define > a new version of TLS protocol, which would be usable on low-power, > low-energy devices, *while remaining backwards compatible with regular > TLS.* > Well, backward compatible here typically would mean "you can send a ClientHello to the server and it won't choke", and this would be true for both your proposal and TLS 1.3. Any other questions about compliance kind of seem like standards lawyering. -Ekr But would that still be considered *TLS Extension Compliant*? (if I can > remove some of the messages not marked as optional in the spec, such as > *ServerHelloDone*, then the answer would be yes). The answer to this > question conditions whether I would need to define 2 separate protocols: > one for TLS 1.2, one for TLS 1.3 or if I potentially can just define the > same protocol that could be used by clients and servers supporting both: > TLS 1.2 and TLS 1.3, by the means of an extension. My main goals would be > to limit the number of messages sent, the amount of transmitted data, as > well as use lighter algorithms. Quite a few of the ideas I had initially > are already implemented in TLS 1.3, so I wanted to migrate a lot of those > to clients and servers that only support TLS 1.2. I've been reading a lot > of RFC's and papers about the work done on this topic, but I haven't found > any of them that does such a thing specifically (removing any of the > messages not marked as optional). > > I'm well aware that I need to be extremely careful when removing messages > or making any significant changes to the protocol. > > > Thank you, > > - Illya > > On Tue, Nov 7, 2017 at 5:56 PM, Eric Rescorla wrote: > >> >> >> On Tue, Nov 7, 2017 at 6:15 AM, Illya Gerasymchuk >> wrote: >> >>> Greetings, >>> >>> I've been reading though various RFCs and couldn't find a definite >>> answer to my question: can a negotiated TLS extension skip some of the TLS >>> Handshake messages and still be compliant with the TLS specification? My >>> goal is to develop a new version of TLS (as part of my Master Thesis work), >>> while preferably, staying backwards-compatible. >>> >>> Here, I will be specifically talking about TLS 1.2, defined in RFC 5246. >>> Below is a message flow for the full handshake (taken directly from RFC >>> 5246): >>> >>> Client Server >>> ------ ------ >>> >>> ClientHello --------> >>> ServerHello >>> Certificate* >>> >>> ServerKeyExchange* >>> >>> CertificateRequest* >>> <-------- ServerHelloDone >>> Certificate* >>> ClientKeyExchange >>> CertificateVerify* >>> [ChangeCipherSpec] >>> Finished --------> >>> >>> [ChangeCipherSpec] >>> <-------- Finished >>> Application Data <-------> Application Data >>> >>> >>> * (asterisk) Indicates optional or situation-dependent messages that are >>> not always sent. >>> Now, I do know that it's perfect legal for a TLS extension to modify the >>> structure of some message or add a new message, but I'm not sure if one of >>> the messages, not defined as optional/situation-dependent can be omitted. >>> >>> Let me give you a concrete example. Let's say I create a new extension >>> called *XYZ*. The client and the server negotiate that extension in the >>> their extended hello messages. Would it be legal for the *XYZ* >>> extension to mandate the server not to send the *ServerHelloDone* >>> message? As far as I understood, this is not legal. >>> >> >> You certainly can use extensions to indicate that a new message is to be >> sent, so I don't think it would be necessarily be prohibited to have it >> remove a message, though I can't offhand think of an example of where we do >> so. >> >> >> RFC 5245 Section 4.4.1.4 states that: >>> >>> "it would be technically possible to use extensions to change major aspects >>> of the design of TLS; for example the design of cipher suite >>> negotiation. This is not recommended; it would be more appropriate to >>> define a new version of TLS -- particularly since the TLS handshake >>> algorithms have specific protection against version rollback attacks >>> based on the version number, and the possibility of version rollback >>> should be a significant consideration in any major design change" >>> >> >> To be honest, this mostly seems aspirational :) >> >> >> I would assume, however, that those major aspects do no include omitting >>> messages not marked as optional/situation-dependent in the spec. >>> >>> Both, TLS 1.2 and TLS 1.3 draft specs mention REQUIRED/MUST in the >>> section describing the ClientHello. There are no REQUIRED mentions in other >>> messages though. You do have the following for the Finished: "A Finished >>> message is always sent immediately after a change cipher spec message to >>> verify that the key exchange and authentication processes were successful." >>> , so things like these lead me to believe that the messages not explicitly >>> marked as optional, are in fact, required. >>> >> >> They're required absent some extension and you would have to be pretty >> careful with changes which moved them. >> >> -Ekr >> >> >>> >>> >>> Thank you. >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> >> > --001a1142e4cc6d2417055d6c5a95 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Nov 7, 2017 at 2:40 PM, Illya Gerasymchuk <giluxonchik@gmail.com> wrote:
Tha= nk you very much for your answer. So just to be clear, hypothetically, it w= ould be possible to define an extension for TLS 1.2 that converts it=C2= =A0to TLS 1.3=C2=A0completely, correct?

Well, this is effectively the syntax that TLS 1.3 with PR 1091 uses= , except that it's called "supported_versions".
=C2=A0
For= example, would it be possible, to have an extension called=C2=A0TLS_1.2= _TO_TLS_1.3 that would define the full handshake to be the following, <= b>and still be TLS 1.2 compliant?=C2=A0(I just copied the full hadshake= from the TLS 1.3 draft and added the text in bold):

This seems like a philosophical question.
=C2=A0<= /div>



To give you a little more background for my mo= tivation behind this, the topic for my master thesis is "TLS For IOT&q= uot;, the goal of which is to define a new version of TLS protocol, which w= ould be usable on low-power, low-energy devices, while remaining backwar= ds compatible with regular TLS.

=
Well, backward compatible here typically would mean "you can send= a ClientHello to the server and it won't choke", and this would b= e true for both your proposal and TLS 1.3. Any other questions about compli= ance kind of seem like standards lawyering.

-Ekr


=C2=A0

But would that still be conside= red TLS Extension=C2=A0Compliant?=C2=A0(if I can remove some = of the messages not marked as optional in the spec, such as ServerHelloD= one, then the answer would be yes). The answer to this question conditi= ons whether I would need to define 2 separate protocols: one for TLS 1.2, o= ne for TLS 1.3 or if I potentially can just define the same protocol that c= ould be used by clients and servers supporting both: TLS 1.2 and TLS 1.3, b= y the means of an extension. My main goals would be to limit the number of = messages sent, the amount of transmitted data, as well as use lighter algor= ithms. Quite a few of the ideas I had initially are already implemented in = TLS 1.3, so I wanted to migrate a lot of those to clients and servers that = only support TLS 1.2. I've been reading a lot of RFC's and papers a= bout the work done on this topic, but I haven't found any of them that = does such a thing specifically (removing any of the messages not marked as = optional).

I'm well aware that I need to be ex= tremely careful when removing messages or making any significant changes to= the protocol.

=C2=A0

Thank you,<= /div>

- Illya

On Tue, Nov 7, 2= 017 at 5:56 PM, Eric Rescorla <ekr@rtfm.com> wrote:


On Tue, Nov 7, 2017 at 6:15 AM, Illya Gerasymchuk <giluxo= nchik@gmail.com> wrote:
Greetings,=

I've been reading though various RFCs and couldn'= ;t find a definite answer to my question: can a negotiated TLS extension sk= ip some of the TLS Handshake messages and still be compliant with the TLS s= pecification? My goal is to develop a new version of TLS (as part of my Mas= ter Thesis work), while preferably, staying backwards-compatible.

Here, I will be specifically talkin= g about TLS 1.2, defined in RFC 5246. Below is a message flow for the full = handshake (taken directly from RFC 5246):

=C2=A0 Client =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Server
=C2=A0 ------ =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0------ =C2=A0= =C2=A0 =C2=A0

=C2=A0 ClientHe= llo =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--------&= gt;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 S= erverHello
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Certificate*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 ServerKeyExchange*
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 CertificateRequest*
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <-------- =C2=A0 = =C2=A0 =C2=A0ServerHelloDone
=C2=A0 Certificate*
=C2=A0 ClientKeyExchange
=C2=A0 Certific= ateVerify*
=C2=A0 [ChangeCipherSpec]
<= font color=3D"#242729" face=3D"Arial, Helvetica Neue, Helvetica, sans-serif= ">=C2=A0 Finished =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 -------->
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ChangeCipherSpec]
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <-------- = =C2=A0 =C2=A0 =C2=A0 =C2=A0Finished
=C2=A0 Application = Data =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<-------> =C2=A0 =C2=A0 =C2=A0= Application Data


* (asterisk) I= ndicates optional or situation-dependent messages that are not always sent.=
Now, I do know that it's perfect legal for a T= LS extension to modify the structure of some message or add a new message, = but I'm not sure if one of the messages, not defined as optional/situat= ion-dependent can be omitted.

= Let me give you a concrete example. Let's say I create a new extension = called XYZ. The client and the server negotiate that extension in th= e their extended hello messages. Would it be legal for the XYZ exten= sion to mandate the server not to send the ServerHelloDone message? = As far as I understood, this is not legal.
<= div>
You certainly can use extensions to indicate that= a new message is to be sent, so I don't think it would be necessarily = be prohibited to have it remove a message, though I can't offhand think= of an example of where we do so.


RFC 5245 Section 4.4.1.4 states that:=

"it would be technically= possible to use extensions to change major aspects of the design of TLS; for example the design of cipher=C2=A0suite negotiation.=C2=A0 This is not recommen= ded; it would be more appropriate to defi= ne a new version of TLS -- particularly since=C2=A0the TLS handshake algorithms have specific protection against=C2= =A0version rollback attacks based on the = version number, and the possibility of ve= rsion rollback should be a significant=C2=A0consideration in any major design change"=C2=A0
<= /blockquote>

To be honest, this mostly seems aspi= rational :)


I would assume, however, that thos= e major aspects do no include omitting messages not marked as optional/situ= ation-dependent in the spec.

Both, TLS 1= .2 and TLS 1.3 draft specs mention REQUIRED/MUST in the section describing = the ClientHello. There are no REQUIRED mentions in other messages though. Y= ou do have the following for the Finished: "A Finished message is alwa= ys sent immediately after a change cipher spec message to verify that the k= ey exchange and authentication processes were successful." , so things= like these lead me to believe that the messages not explicitly marked as o= ptional, are in fact, required.

They're required absent some extension and you would hav= e to be pretty careful with changes which moved them.

<= div>-Ekr
=C2=A0


Than= k you.


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




--001a1142e4cc6d2417055d6c5a95-- From nobody Tue Nov 7 14:47:45 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B757F12954C for ; Tue, 7 Nov 2017 14:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 tr8Dl1QW3gqX for ; Tue, 7 Nov 2017 14:47:25 -0800 (PST) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (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 176D21294E8 for ; Tue, 7 Nov 2017 14:47:25 -0800 (PST) Received: by mail-ot0-x22a.google.com with SMTP id k10so771212otb.0 for ; Tue, 07 Nov 2017 14:47:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ToqE7wrG1cWp1YxNXIKgY59guKyULYROMd32MQ4X9SA=; b=NHTxzzy9bM5WjqAQi6CX4id9LHhafRtpIprnjt+Y/k5VGWJS6FhhCg5eCsrbhcFPPa X4CSBE8ep01PPmxaZ0wkJjkh/yKAJ5X5W2+uHMJFe92Z0G+MD6TbJX3jeoPYZInmJxAh 3y/4hZpJomEVda7VH1OQ09mAL7tWSAulrcPyD31Cp472TDk25IzpaeXXLsF3Gv3xMFZT ncebcUnqSPctS9OfrX/AMlysscGyjofjrX2njKvfffqdV3VwWX7Ak2ax0r4NQ9IrK4D7 L2agJYgWVRJYdtPzNbs9Gd2Bh3vM2g802e/eh79JnJUbxhAfsqpSm1xqDZPC6tCZF+W3 0S6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ToqE7wrG1cWp1YxNXIKgY59guKyULYROMd32MQ4X9SA=; b=lRYkRUy332brZ0E15zYXzKNdpXQsqfwb+yVohr5UOCcG8ZQWPhoM7qbQJAEJkeBBZf QV6v7X3eA1jgzVrxrVFz4LKJJ9Bj43siz+/VB565gfGNTukA4+32kJNBZPVFEb4vvA7w itw4PEEXTs0V0mKJSL8qGENyuaShmFJkmE8E6KKtAU3N08lirHYkKnP7HcuKPuhTmnRe q6i2ylC1CsFzHEm0973+RSPK6Uct4S8HkPkBOVZxfBWeodWJLt9AtNLnJQ80im2SxpeQ v2RZ3adDv/PnECbFilSJED2Z8x6GO6AFfl518xtHEZi0ChMVk+BsaUWVNfLQzg5kPAUd MSJQ== X-Gm-Message-State: AJaThX4orPh7bNC0BHXNgECZLG44i3HD7KTyFDmxEwpwKfRMsoR+xV99 SSpkpQtFGf0Yie2tF6elp5eRuFysvWWc/K8Z7UE= X-Google-Smtp-Source: ABhQp+QaTy3kjxdOGG5Ou9jLiAaPJkPSCilLOtn50UT6T/V3LX9dqxqNqKtPjrSpdvzGGw06RvN2wNvZOoodrnYIuDQ= X-Received: by 10.157.6.77 with SMTP id 71mr42592otn.377.1510094844220; Tue, 07 Nov 2017 14:47:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.15.155 with HTTP; Tue, 7 Nov 2017 14:47:23 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Wed, 8 Nov 2017 09:47:23 +1100 Message-ID: To: Illya Gerasymchuk Cc: Eric Rescorla , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] TLS Extensions: Omitting Handshake Messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 22:47:28 -0000 Hi Illya, You are actually describing TLS 1.3, especially with recent (proposed) changes. It uses an extension to negotiate version, looking like TLS 1.2 otherwise. It has the ability to use lighter-weight algorithms, etc... On Wed, Nov 8, 2017 at 9:40 AM, Illya Gerasymchuk wrote: > Thank you very much for your answer. So just to be clear, hypothetically, it > would be possible to define an extension for TLS 1.2 that converts it to TLS > 1.3 completely, correct? For example, would it be possible, to have an > extension called TLS_1.2_TO_TLS_1.3 that would define the full handshake to > be the following, and still be TLS 1.2 compliant? (I just copied the full > hadshake from the TLS 1.3 draft and added the text in bold): > > Client Server > > ClientHello > + TLS_1.2_TO_TLS_1.3 > + key_share --------> > <-------- HelloRetryRequest > + > TLS_1.2_TO_TLS_1.3 > + key_share > > ClientHello > + key_share --------> > ServerHello > + key_share > {EncryptedExtensions} > {CertificateRequest*} > {Certificate*} > {CertificateVerify*} > {Finished} > <-------- [Application Data*] > {Certificate*} > {CertificateVerify*} > {Finished} --------> > > [Application Data] > <--------------------------------------> [Application Data] > > To give you a little more background for my motivation behind this, the > topic for my master thesis is "TLS For IOT", the goal of which is to define > a new version of TLS protocol, which would be usable on low-power, > low-energy devices, while remaining backwards compatible with regular TLS. > My idea is to define this new protocol through various extensions (even > though I had't had a chance to discuss this with my supervisors, since they > seem to be away). Considering the extension above, I know that I could > easily define a new protocol that would do something like: > >> if TLS_1.2_TO_TLS_1.3 extension present in ClientHello: >> use my custom protocol (with new messages and some omitted) >> else: >> use regular TLS 1.2 > > > But would that still be considered TLS Extension Compliant? (if I can remove > some of the messages not marked as optional in the spec, such as > ServerHelloDone, then the answer would be yes). The answer to this question > conditions whether I would need to define 2 separate protocols: one for TLS > 1.2, one for TLS 1.3 or if I potentially can just define the same protocol > that could be used by clients and servers supporting both: TLS 1.2 and TLS > 1.3, by the means of an extension. My main goals would be to limit the > number of messages sent, the amount of transmitted data, as well as use > lighter algorithms. Quite a few of the ideas I had initially are already > implemented in TLS 1.3, so I wanted to migrate a lot of those to clients and > servers that only support TLS 1.2. I've been reading a lot of RFC's and > papers about the work done on this topic, but I haven't found any of them > that does such a thing specifically (removing any of the messages not marked > as optional). > > I'm well aware that I need to be extremely careful when removing messages or > making any significant changes to the protocol. > > Thank you, > > - Illya > > On Tue, Nov 7, 2017 at 5:56 PM, Eric Rescorla wrote: >> >> >> >> On Tue, Nov 7, 2017 at 6:15 AM, Illya Gerasymchuk >> wrote: >>> >>> Greetings, >>> >>> I've been reading though various RFCs and couldn't find a definite answer >>> to my question: can a negotiated TLS extension skip some of the TLS >>> Handshake messages and still be compliant with the TLS specification? My >>> goal is to develop a new version of TLS (as part of my Master Thesis work), >>> while preferably, staying backwards-compatible. >>> >>> Here, I will be specifically talking about TLS 1.2, defined in RFC 5246. >>> Below is a message flow for the full handshake (taken directly from RFC >>> 5246): >>> >>> Client Server >>> ------ ------ >>> >>> ClientHello --------> >>> ServerHello >>> Certificate* >>> >>> ServerKeyExchange* >>> >>> CertificateRequest* >>> <-------- ServerHelloDone >>> Certificate* >>> ClientKeyExchange >>> CertificateVerify* >>> [ChangeCipherSpec] >>> Finished --------> >>> >>> [ChangeCipherSpec] >>> <-------- Finished >>> Application Data <-------> Application Data >>> >>> >>> * (asterisk) Indicates optional or situation-dependent messages that are >>> not always sent. >>> Now, I do know that it's perfect legal for a TLS extension to modify the >>> structure of some message or add a new message, but I'm not sure if one of >>> the messages, not defined as optional/situation-dependent can be omitted. >>> >>> Let me give you a concrete example. Let's say I create a new extension >>> called XYZ. The client and the server negotiate that extension in the their >>> extended hello messages. Would it be legal for the XYZ extension to mandate >>> the server not to send the ServerHelloDone message? As far as I understood, >>> this is not legal. >> >> >> You certainly can use extensions to indicate that a new message is to be >> sent, so I don't think it would be necessarily be prohibited to have it >> remove a message, though I can't offhand think of an example of where we do >> so. >> >> >>> RFC 5245 Section 4.4.1.4 states that: >>> >>> "it would be technically possible to use extensions to change major >>> aspects of the design of TLS; for example the design of cipher suite >>> negotiation. This is not recommended; it would be more appropriate to >>> define a new version of TLS -- particularly since the TLS handshake >>> algorithms have specific protection against version rollback attacks based >>> on the version number, and the possibility of version rollback should be a >>> significant consideration in any major design change" >> >> >> To be honest, this mostly seems aspirational :) >> >> >>> I would assume, however, that those major aspects do no include omitting >>> messages not marked as optional/situation-dependent in the spec. >>> >>> Both, TLS 1.2 and TLS 1.3 draft specs mention REQUIRED/MUST in the >>> section describing the ClientHello. There are no REQUIRED mentions in other >>> messages though. You do have the following for the Finished: "A Finished >>> message is always sent immediately after a change cipher spec message to >>> verify that the key exchange and authentication processes were successful." >>> , so things like these lead me to believe that the messages not explicitly >>> marked as optional, are in fact, required. >> >> >> They're required absent some extension and you would have to be pretty >> careful with changes which moved them. >> >> -Ekr >> >>> >>> >>> >>> Thank you. >>> >>> >>> _______________________________________________ >>> 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 > From nobody Tue Nov 7 15:07:36 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD30512953B for ; Tue, 7 Nov 2017 15:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Xqajyo7YsuHW for ; Tue, 7 Nov 2017 15:07:32 -0800 (PST) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 C1D9E129478 for ; Tue, 7 Nov 2017 15:07:31 -0800 (PST) Received: by mail-oi0-x22c.google.com with SMTP id r128so666112oig.9 for ; Tue, 07 Nov 2017 15:07:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2o7aqFcLFl7xx6AiOuF3AXIkm1Q3zoRBOpE5mlCSFL0=; b=c86NmUPpqy8X5mVi22mEjlgScLJok9xlhu9/H1Brw8DZN9iGi6bNxw2Oyk7qASydLQ 6IQgFcZPx7a2cqqQ9cDdNiG2bmfgvqsfKOlc+UVyRa6rKcspui2YXSdQd8jsXRiLgxbB VQ50zbwRPsj2cUQaFXIbft/f3a6l78R2QhbHw5HQ4PDqxH12W5LKFhx0iN67j+iwKJpu kCIAmnyPrqZ2AZLE7xotRuDvnLQ1hNVMZlGB1rhgRP6fYnRG40K6LeALSGUvweOYpC5U AlUG8trOAM83M9U1yUW+SVFDFMFgGmb97YpLJZPyJ6Yun4XpkQyE3Ocgw/iS/OKIA1QP LTJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2o7aqFcLFl7xx6AiOuF3AXIkm1Q3zoRBOpE5mlCSFL0=; b=K0WJl5DlnnJxl14md/H8obclglxa7afNqjN8zU7LuUMr7vRGKMAAAanDovMJyLP38Z 3+WogCMQfIflgifXYsI8k3b9syFhrkR4x+ylQ2u0Y+69Ba3bb2Z+XwNLoRwHuuN86Lht hMtJQzcYs2B8k1/jF0Yg6O0PX2C1k+FEWPFdFUQ0XPjPwA1GtcihpVzb8qA5NAs1+9MN M2gRXWN3ciWerU74/q/w++fHAlbheKYs/zd4tOHb+6UP1Pg3zHVqk6Mf0l3S/Uy+ef2i KCBmwbz38f8JfEH+t+evm3QA1QDk8C+fC1lPE0gxD2+YqOu5eMrYowgE6S1XXYIWvrut iB5w== X-Gm-Message-State: AJaThX6EnkFUyxV+zQRPsTcxjZjgNa3kgjPhqXn07ckQsOaSsYcFCJZH xi4yGIpfYLAuret/xJZ+JN8jIzJ8nMZXG31cIPQ= X-Google-Smtp-Source: ABhQp+Sm+ZUPYfl/aAmZW7sRE+0+14RahQM89SaQF86T7mCTr0lEQBVhU3nsA9krSZ5ZCtn+dPWnZN3n0SSIR4v9li0= X-Received: by 10.202.4.19 with SMTP id 19mr192555oie.69.1510096051072; Tue, 07 Nov 2017 15:07:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.168.183.193 with HTTP; Tue, 7 Nov 2017 15:07:30 -0800 (PST) In-Reply-To: References: From: Illya Gerasymchuk Date: Tue, 7 Nov 2017 23:07:30 +0000 Message-ID: To: Eric Rescorla Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a113c2a02b3735d055d6ca213" Archived-At: Subject: Re: [TLS] TLS Extensions: Omitting Handshake Messages X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 23:07:35 -0000 --001a113c2a02b3735d055d6ca213 Content-Type: text/plain; charset="UTF-8" Okay, thank you very much, this clears it all up! Can I make a suggestion of making the section that describes the extension mechanism to mention that extensions can, in fact, choose to omit messages not marked as situation-depended/optional? Maybe this is already covered by the "it would be technically possible to use extensions to change major aspects of the design of TLS" part, but neither reading RFC 5246, nor the TLS 1.3 draft, nor the RFC 4366 (and other related ones), makes it clear, in my opinion. I'm talking from a perspective of someone who studied SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3 and related RFCs in detail in the last 2-3 months, but only knew the basics before (not basics cryptography and other constructs that TLS uses, only the basics of the TLS protocol itself). I've asked the same question I posted here to some friends and on the internet and everyone said that, from what they understood from the spec, *extensions could not remove *messages marked as non-optional. Having such information presented explicitly would be of great help to anyone who is working on changes/extensions to/for TLS. Thank you, - Illya On Tue, Nov 7, 2017 at 10:46 PM, Eric Rescorla wrote: > On Tue, Nov 7, 2017 at 2:40 PM, Illya Gerasymchuk > wrote: > >> Thank you very much for your answer. So just to be clear, hypothetically, >> it would be possible to define an extension for TLS 1.2 that *converts >> it to TLS 1.3 completely*, correct? >> > > Well, this is effectively the syntax that TLS 1.3 with PR 1091 uses, > except that it's called "supported_versions". > > > >> For example, would it be possible, to have an extension called *TLS_1.2_TO_TLS_1.3 >> *that would define the full handshake to be the following, *and still be >> TLS 1.2 compliant?* (I just copied the full hadshake from the TLS 1.3 >> draft and added the text in bold): >> > > This seems like a philosophical question. > > > > >> To give you a little more background for my motivation behind this, the >> topic for my master thesis is "TLS For IOT", the goal of which is to define >> a new version of TLS protocol, which would be usable on low-power, >> low-energy devices, *while remaining backwards compatible with regular >> TLS.* >> > > Well, backward compatible here typically would mean "you can send a > ClientHello to the server and it won't choke", and this would be true for > both your proposal and TLS 1.3. Any other questions about compliance kind > of seem like standards lawyering. > > -Ekr > > > > > But would that still be considered *TLS Extension Compliant*? (if I can >> remove some of the messages not marked as optional in the spec, such as >> *ServerHelloDone*, then the answer would be yes). The answer to this >> question conditions whether I would need to define 2 separate protocols: >> one for TLS 1.2, one for TLS 1.3 or if I potentially can just define the >> same protocol that could be used by clients and servers supporting both: >> TLS 1.2 and TLS 1.3, by the means of an extension. My main goals would be >> to limit the number of messages sent, the amount of transmitted data, as >> well as use lighter algorithms. Quite a few of the ideas I had initially >> are already implemented in TLS 1.3, so I wanted to migrate a lot of those >> to clients and servers that only support TLS 1.2. I've been reading a lot >> of RFC's and papers about the work done on this topic, but I haven't found >> any of them that does such a thing specifically (removing any of the >> messages not marked as optional). >> >> I'm well aware that I need to be extremely careful when removing messages >> or making any significant changes to the protocol. >> > > > >> >> Thank you, >> >> - Illya >> >> On Tue, Nov 7, 2017 at 5:56 PM, Eric Rescorla wrote: >> >>> >>> >>> On Tue, Nov 7, 2017 at 6:15 AM, Illya Gerasymchuk >> > wrote: >>> >>>> Greetings, >>>> >>>> I've been reading though various RFCs and couldn't find a definite >>>> answer to my question: can a negotiated TLS extension skip some of the TLS >>>> Handshake messages and still be compliant with the TLS specification? My >>>> goal is to develop a new version of TLS (as part of my Master Thesis work), >>>> while preferably, staying backwards-compatible. >>>> >>>> Here, I will be specifically talking about TLS 1.2, defined in RFC >>>> 5246. Below is a message flow for the full handshake (taken directly from >>>> RFC 5246): >>>> >>>> Client Server >>>> ------ ------ >>>> >>>> ClientHello --------> >>>> ServerHello >>>> Certificate* >>>> >>>> ServerKeyExchange* >>>> >>>> CertificateRequest* >>>> <-------- ServerHelloDone >>>> Certificate* >>>> ClientKeyExchange >>>> CertificateVerify* >>>> [ChangeCipherSpec] >>>> Finished --------> >>>> >>>> [ChangeCipherSpec] >>>> <-------- Finished >>>> Application Data <-------> Application Data >>>> >>>> >>>> * (asterisk) Indicates optional or situation-dependent messages that >>>> are not always sent. >>>> Now, I do know that it's perfect legal for a TLS extension to modify >>>> the structure of some message or add a new message, but I'm not sure if one >>>> of the messages, not defined as optional/situation-dependent can be omitted. >>>> >>>> Let me give you a concrete example. Let's say I create a new extension >>>> called *XYZ*. The client and the server negotiate that extension in >>>> the their extended hello messages. Would it be legal for the *XYZ* >>>> extension to mandate the server not to send the *ServerHelloDone* >>>> message? As far as I understood, this is not legal. >>>> >>> >>> You certainly can use extensions to indicate that a new message is to be >>> sent, so I don't think it would be necessarily be prohibited to have it >>> remove a message, though I can't offhand think of an example of where we do >>> so. >>> >>> >>> RFC 5245 Section 4.4.1.4 states that: >>>> >>>> "it would be technically possible to use extensions to change major aspects >>>> of the design of TLS; for example the design of cipher suite >>>> negotiation. This is not recommended; it would be more appropriate to >>>> define a new version of TLS -- particularly since the TLS handshake >>>> algorithms have specific protection against version rollback attacks >>>> based on the version number, and the possibility of version rollback >>>> should be a significant consideration in any major design change" >>>> >>> >>> To be honest, this mostly seems aspirational :) >>> >>> >>> I would assume, however, that those major aspects do no include omitting >>>> messages not marked as optional/situation-dependent in the spec. >>>> >>>> Both, TLS 1.2 and TLS 1.3 draft specs mention REQUIRED/MUST in the >>>> section describing the ClientHello. There are no REQUIRED mentions in other >>>> messages though. You do have the following for the Finished: "A Finished >>>> message is always sent immediately after a change cipher spec message to >>>> verify that the key exchange and authentication processes were successful." >>>> , so things like these lead me to believe that the messages not explicitly >>>> marked as optional, are in fact, required. >>>> >>> >>> They're required absent some extension and you would have to be pretty >>> careful with changes which moved them. >>> >>> -Ekr >>> >>> >>>> >>>> >>>> Thank you. >>>> >>>> >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>> >>>> >>> >> > --001a113c2a02b3735d055d6ca213 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Okay, thank you very much, this clears it all up!
=C2= =A0
Can I make a suggestion of making the section that describes t= he extension mechanism to mention that extensions can, in fact, choose to o= mit messages not marked as situation-depended/optional? Maybe this is alrea= dy covered by the "it would be technical= ly possible to use extensions to change major=C2=A0aspects of the design of TLS" part, but neither rea= ding RFC 5246, nor the TLS 1.3 draft, nor the RFC 4366 (and other related o= nes), makes it clear, in my opinion. I'm talking from a perspective=C2= =A0of someone who studied =C2=A0SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3= and related RFCs in detail in the last 2-3 months, but only knew the basic= s before (not basics cryptography and other constructs that TLS uses, only = the basics of the TLS protocol itself). I've asked the same question I = posted here to some friends and on the internet and everyone said that, fro= m what they understood from the spec,=C2=A0extensions could not remove <= /b>messages marked as non-optional. Having such information presented expli= citly would be of great help to anyone who is working on changes/extensions= to/for TLS.
Thank you,

- Illya

On Tue, Nov 7, 2017 at 10:46 PM, Eric Rescorla <ekr@rtfm.com> w= rote:
On Tue, Nov 7, 2017 at= 2:40 PM, Illya Gerasymchuk <giluxonchik@gmail.com> wrot= e:
Thank you very much f= or your answer. So just to be clear, hypothetically, it would be possible t= o define an extension for TLS 1.2 that converts it=C2=A0to TLS 1.3=C2=A0= completely, correct?

Well= , this is effectively the syntax that TLS 1.3 with PR 1091 uses, except tha= t it's called "supported_versions".

=C2=A0
For example, would it be possible, to have an extension called=C2=A0TL= S_1.2_TO_TLS_1.3 that would define the full handshake to be the followi= ng, and still be TLS 1.2 compliant?=C2=A0(I just copied the full had= shake from the TLS 1.3 draft and added the text in bold):

This seems like a philosophical question.
=
=C2=A0



To give you a litt= le more background for my motivation behind this, the topic for my master t= hesis is "TLS For IOT", the goal of which is to define a new vers= ion of TLS protocol, which would be usable on low-power, low-energy devices= , while remaining backwards compatible with regular TLS.
=

Well, backward compatible here typi= cally would mean "you can send a ClientHello to the server and it won&= #39;t choke", and this would be true for both your proposal and TLS 1.= 3. Any other questions about compliance kind of seem like standards lawyeri= ng.

-Ekr


=C2=A0

But would that still be considered TLS Ext= ension=C2=A0Compliant?=C2=A0(if I can remove some of the messages n= ot marked as optional in the spec, such as ServerHelloDone, then the= answer would be yes). The answer to this question conditions whether I wou= ld need to define 2 separate protocols: one for TLS 1.2, one for TLS 1.3 or= if I potentially can just define the same protocol that could be used by c= lients and servers supporting both: TLS 1.2 and TLS 1.3, by the means of an= extension. My main goals would be to limit the number of messages sent, th= e amount of transmitted data, as well as use lighter algorithms. Quite a fe= w of the ideas I had initially are already implemented in TLS 1.3, so I wan= ted to migrate a lot of those to clients and servers that only support TLS = 1.2. I've been reading a lot of RFC's and papers about the work don= e on this topic, but I haven't found any of them that does such a thing= specifically (removing any of the messages not marked as optional).
<= div>
I'm well aware that I need to be extremely careful w= hen removing messages or making any significant changes to the protocol.

=C2=A0

Thank you,

- Illya

On Tue, Nov= 7, 2017 at 5:56 PM, Eric Rescorla <ekr@rtfm.com> wrote:


On Tue, Nov 7, 2017 at 6:15 AM, Ill= ya Gerasymchuk <giluxonchik@gmail.com> wrote:
Greetings,
I've been reading though = various RFCs and couldn't find a definite answer to my question: can a = negotiated TLS extension skip some of the TLS Handshake messages and still = be compliant with the TLS specification? My goal is to develop a new versio= n of TLS (as part of my Master Thesis work), while preferably, staying back= wards-compatible.

Here, I = will be specifically talking about TLS 1.2, defined in RFC 5246. Below is a= message flow for the full handshake (taken directly from RFC 5246):=

=C2=A0 Client =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Server
=C2=A0 ------ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0------ =C2=A0 =C2=A0 =C2=A0

=C2=A0 ClientHello =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0-------->
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ServerHello
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Certificate*
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ServerKeyExchange*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CertificateRequ= est*
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 <-------- =C2=A0 =C2=A0 =C2=A0ServerHelloDone
=C2=A0 Certificate*
=C2=A0 ClientKeyExchange
=C2=A0 CertificateVerify*
=C2=A0 [Change= CipherSpec]
=C2=A0 Finished =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -------->
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [ChangeCiphe= rSpec]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 <-------- =C2=A0 =C2=A0 =C2=A0 =C2=A0Finished
=C2=A0 Application Data =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<-------&= gt; =C2=A0 =C2=A0 =C2=A0 Application Data


* (asterisk) Indicates optional or situation-dependent messages t= hat are not always sent.
Now, I do know that it= 9;s perfect legal for a TLS extension to modify the structure of some messa= ge or add a new message, but I'm not sure if one of the messages, not d= efined as optional/situation-dependent can be omitted.
=
Let me give you a concrete example. Let's say = I create a new extension called XYZ. The client and the server negot= iate that extension in the their extended hello messages. Would it be legal= for the XYZ extension to mandate the server not to send the Serv= erHelloDone message? As far as I understood, this is not legal.<= /div>

You certainly can use ex= tensions to indicate that a new message is to be sent, so I don't think= it would be necessarily be prohibited to have it remove a message, though = I can't offhand think of an example of where we do so.

=
RFC 5245 Section 4.4.1.4 states that:

"it would be technically possible to use extensions = to change major aspects of the design of = TLS; for example the design of cipher=C2=A0appropriate to define a new version of TLS -- p= articularly since=C2=A0the TLS handshake = algorithms have specific protection against=C2=A0version rollback attacks based on the version number, and the possibility of version rollback should be a si= gnificant=C2=A0consideration in any major= design change"=C2=A0

To be honest, this mostly seems aspirational :)

=
I would assume, however, that those major= aspects do no include omitting messages not marked as optional/situation-d= ependent in the spec.

Both, TLS 1.2 and = TLS 1.3 draft specs mention REQUIRED/MUST in the section describing the Cli= entHello. There are no REQUIRED mentions in other messages though. You do h= ave the following for the Finished: "A Finished message is always sent= immediately after a change cipher spec message to verify that the key exch= ange and authentication processes were successful." , so things like t= hese lead me to believe that the messages not explicitly marked as optional= , are in fact, required.

They're required absent some extension and you would have to be= pretty careful with changes which moved them.

-Ek= r
=C2=A0
<= div dir=3D"ltr">


Thank you.<= /font>


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





--001a113c2a02b3735d055d6ca213-- From nobody Tue Nov 7 15:11:05 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9014D1296C6 for ; Tue, 7 Nov 2017 15:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 YIHLTklnDFMz for ; Tue, 7 Nov 2017 15:11:00 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83A0412953B for ; Tue, 7 Nov 2017 15:11:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44698; q=dns/txt; s=iport; t=1510096260; x=1511305860; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=ozY5GmcoBX/TKYn9lkYsyyKu0pjqCAm/DraGowLo/RQ=; b=dJZ2Jg7d074JJkwSn6j6iWwy4EKs9dDmTR9eRnStIxdwACklvKJFQ0H4 AXSyW9ciI0rlJ9mayUH9i0eHyjeMOqiiJX+T8Q8LmIgRlxrptyaypVViI 4cQkUh//Zp786gEWIvG1OhWKErM7qvZMeDVEr6jX5RTPurDO0pd1nsrfT E=; X-IronPort-AV: E=Sophos;i="5.44,361,1505779200"; d="scan'208,217";a="320742893" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Nov 2017 23:10:59 +0000 Received: from [10.118.10.19] (rtp-fandreas-2-8812.cisco.com [10.118.10.19]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vA7NAwZw026508; Tue, 7 Nov 2017 23:10:59 GMT To: Eric Rescorla Cc: "Nancy Cam-Winget (ncamwing)" , "tls@ietf.org" References: <895D1206-28D1-43AB-8A45-11DEEC86A71D@cisco.com> From: Flemming Andreasen Message-ID: <6cec1ed4-cce5-384a-6240-509285596d46@cisco.com> Date: Tue, 7 Nov 2017 18:11:49 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E897D93A12C07BFB9FFA4826" Content-Language: en-US Archived-At: Subject: Re: [TLS] network-based security solution use cases X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 23:11:03 -0000 This is a multi-part message in MIME format. --------------E897D93A12C07BFB9FFA4826 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/7/17 12:23 PM, Eric Rescorla wrote: > > > On Tue, Nov 7, 2017 at 7:56 AM, Flemming Andreasen > wrote: > > Thank you for the feedback Ekr - please see below for responses > > > On 11/6/17 12:43 PM, Eric Rescorla wrote: >> I took a look at this. >> >> Without getting into the question of whether the types of middleboxes >> you describe here provide a security benefit, there are several >> points >> in the document that are either wrong or at least >> misleading/confusing. >> >> - Key Synchronization >> This document notes that in TLS 1.2, it is possible for a middlebox >> that traffic keys match on both sides of the connection it is >> proxying, >> but in TLS 1.3 it is not: >> >>    There are several techniques that can be utilized.  Those >> techniques >>    function with TLS 1.2 and earlier versions but not with TLS 1.3. >> >>    One technique is for the middlebox to negotiate the same master >>    secret with the original TLS client and server, as if the two >>    endpoints handshake directly.  This is also known as "Triple >>    Handshake" used by legitimate middleboxes.  [BreakTLS] >> describes the >>    methods with RSA and DH key exchanges. When the proxy session keys >>    are the same as for a direct handshake, the middlebox is able to >>    "cut-through" the two TLS proxy sessions when it finishes the >>    security inspection. >> >>    This technique is not functional with TLS 1.3 since the transcript >>    hash over the handshake messages is part of the key derivation >>    procedure. >> >> First, I would note that this property of TLS 1.2 is bad, as it leads >> to Unknown Key Share (UKS) attacks, which can be the basis of real >> attacks on TLS 1.2 as fielded. It is for this reason that the TLS >> WG published RFC 7627. >> > Thanks for the bringing that one up - we will make sure to include > that in the next version. > > Understood - it is nevertheless a change from TLS 1.2. In TLS 1.3, > it's an integral part of the protocol that cannot be disabled. The > TLS 1.2 extension does not share that property. > > > It seems like an odd complaint that we are making protection against > Unknown Key Shares an integral part of the protocol I understand your point. What I am saying is that there are some side effects of doing so that impacts use case scenarios that exist today. If you cannot drop out, then you have two choices: 1) Always be a MITM, which you may not want to (e.g. consider sessions with financial institutions) 2) Never be a MITM, which means you cannot do any of the network-based security use cases we have highlighted What you really want is the ability to do it more selectively. >> Finally, you note several times in the document (e.g., S 4.5), that >> with key synchronization, the middlebox can perform the handshake and >> then disengage from the connection. However, the cases you mention >> (e.g.., detecting exploit attempts) ultimately require examining >> all traffic in the connection. >> > We have several different use case scenarios in there, and I agree > with the observation that they cannot all be satisfied at the same > time. For example, we cannot scan for malware in an encrypted > stream to a financial institution that we are not allowed to > decrypt. That doesn't mean either use case is invalid. Customers > do both in real-life (just not at the same time). > > > I'm finding it a bit puzzling what you claim customers do. > Specifically, you seem to be saying that customers examine the > beginning of the connection and then stop. What are they scanning for > and what makes them stop? > It's the handshake process, which typically governs the associated policy for the session (e.g. decrypt-and-inspect or do-not-decrypt). You will try to determine whether the session should undergo inspection at the time the ClientHello passes through the box, however sometimes, you end up making a final (and different) decision when the ServerHello is received. The decision is guided by policies configured for the middlebox which may determine it based on various criteria (e.g. category of the destination such as "Financial Services", geography, etc.) >> - PSK and resumption >> You write: >> >>    In TLS 1.3, the above mechanism is replaced by Pre-Shared Keys >> (PSK), >>    which can be negotiated as part of an initial handshake and >> then used >>    in a subsequent handshake to perform resumption using the >> PSK.  TLS >>    1.3 states that the client SHOULD include a "key_share" >> extension to >>    enable the server to decline resumption and fall back to a full >>    handshake, however it is not an absolute requirement. >> >>    Example scenarios that are impacted by this are middleboxes >> that were >>    not part of the initial handshake, and hence do not know the >> PSK.  If >>    the client does not include the "key_share" extension, the >> middlebox >>    cannot force a fallback to the full handshake.  If the middlebox >>    policy requires it to inspect the session, it will have to >> fail the >>    connection instead. >> >> In TLS 1.3, PSKs and session resumption are basically the same and >> have the same properties. While I concede that the document does >> not require the client to offer key_shares, as a practical matter >> it is very unlikely that a client will act in such a way that >> failure to retain the PSK causes a hard failure, for two reasons: >> >> (a) In every version of TLS, the ticket lifetime is just a hint, and >>     the server can forget it at any time >>     >> (https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#NSTMessage >> ). >> Thus, >>     a client which does not allow a full handshake will often >>     find itself unable to connect. >> >> (b) The relevant question is not whether the client offers a key >> share >>     extension but whether it advertises any DH groups. If the >> client sends >>     a group but not a key share, the server can send >> HelloRetryRequest >>     to force the client to send a key share. >> >> For these reasons, as far as I know, every client (and at least every >> browser client) should allow a full handshake even when trying to >> resume. >> > If that is indeed the case, then I would suggest changing the spec > language to a MUST here instead so we can guarantee it. > > > I don't believe this is necessary. There are certainly reasons why you > would want to do PSK w/o (EC)DHE (e.g., you are really PSK only). > Agree with the example, but is that really a resumption scenario ? > >> - Server Certificate Concealment >> You note that in TLS 1.2 the middlebox can examine both the SNI >> and the >> server's certificate in order to decide whether to MITM the >> connection, >> but that in TLS 1.3, the middlebox cannot guarantee that the SNI in >> uses is correct: >> >>    In TLS 1.2, the ClientHello, ServerHello and Certificate >> messages are >>    all sent in clear-text, however in TLS 1.3, the Certificate >> message >>    is encrypted thereby hiding the server identity from any >>    intermediary.  Note that even _if_ the SNI is provided (in >> cleartext) >>    by the client, there is no guarantee that the actual server >>    responding is the one indicated in the SNI from the client. >> >> In this case, it's important to distinguish between conformant and >> nonconformant clients. In the former case -- as when the user is >> not attempting to evade inspection -- the SNI will reflect the >> identity that the client expects and therefore will compare the >> certificate against. >> >> Of course, in the case where the client is attempting to evade >> inspection, the certificate might not match. However, in this >> scenario, the client and server are colluding and so there are >> a variety of ways to avoid inspection, even when doing TLS 1.2. >> >> For example: >> >> 1. The client and server can share a prearranged public key and then >> negotiate static RSA. The client sends an innocuous SNI and the >> server >> can simply send the certificate of the corresponding server, captured >> by connecting to that server. The client then enciphers the PMS >> under the server's prearranged key and continues with TLS as usual. >> This cannot be detected by the middlebox without decrypting the EPMS. >> >> 2. If an (EC)DHE cipher suite must be negotiated, then the attack >> described above does not work directly because the server's signature >> over the ServerKeyExchange can be validated, and of course the >> attacker server does not have the legitimate server's key. However, >> the server can forward the ClientHello to the legitimate server, >> capture the Certificate and ServerKeyExchange and the proxy those to >> the client. This looks legitimate to the inspection device and then >> the client can simply send the Encrypted PMS in the first chunk of >> data that is apparently encrypted under the server's key. >> >> For these reasons, being able to see the server's certificate >> provides >> a false sense of security, as this check is easily bypassed. > I agree we should distinguish between between conformant and > non-comformant. > > For the conformant case, I do not know to what extent we can rely > on the client always sending the SNI, but even if it is always > sent, there are still use case scenarios around certificate audit, > etc. that cannot be satisified in TLS 1.3 without becoming an > active MITM. > > > You can do certificate audit by making an independent connection and > eliciting the certificate. > Not always. The certificate audit may be for an external server you connected to (outbound scenario). Even for inbound scenarios, you would have to ensure you actually find the local servers and check their certificates, which would imply a need for continuous scanning of all of your infrastructure. I guess it's technically doable (similar to vulnerability scanners), but it's difficult on an IPv6 enabled network due to the size of the address space. > With the recently adopted proposal around SNI encryption, there > are more use cases that cannot be satisfied without becoming an > active MITM. > > > Yes, I agree with that. > > > For the non-conformant case, you bring up some good points. We can > reduce the set of bypass scenarios there, but we cannot eliminate > them. > > > I'm not persuaded that you can meaningfully reduce them. What > technical approach do you believe would do so? > Let me rephrase that: A determined attacker will be able to bypass the above mechanism, however what we see in practice today is that malware is increasingly using TLS to hide command and control traffic (not to mention that it often gets downloaded over a TLS protected session to begin with). I am not aware of specific examples of malware that try to bypass inspection using techniques as described above (nor have I looked), but it's certainly possible. There are other discrepancies that will show up though when you start looking at the actual destination reached and possibly do other analysis over the (encrypted) session. Thanks -- Flemming > -Ekr > > > > Thanks again for the feedback - we will update accordingly in the > next version of the draft. > > -- Flemming > > >> >> -Ekr >> >> >> [0] Note: the use of static DH is very rare. >> >> >> On Fri, Nov 3, 2017 at 6:49 PM, Nancy Cam-Winget (ncamwing) >> > wrote: >> >> All, >> >> @IETF99, awareness was raised to some of the security WGs >> (thanks Kathleen ☺) that TLS 1.3 will obscure visibility >> currently afforded in TLS 1.2 and asked what the implications >> would be for the security solutions today. >> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00 >> is >> an initial draft to describe some of the impacts relating to >> current network security solutions.  The goal of the draft is >> NOT to propose any solution as a few have been proposed, but >> rather to raise awareness to how current network-based >> security solutions work today and their impact on them based >> on the current TLS 1.3 specification. >> >> Regards, Nancy, Flemming and Eric >> >> >> _______________________________________________ >> 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 >> > > --------------E897D93A12C07BFB9FFA4826 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 11/7/17 12:23 PM, Eric Rescorla wrote:


On Tue, Nov 7, 2017 at 7:56 AM, Flemming Andreasen <fandreas@cisco.com> wrote:
Thank you for the feedback Ekr - please see below for responses


On 11/6/17 12:43 PM, Eric Rescorla wrote:
I took a look at this.

Without getting into the question of whether the types of middleboxes
you describe here provide a security benefit, there are several points
in the document that are either wrong or at least misleading/confusing.

- Key Synchronization
This document notes that in TLS 1.2, it is possible for a middlebox
that traffic keys match on both sides of the connection it is proxying,
but in TLS 1.3 it is not:

   There are several techniques that can be utilized.  Those techniques
   function with TLS 1.2 and earlier versions but not with TLS 1.3.

   One technique is for the middlebox to negotiate the same master
   secret with the original TLS client and server, as if the two
   endpoints handshake directly.  This is also known as "Triple
   Handshake" used by legitimate middleboxes.  [BreakTLS] describes the
   methods with RSA and DH key exchanges.  When the proxy session keys
   are the same as for a direct handshake, the middlebox is able to
   "cut-through" the two TLS proxy sessions when it finishes the
   security inspection.

   This technique is not functional with TLS 1.3 since the transcript
   hash over the handshake messages is part of the key derivation
   procedure.

First, I would note that this property of TLS 1.2 is bad, as it leads
to Unknown Key Share (UKS) attacks, which can be the basis of real
attacks on TLS 1.2 as fielded. It is for this reason that the TLS
WG published RFC 7627.

Thanks for the bringing that one up - we will make sure to include that in the next version.

Understood - it is nevertheless a change from TLS 1.2. In TLS 1.3, it's an integral part of the protocol that cannot be disabled. The TLS 1.2 extension does not share that property.

It seems like an odd complaint that we are making protection against Unknown Key Shares an integral part of the protocol
 

I understand your point. What I am saying is that there are some side effects of doing so that impacts use case scenarios that exist today. If you cannot drop out, then you have two choices:
1) Always be a MITM, which you may not want to (e.g. consider sessions with financial institutions)
2) Never be a MITM, which means you cannot do any of the network-based security use cases we have highlighted

What you really want is the ability to do it more selectively.


Finally, you note several times in the document (e.g., S 4.5), that
with key synchronization, the middlebox can perform the handshake and
then disengage from the connection. However, the cases you mention
(e.g.., detecting exploit attempts) ultimately require examining
all traffic in the connection.

 We have several different use case scenarios in there, and I agree with the observation that they cannot all be satisfied at the same time. For example, we cannot scan for malware in an encrypted stream to a financial institution that we are not allowed to decrypt. That doesn't mean either use case is invalid. Customers do both in real-life (just not at the same time).

I'm finding it a bit puzzling what you claim customers do. Specifically, you seem to be saying that customers examine the beginning of the connection and then stop. What are they scanning for and what makes them stop?

It's the handshake process, which typically governs the associated policy for the session (e.g. decrypt-and-inspect or do-not-decrypt). You will try to determine whether the session should undergo inspection at the time the ClientHello passes through the box, however sometimes, you end up making a final (and different) decision when the ServerHello is received. The decision is guided by policies configured for the middlebox which may determine it based on various criteria (e.g. category of the destination such as "Financial Services", geography, etc.)

 
- PSK and resumption
You write:

   In TLS 1.3, the above mechanism is replaced by Pre-Shared Keys (PSK),
   which can be negotiated as part of an initial handshake and then used
   in a subsequent handshake to perform resumption using the PSK.  TLS
   1.3 states that the client SHOULD include a "key_share" extension to
   enable the server to decline resumption and fall back to a full
   handshake, however it is not an absolute requirement.

   Example scenarios that are impacted by this are middleboxes that were
   not part of the initial handshake, and hence do not know the PSK.  If
   the client does not include the "key_share" extension, the middlebox
   cannot force a fallback to the full handshake.  If the middlebox
   policy requires it to inspect the session, it will have to fail the
   connection instead.

In TLS 1.3, PSKs and session resumption are basically the same and
have the same properties. While I concede that the document does
not require the client to offer key_shares, as a practical matter
it is very unlikely that a client will act in such a way that
failure to retain the PSK causes a hard failure, for two reasons:

(a) In every version of TLS, the ticket lifetime is just a hint, and
    the server can forget it at any time
    a client which does not allow a full handshake will often
    find itself unable to connect.

(b) The relevant question is not whether the client offers a key share
    extension but whether it advertises any DH groups. If the client sends
    a group but not a key share, the server can send HelloRetryRequest
    to force the client to send a key share.

For these reasons, as far as I know, every client (and at least every
browser client) should allow a full handshake even when trying to resume.

If that is indeed the case, then I would suggest changing the spec language to a MUST here instead so we can guarantee it.

I don't believe this is necessary. There are certainly reasons why you would want to do PSK w/o (EC)DHE (e.g., you are really PSK only).

Agree with the example, but is that really a resumption scenario ?


- Server Certificate Concealment
You note that in TLS 1.2 the middlebox can examine both the SNI and the
server's certificate in order to decide whether to MITM the connection,
but that in TLS 1.3, the middlebox cannot guarantee that the SNI in
uses is correct:

   In TLS 1.2, the ClientHello, ServerHello and Certificate messages are
   all sent in clear-text, however in TLS 1.3, the Certificate message
   is encrypted thereby hiding the server identity from any
   intermediary.  Note that even _if_ the SNI is provided (in cleartext)
   by the client, there is no guarantee that the actual server
   responding is the one indicated in the SNI from the client.

In this case, it's important to distinguish between conformant and
nonconformant clients. In the former case -- as when the user is
not attempting to evade inspection -- the SNI will reflect the
identity that the client expects and therefore will compare the
certificate against.

Of course, in the case where the client is attempting to evade
inspection, the certificate might not match. However, in this
scenario, the client and server are colluding and so there are
a variety of ways to avoid inspection, even when doing TLS 1.2.

For example:

1. The client and server can share a prearranged public key and then
negotiate static RSA. The client sends an innocuous SNI and the server
can simply send the certificate of the corresponding server, captured
by connecting to that server. The client then enciphers the PMS
under the server's prearranged key and continues with TLS as usual.
This cannot be detected by the middlebox without decrypting the EPMS.

2. If an (EC)DHE cipher suite must be negotiated, then the attack
described above does not work directly because the server's signature
over the ServerKeyExchange can be validated, and of course the
attacker server does not have the legitimate server's key. However,
the server can forward the ClientHello to the legitimate server,
capture the Certificate and ServerKeyExchange and the proxy those to
the client. This looks legitimate to the inspection device and then
the client can simply send the Encrypted PMS in the first chunk of
data that is apparently encrypted under the server's key.

For these reasons, being able to see the server's certificate provides
a false sense of security, as this check is easily bypassed.
I agree we should distinguish between between conformant and non-comformant.

For the conformant case, I do not know to what extent we can rely on the client always sending the SNI, but even if it is always sent, there are still use case scenarios around certificate audit, etc. that cannot be satisified in TLS 1.3 without becoming an active MITM.

You can do certificate audit by making an independent connection and eliciting the certificate.

Not always. The certificate audit may be for an external server you connected to (outbound scenario). Even for inbound scenarios, you would have to ensure you actually find the local servers and check their certificates, which would imply a need for continuous scanning of all of your infrastructure. I guess it's technically doable (similar to vulnerability scanners), but it's difficult on an IPv6 enabled network due to the size of the address space.

 
With the recently adopted proposal around SNI encryption, there are more use cases that cannot be satisfied without becoming an active MITM.  

Yes, I agree with that.


For the non-conformant case, you bring up some good points. We can reduce the set of bypass scenarios there, but we cannot eliminate them.

I'm not persuaded that you can meaningfully reduce them. What technical approach do you believe would do so?

Let me rephrase that: A determined attacker will be able to bypass the above mechanism, however what we see in practice today is that malware is increasingly using TLS to hide command and control traffic (not to mention that it often gets downloaded over a TLS protected session to begin with). I am not aware of specific examples of malware that try to bypass inspection using techniques as described above (nor have I looked), but it's certainly possible. There are other discrepancies that will show up though when you start looking at the actual destination reached and possibly do other analysis over the (encrypted) session.

Thanks

-- Flemming



-Ekr
 


Thanks again for the feedback - we will update accordingly in the next version of the draft.

-- Flemming



-Ekr


[0] Note: the use of static DH is very rare.


On Fri, Nov 3, 2017 at 6:49 PM, Nancy Cam-Winget (ncamwing) <ncamwing@cisco.com> wrote:

All,

 

@IETF99, awareness was raised to some of the security WGs (thanks Kathleen ☺) that TLS 1.3 will obscure visibility currently afforded in TLS 1.2 and asked what the implications would be for the security solutions today.  https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00 is an initial draft to describe some of the impacts relating to current network security solutions.  The goal of the draft is NOT to propose any solution as a few have been proposed, but rather to raise awareness to how current network-based security solutions work today and their impact on them based on the current TLS 1.3 specification.

 

Regards, Nancy, Flemming and Eric


_______________________________________________
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



--------------E897D93A12C07BFB9FFA4826-- From nobody Tue Nov 7 15:27:10 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA95B129B06 for ; Tue, 7 Nov 2017 15:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 10OYMjL8xmS7 for ; Tue, 7 Nov 2017 15:27:06 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 930401298A1 for ; Tue, 7 Nov 2017 15:27:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2176; q=dns/txt; s=iport; t=1510097226; x=1511306826; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=+1EZi8Zt9VwHMYGGXh5MhXG1O3woHGlE9YdhkKYtBjY=; b=Oq9YmIfUjfvbwQUgEDB89RNzjIzYeoG15xvTwUsU83DSlIDu3u1FdoUb whrJpnG9jRY6aJGd3tQu79LyW9bqNwfO9C7CknPNF2azs1AbIdH6lY4/k sD5UJw8T0MkROozmnroPoj+54MUBEHb08Mgw+5tRRzzBB0IJS2pPjSGuE o=; X-IronPort-AV: E=Sophos;i="5.44,361,1505779200"; d="scan'208";a="320747192" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Nov 2017 23:27:06 +0000 Received: from [10.118.10.19] (rtp-fandreas-2-8812.cisco.com [10.118.10.19]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id vA7NR5Or014952; Tue, 7 Nov 2017 23:27:05 GMT To: Stephen Farrell , Florian Weimer , "Nancy Cam-Winget (ncamwing)" Cc: "tls@ietf.org" References: <895D1206-28D1-43AB-8A45-11DEEC86A71D@cisco.com> <874lq868t3.fsf@mid.deneb.enyo.de> <6966da46-0f07-b518-4b6e-f2b5f599b050@cs.tcd.ie> From: Flemming Andreasen Message-ID: Date: Tue, 7 Nov 2017 18:27:56 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <6966da46-0f07-b518-4b6e-f2b5f599b050@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [TLS] network-based security solution use cases X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 23:27:09 -0000 Thanks for taking an initial look at the document Stephen - please see below for responses so far On 11/7/17 4:13 AM, Stephen Farrell wrote: > Hiya, > > On 07/11/17 02:48, Flemming Andreasen wrote: >> We didn't draw any particular line, but the use case scenarios that we >> tried to highlight are those related to overall security and regulatory >> requirements (including public sector) > I had a quick look at the draft (will try read properly en-route to > ietf-100) and I followed the reference to [1] but that only lead to a > forest of documents in which I didn't find any reference to breaking > TLS so far at least. Can you provide an explicit pointer to the > exact document on which that claim is based? For NERC, you can look under  "(CIP) Critital Infrastructure Protection". CIP-005-5 for example covers the electronic security perimeter, which has a couple of relevant requirements and associated text: http://www.nerc.com/_layouts/PrintStandard.aspx?standardnumber=CIP-005-5&title=Cyber%20Security%20-%20Electronic%20Security%20Perimeter(s)&jurisdiction=United%20States To be clear though, the document does not specifically call out breaking TLS, but it does clearly call out the need to detect malicious inbound and outbound communications by leveraging an "Electronic Access Point" (e.g. IDS/IPS) to enforce the Electronic Security Perimeter. > I'd also claim that your reference to PCI-DSS is misleading, as that > same spec also explicitly calls for there to be good key management > specifically including minimising the number of copies of keys, so > at most, one might be able to claim that PCI-DSS is ok with people > who break TLS in a nod-and-a-wink manner. But if you do have a real > quote from PCI-DSS that calls for breaking TLS then please do also > send that (it's been asked for a bunch of times without any answer > being provided so far). I will need to look more closely for such a quote - if anybody else knows of one, please chime in as well. Thanks -- Flemming > Thanks, > S. > > > [1] > https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00.html#ref-NERCCIP > From nobody Tue Nov 7 15:41:59 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572A0129B16 for ; Tue, 7 Nov 2017 15:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 NHdl3mVPPAlv for ; Tue, 7 Nov 2017 15:41:57 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49BEC129B06 for ; Tue, 7 Nov 2017 15:41:57 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vA7NbNGD007116; Tue, 7 Nov 2017 23:41:55 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=PYwKwvNlD02tjz+20fJlBWp9l1nvEX1Z/hUQx1AUkLU=; b=OLv9rIzN1PsT4eqSezgaxeklCKJBqv2sArNX0zHOx3BBsX+xx0lUkr4nd0x8dJil3AeE p+8MBSMQAQrixAKSrDAmIAfEWL5cSlnGZMpoxjuDgJblCK+f2du1/706sK0iCLjy8hnw uPxonCV51wzEH/QRaQjbJo27+R5BIGco0ESFmILK5yUM8y1J+rWBMRwknVaYcfOK2ODD LHAnmEvfkZIwGJfomYaH39jvym5uMTWURHZ3Qjeip7gzwhOlcWEgJY9vmgYP0zvKOPwT Wmo+Xamx4aRfcZA2RVPJz2lLY1EMmK3SAnfBP7Z/xAFv0cdStlUtJBCbG6LzdrLQ2SIc 1w== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050093.ppops.net-00190b01. with ESMTP id 2e15pr5adn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Nov 2017 23:41:54 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vA7Neak8021853; Tue, 7 Nov 2017 18:41:53 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2e18vubbhj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 07 Nov 2017 18:41:53 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 7 Nov 2017 18:41:52 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 7 Nov 2017 18:41:52 -0500 From: "Salz, Rich" To: Martin Thomson CC: Hubert Kario , Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] PR#1091: Changes to provide middlebox robustness Thread-Index: AQHTVyvYee7TW4xp9E6OP50HN76KZ6MJYqeAgAAba4CAAA8EgIAAJQeAgAAbmgCAABu7gA== Date: Tue, 7 Nov 2017 23:41:51 +0000 Message-ID: References: <4406543.RZChgRkkf9@pintsize.usersys.redhat.com> <6818962.9GzJR6rN5C@pintsize.usersys.redhat.com> <965B995B-A5B3-4322-B13A-A2D82AFD2743@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.42.204] Content-Type: text/plain; charset="utf-8" Content-ID: <455C799C1701074187D3756A26363155@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-07_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711070310 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-07_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711070309 Archived-At: Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 23:41:58 -0000 4p6iIEdpdmVuIHRoYXQgd2UncmUgYWxtb3N0IHRoZXJlLCBhbmQgdGhhdCBvbmx5IHJlYWxseSBi cm93c2VycyBhcmUNCiAgICBhc2tpbmcgZm9yIHRoZXNlIGhhY2tzLCBhbmQgdGhhdCBldmVuIHNv bWUgb2YgdGhvc2Ugd2VyZSBhbG1vc3QgcmVhZHkNCiAgICB0byBzaGlwIHdpdGhvdXQgdGhlc2Ug aGFja3MsIEkgZG9uJ3QgdGhpbmsgdGhhdCB0aGlzIGlzIGVudGlyZWx5DQogICAgdW5yZWFsaXN0 aWMgYXMgYW4gYXNwaXJhdGlvbi4NCiAgICANClRoZSBJbnRlcm5ldCBpcyBtb3JlIHRoYW4ganVz dCBhIGNvdXBsZSBvZiBicm93c2VyIGV4ZWN1dGFibGVzLg0KDQpEb2VzIG5vYm9keSB0aGluayBv ZiB0aGUgc2VydmVycz8NCg0K From nobody Tue Nov 7 15:47:14 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8F212957C for ; Tue, 7 Nov 2017 15:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.875 X-Spam-Level: X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com 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 tCRfdO58NKO9 for ; Tue, 7 Nov 2017 15:47:11 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-oln040092001097.outbound.protection.outlook.com [40.92.1.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8DD1129B50 for ; Tue, 7 Nov 2017 15:47:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JF4Lt2TMkQZU8D4h+4+RuvMKu6fO+V4x2/kdmp70zu4=; b=ffk9NYnX4uzm2VPRqfJn1+ZiQAn9rTau8Os/BVfVxw/MO+D1pKLRomNH+peBAiELdDO7mjBXd7wTU3MoUKXRs+9TG/VtViQDisKcZ8BUCBpB1v0A9IqA8sn7eB5NaCVdQvcDiZWXsFIzUU5ZdAzbgZ4rTQGezMYADD+hpA0ThpTXuPQGJyevx0Ectt/qo/NRj0SMvbevbAkaqqM234MYF+cfbJiWz1SanbyuQb1hMf8wVuPd8HHhLUHdILAEuw6wqtsD1ROimc7BvKlt6GxWULedokDDL2sHT6s17g4gHZwCN3BAtUaxMZne0dPF2fBtxzznUZKmlwFESxhW8vZY+Q== Received: from BY2NAM01FT005.eop-nam01.prod.protection.outlook.com (10.152.68.56) by BY2NAM01HT217.eop-nam01.prod.protection.outlook.com (10.152.69.0) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.178.5; Tue, 7 Nov 2017 23:47:05 +0000 Received: from MWHPR1801MB2061.namprd18.prod.outlook.com (10.152.68.56) by BY2NAM01FT005.mail.protection.outlook.com (10.152.68.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.197.9 via Frontend Transport; Tue, 7 Nov 2017 23:47:05 +0000 Received: from MWHPR1801MB2061.namprd18.prod.outlook.com ([10.164.205.38]) by MWHPR1801MB2061.namprd18.prod.outlook.com ([10.164.205.38]) with mapi id 15.20.0197.020; Tue, 7 Nov 2017 23:47:05 +0000 From: Yuhong Bao To: Martin Thomson , "Salz, Rich" CC: "tls@ietf.org" Thread-Topic: [TLS] PR#1091: Changes to provide middlebox robustness Thread-Index: AQHTVyvb2MH+ZKktR0KvrQ+TnVw5FaMJDtaAgAAba4CAAA8DgIAAJQeAgAAbmgCAABztDw== Date: Tue, 7 Nov 2017 23:47:05 +0000 Message-ID: References: <4406543.RZChgRkkf9@pintsize.usersys.redhat.com> <6818962.9GzJR6rN5C@pintsize.usersys.redhat.com> <965B995B-A5B3-4322-B13A-A2D82AFD2743@akamai.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:A7E63628819D8043403D7AAC580FC49EAEAC5433C4BD66FC05CDC614C23815B3; UpperCasedChecksum:942F4CFA0F87F41C33930479EB8FD94F53AB13333130AB12DD12ACF40387A283; SizeAsReceived:7594; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [ZQeuIBud6cmZQAjhPlM1ZXgQWsP7jN30sy8i8mRzz7eJaVee4irWTJ0bHX/edsFs] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2NAM01HT217; 6:5qYqNd2k6rnd5RowGf4v6A+Qiq5FyHMDQ327quolNWAmBB6HSCjsuTE5GeMBDM0jOKC/8urCV3iSI5Z+j1spzWhJK/2/Xkuhq8ggR1KdzAZI9aBo7ufIZWj6UCKOeETFWDnF7ZetJENmmxmYeSJjuEZskiLYE1A0ELFq9AZY+Z+ndFQJLugtslUbbzljqaQuHgQ3NuFJvDgBsjDici8qr6i6AsoGDgZXaxSlw4jwu9p6RKqJO6df5xG2eQKFuJ1/8+2iX5RhuEuJ0AswOGSb0O96peVr/XrzM9BgJBMnWAQwuvWRE0vqVWBcBoya0YXzcV4tYLFMhYWMk5hLVHB/xE3/5VmC6hqGAcfY9Qq9rUM=; 5:gq8jrYy4AZTMQ2Wvyhchb7GJ5Itmv9OVDcE71F36yjHRmt9AtMaBCsrp4244T4cpzFPXTParAA98Y6l6xlPYL/sV2/CdcT6f7fm0HkpIgWRDdysTREbQz4pGXHHDfM+tepCYW41jZqsIzzeYZhJyCJEvx+ZYW0Vye5T1IqVPf2g=; 24:45RYTEG/E2AO2RKHN8HZsS74vzXLdmNz8lHSs1bqz4kYh0oTQjAC9aLlc3M3LtxxAsRi6Hk3RckTnR3aRQsryMIaHTULHP8Qm3kfgXRuzBk=; 7:hnlsrA/yK8dApQe229md2vZMC5muHImlZm9/pglQuiIRVV9yWPqPii4zLA8ij9iY9b9qXaA9e17bQ7HtWKOiE5MU/JHze4lWjT9Mio6F2lvlXdufDpWTOMWQb0MLddBOCKYw380WrHuIGSyjWwk+TGsiU7x1y1n2QLigfay6/wZ0S7pcXu0zchkI20C350aE3ZawlRAK+DWU4kdETnQWj8Ni9VFKbukDqoyrWHpJBPTkrClGcJqzbEs7E9+jod+e x-incomingheadercount: 47 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 6bc5a5ec-6c21-4f71-7977-08d52639da23 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:BY2NAM01HT217; x-ms-traffictypediagnostic: BY2NAM01HT217: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:BY2NAM01HT217; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY2NAM01HT217; x-forefront-prvs: 0484063412 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:BY2NAM01HT217; H:MWHPR1801MB2061.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6bc5a5ec-6c21-4f71-7977-08d52639da23 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2017 23:47:05.7073 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2NAM01HT217 Archived-At: Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 23:47:13 -0000 My favorite of course is introducing another version field in the ServerHel= lo. The same problem may repeat with future middleboxes. ________________________________________ From: TLS on behalf of Martin Thomson Sent: Tuesday, November 7, 2017 2:02:36 PM To: Salz, Rich Cc: tls@ietf.org Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness On Wed, Nov 8, 2017 at 7:23 AM, Salz, Rich wrote: > =93We can remove it when middleboxes aren=92t a problem.=94 Talk about a= spirational ( Given that we're almost there, and that only really browsers are asking for these hacks, and that even some of those were almost ready to ship without these hacks, I don't think that this is entirely unrealistic as an aspiration. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Tue Nov 7 15:54:03 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74DE3127AD4 for ; Tue, 7 Nov 2017 15:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 Tzpei2McGK2V for ; Tue, 7 Nov 2017 15:53:58 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46BF912944C for ; Tue, 7 Nov 2017 15:53:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4452; q=dns/txt; s=iport; t=1510098838; x=1511308438; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bNqwKpiI93sVPfDne/+OfO5FpPt2RbBZSgT/icwGpKc=; b=ZOGGab8fykLFH4WNsAEmcbV93khRv0BmLBN8eC0GKwsbN70NR2YVhmrb a8Iyd46YUO1HCzB8cz+2brmn/172FewuOi8WaCtOUoCNCs26e349vvR39 gMV+XotDQBM6rE4Ea+qB+Fb1/DU92WEajGB6FdRNOIOGlM2+SmAOJzpLj c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CRAQDvRgJa/4cNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM0ZG4nB4N2m0GWSYIRCh6FHQIahF1AFwEBAQEBAQEBAWsohR4?= =?us-ascii?q?BAQEBAQEBIxFFEAIBCBgCAiYCAgIwFRACBAENBRuKAAgQqSqCJ4sZAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBHYEPgiGCB4M9KYMBg0KBHzQXgn4xgjIFohYCh2SNF4I?= =?us-ascii?q?VhgSEBIcbjGeJDAIRGQGBOAEhAzOBcXoVH1cBgjYJglMcgWd3AYsngREBAQE?= X-IronPort-AV: E=Sophos;i="5.44,361,1505779200"; d="scan'208";a="28197515" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Nov 2017 23:53:57 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vA7NrvhI026048 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Nov 2017 23:53:57 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 7 Nov 2017 18:53:56 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Tue, 7 Nov 2017 18:53:56 -0500 From: "Nancy Cam-Winget (ncamwing)" To: "Flemming Andreasen (fandreas)" , Stephen Farrell , Florian Weimer CC: "tls@ietf.org" Thread-Topic: [TLS] network-based security solution use cases Thread-Index: AQHTVQ82KKjKBkAk5kyjDwLCBqb5H6MF7FPMgAKjMwCAAGt7gIAA7sYA//+BIwA= Date: Tue, 7 Nov 2017 23:53:56 +0000 Message-ID: <8448A3AF-CEAF-41F4-A43F-9ED7B209C7B9@cisco.com> References: <895D1206-28D1-43AB-8A45-11DEEC86A71D@cisco.com> <874lq868t3.fsf@mid.deneb.enyo.de> <6966da46-0f07-b518-4b6e-f2b5f599b050@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1a.0.160910 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.155.71.77] Content-Type: text/plain; charset="utf-8" Content-ID: <6328D5F5EE573D40955C977B4A5DC14C@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] network-based security solution use cases X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 23:54:01 -0000 SGkgU3RlcGhlbiwNCkFkZGluZyB0byBGbGVtbWluZ+KAmXMgY29tbWVudCwgIGZpbmRpbmcg4oCc ZXhhY3QgcXVvdGVz4oCdIHdpbGwgYmUgZGlmZmljdWx0IGFzIHRoZWlyIGludGVudCBpcyByZWFs bHkgbm90IHRvIGJyZWFrIHRoaW5ncyBidXQgcmF0aGVyIHdhbnQgdG8gZW5zdXJlIHRoYXQgaW5z cGVjdGlvbiBhbmQgb3ZlcnNpZ2h0IGlzIGF2YWlsYWJsZSB0byBhZmZlY3QgZ3VhcmRzL3Byb3Rl Y3Rpb25zIHdpdGhpbiBhbiAoZW50ZXJwcmlzZS9kYXRhIGNlbnRlcikgaW5mcmFzdHJ1Y3R1cmUu ICAgVGhhdCBzYWlkLCBQQ0kgYW5kIG90aGVyIHJlZ3VsYXRpb25zIHdpbGwgaGF2ZSBhIGxvdCBv ZiBkb2N1bWVudHMgdGhhdCBvbmUgaGFzIHRvIGdvIHRocm91Z2jigKYub25lIHRoYXQga2luZC1v ZiBjYWxscyBleHBsaWNpdGx5IHRvIHRoZSB1c2Ugb2YgcGFja2V0IGluc3BlY3Rpb24sIGZpcmV3 YWxsaW5nIGFuZCBzdWNoIGlzIGluOg0KDQpodHRwczovL3d3dy5wY2lzZWN1cml0eXN0YW5kYXJk cy5vcmcvZG9jdW1lbnRzL1NBUV9EX3YzX01lcmNoYW50LnBkZg0KDQpJdCBpcyBhbiBhc3Nlc3Nt ZW50IHF1ZXN0aW9ubmFpcmUgZm9yIHZlbmRvcnMgdG8gZXZhbHVhdGUgdGhlaXIgY29tcGxpYW5j ZSwgdGhlIHJlcXVpcmVtZW50cyBzcGVhayB0byBzZWN1cmluZyB0aGUgbmV0d29yayBhbmQgc3lz dGVtcyBpbmNsdWRpbmcgZmlyZXdhbGxzLCBETVpzIGFuZCB0aGUgYWJpbGl0eSB0byBkbyBwYWNr ZXQgaW5zcGVjdGlvbi4NCg0KVGhhbmtzLCBOYW5jeSANCg0KT24gMTEvNy8xNywgMzoyNyBQTSwg IkZsZW1taW5nIEFuZHJlYXNlbiAoZmFuZHJlYXMpIiA8ZmFuZHJlYXNAY2lzY28uY29tPiB3cm90 ZToNCg0KICAgIFRoYW5rcyBmb3IgdGFraW5nIGFuIGluaXRpYWwgbG9vayBhdCB0aGUgZG9jdW1l bnQgU3RlcGhlbiAtIHBsZWFzZSBzZWUgDQogICAgYmVsb3cgZm9yIHJlc3BvbnNlcyBzbyBmYXIN CiAgICANCiAgICBPbiAxMS83LzE3IDQ6MTMgQU0sIFN0ZXBoZW4gRmFycmVsbCB3cm90ZToNCiAg ICA+IEhpeWEsDQogICAgPg0KICAgID4gT24gMDcvMTEvMTcgMDI6NDgsIEZsZW1taW5nIEFuZHJl YXNlbiB3cm90ZToNCiAgICA+PiBXZSBkaWRuJ3QgZHJhdyBhbnkgcGFydGljdWxhciBsaW5lLCBi dXQgdGhlIHVzZSBjYXNlIHNjZW5hcmlvcyB0aGF0IHdlDQogICAgPj4gdHJpZWQgdG8gaGlnaGxp Z2h0IGFyZSB0aG9zZSByZWxhdGVkIHRvIG92ZXJhbGwgc2VjdXJpdHkgYW5kIHJlZ3VsYXRvcnkN CiAgICA+PiByZXF1aXJlbWVudHMgKGluY2x1ZGluZyBwdWJsaWMgc2VjdG9yKQ0KICAgID4gSSBo YWQgYSBxdWljayBsb29rIGF0IHRoZSBkcmFmdCAod2lsbCB0cnkgcmVhZCBwcm9wZXJseSBlbi1y b3V0ZSB0bw0KICAgID4gaWV0Zi0xMDApIGFuZCBJIGZvbGxvd2VkIHRoZSByZWZlcmVuY2UgdG8g WzFdIGJ1dCB0aGF0IG9ubHkgbGVhZCB0byBhDQogICAgPiBmb3Jlc3Qgb2YgZG9jdW1lbnRzIGlu IHdoaWNoIEkgZGlkbid0IGZpbmQgYW55IHJlZmVyZW5jZSB0byBicmVha2luZw0KICAgID4gVExT IHNvIGZhciBhdCBsZWFzdC4gQ2FuIHlvdSBwcm92aWRlIGFuIGV4cGxpY2l0IHBvaW50ZXIgdG8g dGhlDQogICAgPiBleGFjdCBkb2N1bWVudCBvbiB3aGljaCB0aGF0IGNsYWltIGlzIGJhc2VkPw0K ICAgIEZvciBORVJDLCB5b3UgY2FuIGxvb2sgdW5kZXIgICIoQ0lQKSBDcml0aXRhbCBJbmZyYXN0 cnVjdHVyZSANCiAgICBQcm90ZWN0aW9uIi4gQ0lQLTAwNS01IGZvciBleGFtcGxlIGNvdmVycyB0 aGUgZWxlY3Ryb25pYyBzZWN1cml0eSANCiAgICBwZXJpbWV0ZXIsIHdoaWNoIGhhcyBhIGNvdXBs ZSBvZiByZWxldmFudCByZXF1aXJlbWVudHMgYW5kIGFzc29jaWF0ZWQgdGV4dDoNCiAgICANCiAg ICBodHRwOi8vd3d3Lm5lcmMuY29tL19sYXlvdXRzL1ByaW50U3RhbmRhcmQuYXNweD9zdGFuZGFy ZG51bWJlcj1DSVAtMDA1LTUmdGl0bGU9Q3liZXIlMjBTZWN1cml0eSUyMC0lMjBFbGVjdHJvbmlj JTIwU2VjdXJpdHklMjBQZXJpbWV0ZXIocykmanVyaXNkaWN0aW9uPVVuaXRlZCUyMFN0YXRlcyAN CiAgICANCiAgICANCiAgICBUbyBiZSBjbGVhciB0aG91Z2gsIHRoZSBkb2N1bWVudCBkb2VzIG5v dCBzcGVjaWZpY2FsbHkgY2FsbCBvdXQgYnJlYWtpbmcgDQogICAgVExTLCBidXQgaXQgZG9lcyBj bGVhcmx5IGNhbGwgb3V0IHRoZSBuZWVkIHRvIGRldGVjdCBtYWxpY2lvdXMgaW5ib3VuZCANCiAg ICBhbmQgb3V0Ym91bmQgY29tbXVuaWNhdGlvbnMgYnkgbGV2ZXJhZ2luZyBhbiAiRWxlY3Ryb25p YyBBY2Nlc3MgUG9pbnQiIA0KICAgIChlLmcuIElEUy9JUFMpIHRvIGVuZm9yY2UgdGhlIEVsZWN0 cm9uaWMgU2VjdXJpdHkgUGVyaW1ldGVyLg0KICAgID4gSSdkIGFsc28gY2xhaW0gdGhhdCB5b3Vy IHJlZmVyZW5jZSB0byBQQ0ktRFNTIGlzIG1pc2xlYWRpbmcsIGFzIHRoYXQNCiAgICA+IHNhbWUg c3BlYyBhbHNvIGV4cGxpY2l0bHkgY2FsbHMgZm9yIHRoZXJlIHRvIGJlIGdvb2Qga2V5IG1hbmFn ZW1lbnQNCiAgICA+IHNwZWNpZmljYWxseSBpbmNsdWRpbmcgbWluaW1pc2luZyB0aGUgbnVtYmVy IG9mIGNvcGllcyBvZiBrZXlzLCBzbw0KICAgID4gYXQgbW9zdCwgb25lIG1pZ2h0IGJlIGFibGUg dG8gY2xhaW0gdGhhdCBQQ0ktRFNTIGlzIG9rIHdpdGggcGVvcGxlDQogICAgPiB3aG8gYnJlYWsg VExTIGluIGEgbm9kLWFuZC1hLXdpbmsgbWFubmVyLiBCdXQgaWYgeW91IGRvIGhhdmUgYSByZWFs DQogICAgPiBxdW90ZSBmcm9tIFBDSS1EU1MgdGhhdCBjYWxscyBmb3IgYnJlYWtpbmcgVExTIHRo ZW4gcGxlYXNlIGRvIGFsc28NCiAgICA+IHNlbmQgdGhhdCAoaXQncyBiZWVuIGFza2VkIGZvciBh IGJ1bmNoIG9mIHRpbWVzIHdpdGhvdXQgYW55IGFuc3dlcg0KICAgID4gYmVpbmcgcHJvdmlkZWQg c28gZmFyKS4NCiAgICANCiAgICBJIHdpbGwgbmVlZCB0byBsb29rIG1vcmUgY2xvc2VseSBmb3Ig c3VjaCBhIHF1b3RlIC0gaWYgYW55Ym9keSBlbHNlIA0KICAgIGtub3dzIG9mIG9uZSwgcGxlYXNl IGNoaW1lIGluIGFzIHdlbGwuDQogICAgDQogICAgVGhhbmtzDQogICAgDQogICAgLS0gRmxlbW1p bmcNCiAgICANCiAgICANCiAgICA+IFRoYW5rcywNCiAgICA+IFMuDQogICAgPg0KICAgID4NCiAg ICA+IFsxXQ0KICAgID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNhbXdpbmdl dC10bHMtdXNlLWNhc2VzLTAwLmh0bWwjcmVmLU5FUkNDSVANCiAgICA+DQogICAgDQogICAgDQoN Cg== From nobody Tue Nov 7 15:57:53 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D337D129BCA for ; Tue, 7 Nov 2017 15:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 0fXWYdkoZoCZ for ; Tue, 7 Nov 2017 15:57:50 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 65BDB129BCC for ; Tue, 7 Nov 2017 15:57:50 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id y75so899228ywg.0 for ; Tue, 07 Nov 2017 15:57:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Vj/vqPSmGEf9LSWpJNuA3+99souGP+H7ovhrPuBw7+Q=; b=VO7SkVND/wQKmutPzVDXRKkkyrEQ4sI4cVSuY1+uQjjeKCgHngzKVPwJc4PkzhZ1wn qL7WxRPGu9p/8WR/lGj9yS4Kjo4n3u9T5fjs9qyPK0iJ9M96mNyCtmlw4u51rbwQXSjn GJn4SxxfGfP8SJvNrQrQfAOyzZI9XshoYlZC2gxGIHED8Vzl2qRRKNyiU0UXROs+YXiW fLo2OWk0PAaKkOagVxyrHvuoJPsRsR8A4nudr3Yw/nUcz0YeE4xh+18kVyGyErZlztI9 TtYXEKoLBRY0T15aXNcuG8AKjeecvYsP+UC79xn5azQJz7tX7IYleGyIX5EzBowMTk+k E9iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Vj/vqPSmGEf9LSWpJNuA3+99souGP+H7ovhrPuBw7+Q=; b=aljp/WPYOkdqt3ztkqUst4VjoGnmkB7gut4utj4VUgcdHy+m//qyuUR7ZcNu1zM5UJ c2d02iFjn2LUVyHrQnjB2F96mtlsx7gDW9E0dNDQLcjGhZEnZz0fRg7iZI8V/WXyTBYG 93zFBmqG5NTsqICR3aZ9XQScSi2c/SIXY8NVbLQRCb1fULbgfeySpq3alLq09PVHtZKc r6BujrTPppBlcnb81xALAb42EjuOkfBasKXc3pSMd3HL8hr8ThilxIsM0uT0G4BFwNJy c0o3Uj8GkPE8je5W/8doc3fo/A3EBd1vhsJG4g9i1FKu2ElspE24bguloGvCuJORm/FY iLEA== X-Gm-Message-State: AJaThX5FFVfc3l+VAbwOI1HjN45SbODfo843RCMt8QhfmqSkCa4K/rrl 2IFm+W7Vg1tkVp1zJkKEWG3LPojUCNpFJ6IzjmXdwA== X-Google-Smtp-Source: ABhQp+TqC1KcuGWxVYSFaeGT/odn2Bxce2akdl4s3Y1RwkotX0f7WH0Fw1oLeyF8yawCUvc1oJtL1VUE1gV52TgqMLE= X-Received: by 10.37.188.18 with SMTP id i18mr255802ybh.419.1510099069710; Tue, 07 Nov 2017 15:57:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.61.12 with HTTP; Tue, 7 Nov 2017 15:57:08 -0800 (PST) In-Reply-To: References: <4406543.RZChgRkkf9@pintsize.usersys.redhat.com> <6818962.9GzJR6rN5C@pintsize.usersys.redhat.com> <965B995B-A5B3-4322-B13A-A2D82AFD2743@akamai.com> From: Eric Rescorla Date: Tue, 7 Nov 2017 15:57:08 -0800 Message-ID: To: "Salz, Rich" Cc: Martin Thomson , Hubert Kario , "tls@ietf.org" Content-Type: multipart/alternative; boundary="089e08247eb4a04a4d055d6d5653" Archived-At: Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 23:57:52 -0000 --089e08247eb4a04a4d055d6d5653 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 7, 2017 at 3:41 PM, Salz, Rich wrote: > =E2=9E=A2 Given that we're almost there, and that only really browsers ar= e > asking for these hacks, and that even some of those were almost ready > to ship without these hacks, I don't think that this is entirely > unrealistic as an aspiration. > > The Internet is more than just a couple of browser executables. > > Does nobody think of the servers? > I do, but I don't really see how they're relevant for this question. Don't the servers control the middleboxes they are behind? -Ekr --089e08247eb4a04a4d055d6d5653 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Nov 7, 2017 at 3:41 PM, Salz, Rich <rsalz@akamai.com> wrote:
=E2=9E=A2 Given that we'r= e almost there, and that only really browsers are
=C2=A0 =C2=A0 asking for these hacks, and that even some o= f those were almost ready
=C2=A0 =C2=A0 to ship without these hacks, I don't think that this is e= ntirely
=C2=A0 =C2=A0 unrealistic as an aspiration.

The Internet is more than just a couple of browser executables.

Does nobody think of the servers?

I do,= but I don't really see how they're relevant for this question. Don= 't the servers control the middleboxes they are behind?

<= /div>
-Ekr


--089e08247eb4a04a4d055d6d5653-- From nobody Tue Nov 7 16:01:40 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCFA129BCA for ; Tue, 7 Nov 2017 16:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 RCGWPSOFjAem for ; Tue, 7 Nov 2017 16:01:36 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1200129B74 for ; Tue, 7 Nov 2017 16:01:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 098FFBE39; Wed, 8 Nov 2017 00:01:34 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4ashdpkmYPf; Wed, 8 Nov 2017 00:01:31 +0000 (GMT) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7FDC5BE38; Wed, 8 Nov 2017 00:01:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1510099291; bh=8fAl7R0JfVLdTPORTwlCW4qWb/tpeIhhkO/md/llAVY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=LxQ/E9Cp6+QzeO4sQI/JHdzOk4uZ7jGKlbtDnjXbby3zXmBMrk0zcGTYgQzLSxd/3 xf7Ls8z68UZMhtnCmLNyJFbH5DHcAE9HGCXpTnP41HjbJBHWRJ//QXfnhHoEiUAP6A 5httKI+PCYH+wn7nPBmYDPsCtBAo7U6VnAD3t43g= To: Flemming Andreasen , Florian Weimer , "Nancy Cam-Winget (ncamwing)" Cc: "tls@ietf.org" References: <895D1206-28D1-43AB-8A45-11DEEC86A71D@cisco.com> <874lq868t3.fsf@mid.deneb.enyo.de> <6966da46-0f07-b518-4b6e-f2b5f599b050@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Wed, 8 Nov 2017 00:01:30 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4rmcX1MfiidtAt4c8pnDc0JBECDAtMO6N" Archived-At: Subject: Re: [TLS] network-based security solution use cases X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 00:01:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4rmcX1MfiidtAt4c8pnDc0JBECDAtMO6N Content-Type: multipart/mixed; boundary="2jA2Fk00mlGcjUL4UpXR7EEAol41TFe4m"; protected-headers="v1" From: Stephen Farrell To: Flemming Andreasen , Florian Weimer , "Nancy Cam-Winget (ncamwing)" Cc: "tls@ietf.org" Message-ID: Subject: Re: [TLS] network-based security solution use cases References: <895D1206-28D1-43AB-8A45-11DEEC86A71D@cisco.com> <874lq868t3.fsf@mid.deneb.enyo.de> <6966da46-0f07-b518-4b6e-f2b5f599b050@cs.tcd.ie> In-Reply-To: --2jA2Fk00mlGcjUL4UpXR7EEAol41TFe4m Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 07/11/17 23:27, Flemming Andreasen wrote: > Thanks for taking an initial look at the document Stephen - please see > below for responses so far >=20 > On 11/7/17 4:13 AM, Stephen Farrell wrote: >> Hiya, >> >> On 07/11/17 02:48, Flemming Andreasen wrote: >>> We didn't draw any particular line, but the use case scenarios that w= e >>> tried to highlight are those related to overall security and regulato= ry >>> requirements (including public sector) >> I had a quick look at the draft (will try read properly en-route to >> ietf-100) and I followed the reference to [1] but that only lead to a >> forest of documents in which I didn't find any reference to breaking >> TLS so far at least. Can you provide an explicit pointer to the >> exact document on which that claim is based? > For NERC, you can look under=C2=A0 "(CIP) Critital Infrastructure > Protection". CIP-005-5 for example covers the electronic security > perimeter, which has a couple of relevant requirements and associated t= ext: >=20 > http://www.nerc.com/_layouts/PrintStandard.aspx?standardnumber=3DCIP-00= 5-5&title=3DCyber%20Security%20-%20Electronic%20Security%20Perimeter(s)&j= urisdiction=3DUnited%20States >=20 Thanks for that. So I didn't see any mention of TLS in that document at all. >=20 > To be clear though, the document does not specifically call out breakin= g > TLS, but it does clearly call out the need to detect malicious inbound For inbound (on page 9) I see it mentions IDSes and application layer firewalls as examples yes. Given that the latter would not require any messing with TLS at all, this seems to be a very clear example of a regulation not requiring breaking TLS. That'd mean there is no regulatory requirement at all wouldn't it? But again, if there are real regulatory requirements there that really do call for MitM attacks on TLS I'd be glad to look at them if you want to quote them. > and outbound communications by leveraging an "Electronic Access Point" > (e.g. IDS/IPS) to enforce the Electronic Security Perimeter. Personally, I have to say I find the outbound stuff nonsense. I know people make money selling product and services for that. >> I'd also claim that your reference to PCI-DSS is misleading, as that >> same spec also explicitly calls for there to be good key management >> specifically including minimising the number of copies of keys, so >> at most, one might be able to claim that PCI-DSS is ok with people >> who break TLS in a nod-and-a-wink manner. But if you do have a real >> quote from PCI-DSS that calls for breaking TLS then please do also >> send that (it's been asked for a bunch of times without any answer >> being provided so far). >=20 > I will need to look more closely for such a quote - if anybody else > knows of one, please chime in as well. It's been asked for a number of times without any substantive response. I would assume that one of the authors of this would be able to point at the text that caused you to add in a mention of PCI-DSS. If not, that seems odd. I actually looked through the PCI spec myself and found that it is fairly explicitly asking for good crypto and not bad crypto. (E.g. as mentioned, saying to minimise the number of copies of keys that are anywhere.) Maybe the ADs ought liaise to some of those organisations and ask them if they do or do not recognise the claims related to breaking TLS being attributed to them? Or even better, maybe just not making those claims would be easier all around and more accurate. S. >=20 > Thanks >=20 > -- Flemming >=20 >=20 >> Thanks, >> S. >> >> >> [1] >> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00.html#ref-= NERCCIP >> >> >=20 >=20 --2jA2Fk00mlGcjUL4UpXR7EEAol41TFe4m-- --4rmcX1MfiidtAt4c8pnDc0JBECDAtMO6N Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaAklaAAoJEC88hzaAX42iyBAIALhPV0lVrssL27Fa2O9EwJ90 W02Ao/lHKhBOgL81Mli7oP2KebMl30CmAC1JnYGgIN7TPH08cT8p8pGYGEu0fgsE F12QqitFXd+uszv6RDjBM2PRRSm70yV0vgRteRxal8vxhYb0zD8ifC7SPRJvkO3+ zhZXzcHxwiYdfzzj5LajVwpiqE6eLCmJDQhwj5bHz1di4SNH3utZEh7SOkEuA0Gg RsRowzMBqbHilRK4aa0hyJOsf4QljVYuf4WgKmV93f6HBHBveIC+HVEEUyvfeHjv Lw8f1FE5pEX9u5R1On1aJKSSREDXNUIvsHnl4a6VkSyS5f7/ROvv+6n0ODPPvyM= =QYlx -----END PGP SIGNATURE----- --4rmcX1MfiidtAt4c8pnDc0JBECDAtMO6N-- From nobody Tue Nov 7 16:06:07 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81C8A129B1E for ; Tue, 7 Nov 2017 16:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 rJpjXGiZ6dSb for ; Tue, 7 Nov 2017 16:06:01 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 0F6F3129B16 for ; Tue, 7 Nov 2017 16:06:00 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id i198so896632ywe.7 for ; Tue, 07 Nov 2017 16:06:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NFr2NQDYnNB38i/cWe9/kntTayaT9Eoc7AeS1UvS+tU=; b=QUmBTwhfK8Y0iDmnAOj02yvCs8Rh4GN9RSsh42GPtlhhPM7szpiQjGdf8Mnqa/S7to DtBQ8J8ufTZFSr3NrxIDAp8IjltNIr+VWwqCAz12oP5zGBrffa9TpKR5BkTB4DfnxxkW 19uwaiyrmvXO6rcBa3O3Hq7eVUV7R9ew8g0E5fnTVOiD4+QIMUqCxyDjqKXHVcP+Fmzb fSaE3GN2ZSbfWDAxmOU2NYMszq7LIUBftXNVbUmXM1f50rctaMmeRG8uW6+FkihErU7w 7sbIj8eWe0E+rq+05GkdZnq+HusyUEkgo58gUDBwDfnqFOk+HGk1ifFw4ZLyibdHzTSA BkTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NFr2NQDYnNB38i/cWe9/kntTayaT9Eoc7AeS1UvS+tU=; b=bCILwv2F4+yZMFYMANQwZgUOZpIsJjbhFQ8v3fpJnNh3/RJKuSKvR+ksH68jZEZIU8 bDyeFx7yIvvlrplevOGfU9oFJ4GT9hdsUgV+H8ZVI2pZ9I5YQTEKLqcgi+elfEPSiZzI C5efMwwH33giIMBjDySXS3szZ0TpYDWZhUaT4qAptr8gvALkYVPTyI44K7Ym9vXRpJ7Z paA3/EXgCcoyHbGTLVLzzdN5BNxhXyA6/xa4tJxNbgRuphiqFgRwRsnSHKPGwCkKHwe5 Q5FWZdAAJicdGTal3wGK7WMjRKgPnWIo+2zdjhfJMO5xLGZ236A8MLgTcfYlOr6Cl7Ut lWYw== X-Gm-Message-State: AJaThX6hqnt7cbhQtzXD5Ar/yPa/2JTcZyu5+ZkYiopgMD9GCqjgc8c/ D7LLnZI3BE2jmUx8Pw7VzG+y0bLQbe2Qwh5lvWLPGw== X-Google-Smtp-Source: ABhQp+Tj5ZPO8JNjRD/72lcJNSxEK5ivxghbGyE5pXOxRlx5G1MAZZn+PQ/gO6fNYVbWV2XG32vuQNjnZpLNtC2R9es= X-Received: by 10.37.132.73 with SMTP id r9mr270457ybm.323.1510099559650; Tue, 07 Nov 2017 16:05:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.70.5 with HTTP; Tue, 7 Nov 2017 16:05:58 -0800 (PST) In-Reply-To: References: <4406543.RZChgRkkf9@pintsize.usersys.redhat.com> <6818962.9GzJR6rN5C@pintsize.usersys.redhat.com> <965B995B-A5B3-4322-B13A-A2D82AFD2743@akamai.com> From: Jana Iyengar Date: Tue, 7 Nov 2017 16:05:58 -0800 Message-ID: To: Eric Rescorla Cc: "Salz, Rich" , "tls@ietf.org" Content-Type: multipart/alternative; boundary="089e0826fee4d4f5bf055d6d736f" Archived-At: Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 00:06:06 -0000 --089e0826fee4d4f5bf055d6d736f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FWIW: In my experience middleboxes don't ossify based on what the spec says, they ossify based on what they see on the wire. So, if common implementations send CCS in a particular way, that's what will get --- and, I'll argue, what has gotten --- ossified. I also agree with David and Eric that compatibility mode shouldn't be required because QUIC doesn't need it. On Tue, Nov 7, 2017 at 3:57 PM, Eric Rescorla wrote: > > > On Tue, Nov 7, 2017 at 3:41 PM, Salz, Rich wrote: > >> =E2=9E=A2 Given that we're almost there, and that only really browsers a= re >> asking for these hacks, and that even some of those were almost read= y >> to ship without these hacks, I don't think that this is entirely >> unrealistic as an aspiration. >> >> The Internet is more than just a couple of browser executables. >> >> Does nobody think of the servers? >> > > I do, but I don't really see how they're relevant for this question. Don'= t > the servers control the middleboxes they are behind? > > -Ekr > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --089e0826fee4d4f5bf055d6d736f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FWIW: In my experience middleboxes don't ossify based = on what the spec says, they ossify based on what they see on the wire. So, = if common implementations send CCS in a particular way, that's what wil= l get --- and, I'll argue, what has gotten --- ossified. I also agree w= ith David and Eric that compatibility mode shouldn't be required becaus= e QUIC doesn't need it.



On Tue, Nov 7, 2017 at 3:57= PM, Eric Rescorla <ekr@rtfm.com> wrote:


On Tue, Nov 7, 2017 at 3:41 PM, Salz, Rich <= span dir=3D"ltr"><= rsalz@akamai.com> wrote:
= =E2=9E=A2 Given that we're almost there, and that only really browsers = are
=C2=A0 =C2=A0 asking for these hacks, and that even some of those wer= e almost ready
=C2=A0 =C2=A0 to ship without these hacks, I don't think that this is e= ntirely
=C2=A0 =C2=A0 unrealistic as an aspiration.

The Internet is more than just a couple of browser executables.

Does nobody think of the servers?

I do, but I don't really see how they're relevant for this questi= on. Don't the servers control the middleboxes they are behind?

-Ekr



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


--089e0826fee4d4f5bf055d6d736f-- From nobody Tue Nov 7 16:09:01 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7F8129B6F for ; Tue, 7 Nov 2017 16:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 uZY3dduFcJeQ for ; Tue, 7 Nov 2017 16:08:56 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80C85129B74 for ; Tue, 7 Nov 2017 16:08:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 395A4BE39; Wed, 8 Nov 2017 00:08:55 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvWhPatp4GhI; Wed, 8 Nov 2017 00:08:53 +0000 (GMT) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 270D0BE38; Wed, 8 Nov 2017 00:08:53 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1510099733; bh=ufJdxQT+4LVbX1+2Z5LiteogDdSr6vVZg2y5VlYYL/g=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=JaLZuKUOQpmRFSygM/YwX+NxILwdqsNNnjLMfCdV+XBWcDoxA3FV5lVYMQmKvlUhs GX5Cjbc6zTt1f4ss0rhUhYjWMMEST0zdlUnKivIt5KSk0R5rBCUDgWuSKtLhnRV7H1 BqFUqFem2IdiiAbkHDLVITIC5iRd16S08xiEr5OA= To: "Nancy Cam-Winget (ncamwing)" , "Flemming Andreasen (fandreas)" , Florian Weimer Cc: "tls@ietf.org" References: <895D1206-28D1-43AB-8A45-11DEEC86A71D@cisco.com> <874lq868t3.fsf@mid.deneb.enyo.de> <6966da46-0f07-b518-4b6e-f2b5f599b050@cs.tcd.ie> <8448A3AF-CEAF-41F4-A43F-9ED7B209C7B9@cisco.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <84562f24-7a4f-4a9f-264c-1edf1e41bebe@cs.tcd.ie> Date: Wed, 8 Nov 2017 00:08:52 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <8448A3AF-CEAF-41F4-A43F-9ED7B209C7B9@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vvovkIU0G7TLAG4j0u76tsGowHi5j79mR" Archived-At: Subject: Re: [TLS] network-based security solution use cases X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 00:09:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vvovkIU0G7TLAG4j0u76tsGowHi5j79mR Content-Type: multipart/mixed; boundary="6KOHnKlQ97eIXT5hhGBceQpx5GrnWoKgN"; protected-headers="v1" From: Stephen Farrell To: "Nancy Cam-Winget (ncamwing)" , "Flemming Andreasen (fandreas)" , Florian Weimer Cc: "tls@ietf.org" Message-ID: <84562f24-7a4f-4a9f-264c-1edf1e41bebe@cs.tcd.ie> Subject: Re: [TLS] network-based security solution use cases References: <895D1206-28D1-43AB-8A45-11DEEC86A71D@cisco.com> <874lq868t3.fsf@mid.deneb.enyo.de> <6966da46-0f07-b518-4b6e-f2b5f599b050@cs.tcd.ie> <8448A3AF-CEAF-41F4-A43F-9ED7B209C7B9@cisco.com> In-Reply-To: <8448A3AF-CEAF-41F4-A43F-9ED7B209C7B9@cisco.com> --6KOHnKlQ97eIXT5hhGBceQpx5GrnWoKgN Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 07/11/17 23:53, Nancy Cam-Winget (ncamwing) wrote: > Hi Stephen, Adding to Flemming=E2=80=99s comment, finding =E2=80=9Cexa= ct quotes=E2=80=9D > will be difficult=20 I'm sorry but when making a claim that such and such a regulation *requires* breaking TLS then you really do need to be that precise. > as their intent is really not to break things but > rather want to ensure that inspection and oversight is available to > affect guards/protections within an (enterprise/data center) > infrastructure. That said, PCI and other regulations will have a > lot of documents that one has to go through=E2=80=A6.one that kind-of c= alls > explicitly to the use of packet inspection, firewalling and such is > in: >=20 > https://www.pcisecuritystandards.org/documents/SAQ_D_v3_Merchant.pdf The first mention of TLS there talks about protecting administrator passwords via TLS. That totally argues against deployment of any kind of MitM infrastructure. >=20 > It is an assessment questionnaire for vendors to evaluate their > compliance, the requirements speak to securing the network and > systems including firewalls, DMZs and the ability to do packet > inspection. Please point me at the specific text. Given you added PCI-DSS to your document I would assume you did the work already. If not, that's a bit odd. S. >=20 > Thanks, Nancy >=20 > On 11/7/17, 3:27 PM, "Flemming Andreasen (fandreas)" > wrote: >=20 > Thanks for taking an initial look at the document Stephen - please > see below for responses so far >=20 > On 11/7/17 4:13 AM, Stephen Farrell wrote: >> Hiya, >>=20 >> On 07/11/17 02:48, Flemming Andreasen wrote: >>> We didn't draw any particular line, but the use case scenarios >>> that we tried to highlight are those related to overall security >>> and regulatory requirements (including public sector) >> I had a quick look at the draft (will try read properly en-route >> to ietf-100) and I followed the reference to [1] but that only lead >> to a forest of documents in which I didn't find any reference to >> breaking TLS so far at least. Can you provide an explicit pointer >> to the exact document on which that claim is based? > For NERC, you can look under "(CIP) Critital Infrastructure=20 > Protection". CIP-005-5 for example covers the electronic security=20 > perimeter, which has a couple of relevant requirements and associated > text: >=20 > http://www.nerc.com/_layouts/PrintStandard.aspx?standardnumber=3DCIP-00= 5-5&title=3DCyber%20Security%20-%20Electronic%20Security%20Perimeter(s)&j= urisdiction=3DUnited%20States >=20 >=20 >=20 > To be clear though, the document does not specifically call out > breaking TLS, but it does clearly call out the need to detect > malicious inbound and outbound communications by leveraging an > "Electronic Access Point" (e.g. IDS/IPS) to enforce the Electronic > Security Perimeter. >> I'd also claim that your reference to PCI-DSS is misleading, as >> that same spec also explicitly calls for there to be good key >> management specifically including minimising the number of copies >> of keys, so at most, one might be able to claim that PCI-DSS is ok >> with people who break TLS in a nod-and-a-wink manner. But if you do >> have a real quote from PCI-DSS that calls for breaking TLS then >> please do also send that (it's been asked for a bunch of times >> without any answer being provided so far). >=20 > I will need to look more closely for such a quote - if anybody else=20 > knows of one, please chime in as well. >=20 > Thanks >=20 > -- Flemming >=20 >=20 >> Thanks, S. >>=20 >>=20 >> [1]=20 >> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00.html#ref-= NERCCIP > >>=20 >=20 >=20 >=20 >=20 --6KOHnKlQ97eIXT5hhGBceQpx5GrnWoKgN-- --vvovkIU0G7TLAG4j0u76tsGowHi5j79mR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaAksUAAoJEC88hzaAX42iSfcH/iQwzxTeqTwUb+qublgSIbvE 6WNG+5upHwTEtpKA8ZCCDQwKiKZ7yCFBq3lroDROH0V289GV/4lXLjDAb/B/znqe VNffsq0bnE6RmSM5pOFegV8gYaxCvPvsp4ckszOLwfH67lNlDYdDb2EBqUxYe8uI a01kjecE0IpJK8sZ6hx1mSqOsIye/CKKeJxB/6nqMhtqXwKGO8Nw38TdACODC0H5 ISXYwOejHHrASa5prFNg6fH1cp8dM7Ue49KY0GijBZnvShxMS9lk2KgsoiAdgPYF ydzoQj/95liSge7rzexTOKYX0fWYHX35NHNdoy1dvuqvsjCqDq0RO4kk4v1w/4M= =rZQR -----END PGP SIGNATURE----- --vvovkIU0G7TLAG4j0u76tsGowHi5j79mR-- From nobody Tue Nov 7 16:23:09 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1639812711D for ; Tue, 7 Nov 2017 16:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 Wq9q4rxKIttA for ; Tue, 7 Nov 2017 16:23:05 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77ACA129B74 for ; Tue, 7 Nov 2017 16:23:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6520; q=dns/txt; s=iport; t=1510100585; x=1511310185; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vxFBJ5Uy/gGgTuPE5c9cFyDNl6Ql4jW4FKKzOxTrJBo=; b=YxLAIOhrECVpttBkEe+LD+LDdV1aTAQhVEnRjX3YmdVBj1hhQ1IUzxOA GYo1RqB13fToSEu6ZwT7f9NcUGVNr04EIQYFjDyVeqv83KgYWiVLiabR4 KzFc5gVmYVgUIa4Qnu5BZjiO8pdR4T3gNwTBsH9vskn6dePAzmSaa1LTP I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CRAQBPTQJa/5hdJa1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDNGRuJweDdptBlkmCEQoehR0CGoRdQRYBAQEBAQEBAQFrKIU?= =?us-ascii?q?eAQEBAQEBASMRRRACAQgYAgImAgICMBUQAgQBDQUbigAIEKhfgieLGQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAR2BD4IhggeDPSmDAYNCgR8KKheCfjGCMgWiFgKHZI0?= =?us-ascii?q?XghWGBIQEhxuMZ4kMAhEZAYE4ASYDLoFxehUfVwGCNgmCTgUcgWd3AYsngREBA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.44,361,1505779200"; d="scan'208";a="28225044" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Nov 2017 00:23:04 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vA80N4SW031727 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Nov 2017 00:23:04 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 7 Nov 2017 19:23:03 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Tue, 7 Nov 2017 19:23:03 -0500 From: "Nancy Cam-Winget (ncamwing)" To: Stephen Farrell , "Flemming Andreasen (fandreas)" , Florian Weimer CC: "tls@ietf.org" Thread-Topic: [TLS] network-based security solution use cases Thread-Index: AQHTVQ82KKjKBkAk5kyjDwLCBqb5H6MF7FPMgAKjMwCAAGt7gIAA7sYA//+BIwCAAIpNAP//fdaA Date: Wed, 8 Nov 2017 00:23:03 +0000 Message-ID: References: <895D1206-28D1-43AB-8A45-11DEEC86A71D@cisco.com> <874lq868t3.fsf@mid.deneb.enyo.de> <6966da46-0f07-b518-4b6e-f2b5f599b050@cs.tcd.ie> <8448A3AF-CEAF-41F4-A43F-9ED7B209C7B9@cisco.com> <84562f24-7a4f-4a9f-264c-1edf1e41bebe@cs.tcd.ie> In-Reply-To: <84562f24-7a4f-4a9f-264c-1edf1e41bebe@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1a.0.160910 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.155.71.77] Content-Type: text/plain; charset="utf-8" Content-ID: <23007C39AF06E54B86E0C30812F9348D@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] network-based security solution use cases X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 00:23:07 -0000 SGkgU3RlcGhlbiwNClBsZWFzZSBzZWUgYmVsb3c6DQoNCk9uIDExLzcvMTcsIDQ6MDggUE0sICJT dGVwaGVuIEZhcnJlbGwiIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPiB3cm90ZToNCg0KICAg IA0KICAgIEhpeWEsDQogICAgDQogICAgT24gMDcvMTEvMTcgMjM6NTMsIE5hbmN5IENhbS1XaW5n ZXQgKG5jYW13aW5nKSB3cm90ZToNCiAgICA+IEhpIFN0ZXBoZW4sIEFkZGluZyB0byBGbGVtbWlu Z+KAmXMgY29tbWVudCwgIGZpbmRpbmcg4oCcZXhhY3QgcXVvdGVz4oCdDQogICAgPiB3aWxsIGJl IGRpZmZpY3VsdCANCiAgICANCiAgICBJJ20gc29ycnkgYnV0IHdoZW4gbWFraW5nIGEgY2xhaW0g dGhhdCBzdWNoIGFuZCBzdWNoIGEgcmVndWxhdGlvbg0KICAgICpyZXF1aXJlcyogYnJlYWtpbmcg VExTIHRoZW4geW91IHJlYWxseSBkbyBuZWVkIHRvIGJlIHRoYXQgcHJlY2lzZS4NCltOQ1ddIElu IFRMUyAxLjIsIG5vdCBzdXJlIHdoeSB5b3Ugc3RhdGUgKnJlcXVpcmVzKiBhcyB0aGVyZSBpcyB0 aGUgdmlzaWJpbGl0eSBhZmZvcmRlZCB0byANCmF0IGxlYXN0IGFsbG93IGZvciB0aGUgaWRlbnRp dHkgZGlzY2xvc3VyZSB0byBlbmFibGUgd2hpdGUgb3IgYmxhY2tsaXN0IGZvciBleGFtcGxlLiAg DQoNCiAgICA+IGFzIHRoZWlyIGludGVudCBpcyByZWFsbHkgbm90IHRvIGJyZWFrIHRoaW5ncyBi dXQNCiAgICA+IHJhdGhlciB3YW50IHRvIGVuc3VyZSB0aGF0IGluc3BlY3Rpb24gYW5kIG92ZXJz aWdodCBpcyBhdmFpbGFibGUgdG8NCiAgICA+IGFmZmVjdCBndWFyZHMvcHJvdGVjdGlvbnMgd2l0 aGluIGFuIChlbnRlcnByaXNlL2RhdGEgY2VudGVyKQ0KICAgID4gaW5mcmFzdHJ1Y3R1cmUuICAg VGhhdCBzYWlkLCBQQ0kgYW5kIG90aGVyIHJlZ3VsYXRpb25zIHdpbGwgaGF2ZSBhDQogICAgPiBs b3Qgb2YgZG9jdW1lbnRzIHRoYXQgb25lIGhhcyB0byBnbyB0aHJvdWdo4oCmLm9uZSB0aGF0IGtp bmQtb2YgY2FsbHMNCiAgICA+IGV4cGxpY2l0bHkgdG8gdGhlIHVzZSBvZiBwYWNrZXQgaW5zcGVj dGlvbiwgZmlyZXdhbGxpbmcgYW5kIHN1Y2ggaXMNCiAgICA+IGluOg0KICAgID4gDQogICAgPiBo dHRwczovL3d3dy5wY2lzZWN1cml0eXN0YW5kYXJkcy5vcmcvZG9jdW1lbnRzL1NBUV9EX3YzX01l cmNoYW50LnBkZg0KICAgIA0KICAgIFRoZSBmaXJzdCBtZW50aW9uIG9mIFRMUyB0aGVyZSB0YWxr cyBhYm91dCBwcm90ZWN0aW5nIGFkbWluaXN0cmF0b3INCiAgICBwYXNzd29yZHMgdmlhIFRMUy4g VGhhdCB0b3RhbGx5IGFyZ3VlcyBhZ2FpbnN0IGRlcGxveW1lbnQgb2YgYW55IGtpbmQNCiAgICBv ZiBNaXRNIGluZnJhc3RydWN0dXJlLg0KW05DV10gQWdyZWVkLCB0aGV5IGFsc28gc3RhdGUgaW4g ZW5zdXJpbmcgdGhhdCB0aGUgbmV3ZXN0IFRMUyB2ZXJzaW9uIHdoZXJlIA0KcG9zc2libGUgaXMg dXNlZC4gIEJVVCwgdGhleSBhbHNvIGV4cGVjdCBtb25pdG9yaW5nIGFuZCB0cm91Ymxlc2hvb3Rp bmcuDQogICAgDQogICAgPiANCiAgICA+IEl0IGlzIGFuIGFzc2Vzc21lbnQgcXVlc3Rpb25uYWly ZSBmb3IgdmVuZG9ycyB0byBldmFsdWF0ZSB0aGVpcg0KICAgID4gY29tcGxpYW5jZSwgdGhlIHJl cXVpcmVtZW50cyBzcGVhayB0byBzZWN1cmluZyB0aGUgbmV0d29yayBhbmQNCiAgICA+IHN5c3Rl bXMgaW5jbHVkaW5nIGZpcmV3YWxscywgRE1acyBhbmQgdGhlIGFiaWxpdHkgdG8gZG8gcGFja2V0 DQogICAgPiBpbnNwZWN0aW9uLg0KICAgIA0KICAgIFBsZWFzZSBwb2ludCBtZSBhdCB0aGUgc3Bl Y2lmaWMgdGV4dC4gR2l2ZW4geW91IGFkZGVkIFBDSS1EU1MgdG8NCiAgICB5b3VyIGRvY3VtZW50 IEkgd291bGQgYXNzdW1lIHlvdSBkaWQgdGhlIHdvcmsgYWxyZWFkeS4gSWYgbm90LA0KICAgIHRo YXQncyBhIGJpdCBvZGQuDQpbTkNXXSBGcm9tIHRoZSBsaW5rIGFib3ZlLCB5b3UgY2FuIGxvb2sg YXQgcmVxdWlyZW1lbnRzIGluIDEuMywNCmFsc28gUmVxdWlyZW1lbnQgMTAgZGV0YWlscyB0aGUg bmVlZCB0byBtb25pdG9yIGFuZCBwcm92aWRlIGF1ZGl0IHRyYWlscw0KZm9yIG5ldHdvcmsgcmVz b3VyY2VzIGFuZCBjYXJkaG9sZGVyIGRhdGEuDQogICAgDQogICAgUy4NCiAgICANCiAgICANCiAg ICA+IA0KICAgID4gVGhhbmtzLCBOYW5jeQ0KICAgID4gDQogICAgPiBPbiAxMS83LzE3LCAzOjI3 IFBNLCAiRmxlbW1pbmcgQW5kcmVhc2VuIChmYW5kcmVhcykiDQogICAgPiA8ZmFuZHJlYXNAY2lz Y28uY29tPiB3cm90ZToNCiAgICA+IA0KICAgID4gVGhhbmtzIGZvciB0YWtpbmcgYW4gaW5pdGlh bCBsb29rIGF0IHRoZSBkb2N1bWVudCBTdGVwaGVuIC0gcGxlYXNlDQogICAgPiBzZWUgYmVsb3cg Zm9yIHJlc3BvbnNlcyBzbyBmYXINCiAgICA+IA0KICAgID4gT24gMTEvNy8xNyA0OjEzIEFNLCBT dGVwaGVuIEZhcnJlbGwgd3JvdGU6DQogICAgPj4gSGl5YSwNCiAgICA+PiANCiAgICA+PiBPbiAw Ny8xMS8xNyAwMjo0OCwgRmxlbW1pbmcgQW5kcmVhc2VuIHdyb3RlOg0KICAgID4+PiBXZSBkaWRu J3QgZHJhdyBhbnkgcGFydGljdWxhciBsaW5lLCBidXQgdGhlIHVzZSBjYXNlIHNjZW5hcmlvcw0K ICAgID4+PiB0aGF0IHdlIHRyaWVkIHRvIGhpZ2hsaWdodCBhcmUgdGhvc2UgcmVsYXRlZCB0byBv dmVyYWxsIHNlY3VyaXR5DQogICAgPj4+IGFuZCByZWd1bGF0b3J5IHJlcXVpcmVtZW50cyAoaW5j bHVkaW5nIHB1YmxpYyBzZWN0b3IpDQogICAgPj4gSSBoYWQgYSBxdWljayBsb29rIGF0IHRoZSBk cmFmdCAod2lsbCB0cnkgcmVhZCBwcm9wZXJseSBlbi1yb3V0ZQ0KICAgID4+IHRvIGlldGYtMTAw KSBhbmQgSSBmb2xsb3dlZCB0aGUgcmVmZXJlbmNlIHRvIFsxXSBidXQgdGhhdCBvbmx5IGxlYWQN CiAgICA+PiB0byBhIGZvcmVzdCBvZiBkb2N1bWVudHMgaW4gd2hpY2ggSSBkaWRuJ3QgZmluZCBh bnkgcmVmZXJlbmNlIHRvDQogICAgPj4gYnJlYWtpbmcgVExTIHNvIGZhciBhdCBsZWFzdC4gQ2Fu IHlvdSBwcm92aWRlIGFuIGV4cGxpY2l0IHBvaW50ZXINCiAgICA+PiB0byB0aGUgZXhhY3QgZG9j dW1lbnQgb24gd2hpY2ggdGhhdCBjbGFpbSBpcyBiYXNlZD8NCiAgICA+IEZvciBORVJDLCB5b3Ug Y2FuIGxvb2sgdW5kZXIgICIoQ0lQKSBDcml0aXRhbCBJbmZyYXN0cnVjdHVyZSANCiAgICA+IFBy b3RlY3Rpb24iLiBDSVAtMDA1LTUgZm9yIGV4YW1wbGUgY292ZXJzIHRoZSBlbGVjdHJvbmljIHNl Y3VyaXR5IA0KICAgID4gcGVyaW1ldGVyLCB3aGljaCBoYXMgYSBjb3VwbGUgb2YgcmVsZXZhbnQg cmVxdWlyZW1lbnRzIGFuZCBhc3NvY2lhdGVkDQogICAgPiB0ZXh0Og0KICAgID4gDQogICAgPiBo dHRwOi8vd3d3Lm5lcmMuY29tL19sYXlvdXRzL1ByaW50U3RhbmRhcmQuYXNweD9zdGFuZGFyZG51 bWJlcj1DSVAtMDA1LTUmdGl0bGU9Q3liZXIlMjBTZWN1cml0eSUyMC0lMjBFbGVjdHJvbmljJTIw U2VjdXJpdHklMjBQZXJpbWV0ZXIocykmanVyaXNkaWN0aW9uPVVuaXRlZCUyMFN0YXRlcw0KICAg ID4gDQogICAgPiANCiAgICA+IA0KICAgID4gVG8gYmUgY2xlYXIgdGhvdWdoLCB0aGUgZG9jdW1l bnQgZG9lcyBub3Qgc3BlY2lmaWNhbGx5IGNhbGwgb3V0DQogICAgPiBicmVha2luZyBUTFMsIGJ1 dCBpdCBkb2VzIGNsZWFybHkgY2FsbCBvdXQgdGhlIG5lZWQgdG8gZGV0ZWN0DQogICAgPiBtYWxp Y2lvdXMgaW5ib3VuZCBhbmQgb3V0Ym91bmQgY29tbXVuaWNhdGlvbnMgYnkgbGV2ZXJhZ2luZyBh bg0KICAgID4gIkVsZWN0cm9uaWMgQWNjZXNzIFBvaW50IiAoZS5nLiBJRFMvSVBTKSB0byBlbmZv cmNlIHRoZSBFbGVjdHJvbmljDQogICAgPiBTZWN1cml0eSBQZXJpbWV0ZXIuDQogICAgPj4gSSdk IGFsc28gY2xhaW0gdGhhdCB5b3VyIHJlZmVyZW5jZSB0byBQQ0ktRFNTIGlzIG1pc2xlYWRpbmcs IGFzDQogICAgPj4gdGhhdCBzYW1lIHNwZWMgYWxzbyBleHBsaWNpdGx5IGNhbGxzIGZvciB0aGVy ZSB0byBiZSBnb29kIGtleQ0KICAgID4+IG1hbmFnZW1lbnQgc3BlY2lmaWNhbGx5IGluY2x1ZGlu ZyBtaW5pbWlzaW5nIHRoZSBudW1iZXIgb2YgY29waWVzDQogICAgPj4gb2Yga2V5cywgc28gYXQg bW9zdCwgb25lIG1pZ2h0IGJlIGFibGUgdG8gY2xhaW0gdGhhdCBQQ0ktRFNTIGlzIG9rDQogICAg Pj4gd2l0aCBwZW9wbGUgd2hvIGJyZWFrIFRMUyBpbiBhIG5vZC1hbmQtYS13aW5rIG1hbm5lci4g QnV0IGlmIHlvdSBkbw0KICAgID4+IGhhdmUgYSByZWFsIHF1b3RlIGZyb20gUENJLURTUyB0aGF0 IGNhbGxzIGZvciBicmVha2luZyBUTFMgdGhlbg0KICAgID4+IHBsZWFzZSBkbyBhbHNvIHNlbmQg dGhhdCAoaXQncyBiZWVuIGFza2VkIGZvciBhIGJ1bmNoIG9mIHRpbWVzDQogICAgPj4gd2l0aG91 dCBhbnkgYW5zd2VyIGJlaW5nIHByb3ZpZGVkIHNvIGZhcikuDQogICAgPiANCiAgICA+IEkgd2ls bCBuZWVkIHRvIGxvb2sgbW9yZSBjbG9zZWx5IGZvciBzdWNoIGEgcXVvdGUgLSBpZiBhbnlib2R5 IGVsc2UgDQogICAgPiBrbm93cyBvZiBvbmUsIHBsZWFzZSBjaGltZSBpbiBhcyB3ZWxsLg0KICAg ID4gDQogICAgPiBUaGFua3MNCiAgICA+IA0KICAgID4gLS0gRmxlbW1pbmcNCiAgICA+IA0KICAg ID4gDQogICAgPj4gVGhhbmtzLCBTLg0KICAgID4+IA0KICAgID4+IA0KICAgID4+IFsxXSANCiAg ICA+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2Ftd2luZ2V0LXRscy11c2Ut Y2FzZXMtMDAuaHRtbCNyZWYtTkVSQ0NJUA0KICAgID4NCiAgICA+PiANCiAgICA+IA0KICAgID4g DQogICAgPiANCiAgICA+IA0KICAgIA0KICAgIA0KDQo= From nobody Tue Nov 7 16:25:54 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787EE129BF8 for ; Tue, 7 Nov 2017 16:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 bFloFiZ4ucdk for ; Tue, 7 Nov 2017 16:25:51 -0800 (PST) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (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 225FD129B16 for ; Tue, 7 Nov 2017 16:25:50 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id v3so673672vkb.8 for ; Tue, 07 Nov 2017 16:25:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WB6rKf9EvQ6+/CyuZXLIY3m5u53dQO52ZlqKQHUI4qU=; b=SVDqh4xepc1aVZnTSjcj40NB/UblIM3KKbxU3unmRvt2zGg4xC4W15LO+891pFVNgo wthlLidUeX372LwiqhAvHnGtJ83iQ0NkB0axlt5oPtow7N9aNIstcub0pMtqe5XS7caY n5SjYpuGNKiIVGhyuRiN0ur/HkU3llPPkUU/p6BiCJRO85RxOh16NcMmtrkmcA1Hjb4I jY15ufF5AAQMbIKz2HrJZTSmbM5JT6dkK2OgsiSGHork6dSYXtl040TMq+FHPtTEW6FC HledYKvRJHNEdAC8zOvZZ0YJ+VY9/g0j244Io5GgbBFaPpdBIu8+7op//QNGCrI+D9UF Q53A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WB6rKf9EvQ6+/CyuZXLIY3m5u53dQO52ZlqKQHUI4qU=; b=WQQraz68wq2EfUi70/ppCx4D/pj8cZe8sLINkS2goJE45BX9WW7dW20bcL8iU1Va4h l9v3rv/vl2bgJDfhavm+g9bnD9HeL+Kpa2pyJjJ8FVmlgg45wnyD6NK+93dX1e4tQe3e 8sVR1VQTC8e5qgSQ4q/JzbP7CFZLgxU+LEZXK6TDxLx1PyIkSX3TJ/3LsVosotczfKjc CZ35TCnah8NBjLflrdtrvDCA/i/ro/vt54swWh+Sx5X0DbZwKdcRxYE/iQYrOoVku4wT i9EFOvJKu83d6EP9kHjMnexy7itC0pbNwAy8JwBBQNxdtTsf4z1+s6tGovM6j42cuBfL Nzvg== X-Gm-Message-State: AJaThX53UDTtHwHtqVBqduEUTy56yDhgT8JhegEJFgCLZECRhNYtQJW+ wk9xYVIRcbrAVvKy63WNuOqN1N9ijVFwadkT88c= X-Google-Smtp-Source: ABhQp+QW7uWfM2vS0ogDRWv/vpMUvzjCeawr3BGWFKRSSOTj6Mh75XzxTEWTYWcem9pQ01aikrXCtTngewlbMIClN5Y= X-Received: by 10.31.226.3 with SMTP id z3mr364951vkg.193.1510100748961; Tue, 07 Nov 2017 16:25:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.11.132 with HTTP; Tue, 7 Nov 2017 16:25:48 -0800 (PST) In-Reply-To: References: <4406543.RZChgRkkf9@pintsize.usersys.redhat.com> <6818962.9GzJR6rN5C@pintsize.usersys.redhat.com> <965B995B-A5B3-4322-B13A-A2D82AFD2743@akamai.com> From: Watson Ladd Date: Tue, 7 Nov 2017 16:25:48 -0800 Message-ID: To: Jana Iyengar Cc: Eric Rescorla , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 00:25:52 -0000 On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar wrote: > FWIW: In my experience middleboxes don't ossify based on what the spec says, > they ossify based on what they see on the wire. So, if common > implementations send CCS in a particular way, that's what will get --- and, > I'll argue, what has gotten --- ossified. I also agree with David and Eric > that compatibility mode shouldn't be required because QUIC doesn't need it. What does compatibility mode mean here? If we end up with having two slightly different versions of TLS 1.3, one that looks more like TLS 1.2 and the other that does not, that doesn't seem like a good thing to me. My understanding is we already have ossification here and the debate is what to do about it. -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Tue Nov 7 16:27:38 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9CA129BD7 for ; Tue, 7 Nov 2017 16:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 59VY5GOrLJ_R for ; Tue, 7 Nov 2017 16:27:33 -0800 (PST) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 2F953129BAD for ; Tue, 7 Nov 2017 16:27:33 -0800 (PST) Received: by mail-ua0-x22f.google.com with SMTP id j14so740682uag.11 for ; Tue, 07 Nov 2017 16:27:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rySOFpJVQ+3EG9mPyy+1I/Fp2I79e3dgXnPUcg2yFYo=; b=PnA/PvfqFb0RyMir5XwbpJoXKtTFRzW95k/QD2wWOsaOH+1z+mG2OePH5B2NqOQgKK 0MIJeY1VDZg56sTVhRq3CxgSuunhXgVannuPWLL5hZXErZtbdyNMvvxdDYt5P6yaFM1J nkkELdL+pO2poMuO5jZtmvnHQ5Ylt8YOJWmGfuURnBfymMSCI2nz3GnwcKFe7jGiTQZK p06X1IaeoKlaHnpeVCHfV6Hq+NxDi9t2RdDaHWguPDWKiYw6PqF6xVOGwO2V8LqoFXrO TLSleeeVsVIFiSHn4wB8zKNiJ7CuWczOvfoIN1OROZ7OsPp8tk7op34dkQD5spRACNs3 shTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rySOFpJVQ+3EG9mPyy+1I/Fp2I79e3dgXnPUcg2yFYo=; b=DoRYKIZ/b5eUn2uTfrqUYvHuzEzq/JdwR6FPNtIuyIj1vQ4CcrEiNJlm16Oi7zFtDx 5xFxV11i6kdDKSFyTZyHUxKovjbunSCvEM9578hHXgMFZFKOVvtLyZHgg+XxFP+pwWye VIV/yo5hWfqC0vEuqe3JJNtZbIdHNN2mm4SwrdZj+yamnpx+f49SaodywSCpagEME7kk LfU6iC682iRdijY+z9Bfj2LR/ISsSQGlVVcwi5QoLnCHcazOwVGH0nqzwaQyu0Rm9d9L M+j5hP9zmqIcjT3qffCMHym5/dqExepMVw3OrvkFnSoxndIXFbaOh4ZC6WwEE++7WWjn hEaA== X-Gm-Message-State: AJaThX5VbksChL75LhUI9+3IT8koWW3UNxwIyAFzAKLtenHGDS8Avl3e m6NJi9CWuOJkkTDcsqiL5onNCSKZbEmd7NBpV0Ku9Q== X-Google-Smtp-Source: ABhQp+TMrAgF4zWaBn3ur7fOcHhmC8vmn1oPtIYVKblZySRBekjjQZyh30/WoWM4FLZ4VQVa6pAN5ZAinwaAvQL3pgo= X-Received: by 10.176.21.79 with SMTP id p15mr474416uae.140.1510100852087; Tue, 07 Nov 2017 16:27:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.11.132 with HTTP; Tue, 7 Nov 2017 16:27:31 -0800 (PST) In-Reply-To: References: <895D1206-28D1-43AB-8A45-11DEEC86A71D@cisco.com> <874lq868t3.fsf@mid.deneb.enyo.de> <6966da46-0f07-b518-4b6e-f2b5f599b050@cs.tcd.ie> <8448A3AF-CEAF-41F4-A43F-9ED7B209C7B9@cisco.com> <84562f24-7a4f-4a9f-264c-1edf1e41bebe@cs.tcd.ie> From: Watson Ladd Date: Tue, 7 Nov 2017 16:27:31 -0800 Message-ID: To: "Nancy Cam-Winget (ncamwing)" Cc: Stephen Farrell , "Flemming Andreasen (fandreas)" , Florian Weimer , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] network-based security solution use cases X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 00:27:36 -0000 On Tue, Nov 7, 2017 at 4:23 PM, Nancy Cam-Winget (ncamwing) wrote: > Hi Stephen, > Please see below: > > On 11/7/17, 4:08 PM, "Stephen Farrell" wrote: > > > Hiya, > > On 07/11/17 23:53, Nancy Cam-Winget (ncamwing) wrote: > > Hi Stephen, Adding to Flemming=E2=80=99s comment, finding =E2=80= =9Cexact quotes=E2=80=9D > > will be difficult > > I'm sorry but when making a claim that such and such a regulation > *requires* breaking TLS then you really do need to be that precise. > [NCW] In TLS 1.2, not sure why you state *requires* as there is the visib= ility afforded to > at least allow for the identity disclosure to enable white or blacklist f= or example. > > > as their intent is really not to break things but > > rather want to ensure that inspection and oversight is available to > > affect guards/protections within an (enterprise/data center) > > infrastructure. That said, PCI and other regulations will have a > > lot of documents that one has to go through=E2=80=A6.one that kind-= of calls > > explicitly to the use of packet inspection, firewalling and such is > > in: > > > > https://www.pcisecuritystandards.org/documents/SAQ_D_v3_Merchant.pd= f > > The first mention of TLS there talks about protecting administrator > passwords via TLS. That totally argues against deployment of any kind > of MitM infrastructure. > [NCW] Agreed, they also state in ensuring that the newest TLS version whe= re > possible is used. BUT, they also expect monitoring and troubleshooting. > > > > > It is an assessment questionnaire for vendors to evaluate their > > compliance, the requirements speak to securing the network and > > systems including firewalls, DMZs and the ability to do packet > > inspection. > > Please point me at the specific text. Given you added PCI-DSS to > your document I would assume you did the work already. If not, > that's a bit odd. > [NCW] From the link above, you can look at requirements in 1.3, > also Requirement 10 details the need to monitor and provide audit trails > for network resources and cardholder data. None of the questions in requirement 10 require middlebox interception. > > S. > > > > > > Thanks, Nancy > > > > On 11/7/17, 3:27 PM, "Flemming Andreasen (fandreas)" > > wrote: > > > > Thanks for taking an initial look at the document Stephen - please > > see below for responses so far > > > > On 11/7/17 4:13 AM, Stephen Farrell wrote: > >> Hiya, > >> > >> On 07/11/17 02:48, Flemming Andreasen wrote: > >>> We didn't draw any particular line, but the use case scenarios > >>> that we tried to highlight are those related to overall security > >>> and regulatory requirements (including public sector) > >> I had a quick look at the draft (will try read properly en-route > >> to ietf-100) and I followed the reference to [1] but that only lea= d > >> to a forest of documents in which I didn't find any reference to > >> breaking TLS so far at least. Can you provide an explicit pointer > >> to the exact document on which that claim is based? > > For NERC, you can look under "(CIP) Critital Infrastructure > > Protection". CIP-005-5 for example covers the electronic security > > perimeter, which has a couple of relevant requirements and associat= ed > > text: > > > > http://www.nerc.com/_layouts/PrintStandard.aspx?standardnumber=3DCI= P-005-5&title=3DCyber%20Security%20-%20Electronic%20Security%20Perimeter(s)= &jurisdiction=3DUnited%20States > > > > > > > > To be clear though, the document does not specifically call out > > breaking TLS, but it does clearly call out the need to detect > > malicious inbound and outbound communications by leveraging an > > "Electronic Access Point" (e.g. IDS/IPS) to enforce the Electronic > > Security Perimeter. > >> I'd also claim that your reference to PCI-DSS is misleading, as > >> that same spec also explicitly calls for there to be good key > >> management specifically including minimising the number of copies > >> of keys, so at most, one might be able to claim that PCI-DSS is ok > >> with people who break TLS in a nod-and-a-wink manner. But if you d= o > >> have a real quote from PCI-DSS that calls for breaking TLS then > >> please do also send that (it's been asked for a bunch of times > >> without any answer being provided so far). > > > > I will need to look more closely for such a quote - if anybody else > > knows of one, please chime in as well. > > > > Thanks > > > > -- Flemming > > > > > >> Thanks, S. > >> > >> > >> [1] > >> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00.html#= ref-NERCCIP > > > >> > > > > > > > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Tue Nov 7 16:32:09 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF43E129BF8 for ; Tue, 7 Nov 2017 16:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 rhuSEdwWSpKZ for ; Tue, 7 Nov 2017 16:32:05 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6023B129BDD for ; Tue, 7 Nov 2017 16:32:05 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vA80R1CO018801; Wed, 8 Nov 2017 00:32:03 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=/GUsAW61/W61TF1+rRvbDdzv/SUwQE/Dj6pWxIFCAGM=; b=BQriwS3PVK/wrs84BqOvTPNVLQJUlOhI2CvbXr7/WGkhpbO7USF5t9+MBSAyF2LEJZXk vH3r/HQqAe3d80i8o8Fjqn3ThNCMV1ilmlbwk8qld1Gg5oXmHCpMN9gCj4WRfDmdLOTj 0btpx1cDxO4ENp1HweGEPEVSKBmrsJ1FzraPE1IIHXKHBbma+ju57PtSE8U7S9/vdt4o wVv6G8kAqPfvqbv02YAR6+4IJNTX/Jw0GDyTpPYas3NXFk2xbRRZl3bsKoRYDn51nzSn c5BfGVY0K+740LsN3J3M5r9MLB4mvW80Ahd+lXW/4qPbUxb5bVSoW43zd9hiZXEnlOPH Rw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050095.ppops.net-00190b01. with ESMTP id 2e15y5wds2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 Nov 2017 00:32:02 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vA80ValS025769; Tue, 7 Nov 2017 19:32:01 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2e18vubesq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 07 Nov 2017 19:32:01 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 7 Nov 2017 19:32:00 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 7 Nov 2017 19:32:00 -0500 From: "Salz, Rich" To: Eric Rescorla CC: Martin Thomson , Hubert Kario , "tls@ietf.org" Thread-Topic: [TLS] PR#1091: Changes to provide middlebox robustness Thread-Index: AQHTVyvYee7TW4xp9E6OP50HN76KZ6MJYqeAgAAba4CAAA8EgIAAJQeAgAAbmgCAABu7gIAABEUAgAAJuwA= Date: Wed, 8 Nov 2017 00:32:00 +0000 Message-ID: References: <4406543.RZChgRkkf9@pintsize.usersys.redhat.com> <6818962.9GzJR6rN5C@pintsize.usersys.redhat.com> <965B995B-A5B3-4322-B13A-A2D82AFD2743@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.42.204] Content-Type: multipart/alternative; boundary="_000_F871F4D83EF843F5B45FB8CC69D49386akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-07_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711080006 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-07_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711080004 Archived-At: Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 00:32:07 -0000 --_000_F871F4D83EF843F5B45FB8CC69D49386akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4p6iIEdpdmVuIHRoYXQgd2UncmUgYWxtb3N0IHRoZXJlLCBhbmQgdGhhdCBvbmx5IHJlYWxseSBi cm93c2VycyBhcmUNCiAgICBhc2tpbmcgZm9yIHRoZXNlIGhhY2tzLCBhbmQgdGhhdCBldmVuIHNv bWUgb2YgdGhvc2Ugd2VyZSBhbG1vc3QgcmVhZHkNCiAgICB0byBzaGlwIHdpdGhvdXQgdGhlc2Ug aGFja3MsIEkgZG9uJ3QgdGhpbmsgdGhhdCB0aGlzIGlzIGVudGlyZWx5DQogICAgdW5yZWFsaXN0 aWMgYXMgYW4gYXNwaXJhdGlvbi4NCg0KVGhlIEludGVybmV0IGlzIG1vcmUgdGhhbiBqdXN0IGEg Y291cGxlIG9mIGJyb3dzZXIgZXhlY3V0YWJsZXMuDQoNCkRvZXMgbm9ib2R5IHRoaW5rIG9mIHRo ZSBzZXJ2ZXJzPw0KDQoNCiAgKiAgIEkgZG8sIGJ1dCBJIGRvbid0IHJlYWxseSBzZWUgaG93IHRo ZXkncmUgcmVsZXZhbnQgZm9yIHRoaXMgcXVlc3Rpb24uIERvbid0IHRoZSBzZXJ2ZXJzIGNvbnRy b2wgdGhlIG1pZGRsZWJveGVzIHRoZXkgYXJlIGJlaGluZD8NCg0KVGhlIHNtaWxleSBnb3QgbG9z dC4gIEJ1dCBzbWlsZXkgaXNu4oCZdCBxdWl0ZSB0aGUgcmlnaHQgZW1vdGljb24gZWl0aGVyLiAg QnV0IHRvIGFuc3dlciB5b3VyIHF1ZXN0aW9uOiBubywgdGhlIG9mdGVuIGRvbuKAmXQuICBBbmQg aXTigJlzIG5vdCBqdXN0IHRoZSBtaWRkbGVib3hlcyB0aGV5IGFyZSBiZWhpbmQsIGJ1dCBhbGwg dGhvc2UgYWxvbmcgdGhlIHdheS4NCg0KVG8gc2F5IHRoYXQgb25seSBicm93c2VycyB3ZXJlIGFz a2luZyBmb3IgdGhlc2UgaGFja3MgaXMgYWxzbyBhIGxpdHRsZSBkaXNpbmdlbnVvdXMuICBJdCB3 YXMgYSBzZWxmLXNlbGVjdGVkIGRlc2lnbiBncm91cCAodG8gYmUgY2hhcml0YWJsZSkgdGhhdCBt b3N0bHkgd29ya2VkIGJ5IHRoZW1zZWx2ZXMgd2l0aG91dCB0aGUgd2hvbGUgV0cgYmVpbmcgaW52 b2x2ZWQuICBJ4oCZbSBnbGFkIHdlIHNlZW0gdG8gYmUgZW5kaW5nIHVwIHdpdGggc29tZXRoaW5n IHRoYXQgd29ya3MsIHdpdGggdGhlIG9ubHkgdGhpbmcgYmVpbmcgbG9zdCBpcyBzb21lIG5lcmQg ZXN0aGV0aWNzLCBidXQgbGV04oCZcyBub3QgZm9yZ2V0IHRoZSAodG8gbWUsIGRpc2FwcG9pbnRp bmcpIHdheSB0aGUgd2hvbGUgdGhpbmcgd2VudCBkb3duOiBhIGNvbGxhYm9yYXRpb24gYW1vbmcs IGFuZCBvbmx5IGFtb25nLCBHb29nbGUsIE1vemlsbGEsIGFuZCBGYWNlYm9vay4NCg0KDQo= --_000_F871F4D83EF843F5B45FB8CC69D49386akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0x OjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9y OnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDAN Cgl7bXNvLWxpc3QtaWQ6NjQ3NTE4OTkyOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotNTg4MzY1NjggNjc2OTg2OTkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2 OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxp c3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci LHNlcmlmO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3Qg bDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01T IE1pbmNobyZxdW90OyxzZXJpZiI+4p6iPC9zcGFuPiBHaXZlbiB0aGF0IHdlJ3JlIGFsbW9zdCB0 aGVyZSwgYW5kIHRoYXQgb25seSByZWFsbHkgYnJvd3NlcnMgYXJlPGJyPg0KJm5ic3A7ICZuYnNw OyBhc2tpbmcgZm9yIHRoZXNlIGhhY2tzLCBhbmQgdGhhdCBldmVuIHNvbWUgb2YgdGhvc2Ugd2Vy ZSBhbG1vc3QgcmVhZHk8YnI+DQombmJzcDsgJm5ic3A7IHRvIHNoaXAgd2l0aG91dCB0aGVzZSBo YWNrcywgSSBkb24ndCB0aGluayB0aGF0IHRoaXMgaXMgZW50aXJlbHk8YnI+DQombmJzcDsgJm5i c3A7IHVucmVhbGlzdGljIGFzIGFuIGFzcGlyYXRpb24uPGJyPg0KPGJyPg0KVGhlIEludGVybmV0 IGlzIG1vcmUgdGhhbiBqdXN0IGEgY291cGxlIG9mIGJyb3dzZXIgZXhlY3V0YWJsZXMuPGJyPg0K PGJyPg0KRG9lcyBub2JvZHkgdGhpbmsgb2YgdGhlIHNlcnZlcnM/PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+SSBkbywgYnV0IEkgZG9uJ3QgcmVhbGx5IHNlZSBob3cgdGhleSdyZSByZWxl dmFudCBmb3IgdGhpcyBxdWVzdGlvbi4gRG9uJ3QgdGhlIHNlcnZlcnMgY29udHJvbCB0aGUgbWlk ZGxlYm94ZXMgdGhleSBhcmUgYmVoaW5kPzxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGUgc21pbGV5IGdvdCBsb3N0LiZuYnNwOyBCdXQgc21pbGV5IGlzbuKA mXQgcXVpdGUgdGhlIHJpZ2h0IGVtb3RpY29uIGVpdGhlci4mbmJzcDsgQnV0IHRvIGFuc3dlciB5 b3VyIHF1ZXN0aW9uOiBubywgdGhlIG9mdGVuIGRvbuKAmXQuJm5ic3A7IEFuZCBpdOKAmXMgbm90 IGp1c3QgdGhlIG1pZGRsZWJveGVzIHRoZXkgYXJlIGJlaGluZCwgYnV0IGFsbCB0aG9zZSBhbG9u ZyB0aGUgd2F5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBzYXkgdGhhdCBvbmx5IGJyb3dz ZXJzIHdlcmUgYXNraW5nIGZvciB0aGVzZSBoYWNrcyBpcyBhbHNvIGEgbGl0dGxlIGRpc2luZ2Vu dW91cy4mbmJzcDsgSXQgd2FzIGEgc2VsZi1zZWxlY3RlZCBkZXNpZ24gZ3JvdXAgKHRvIGJlIGNo YXJpdGFibGUpIHRoYXQgbW9zdGx5IHdvcmtlZCBieSB0aGVtc2VsdmVzIHdpdGhvdXQgdGhlIHdo b2xlIFdHIGJlaW5nIGludm9sdmVkLiZuYnNwOyBJ4oCZbSBnbGFkIHdlIHNlZW0gdG8gYmUgZW5k aW5nDQogdXAgd2l0aCBzb21ldGhpbmcgdGhhdCB3b3Jrcywgd2l0aCB0aGUgb25seSB0aGluZyBi ZWluZyBsb3N0IGlzIHNvbWUgbmVyZCBlc3RoZXRpY3MsIGJ1dCBsZXTigJlzIG5vdCBmb3JnZXQg dGhlICh0byBtZSwgZGlzYXBwb2ludGluZykgd2F5IHRoZSB3aG9sZSB0aGluZyB3ZW50IGRvd246 IGEgY29sbGFib3JhdGlvbiBhbW9uZywgYW5kIG9ubHkgYW1vbmcsIEdvb2dsZSwgTW96aWxsYSwg YW5kIEZhY2Vib29rLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_F871F4D83EF843F5B45FB8CC69D49386akamaicom_-- From nobody Tue Nov 7 16:32:54 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3837F129C3B for ; Tue, 7 Nov 2017 16:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 HanPa9VUm5Mg for ; Tue, 7 Nov 2017 16:32:51 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 8FE85129BDD for ; Tue, 7 Nov 2017 16:32:51 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id u142so946109ywg.4 for ; Tue, 07 Nov 2017 16:32:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UJBxlyjXgYtWvSUswKBtmmOGn1gRo3DXhlaHYByZ4Wk=; b=gpcEsWnBscLi3iTsYIhRSoRYWrePkrhfk5MIW7Ql9TXaPifg3xzzkfdC007S5G8aEv zm8K2uMWqGw7l/d11Myi4OKefZi3eKq2hD7v4db5qR7TFiGyq3vul7CfGdBl+dOhmpqi 95kIRqvVdrl5oX0DddWm7uphNUcvHm6D+LMe3Wi8hFubn9AJwAFnhOPnwx2U0L3KjbRT G/uR3higI2uCTmyf/N9hgsIKVH1V3MOHzo49E37rfgcFh096H83EVq9S+0UfpKA+gpkK NKdjnNSGI9pApGJPC1iQjFgprQsViHHf2YgIJkOlAmmZuL530CrvQh9MTVpKoEgZNlnS dvUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UJBxlyjXgYtWvSUswKBtmmOGn1gRo3DXhlaHYByZ4Wk=; b=i0HhvngAx3Bz9IHloYBIbBWu5UL1HjHvBa91/kADBqh1sVQKG+m1X9YBkT9cb6evfV lU/jo5JylvNt1AR2Yqypmp2cWaAJZ5x0IEMX3z6tSatndPuoyEYXbJeioT4/csOTVoPU v+fyHM3JQ5b0ltIqc9eBWuOBi5h9ueu4El8Q6v8jTYjWvF7nR3pXh/WAul8IkuL8wgz+ wZC9d1bJJXp2VHAEmm4Nuz7i4R4Dex1EC2QCZHIhoe7OjSC12+yCVlsKCL1/ahsyZfbL uZNiqECc/fE8Zy6VQCYWjOOT9y7KWMDp7nzc/iaTxihbpVNEwm/wwNoyE1IOIWWJJNhy 91HQ== X-Gm-Message-State: AJaThX4ndeBqsnBjogl5pXjHKSAVaR1IIDqugNbg9hCjs33Ma+LJxOpC FcS0DV2N9AWiwtXx4S1hsqufSA36Gqsj6tXY/DKzJQ== X-Google-Smtp-Source: ABhQp+S4E9UUIPl/BKK4TDKSQRsIbKMJ2vLO4lGxFnOVRGIak5V3V5ptX2m4gRkmDPtZHpFG8UWnQwBpi2OyQ8ARilo= X-Received: by 10.37.195.65 with SMTP id t62mr314414ybf.71.1510101170886; Tue, 07 Nov 2017 16:32:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.61.12 with HTTP; Tue, 7 Nov 2017 16:32:09 -0800 (PST) In-Reply-To: References: <4406543.RZChgRkkf9@pintsize.usersys.redhat.com> <6818962.9GzJR6rN5C@pintsize.usersys.redhat.com> <965B995B-A5B3-4322-B13A-A2D82AFD2743@akamai.com> From: Eric Rescorla Date: Tue, 7 Nov 2017 16:32:09 -0800 Message-ID: To: Watson Ladd Cc: Jana Iyengar , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114d7db2ddc137055d6dd35d" Archived-At: Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 00:32:53 -0000 --001a114d7db2ddc137055d6dd35d Content-Type: text/plain; charset="UTF-8" On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd wrote: > On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar wrote: > > FWIW: In my experience middleboxes don't ossify based on what the spec > says, > > they ossify based on what they see on the wire. So, if common > > implementations send CCS in a particular way, that's what will get --- > and, > > I'll argue, what has gotten --- ossified. I also agree with David and > Eric > > that compatibility mode shouldn't be required because QUIC doesn't need > it. > > What does compatibility mode mean here? It means: 1. Send the fake session_id 2. Send a bunch of spurious CCS values. If we end up with having two > slightly different versions of TLS 1.3, one that looks more like TLS > 1.2 and the other that does not, that doesn't seem like a good thing > to me. > Well, the idea is that this is a purely local decision by one side. -Ekr > My understanding is we already have ossification here and the debate > is what to do about it. > > > -- > "Man is born free, but everywhere he is in chains". > --Rousseau. > --001a114d7db2ddc137055d6dd35d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd <watsonbladd@gmail.com= > wrote:
O= n Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar <jri@google.com> wrote:
> FWIW: In my experience middleboxes don't ossify based on what the = spec says,
> they ossify based on what they see on the wire. So, if common
> implementations send CCS in a particular way, that's what will get= --- and,
> I'll argue, what has gotten --- ossified. I also agree with David = and Eric
> that compatibility mode shouldn't be required because QUIC doesn&#= 39;t need it.

What does compatibility mode mean here?

<= div>It means:

1. Send the fake session_id
2. Send a bunch of spurious CCS values.


If we end up with having two
slightly different versions of TLS 1.3, one that looks more like TLS
1.2 and the other that does not, that doesn't seem like a good thing to me.

Well, the idea is that this is a= purely local decision by one side.

-Ekr


My understanding is we already have ossification here and the debate
is what to do about it.


--
"Man is born free, but everywhere he is in chains".
--Rousseau.

--001a114d7db2ddc137055d6dd35d-- From nobody Tue Nov 7 16:40:51 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F56B129C67 for ; Tue, 7 Nov 2017 16:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 2aVI72pUktxe for ; Tue, 7 Nov 2017 16:40:46 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16451129C5F for ; Tue, 7 Nov 2017 16:40:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B3D69BE39; Wed, 8 Nov 2017 00:40:43 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBGPxHfVm_dF; Wed, 8 Nov 2017 00:40:38 +0000 (GMT) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 16205BE38; Wed, 8 Nov 2017 00:40:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1510101638; bh=zmalz7i0KTSnHoDDc7z737/weIed7kpVfF1zVkAl+mU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=aCGyI5PLOhAqXiJJWZPN/vSbfQcPVjyPiJ3OO2AepxxFOMTngS8NmvJ17O+fslmIq qHcsKmb2FrlTQFKhkjrDicQi/DHZj5INhfL/zojZTEJJXIUSyl7Lq5uWMAkNA2pvxh DavRTgbrTjFd5o3Pu2qjhWt0B9UqftzYUU9paiwQ= To: "Nancy Cam-Winget (ncamwing)" , "Flemming Andreasen (fandreas)" , Florian Weimer Cc: "tls@ietf.org" References: <895D1206-28D1-43AB-8A45-11DEEC86A71D@cisco.com> <874lq868t3.fsf@mid.deneb.enyo.de> <6966da46-0f07-b518-4b6e-f2b5f599b050@cs.tcd.ie> <8448A3AF-CEAF-41F4-A43F-9ED7B209C7B9@cisco.com> <84562f24-7a4f-4a9f-264c-1edf1e41bebe@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <3db42c7c-2904-f11f-ab8e-116835669816@cs.tcd.ie> Date: Wed, 8 Nov 2017 00:40:37 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="P9SdcQD2PJLJjNANDuLhEGRTLvCTcTDO2" Archived-At: Subject: Re: [TLS] network-based security solution use cases X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 00:40:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --P9SdcQD2PJLJjNANDuLhEGRTLvCTcTDO2 Content-Type: multipart/mixed; boundary="1PGeJaNhECV8FGn1d9BocFp9TKGo244TB"; protected-headers="v1" From: Stephen Farrell To: "Nancy Cam-Winget (ncamwing)" , "Flemming Andreasen (fandreas)" , Florian Weimer Cc: "tls@ietf.org" Message-ID: <3db42c7c-2904-f11f-ab8e-116835669816@cs.tcd.ie> Subject: Re: [TLS] network-based security solution use cases References: <895D1206-28D1-43AB-8A45-11DEEC86A71D@cisco.com> <874lq868t3.fsf@mid.deneb.enyo.de> <6966da46-0f07-b518-4b6e-f2b5f599b050@cs.tcd.ie> <8448A3AF-CEAF-41F4-A43F-9ED7B209C7B9@cisco.com> <84562f24-7a4f-4a9f-264c-1edf1e41bebe@cs.tcd.ie> In-Reply-To: --1PGeJaNhECV8FGn1d9BocFp9TKGo244TB Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 08/11/17 00:23, Nancy Cam-Winget (ncamwing) wrote: > Hi Stephen, > Please see below: >=20 > On 11/7/17, 4:08 PM, "Stephen Farrell" wrot= e: >=20 > =20 > Hiya, > =20 > On 07/11/17 23:53, Nancy Cam-Winget (ncamwing) wrote: > > Hi Stephen, Adding to Flemming=E2=80=99s comment, finding =E2=80= =9Cexact quotes=E2=80=9D > > will be difficult=20 > =20 > I'm sorry but when making a claim that such and such a regulation > *requires* breaking TLS then you really do need to be that precise.= > [NCW] In TLS 1.2, not sure why you state *requires* as there is the vis= ibility afforded to=20 > at least allow for the identity disclosure to enable white or blacklist= for example. =20 Quoting from your draft wrt PCI-DSS: " Requirement #2 (and Appendix A2 as it concerns TLS) describes the need to be able to detect protocol and protocol usage correctness." That one is nice - you seem to be arguing for protocol non-conformance (or for weakening conformant implementations) in order to help ensure "protocol usage correctness." That kind of makes my head spin. Another quote wrt NERC: " In fact, regulatory standards such as NERC CIP [NERCCIP] place strong requirements about network perimeter security and its ability to have visibility to provide security information to the security management and control systems. " Where exactly did you see those "strong requirements" that presumably *require* breaking TLS? I don't see them. When I or others ask to be shown them we don't get shown them. To me that means those are not *required*. >=20 > > as their intent is really not to break things but > > rather want to ensure that inspection and oversight is available = to > > affect guards/protections within an (enterprise/data center) > > infrastructure. That said, PCI and other regulations will have = a > > lot of documents that one has to go through=E2=80=A6.one that kin= d-of calls > > explicitly to the use of packet inspection, firewalling and such = is > > in: > >=20 > > https://www.pcisecuritystandards.org/documents/SAQ_D_v3_Merchant.= pdf > =20 > The first mention of TLS there talks about protecting administrator= > passwords via TLS. That totally argues against deployment of any ki= nd > of MitM infrastructure. > [NCW] Agreed, they also state in ensuring that the newest TLS version w= here=20 > possible is used. BUT, they also expect monitoring and troubleshooting= =2E Sure. Not all monitoring *requires* breaking TLS. Same for troubleshooting. Of course people who sell kit for that or have been doing that for a while might want to see what they do as being mandatory/required/regulated-for but I'm not seeing it. > =20 > >=20 > > It is an assessment questionnaire for vendors to evaluate their > > compliance, the requirements speak to securing the network and > > systems including firewalls, DMZs and the ability to do packet > > inspection. > =20 > Please point me at the specific text. Given you added PCI-DSS to > your document I would assume you did the work already. If not, > that's a bit odd. > [NCW] From the link above, you can look at requirements in 1.3, > also Requirement 10 details the need to monitor and provide audit trail= s > for network resources and cardholder data You mean 1.3 on page 6 I guess. I see nothing on pages 6 or 7 that call for MitMing TLS. That seems to be about addressing and DMZs and firewall and router configs. Requirement 10 seems to be dealing with audit of accesses to cardholder data, not with TLS at all. I read pages 50-55 for that. Honestly, what you're saying is there does not seem to be there. S. > =20 > S. > =20 > =20 > >=20 > > Thanks, Nancy > >=20 > > On 11/7/17, 3:27 PM, "Flemming Andreasen (fandreas)" > > wrote: > >=20 > > Thanks for taking an initial look at the document Stephen - pleas= e > > see below for responses so far > >=20 > > On 11/7/17 4:13 AM, Stephen Farrell wrote: > >> Hiya, > >>=20 > >> On 07/11/17 02:48, Flemming Andreasen wrote: > >>> We didn't draw any particular line, but the use case scenarios > >>> that we tried to highlight are those related to overall securit= y > >>> and regulatory requirements (including public sector) > >> I had a quick look at the draft (will try read properly en-route= > >> to ietf-100) and I followed the reference to [1] but that only l= ead > >> to a forest of documents in which I didn't find any reference to= > >> breaking TLS so far at least. Can you provide an explicit pointe= r > >> to the exact document on which that claim is based? > > For NERC, you can look under "(CIP) Critital Infrastructure=20 > > Protection". CIP-005-5 for example covers the electronic security= =20 > > perimeter, which has a couple of relevant requirements and associ= ated > > text: > >=20 > > http://www.nerc.com/_layouts/PrintStandard.aspx?standardnumber=3D= CIP-005-5&title=3DCyber%20Security%20-%20Electronic%20Security%20Perimete= r(s)&jurisdiction=3DUnited%20States > >=20 > >=20 > >=20 > > To be clear though, the document does not specifically call out > > breaking TLS, but it does clearly call out the need to detect > > malicious inbound and outbound communications by leveraging an > > "Electronic Access Point" (e.g. IDS/IPS) to enforce the Electroni= c > > Security Perimeter. > >> I'd also claim that your reference to PCI-DSS is misleading, as > >> that same spec also explicitly calls for there to be good key > >> management specifically including minimising the number of copie= s > >> of keys, so at most, one might be able to claim that PCI-DSS is = ok > >> with people who break TLS in a nod-and-a-wink manner. But if you= do > >> have a real quote from PCI-DSS that calls for breaking TLS then > >> please do also send that (it's been asked for a bunch of times > >> without any answer being provided so far). > >=20 > > I will need to look more closely for such a quote - if anybody el= se=20 > > knows of one, please chime in as well. > >=20 > > Thanks > >=20 > > -- Flemming > >=20 > >=20 > >> Thanks, S. > >>=20 > >>=20 > >> [1]=20 > >> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00.htm= l#ref-NERCCIP > > > >>=20 > >=20 > >=20 > >=20 > >=20 > =20 > =20 >=20 --1PGeJaNhECV8FGn1d9BocFp9TKGo244TB-- --P9SdcQD2PJLJjNANDuLhEGRTLvCTcTDO2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaAlKFAAoJEC88hzaAX42iEB4IAJkj4y6R81HhsIwrTKkG3rCh E4VeMQI/hHjT/YDEWDMqO3fJv5m6OWb97T1DBLW+3VsJY+HZ1vtuyev+XfLGxlZi Ojvpm18VFqbIARmukzUH0xoLIp/8s9LTANtUmG+lGjSo6PC2y7yNwkBVHA6dnyma VnPw38zlCHcsUwh3GwR3qLbW//CnQToI0J3ck925jKHqAx/0bQvt4CR5ZxbsHpLj sBk0WlNyBaoeEwEwZQzAVOO/gtMswl7Gw5YHyMxhBsgpvmMky/1M5n0Ea2yl+Wt9 qXspPli94xqC8RVWOigZWY9GWICOMppSz2BE35vCXE89alnE+0/Hm7QvchpruxY= =EMk/ -----END PGP SIGNATURE----- --P9SdcQD2PJLJjNANDuLhEGRTLvCTcTDO2-- From nobody Tue Nov 7 16:41:25 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFBA612D0C3 for ; Tue, 7 Nov 2017 16:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 NxhFwumdCQAU for ; Tue, 7 Nov 2017 16:41:21 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 28C72129C3E for ; Tue, 7 Nov 2017 16:41:17 -0800 (PST) Received: by mail-oi0-x235.google.com with SMTP id g125so789746oib.12 for ; Tue, 07 Nov 2017 16:41:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q+HER7ynNI//2Ymb5lpZWdX2g8UcOO5K4+zhAzmjQAo=; b=i60oA24R+45ZaDKikexHiAHOTMc6JBWXN3TkE1tJm0Tqn8RSpk0XCtP6IDRms/lM2L NprNF4z1zb+5DwpS4YpvfnzzdEtKV0LmdNCbVavCrx8xu9d0IeSdQdhkm5UwRu1hInXf 3lE2hsCcEp+GB8LvQQzbGaByFFq83uhi3X549Cl+jAL8CAp0NINa/EwJ6QZJ/+9fadTy 0Kzsd5w0Zu4z8NGmoY3s/5bA0w++JQN8I9EHI0jKzMhin2JNT2R6FOfrZSjmsoYB5vcI DcOdieC2kDjD6Wuz54WvNCEE5g3bTRujDPAEMCEiyFGMJl0aKhkUPsbIk+HeneGNyvp+ bG4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q+HER7ynNI//2Ymb5lpZWdX2g8UcOO5K4+zhAzmjQAo=; b=mFaYUVA9YnUtMchlOV9M245PxmIxeZMcLmMiF58AtOc6kbOWsbgCnl0crfd1hg7jey /5CX5ycwmqTtJHZccMGYYrF6rfvgLw2nEjMh3XhJ3r8OjHT0Ac8Kpihi3qhFwEt8uVD2 asbMYBYD0+ndRy2K2kp3lVUAaClYtc/qSFKIXh86VTJE1/ZJ/i6S6pMw/+M6G3QC3VeS uLyKGc1DKx1R1AutWAWxQAQvqOqNXwAHWz4/I027WgNl1TiDYAtssY9mTE3MLP1Z2CoP zn8N6yWdDXmonjmSCmP1P1DwS0zqGdS1ogFSDSRAWnHBrb2Q4GwXuNkD+HNPpk58RYaq 2X9w== X-Gm-Message-State: AJaThX7wgni9RtmBfAjrUaj/dze/q8TYnmDuyBjLikUJQnrc2gVs6Hp2 Xk0NJc22hps1GSvpZHB3WQnrcrjdRcOpZCsYuGc= X-Google-Smtp-Source: ABhQp+THlJ8nJz8z2cnoPpVklVZV52YxAOXai0eTXdOdM12HM0/6n8wsLANwqjRcawx1Yn/qjIjSN/BlNI6KXSXL7ys= X-Received: by 10.202.75.216 with SMTP id y207mr337023oia.282.1510101676465; Tue, 07 Nov 2017 16:41:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.15.155 with HTTP; Tue, 7 Nov 2017 16:41:15 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Wed, 8 Nov 2017 11:41:15 +1100 Message-ID: To: Eric Rescorla Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 00:41:24 -0000 On Tue, Nov 7, 2017 at 5:19 AM, Eric Rescorla wrote: > - The client sends a fake session_id and the server echoes it One friendly amendment. I think that we should insist (with a MUST) that the server send CCS in the case that it receives a non-empty session_id. That gives clients the ability to insist on use of the compatibility hack by a server. Evidence shows that the server can't ensure that these (expletive deleted) middleboxes don't mess with the connect unless the client takes the steps that are outlined here, so it has no way to control the use of the compatibility mode. On the other hand, having the server not send CCS when compatibility mode was needed would somewhat undermine the client's efforts. From nobody Tue Nov 7 16:47:16 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04801129BF8 for ; Tue, 7 Nov 2017 16:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 EgeJhy-v8CeO for ; Tue, 7 Nov 2017 16:47:12 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 DFE0712751F for ; Tue, 7 Nov 2017 16:47:11 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id v137so1420374qkb.1 for ; Tue, 07 Nov 2017 16:47:11 -0800 (PST) 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 :cc; bh=aSprGuZelRvcRigavEN32BqVtSCDBkKAehqSBr4hDVk=; b=G2a5hMh3SBNRZws1YXk52WKCRAmp84Koyoth1dDnamg09/5xQb8IR80i6zseKmXkqm TtZ5BRypsPjdLysRD0qCSeY96rP1zHA7eKJ63XY9rq7nKwzQohDsnO7fRXIRSnTnmh82 XdDplvwobEHBHgZzBkFsPrSf3IdKiL9Uoj10o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aSprGuZelRvcRigavEN32BqVtSCDBkKAehqSBr4hDVk=; b=LtHsEOFx4mfyqRoBiCdKcK4uH5CO2q+KrClQcCsJ30c0x6q0ZXmYNBfRUeBi3NlFRG N+PeSj5G5vRZy6dj6vKIE6mZEZDxmwJcdcdEk95sgXvEF6WgVM1z9O3A+NIm7OhoCK9j woUXFClxAtFbSoA2nR8FKa5gGJiu7GWjXhLpt0INvG60hVV+K3UwSEiqA9HgiEH2ZVGS iy15x2lPHSMb/cWj2zJo3NALRglcFjPch+fUxj6sADus1sH+xA+WJx90ePcxBMzywS6R bx7I+yEMV1w60S8cTOF7WTNbyfqspIFXSkMPvw5y2KAHN0X9cEmaA25rncNXdCiBZYOn rAtA== X-Gm-Message-State: AJaThX4m53D0c3HStD6AKPzE4bhOJ/OOQWFokxxGF/At/3OLKPuACPpn gkrX87dH7A+TLG8/3PNCUutvOrjl/qraqV91dR3h X-Google-Smtp-Source: ABhQp+QHSTbEYiMeDSyrv9yOo8AOfWKYE6ko9NflIU22YvxVPTeZKKPrgb2grQHOyugYEnkv0rSIOzSGZBg489midb8= X-Received: by 10.55.34.135 with SMTP id i129mr887987qki.86.1510102030752; Tue, 07 Nov 2017 16:47:10 -0800 (PST) MIME-Version: 1.0 References: <4406543.RZChgRkkf9@pintsize.usersys.redhat.com> <6818962.9GzJR6rN5C@pintsize.usersys.redhat.com> <965B995B-A5B3-4322-B13A-A2D82AFD2743@akamai.com> In-Reply-To: From: David Benjamin Date: Wed, 08 Nov 2017 00:46:58 +0000 Message-ID: To: Eric Rescorla Cc: Watson Ladd , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1147fd781eae58055d6e0786" Archived-At: Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 00:47:15 -0000 --001a1147fd781eae58055d6e0786 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 7, 2017 at 7:32 PM Eric Rescorla wrote: > On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd wrote: > >> On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar wrote: >> > FWIW: In my experience middleboxes don't ossify based on what the spec >> says, >> > they ossify based on what they see on the wire. So, if common >> > implementations send CCS in a particular way, that's what will get --- >> and, >> > I'll argue, what has gotten --- ossified. I also agree with David and >> Eric >> > that compatibility mode shouldn't be required because QUIC doesn't need >> it. >> >> What does compatibility mode mean here? > > > It means: > > 1. Send the fake session_id > 2. Send a bunch of spurious CCS values. > > > If we end up with having two >> slightly different versions of TLS 1.3, one that looks more like TLS >> 1.2 and the other that does not, that doesn't seem like a good thing >> to me. >> > > Well, the idea is that this is a purely local decision by one side. > In particular, either "mode" leaves everything interoperable with everything else, modulo middlebox misbehavior. The arrangement with CCS and session_id is that the sender MAY send some random vestigial junk that the receiver MUST ignore. If you know your implementation lives in a context whether it doesn't matter (QUIC, internal networks, a happy unrealistic future where networks are made of unicorns and sunshine instead of middleboxes), you can avoid sending the useless bits. Otherwise, you probably want to send it. -Ekr > > >> My understanding is we already have ossification here and the debate >> is what to do about it. >> >> >> -- >> "Man is born free, but everywhere he is in chains". >> --Rousseau. >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1147fd781eae58055d6e0786 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 7,= 2017 at 7:32 PM Eric Rescorla <ekr@rtfm.com> wrote:
On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
On Tue, Nov 7,= 2017 at 4:05 PM, Jana Iyengar <jri@google.com> wrote:
> FWIW: In my experience middleboxes don't ossify based on what the = spec says,
> they ossify based on what they see on the wire. So, if common
> implementations send CCS in a particular way, that's what will get= --- and,
> I'll argue, what has gotten --- ossified. I also agree with David = and Eric
> that compatibility mode shouldn't be required because QUIC doesn&#= 39;t need it.

What does compatibility mode mean here?

<= /div>
It means:

1. Send the fake sessi= on_id
2. Send a bunch of spurious CCS values.
=


If we end up = with having two
slightly different versions of TLS 1.3, one that looks more like TLS
1.2 and the other that does not, that doesn't seem like a good thing to me.

Well, the idea is = that this is a purely local decision by one side.

In particular, either "mode" leaves everything interoperabl= e with everything else, modulo middlebox misbehavior. The arrangement with = CCS and session_id is that the sender MAY send some random vestigial junk t= hat the receiver MUST ignore.

If you know your imp= lementation lives in a context whether it doesn't matter (QUIC, interna= l networks, a happy unrealistic future where networks are made of unicorns = and sunshine instead of middleboxes), you can avoid sending the useless bit= s. Otherwise, you probably want to send it.

-Ekr
<= div class=3D"gmail_quote">


My understanding is we already have ossification here and the debate
is what to do about it.


--
"Man is born free, but everywhere he is in chains".
--Rousseau.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a1147fd781eae58055d6e0786-- From nobody Tue Nov 7 22:50:40 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FC912ECA6 for ; Tue, 7 Nov 2017 22:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 QdlOVm81Km28 for ; Tue, 7 Nov 2017 22:50:36 -0800 (PST) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (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 63CD612EC9A for ; Tue, 7 Nov 2017 22:50:36 -0800 (PST) Received: by mail-wr0-x22d.google.com with SMTP id p96so1424031wrb.7 for ; Tue, 07 Nov 2017 22:50:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=+X/PK5f5RalOHIaPUtBFeSHqpSu/Vm93NK+6HlWtgzM=; b=rfy6dzC9EmX9DHpRI73WDJ/L8b+xTe1bOs4DVvuuKJs7pHuelzn+NMvVTkTOnlpBwY 0UU9FnVUh8xbgj49qDGKZ00E1Xtm+4mT9J5oUqwx2Svb0n31i5SdnrFMYJoW/1DFnJii FhVUy/z5xHnX4+C4ZVPpRZGkhMDGH1vZIGPemIOGcLiPMtDsZIEtbG52U3yAZuAgHVeK rC+MTA2jHjl1RSqGD5VWEveN+niBiReiiq1aI16M6uD8TSgJU+/C9ZCkqhl+2JSd+L/W SO3K01H8BVKiel3QJUggp/5rLSKyV3ze+pUsbCkaUh+ErQnWHJps7CP1vbmXSxrHVoKv cCuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=+X/PK5f5RalOHIaPUtBFeSHqpSu/Vm93NK+6HlWtgzM=; b=Fmez9/64KlY+BySp1669AArXlBBohhFMNms3vS6ATrszl4gRy25z50z5TYD/rPX7eN c1IFW0gLxi0uz3jNyrmooCDkqqZrnJyGlYG8jLrj8ts86IjCG/WZNpswUWEpwwXnR2gr wqjQbFJx+8oDvi3D1NFA0ZEMtZmypbRIj5jnhnLpXevUbXr1R9MJ57iHKDTEa6qPVgb/ Yg+weLtVlSF5DWtL7IetaXQytNv4CIb+hghbFbVNVnaRUS1imJbBJykRY+O2/cNQB+CB k0WSxKwoV1L4i0CoJOJPrY1QRNdwOm/KdidvcxUn6BZFzs+U8XnGLRPyCI+qDr5pEWeB UxSA== X-Gm-Message-State: AJaThX4vF1rZVwCkofJjO1VWsGq/A5xu5RspSDwBOVtG5GEH5zXWMQL1 1uAWFScyJ0SfqR8DhduWs+nOSF1A X-Google-Smtp-Source: ABhQp+TJ8VPhhTUGeNcqyZpE9saBBNuEWMii2R8sS4wTqL0p8DFzA5+KdQdcvi+UJFm65Azyf+CnlA== X-Received: by 10.223.202.1 with SMTP id o1mr947767wrh.205.1510123834929; Tue, 07 Nov 2017 22:50:34 -0800 (PST) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id m37sm3980741wrm.4.2017.11.07.22.50.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Nov 2017 22:50:34 -0800 (PST) From: Yoav Nir Message-Id: <0357F569-0F1C-4B55-95C1-730C2AB0D988@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1A5B0FFD-9B40-4AD7-BEA3-31480EA51859" Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Wed, 8 Nov 2017 08:50:31 +0200 In-Reply-To: Cc: Eric Rescorla , "tls@ietf.org" To: Rich Salz References: <4406543.RZChgRkkf9@pintsize.usersys.redhat.com> <6818962.9GzJR6rN5C@pintsize.usersys.redhat.com> <965B995B-A5B3-4322-B13A-A2D82AFD2743@akamai.com> X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 06:50:39 -0000 --Apple-Mail=_1A5B0FFD-9B40-4AD7-BEA3-31480EA51859 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 8 Nov 2017, at 2:32, Salz, Rich wrote: >=20 > =E2=9E=A2 Given that we're almost there, and that only really browsers = are > asking for these hacks, and that even some of those were almost = ready > to ship without these hacks, I don't think that this is entirely > unrealistic as an aspiration. >=20 > The Internet is more than just a couple of browser executables. >=20 > Does nobody think of the servers? > =20 > I do, but I don't really see how they're relevant for this question. = Don't the servers control the middleboxes they are behind? > =20 > The smiley got lost. But smiley isn=E2=80=99t quite the right = emoticon either.=20 Maybe we need a resigned to the harsh reality emoticon. Oh wait, there = is one [1] > But to answer your question: no, the often don=E2=80=99t. And it=E2=80=99= s not just the middleboxes they are behind, but all those along the way. The server-side middleboxes tend to be somewhat higher quality and get = more regular updates. There are also fewer vendors, so the problem is = more manageable. > =20 > To say that only browsers were asking for these hacks is also a little = disingenuous. It was a self-selected design group (to be charitable) = that mostly worked by themselves without the whole WG being involved. = I=E2=80=99m glad we seem to be ending up with something that works, with = the only thing being lost is some nerd esthetics, but let=E2=80=99s not = forget the (to me, disappointing) way the whole thing went down: a = collaboration among, and only among, Google, Mozilla, and Facebook. Sure. Whatever applies to browsers applies to every app or library that = uses a web service. So wget, cURL, any of the libraries for Java, = whatever you call the libraries behind apps on the various mobile = platforms.=20 Yoav=20 [1] https://www.urbandictionary.com/define.php?term=3D%F0%9F%98%8C --Apple-Mail=_1A5B0FFD-9B40-4AD7-BEA3-31480EA51859 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 8 Nov 2017, at 2:32, Salz, Rich <rsalz@akamai.com> = wrote:

=E2=9E=A2 Given that we're almost = there, and that only really browsers are
    = asking for these hacks, and that even some of those were almost ready
    to ship without these hacks, I don't think that = this is entirely
    unrealistic as an = aspiration.

The Internet is more than just = a couple of browser executables.

Does = nobody think of the servers?
 
  • I do, but I don't really see = how they're relevant for this question. Don't the servers control the = middleboxes they are behind?
 
The = smiley got lost.  But smiley isn=E2=80=99t quite the right emoticon = either. 

Maybe we need a resigned to the harsh reality = emoticon. Oh wait, there is one [1]

But to = answer your question: no, the often don=E2=80=99t.  And it=E2=80=99s = not just the middleboxes they are behind, but all those along the = way.

The server-side middleboxes tend to be somewhat = higher quality and get more regular updates. There are also fewer = vendors, so the problem is more manageable.

 
To say that only browsers were asking = for these hacks is also a little disingenuous.  It was a = self-selected design group (to be charitable) that mostly worked by = themselves without the whole WG being involved.  I=E2=80=99m glad = we seem to be ending up with something that works, with the only thing = being lost is some nerd esthetics, but let=E2=80=99s not forget the (to = me, disappointing) way the whole thing went down: a collaboration among, = and only among, Google, Mozilla, and = Facebook.

Sure. = Whatever applies to browsers applies to every app or library that uses a = web service. So wget, cURL, any of the libraries for Java, whatever you = call the libraries behind apps on the various mobile = platforms. 

Yoav 



= --Apple-Mail=_1A5B0FFD-9B40-4AD7-BEA3-31480EA51859-- From nobody Tue Nov 7 22:52:30 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F01A012EC69 for ; Tue, 7 Nov 2017 22:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 W0V7C1nXrw6P for ; Tue, 7 Nov 2017 22:52:27 -0800 (PST) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (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 854F412EA24 for ; Tue, 7 Nov 2017 22:52:27 -0800 (PST) Received: by mail-wr0-x236.google.com with SMTP id k61so1437037wrc.4 for ; Tue, 07 Nov 2017 22:52:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZeAXAvLpU9AmHOMMfBoGJOby8GMwCRULCVPwzISuoeE=; b=NV+xovjDbGs8d9gjlXF93QBfk1BI/ur2NHwQr/RE9JoTZfDhqKVCsF3iXlOTdIwYAs CWZq/JKoajtmbOLll7FOijbVCga/dPad6WKLnr8TfdXJJMlO1Sj5CZg9bECdFQ2mj2DQ e4vgpzchlC8rMY/v+Q15c/flGLCv42rz5j2YTooskbv4LFS2hnv9ufK3TmvMc211w4IL 0eCtoUFIhm3BfOQ6Vgwq0/Gjw5LSN/sXyvI/WbuItwdlpNHMqCvfqYd3gri2gteu4BX8 T4qq4MQHIHS7qDyv0hq6B/bBen6MMAPYpnLgpIpBUOzgmFGq81YRX9e/wb/EaMf++3O0 Kcvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZeAXAvLpU9AmHOMMfBoGJOby8GMwCRULCVPwzISuoeE=; b=ogHkMX3tz6Nsp/E8Jq3LzES20qQJGy6jOGk3qhq7XUtfJ3KjmNgnutbBRfNaC2J/zT hpiMBWw46ixVZ+EkezLznKnPxPz6j7JnfT+yMlSAjOsrj18k8nCXlV6UK3cEDLFNaUVy rQ00w7SyBwpfUoJdnc9TG+l8EOZZQ3RMIYj5jz+bl05xf11Cazqu2AMd6NUzpGhOvtfa jIrWlPSY9vvIL9Vbh9jWwWd2jh8Rc1qJaNPuIz6mPDqY08zcvSkqPunAcC6PeP7pt9mF G+ECbEz2LeJpVGjJig4BpjKTiZWc//n/Tnei6Dwaq9f2YZlFl0ojwg6ZDimMEK3aIpZy 4PBQ== X-Gm-Message-State: AJaThX6GjwT8uPFqMwhasesnWLgneEpCcdFTX6Dchpt4zYpEOmmjMsqc IApbr9eERzTrNUdkHimfnAc= X-Google-Smtp-Source: ABhQp+ROLROrBrqyHmNb7V2DZhIRxDtlbeV/fYvp2CyUsAiSHDTcD9vi/hrb5t92OqhUMWyheNazrA== X-Received: by 10.223.176.220 with SMTP id j28mr871844wra.99.1510123946122; Tue, 07 Nov 2017 22:52:26 -0800 (PST) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id s12sm7623634wrc.89.2017.11.07.22.52.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Nov 2017 22:52:25 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Yoav Nir In-Reply-To: Date: Wed, 8 Nov 2017 08:52:23 +0200 Cc: Jana Iyengar , "tls@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6108A155-1317-4210-89BA-E32ADE349C94@gmail.com> References: <4406543.RZChgRkkf9@pintsize.usersys.redhat.com> <6818962.9GzJR6rN5C@pintsize.usersys.redhat.com> <965B995B-A5B3-4322-B13A-A2D82AFD2743@akamai.com> To: Watson Ladd X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 06:52:29 -0000 > On 8 Nov 2017, at 2:25, Watson Ladd wrote: >=20 > On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar wrote: >> FWIW: In my experience middleboxes don't ossify based on what the = spec says, >> they ossify based on what they see on the wire. So, if common >> implementations send CCS in a particular way, that's what will get = --- and, >> I'll argue, what has gotten --- ossified. I also agree with David and = Eric >> that compatibility mode shouldn't be required because QUIC doesn't = need it. >=20 > What does compatibility mode mean here? If we end up with having two > slightly different versions of TLS 1.3, one that looks more like TLS > 1.2 and the other that does not, that doesn't seem like a good thing > to me. So you=E2=80=99d prefer that we just make this compatibility mode = mandatory and always use it? Despite the wasted bits, I think I=E2=80=99m= with you on that. Yoav From nobody Wed Nov 8 01:12:15 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A3E13183C for ; Wed, 8 Nov 2017 01:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.421 X-Spam-Level: X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=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 K3Eq6dBsejX6 for ; Wed, 8 Nov 2017 01:12:13 -0800 (PST) Received: from mail-wm0-f65.google.com (mail-wm0-f65.google.com [74.125.82.65]) (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 DFA82131878 for ; Wed, 8 Nov 2017 01:12:12 -0800 (PST) Received: by mail-wm0-f65.google.com with SMTP id z3so9161942wme.5 for ; Wed, 08 Nov 2017 01:12:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=IV2vyjcMK00uRLFSMv4heXK5wt4K5IgmUL3dUmM1nlU=; b=SxQa0CBBI8MtQEhbqGk3m//FsTsgEHJNdYb5tQk0JQ8j9ovKkhbZ6qq4E/kSR+/UiW oB6oXRwBPXNo55B1SBslxhFnLmZd6Ox3jCUoOaSqpSMZXb0vg0OHtobcBLMT0R2kKGvh 6g4Bchys4dIPinH32HY00asrLJlAMea0pWQ0y8CPPrsSPW4b6CmXXIShfKSUaHFkXtkP i17XQa0gJOrjipHSWeiRwr3ZJP3o40mAuzIDZO/+0ynCIUeWaFwYj98PLAizWtmdp0J8 ei4zdEy/I/c1GyxTLtpjTddJIWa2+JAq+52Ill5JdOPX52vLXOGZkePL2SB78z3rQ8oZ fuZQ== X-Gm-Message-State: AJaThX6XiNcDCpg4aDfc1mFgA4G/alN/0aiuV2SZy+A3lOe7Kp2Boimj DN+Vp19DqcdBqa5mXiv60KdgIA== X-Google-Smtp-Source: ABhQp+Sks5EUpHzQ4UqpZ6x4dLlKgy1uXrLkFMfvCPgvNmC3yzDiuO3CP8BPAJ7I6aYnzoK6ATYzww== X-Received: by 10.80.170.107 with SMTP id p40mr2623338edc.158.1510132331026; Wed, 08 Nov 2017 01:12:11 -0800 (PST) Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id i16sm3157519edj.77.2017.11.08.01.12.10 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 08 Nov 2017 01:12:10 -0800 (PST) Message-ID: <1510132329.17184.123.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Eric Rescorla , Watson Ladd Cc: "tls@ietf.org" Date: Wed, 08 Nov 2017 10:12:09 +0100 In-Reply-To: References: <4406543.RZChgRkkf9@pintsize.usersys.redhat.com> <6818962.9GzJR6rN5C@pintsize.usersys.redhat.com> <965B995B-A5B3-4322-B13A-A2D82AFD2743@akamai.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.6 (3.24.6-1.fc26) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 09:12:15 -0000 On Tue, 2017-11-07 at 16:32 -0800, Eric Rescorla wrote: > > > On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd > wrote: > > On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar > > wrote: > > > FWIW: In my experience middleboxes don't ossify based on what the > > spec says, > > > they ossify based on what they see on the wire. So, if common > > > implementations send CCS in a particular way, that's what will > > get --- and, > > > I'll argue, what has gotten --- ossified. I also agree with David > > and Eric > > > that compatibility mode shouldn't be required because QUIC > > doesn't need it. > > > > What does compatibility mode mean here? > > It means: > > 1. Send the fake session_id > 2. Send a bunch of spurious CCS values. > > > > If we end up with having two > > slightly different versions of TLS 1.3, one that looks more like > > TLS > > 1.2 and the other that does not, that doesn't seem like a good > > thing > > to me. > > Well, the idea is that this is a purely local decision by one side. Which increases the cost of TLS1.3 implementation and testing by introducing different handshake state machines. Why not negotiate that CCS addition with an extension and have it defined outside the TLS 1.3 spec? I understand the concerns of the browser "community" on being 100% backwards compatible with middle boxes, but the TLS1.3 standard is more than just browsers. If 100% compatibility is required, there is a very simple solution, use TLS 1.2. regards, Nikos From nobody Wed Nov 8 04:01:45 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8581200E5 for ; Wed, 8 Nov 2017 04:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 av31yTtcdliG for ; Wed, 8 Nov 2017 04:01:41 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB9631200CF for ; Wed, 8 Nov 2017 04:01:40 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 01B3D25CC0; Wed, 8 Nov 2017 12:01:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 01B3D25CC0 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hkario@redhat.com Received: from pintsize.usersys.redhat.com (ovpn-200-45.brq.redhat.com [10.40.200.45]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7BD765D964; Wed, 8 Nov 2017 12:01:39 +0000 (UTC) From: Hubert Kario To: Eric Rescorla Cc: "tls@ietf.org" Date: Wed, 08 Nov 2017 13:01:37 +0100 Message-ID: <4651345.7yjsJ4Y0gv@pintsize.usersys.redhat.com> In-Reply-To: References: <6818962.9GzJR6rN5C@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2480396.r9l4BcvYBj"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Wed, 08 Nov 2017 12:01:40 +0000 (UTC) Archived-At: Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 12:01:43 -0000 --nextPart2480396.r9l4BcvYBj Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 7 November 2017 19:31:23 CET Eric Rescorla wrote: > On Tue, Nov 7, 2017 at 10:11 AM, Hubert Kario wrote: > > On Tuesday, 7 November 2017 18:17:33 CET Eric Rescorla wrote: > > > On Tue, Nov 7, 2017 at 7:39 AM, Hubert Kario wrot= e: > > > > In general +1, I like to see TLS 1.3 deployed ASAP and making the > >=20 > > spurious > >=20 > > > > failures as rare as possible is a good way to make that happen. > > > >=20 > > > > that being said, I have few comments: > > > >=20 > > > > On Monday, 6 November 2017 19:19:01 CET Eric Rescorla wrote: > > > > > https://github.com/tlswg/tls13-spec/pull/1091 > > > > >=20 > > > > > As I mentioned a while back, we've been seeing evidence of middle= box > > > > > intolerance. I just posted PR 1091, which is based on a bunch of > > > > > work > > > > > by the BoringSSL team and an original suggestion by Kyle Nekritz > > > > > that > > > > > should significantly decrease the rate of these errors. > > > > >=20 > > > > > The general idea here is to make TLS 1.3 look more like TLS 1.2 > > > > > resumption. The major changes are: > > > > >=20 > > > > > - Move version negotiation entirely into "supported_versions", and > >=20 > > hence > >=20 > > > > > ServerHello.version =3D=3D 0x0303 (TLS 1.2) > > > > >=20 > > > > > - Restore the missing session_id and compression fields in > >=20 > > ServerHello > >=20 > > > > less special cases in parser code - big +1 > > > >=20 > > > > > - The client sends a fake session_id and the server echoes it > > > > > - The server sends ChangeCipherSpec messages after > > > > > ServerHello/HelloRetryRequest > > > > >=20 > > > > > (so that the middlebox ignores any "encrypted" data afterwards), > > > > > and the client sends ChangeCipherSpec after ClientHello. Either > > > > > side has to ignore ChangeCipherSpec during the handshake. > > > >=20 > > > > That's the part I have a bit of a problem with. > > > > If the CCS is necessary to make middleboxes work, and given that > > > > lack-of-CCS- > > > > intolerance is not something that we can detect reliably (not in a = way > > > > that > > > > can be simulated by an attacker), I think the CCS should be baked in > >=20 > > the > >=20 > > > > TLS > > > > 1.3 as deep as it was baked into TLS 1.2. > > >=20 > > > You don't detect it on an individualized basis. Rather, you measure > >=20 > > whether > >=20 > > > it's > > > necessary and if/when the necessary level of CCS becomes low enough, = you > > > just stop sending it ever. > > >=20 > > > > That is, the standard should make it a mandatory message to send, > > > > fully > > > > parsed > > > > and validated, requiring aborting connection if it is received at a= ny > > > > unexpected moment, in duplicate, omitted or malformed. Not only as > >=20 > > part of > >=20 > > > > the > > > > "compatibility mode". > > >=20 > > > Yeah, I'm not enthusiastic about this. It's more stuff in the state > >=20 > > machine > >=20 > > > that > > > we hope to eventually eliminate. And as David says, it's totally > >=20 > > unnecessary > >=20 > > > for QUIC and DTLS > > >=20 > > > -Ekr > >=20 > > what I was getting at is that if you want to be compatible with > > middleboxes, > > you send that CCS always, as you never know what thing will be between = you > > and > > the peer > >=20 > > that means that all the large implementations will be sending them alwa= ys > >=20 > > that means that new middleboxes will likely end up expecting it either = way > > and > > existing ones won't have much incentive to update/fix > >=20 > > secondly, if we allow for sending CCS at any point, we will end up with > > the > > same bug as the Alert processing DoS there was in some implementations = =E2=80=94 > > one > > that allowed the peer to send unlimited amount of warning alerts >=20 > Given that this is (a) not encrypted (b) just discarded and (c) only > allowed during the handshake, this > doesn't seem like much of a DoS. same could have been said about the warning alert handling, yet not even a= =20 10mbps flow could completely lock up 4 cores of a 3GHz Haswell CPU yes, it all depended on how they were handled, but point still stands, 2 ma= jor=20 implementations got it wrong and given the information we were provided, I don't see a need to send=20 multiple CCS messages > > so even if we mark it as optional, I still think we should allow for it= to > > be > > sent at only very specific moments and only once per side >=20 > I might be fine if it were required in this way, but not fine if it was > required that one enforce it. by "enforce" you mean "enforce CCS being sent" or "enforce that a single CC= S=20 was sent"? And to answer the "Don't the servers control the middleboxes they are=20 behind?": No, they do not. And with B2B communication you never know what will be=20 looking on-route on the connection. It's not inconceivable that even a 3rd= =20 party that is _not_ an ISP controls those middleboxes is involved. Let alon= e a=20 different team that has different priorities that people that need that=20 connection working. In the web world you may think that we're already in the 2020s. In some=20 enterprise networks people just recently noticed that we crossed to the new= =20 millennium. (I'm of course joking, but the internal networks and Internet work on=20 completely different timescales) =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart2480396.r9l4BcvYBj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJaAvIhAAoJEJKo0bgB0vX1eZAP/1sa4xYfMiiXFETSw9ljMkv2 /JyLSdgiqZbSfDLUWgZGt71j4ybAXySl2qajnNHBOHc6ZXxDj7p3E1HIqPVGL1A5 8hJydBc3qKtfgjhO9PWiA42T69BGVa8Q9fq46km8QLobngskVvY6pMAz3ELEsvyS apDvp8TO5UcSoQFknaAfaYn6oie5bPwgP/FARqXh7EkpnglQn2xiBiuYi0aNKNs8 4MWFXi5zgFaF2IrfRttcpcqm0Q9lKQJZReCbU5aY8NhK+stqjVK8sAmTmK1TSe7i 8oPSLb8ZaMAPdQH7bfxGO72mozjTOf3Q5WfcqscovdE+MuuAav7xFAl2o7bZLZR3 OBZX+9+x3kK6usUWGKN+bkIrndpr7Ie2t+0D5cU9gSFpBNdnz1v4ZhZVxdOj9uBR Z/FgPtDzddHQkgNHWXH77CIns6zSFrkYP5p1lFwep1t7P7eBlPCFN5dtSyCQJo67 80rRlePXLWyZKtK7AfMmYJjv0Ig0VifGpBVWtNEmDQu2gHgk3AyP3uVnX/hjQJPA 01mrdovJqD0ZMDRt/1Th3wJmqg1qbTXynBZsoCd4xmwIpxZswIrIXfZ2JL8t0Rx7 /Wa1xI07wJjawW/3Fzy4sO1XHzAjo5x2MhmN9qMRDhWkqgOX8+/Er6wXmzeu5O5b NQzf0sNBNNf0wq8c16sd =Evan -----END PGP SIGNATURE----- --nextPart2480396.r9l4BcvYBj-- From nobody Wed Nov 8 05:35:24 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B32126D45 for ; Wed, 8 Nov 2017 05:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 SpU-B_msQEgC for ; Wed, 8 Nov 2017 05:35:21 -0800 (PST) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 CBE7B126CF9 for ; Wed, 8 Nov 2017 05:35:16 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id y75so2290393ywg.0 for ; Wed, 08 Nov 2017 05:35:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jreJXShnkxNS+QAML+Tdtfo7/1o8kpQiMkME0ebHv4Q=; b=bBJqdaXG1v8tVRwftJA7Ao51fvTd2HL0ho7Y2j+A6jNIjyAiE1tEzHnFJLViHG8//O HrLlVwPTvYuJ6g/lAQizSuoS56XJ8+z8CoDHkEzlw7v2lGVvXn+AxUPXHNPsz7rd933j iEJLZ3vK1Vts2tRJN436HWazrAIH/6QBgcpgMaIGn2RFqemU3793Wmy/8kMv1EW+/Jro VMap25SJPOXhSPzhPOW0mtj3HRV9Q3MtaLPMzSOEk97Pfbvf0Wg4bXKf43wzPApcJknF pAIVoc49/GpLwKkaM8WWEJdwETO5IyZsK8krnBMBkEWTPLSXYw+FNm38DLLpRBB8CJNE wC7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jreJXShnkxNS+QAML+Tdtfo7/1o8kpQiMkME0ebHv4Q=; b=HJiNv5GqPXsy7xlPFSGvPxQVfrvdGwVSouDsniudutIpQDjXbQNTFGcVdXonoJeRK1 t9fGTkv9is3d3fXgyoMaRvvsjPI4e+xOq3/EeZ/GTrEpTug7mtCsTVhEsGIa+QC8uRuD YaD96DGnNEKaManOki4L6pilEzURrv8efucXWbxV2MhKbn3Q9HV6TFjOoV6PAYpBoh0x N+Z6QHINTXM8KrDdUzQ0lNmnU8mdVwGCJ0KdmTvvXNZPwAySaYTZRrONQPNQWgER7Nc9 6iaAmf/zSVm1qNbCCQGRjAMY7uWBEuTmXAjGef3axU+QdSMzUCbyg/P/I8EmMxtkW23F Pg/A== X-Gm-Message-State: AJaThX4FtCgO9gJPb/B8Uat1eciMCZfeVosnKoJG1yls7VHr/TQQ21QJ vtpsO8Hw5jwFfemVl6GQNVtjfSuEHBtueBxuIKvVjg== X-Google-Smtp-Source: ABhQp+Tf5+qpnm1IAWtaPq41kmi/LhAY9yzc34KG6nzn+y+fdeWG4i+FoQITQO9hJADHPlZeid+aKY0XB2FJh3wgyFE= X-Received: by 10.129.173.99 with SMTP id l35mr361154ywk.132.1510148115964; Wed, 08 Nov 2017 05:35:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.61.12 with HTTP; Wed, 8 Nov 2017 05:34:35 -0800 (PST) In-Reply-To: <1510132329.17184.123.camel@redhat.com> References: <4406543.RZChgRkkf9@pintsize.usersys.redhat.com> <6818962.9GzJR6rN5C@pintsize.usersys.redhat.com> <965B995B-A5B3-4322-B13A-A2D82AFD2743@akamai.com> <1510132329.17184.123.camel@redhat.com> From: Eric Rescorla Date: Wed, 8 Nov 2017 05:34:35 -0800 Message-ID: To: Nikos Mavrogiannopoulos Cc: Watson Ladd , "tls@ietf.org" Content-Type: multipart/alternative; boundary="f403045e8bde02b62d055d78c2a8" Archived-At: Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 13:35:23 -0000 --f403045e8bde02b62d055d78c2a8 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 8, 2017 at 1:12 AM, Nikos Mavrogiannopoulos wrote: > On Tue, 2017-11-07 at 16:32 -0800, Eric Rescorla wrote: > > > > > > On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd > > wrote: > > > On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar > > > wrote: > > > > FWIW: In my experience middleboxes don't ossify based on what the > > > spec says, > > > > they ossify based on what they see on the wire. So, if common > > > > implementations send CCS in a particular way, that's what will > > > get --- and, > > > > I'll argue, what has gotten --- ossified. I also agree with David > > > and Eric > > > > that compatibility mode shouldn't be required because QUIC > > > doesn't need it. > > > > > > What does compatibility mode mean here? > > > > It means: > > > > 1. Send the fake session_id > > 2. Send a bunch of spurious CCS values. > > > > > > > If we end up with having two > > > slightly different versions of TLS 1.3, one that looks more like > > > TLS > > > 1.2 and the other that does not, that doesn't seem like a good > > > thing > > > to me. > > > > Well, the idea is that this is a purely local decision by one side. > > Which increases the cost of TLS1.3 implementation and testing by > introducing different handshake state machines. It doesn't introduce different handshake state machines, because you just ignore the CCS. > Why not negotiate that > CCS addition with an extension and have it defined outside the TLS 1.3 > spec? That actually does introduce different state machines. -Ekr I understand the concerns of the browser "community" on being > 100% backwards compatible with middle boxes, but the TLS1.3 standard is > more than just browsers. If 100% compatibility is required, there is a > very simple solution, use TLS 1.2. > > regards, > Nikos > > --f403045e8bde02b62d055d78c2a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Nov 8, 2017 at 1:12 AM, Nikos Mavrogiannopoulos <nmav@redhat.com= > wrote:
On Tue, 2017-11-07 at 16:32 -0800, Eric Rescorla wrot= e:
>
>
> On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd <watsonbladd@gmail.com>
> wrote:
> > On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar <jri@google.com>
> > wrote:
> > > FWIW: In my experience middleboxes don't ossify based on= what the
> > spec says,
> > > they ossify based on what they see on the wire. So, if commo= n
> > > implementations send CCS in a particular way, that's wha= t will
> > get --- and,
> > > I'll argue, what has gotten --- ossified. I also agree w= ith David
> > and Eric
> > > that compatibility mode shouldn't be required because QU= IC
> > doesn't need it.
> >
> > What does compatibility mode mean here?
>
> It means:
>
> 1. Send the fake session_id
> 2. Send a bunch of spurious CCS values.
>
>
> > If we end up with having two
> > slightly different versions of TLS 1.3, one that looks more like<= br> > > TLS
> > 1.2 and the other that does not, that doesn't seem like a goo= d
> > thing
> > to me.
>
> Well, the idea is that this is a purely local decision by one side.
Which increases the cost of TLS1.3 implementation and testing b= y
introducing different handshake state machines.

It doesn't introduce different handshake state machines, because = you just
ignore the CCS.

=C2=A0
Why not negotiate that
CCS addition with an extension and have it defined outside the TLS 1.3
spec?

That actually does introduce differen= t state machines.

-Ekr

I understand the concerns of the browser "com= munity" on being
100% backwards compatible with middle boxes, but the TLS1.3 standard is
more than just browsers. If 100% compatibility is required, there is a
very simple solution, use TLS 1.2.

regards,
Nikos


--f403045e8bde02b62d055d78c2a8-- From nobody Wed Nov 8 05:38:05 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A162C1201F2 for ; Wed, 8 Nov 2017 05:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 v0c7HXsKnDvJ for ; Wed, 8 Nov 2017 05:38:00 -0800 (PST) Received: from 6.mo3.mail-out.ovh.net (6.mo3.mail-out.ovh.net [188.165.43.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E982A126D45 for ; Wed, 8 Nov 2017 05:37:58 -0800 (PST) Received: from player771.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo3.mail-out.ovh.net (Postfix) with ESMTP id D784816ECF8 for ; Wed, 8 Nov 2017 14:37:56 +0100 (CET) Received: from [10.41.51.212] (130.163-14-84.ripe.coltfrance.com [84.14.163.130]) (Authenticated sender: contact@simonbernard.eu) by player771.ha.ovh.net (Postfix) with ESMTPSA id 12C8984007C; Wed, 8 Nov 2017 14:37:53 +0100 (CET) To: Matt Caswell , Martin Thomson Cc: "tls@ietf.org" References: <4833b54e-880b-c2c4-99ed-4dde0c96fc5c@openssl.org> <46a95f41-ee4a-dccc-b6f4-8b2bce6582d4@openssl.org> From: Simon Bernard Message-ID: <6c02b7a5-cda0-bb1c-3f31-833b9cca78c0@simonbernard.eu> Date: Wed, 8 Nov 2017 14:37:52 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <46a95f41-ee4a-dccc-b6f4-8b2bce6582d4@openssl.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Ovh-Tracer-Id: 627126248619194609 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedttddrheelgdehhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd Archived-At: Subject: Re: [TLS] Connection ID Draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 13:38:04 -0000 Hi, Here are the scenarios we would be interested to see covered by this CID extension. 1. Clients in unstable IP environment (like NAT) 2. stateless middlebox (like load balancer) with mixed CID and no CID connections. 3. stateless packet introspection (wireshark), with mixed CID and no CID connections. Linkability is not an issue for us, we have almost the same kind of linkability than with fixed IP. Point 1. seems already supported. Points 2. and 3. seems not ok for now because its not so easy to know if a record contains a CID or not. To know if a record contains a CID, the proposed solution in this thread are: - using content type (not sure to see how?) - using version (not available in DTLS 1.3? impact on current implementation?) - add a MAC for CID (bandwidth cost?) I don’t know which one could be the best, but I have one question: how to know the CID length for stateless middlebox or packet introspector ? Simon Le 03/11/2017 à 11:12, Matt Caswell a écrit : > > On 03/11/17 09:28, Martin Thomson wrote: >> On Fri, Nov 3, 2017 at 8:15 PM, Matt Caswell wrote: >>> It was my understanding that it is precisely this sort of problem that >>> this draft was attempting to address. Explicit marking would solve this. >> Yes, and the connection ID is that marking. The contention - I think >> - is what to do when there is a mix of marked connections and >> unmarked. > Right - where you have a mix of packets with connection ID and no > connection ID you don't know whether to look for one or not. IMO this > draft won't really be addressing the issues unless it includes a > mechanism for determining that. > > Matt > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Nov 8 05:39:16 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58DA126CD8 for ; Wed, 8 Nov 2017 05:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 tWCbvrgliZ_j for ; Wed, 8 Nov 2017 05:39:07 -0800 (PST) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 6DBCF1201F2 for ; Wed, 8 Nov 2017 05:39:07 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id t71so2294435ywc.3 for ; Wed, 08 Nov 2017 05:39:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mZnkQk0Ry7TE7yBvyiYkxR34Gu5SjCjJyQE5Go3iDPc=; b=WXV0qw34BuETPFe5KHRfTLiSHOjPKKnlqSHLUn8a1ZfiljI6gyCixfkfv3bi9Svl0V tb4k9KN+RUzoAgL0xPrwUqxkKKamAFoCrNLE6a05MpsHFKdBFtP4mu6P2wQbAu73dPKR uDIsvPEHtub6CMjlwajTvPKfKkPl3AvcHx/t31qqNBwN870hCy99/rBSKQDbn2E6BX1m 2YIXkGT3jN0wynumpkb2D2fD+0/s2fr3OG7AwrSYaIcpz0nxlPkmj7x1X5+4XjLh+RFL sUCRVHy7zdyJ1nO3ZWDFl6lbZ/lQ8XLaMqBXfcCv2CWYasKCMG1VNeENSLCFoZuEoKql wI7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mZnkQk0Ry7TE7yBvyiYkxR34Gu5SjCjJyQE5Go3iDPc=; b=tTY9xaLmgnRnJQOOun7yFbx7IQGzEkO/Vcq5Jb6A3NJ9sxF5OCLNNczNowsp/cKLl7 NQk4C03RnLgaRBjCYecc8gUxQofuMHPpw3iSN5wxubY7EwYCD7LODaaJrH/7qNqFlcpU A2R1nn0jaOWOevP1uG8KHN7ERwDBWirk2uZLrbq9mVWtNCTS2Ir6Njk5e/H3e2IniRYL x36+SO3m5pLLcK9Oq/Z4e5zr9yuOQDKrsbONKLEYYBiZElTksz6pnAfwZ9BsDie9T4uS Y0lAkgpiW/5d3efYAAdCfjGSjolTTXUSxbNuBV0FYqj676goARrGg0fqQMMKdRjbD/d1 gLhA== X-Gm-Message-State: AJaThX7Tb4KCK2ZrngkwZog9tmtrCQUeayeAW78StH/BWSuDP60qD46N +SPxIahGJh+mH82QECj3+WsOcWz+UPl4z4fvUjXcmw== X-Google-Smtp-Source: ABhQp+S5p6PCgifVk4qLZng0r9eM4x0zyPVdCQzQgB9DbRtw/iSESSvzJ1/5oJkackTmFLuJgXoBImOkNahlynV9yk0= X-Received: by 10.37.230.200 with SMTP id d191mr325851ybh.348.1510148346690; Wed, 08 Nov 2017 05:39:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.61.12 with HTTP; Wed, 8 Nov 2017 05:38:26 -0800 (PST) In-Reply-To: <4651345.7yjsJ4Y0gv@pintsize.usersys.redhat.com> References: <6818962.9GzJR6rN5C@pintsize.usersys.redhat.com> <4651345.7yjsJ4Y0gv@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Wed, 8 Nov 2017 05:38:26 -0800 Message-ID: To: Hubert Kario Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0afb14c35693055d78cfa4" Archived-At: Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 13:39:15 -0000 --94eb2c0afb14c35693055d78cfa4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 8, 2017 at 4:01 AM, Hubert Kario wrote: > On Tuesday, 7 November 2017 19:31:23 CET Eric Rescorla wrote: > > On Tue, Nov 7, 2017 at 10:11 AM, Hubert Kario wrote= : > > > On Tuesday, 7 November 2017 18:17:33 CET Eric Rescorla wrote: > > > > On Tue, Nov 7, 2017 at 7:39 AM, Hubert Kario > wrote: > > > > > In general +1, I like to see TLS 1.3 deployed ASAP and making the > > > > > > spurious > > > > > > > > failures as rare as possible is a good way to make that happen. > > > > > > > > > > that being said, I have few comments: > > > > > > > > > > On Monday, 6 November 2017 19:19:01 CET Eric Rescorla wrote: > > > > > > https://github.com/tlswg/tls13-spec/pull/1091 > > > > > > > > > > > > As I mentioned a while back, we've been seeing evidence of > middlebox > > > > > > intolerance. I just posted PR 1091, which is based on a bunch o= f > > > > > > work > > > > > > by the BoringSSL team and an original suggestion by Kyle Nekrit= z > > > > > > that > > > > > > should significantly decrease the rate of these errors. > > > > > > > > > > > > The general idea here is to make TLS 1.3 look more like TLS 1.2 > > > > > > resumption. The major changes are: > > > > > > > > > > > > - Move version negotiation entirely into "supported_versions", > and > > > > > > hence > > > > > > > > > ServerHello.version =3D=3D 0x0303 (TLS 1.2) > > > > > > > > > > > > - Restore the missing session_id and compression fields in > > > > > > ServerHello > > > > > > > > less special cases in parser code - big +1 > > > > > > > > > > > - The client sends a fake session_id and the server echoes it > > > > > > - The server sends ChangeCipherSpec messages after > > > > > > ServerHello/HelloRetryRequest > > > > > > > > > > > > (so that the middlebox ignores any "encrypted" data > afterwards), > > > > > > and the client sends ChangeCipherSpec after ClientHello. Eith= er > > > > > > side has to ignore ChangeCipherSpec during the handshake. > > > > > > > > > > That's the part I have a bit of a problem with. > > > > > If the CCS is necessary to make middleboxes work, and given that > > > > > lack-of-CCS- > > > > > intolerance is not something that we can detect reliably (not in = a > way > > > > > that > > > > > can be simulated by an attacker), I think the CCS should be baked > in > > > > > > the > > > > > > > > TLS > > > > > 1.3 as deep as it was baked into TLS 1.2. > > > > > > > > You don't detect it on an individualized basis. Rather, you measure > > > > > > whether > > > > > > > it's > > > > necessary and if/when the necessary level of CCS becomes low enough= , > you > > > > just stop sending it ever. > > > > > > > > > That is, the standard should make it a mandatory message to send, > > > > > fully > > > > > parsed > > > > > and validated, requiring aborting connection if it is received at > any > > > > > unexpected moment, in duplicate, omitted or malformed. Not only a= s > > > > > > part of > > > > > > > > the > > > > > "compatibility mode". > > > > > > > > Yeah, I'm not enthusiastic about this. It's more stuff in the state > > > > > > machine > > > > > > > that > > > > we hope to eventually eliminate. And as David says, it's totally > > > > > > unnecessary > > > > > > > for QUIC and DTLS > > > > > > > > -Ekr > > > > > > what I was getting at is that if you want to be compatible with > > > middleboxes, > > > you send that CCS always, as you never know what thing will be betwee= n > you > > > and > > > the peer > > > > > > that means that all the large implementations will be sending them > always > > > > > > that means that new middleboxes will likely end up expecting it eithe= r > way > > > and > > > existing ones won't have much incentive to update/fix > > > > > > secondly, if we allow for sending CCS at any point, we will end up wi= th > > > the > > > same bug as the Alert processing DoS there was in some implementation= s > =E2=80=94 > > > one > > > that allowed the peer to send unlimited amount of warning alerts > > > > Given that this is (a) not encrypted (b) just discarded and (c) only > > allowed during the handshake, this > > doesn't seem like much of a DoS. > > same could have been said about the warning alert handling, yet not even = a > 10mbps flow could completely lock up 4 cores of a 3GHz Haswell CPU > > yes, it all depended on how they were handled, but point still stands, 2 > major > implementations got it wrong > We already have plenty of places where you can send an arbitrary number of dummy messages, including the special case of padding-only packets which we explicitly allow. and given the information we were provided, I don't see a need to send > multiple CCS messages > Yes I might be OK with forbidding it. My objection is rather to requiring that receivers check. > > so even if we mark it as optional, I still think we should allow for it > to > > > be > > > sent at only very specific moments and only once per side > > > > I might be fine if it were required in this way, but not fine if it was > > required that one enforce it. > > by "enforce" you mean "enforce CCS being sent" or "enforce that a single > CCS > was sent"? > See above. And to answer the "Don't the servers control the middleboxes they are > behind?": > > No, they do not. And with B2B communication you never know what will be > looking on-route on the connection. It's not inconceivable that even a 3r= d > party that is _not_ an ISP controls those middleboxes is involved. Let > alone a > different team that has different priorities that people that need that > connection working. > > In the web world you may think that we're already in the 2020s. In some > enterprise networks people just recently noticed that we crossed to the n= ew > millennium. > (I'm of course joking, but the internal networks and Internet work on > completely different timescales) They don't have to *control* those middleboxes. The point is that servers have a stable elationship with the middleboxes and therefore should be able to determine whether they can safely do TLS 1.3 or not and simply not negotiated. Clients do not have that luxury. -Ekr -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic > --94eb2c0afb14c35693055d78cfa4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Nov 8, 2017 at 4:01 AM, Hubert Kario <hkario@redhat.com>= ; wrote:
On Tuesday, 7 November 2017 19:31:23 CET Eric Rescorla wrote= :
> On Tue, Nov 7, 2017 at 10:11 AM, Hubert Kario <hkario@redhat.com> wrote:
> > On Tuesday, 7 November 2017 18:17:33 CET Eric Rescorla wrote:
> > > On Tue, Nov 7, 2017 at 7:39 AM, Hubert Kario <hkario@redhat.com> wrote:
> > > > In general +1, I like to see TLS 1.3 deployed ASAP and = making the
> >
> > spurious
> >
> > > > failures as rare as possible is a good way to make that= happen.
> > > >
> > > > that being said, I have few comments:
> > > >
> > > > On Monday, 6 November 2017 19:19:01 CET Eric Rescorla w= rote:
> > > > > https://github.com/tlswg/= tls13-spec/pull/1091
> > > > >
> > > > > As I mentioned a while back, we've been seeing= evidence of middlebox
> > > > > intolerance. I just posted PR 1091, which is based= on a bunch of
> > > > > work
> > > > > by the BoringSSL team and an original suggestion b= y Kyle Nekritz
> > > > > that
> > > > > should significantly decrease the rate of these er= rors.
> > > > >
> > > > > The general idea here is to make TLS 1.3 look more= like TLS 1.2
> > > > > resumption. The major changes are:
> > > > >
> > > > > - Move version negotiation entirely into "sup= ported_versions", and
> >
> > hence
> >
> > > > >=C2=A0 =C2=A0ServerHello.version =3D=3D 0x0303 (TLS= 1.2)
> > > > >
> > > > > - Restore the missing session_id and compression f= ields in
> >
> > ServerHello
> >
> > > > less special cases in parser code - big +1
> > > >
> > > > > - The client sends a fake session_id and the serve= r echoes it
> > > > > - The server sends ChangeCipherSpec messages after=
> > > > > ServerHello/HelloRetryRequest
> > > > >
> > > > >=C2=A0 =C2=A0(so that the middlebox ignores any &qu= ot;encrypted" data afterwards),
> > > > >=C2=A0 =C2=A0and the client sends ChangeCipherSpec = after ClientHello. Either
> > > > >=C2=A0 =C2=A0side has to ignore ChangeCipherSpec du= ring the handshake.
> > > >
> > > > That's the part I have a bit of a problem with.
> > > > If the CCS is necessary to make middleboxes work, and g= iven that
> > > > lack-of-CCS-
> > > > intolerance is not something that we can detect reliabl= y (not in a way
> > > > that
> > > > can be simulated by an attacker), I think the CCS shoul= d be baked in
> >
> > the
> >
> > > > TLS
> > > > 1.3 as deep as it was baked into TLS 1.2.
> > >
> > > You don't detect it on an individualized basis. Rather, = you measure
> >
> > whether
> >
> > > it's
> > > necessary and if/when the necessary level of CCS becomes low= enough, you
> > > just stop sending it ever.
> > >
> > > > That is, the standard should make it a mandatory messag= e to send,
> > > > fully
> > > > parsed
> > > > and validated, requiring aborting connection if it is r= eceived at any
> > > > unexpected moment, in duplicate, omitted or malformed. = Not only as
> >
> > part of
> >
> > > > the
> > > > "compatibility mode".
> > >
> > > Yeah, I'm not enthusiastic about this. It's more stu= ff in the state
> >
> > machine
> >
> > > that
> > > we hope to eventually eliminate. And as David says, it's= totally
> >
> > unnecessary
> >
> > > for QUIC and DTLS
> > >
> > > -Ekr
> >
> > what I was getting at is that if you want to be compatible with > > middleboxes,
> > you send that CCS always, as you never know what thing will be be= tween you
> > and
> > the peer
> >
> > that means that all the large implementations will be sending the= m always
> >
> > that means that new middleboxes will likely end up expecting it e= ither way
> > and
> > existing ones won't have much incentive to update/fix
> >
> > secondly, if we allow for sending CCS at any point, we will end u= p with
> > the
> > same bug as the Alert processing DoS there was in some implementa= tions =E2=80=94
> > one
> > that allowed the peer to send unlimited amount of warning alerts<= br> >
> Given that this is (a) not encrypted (b) just discarded and (c) only > allowed during the handshake, this
> doesn't seem like much of a DoS.

same could have been said about the warning alert handling, yet= not even a
10mbps flow could completely lock up 4 cores of a 3GHz Haswell CPU

yes, it all depended on how they were handled, but point still stands, 2 ma= jor
implementations got it wrong
=C2=A0
We alrea= dy have plenty of places where you can send an arbitrary number
o= f dummy messages, including the special case of padding-only packets which<= /div>
we explicitly allow.


and given the information we were provided, I don't see a need to send<= br> multiple CCS messages

Yes I might be OK= with forbidding it. My objection is rather to requiring that receivers
check.


> > so even if we mark it as optional, I still think we should allow = for it to
> > be
> > sent at only very specific moments and only once per side
>
> I might be fine if it were required in this way, but not fine if it wa= s
> required that one enforce it.

by "enforce" you mean "enforce CCS being sent" o= r "enforce that a single CCS
was sent"?

See above.

And to answer the "Don't the servers control the middleboxes they = are
behind?":

No, they do not. And with B2B communication you never know what will be
looking on-route on the connection. It's not inconceivable that even a = 3rd
party that is _not_ an ISP controls those middleboxes is involved. Let alon= e a
different team that has different priorities that people that need that
connection working.

In the web world you may think that we're already in the 2020s. In some=
enterprise networks people just recently noticed that we crossed to the new=
millennium.
(I'm of course joking, but the internal networks and Internet work on completely different timescales)

They don&#= 39;t have to *control* those middleboxes. The point is that servers have
a stable elationship with the middleboxes and therefore should be a= ble to determine
whether they can safely do TLS 1.3 or not and si= mply not negotiated. Clients do
not have that luxury.
<= br>
-Ekr

=C2= =A0
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech Republic=

--94eb2c0afb14c35693055d78cfa4-- From nobody Wed Nov 8 05:55:06 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D140126C3D for ; Wed, 8 Nov 2017 05:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 j515G6XoMH5t for ; Wed, 8 Nov 2017 05:55:03 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32153126CD6 for ; Wed, 8 Nov 2017 05:55:03 -0800 (PST) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vA8Ds1rv011621; Wed, 8 Nov 2017 13:55:01 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=FXudQ+IhUagMSCe3drvTK52cxOsbMfN+pDkv/6tc6fs=; b=cYof1WslDe1xmB63eU2EJORxMs353PoJnifqf70KFqrxeuhwI7fWLhdL4MeM83xezle9 99YRK03DeMlJRuSx9dY+TDYu0tyEYWEdo+Mb/gq8CdQozDRKVVQCbcwDKiSvhs0F7+D5 CtfurizGkGWgxFPiNj2pHw9riQx5HJMyjZt1ZzijW7jqCJZZXxbsqhHEPANQ1GBtF/nx lWYQysFIuAZYxSPi1avRb3XwJ6wj2q/ac96eM6iRgau8B4SaFLVGApuB73dNfQNz7uQD v/LAULlAPAJOz6qqimX5VI+f3bW3i9Y77Xha22nQaQrYj+b/wGhFxVn0rPfh5p43p9TR 1Q== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0a-00190b01.pphosted.com with ESMTP id 2e40q1rjvw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 08 Nov 2017 13:55:01 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vA8DpSJ3005746; Wed, 8 Nov 2017 08:55:00 -0500 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint3.akamai.com with ESMTP id 2e18vvypnx-1; Wed, 08 Nov 2017 08:55:00 -0500 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 99E39839B2; Wed, 8 Nov 2017 06:54:59 -0700 (MST) To: Eric Rescorla , Nikos Mavrogiannopoulos Cc: "tls@ietf.org" References: <4406543.RZChgRkkf9@pintsize.usersys.redhat.com> <6818962.9GzJR6rN5C@pintsize.usersys.redhat.com> <965B995B-A5B3-4322-B13A-A2D82AFD2743@akamai.com> <1510132329.17184.123.camel@redhat.com> From: Benjamin Kaduk Message-ID: <126ede22-36d3-42d5-18fd-511b7e1349c7@akamai.com> Date: Wed, 8 Nov 2017 07:54:59 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0C41299F2A571CAFE3AA3F12" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-08_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711080189 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-08_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711080189 Archived-At: Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 13:55:05 -0000 This is a multi-part message in MIME format. --------------0C41299F2A571CAFE3AA3F12 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 11/08/2017 07:34 AM, Eric Rescorla wrote: > > > On Wed, Nov 8, 2017 at 1:12 AM, Nikos Mavrogiannopoulos > > wrote: > > On Tue, 2017-11-07 at 16:32 -0800, Eric Rescorla wrote: > > > > > > On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd > > > > wrote: > > > On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar > > > > wrote: > > > > FWIW: In my experience middleboxes don't ossify based on > what the > > > spec says, > > > > they ossify based on what they see on the wire. So, if common > > > > implementations send CCS in a particular way, that's what will > > > get --- and, > > > > I'll argue, what has gotten --- ossified. I also agree with > David > > > and Eric > > > > that compatibility mode shouldn't be required because QUIC > > > doesn't need it. > > > > > > What does compatibility mode mean here? > > > > It means: > > > > 1. Send the fake session_id > > 2. Send a bunch of spurious CCS values. > > > > > > > If we end up with having two > > > slightly different versions of TLS 1.3, one that looks more like > > > TLS > > > 1.2 and the other that does not, that doesn't seem like a good > > > thing > > > to me. > > > > Well, the idea is that this is a purely local decision by one side. > > Which increases the cost of TLS1.3 implementation and testing by > introducing different handshake state machines. > > > It doesn't introduce different handshake state machines, because you just > ignore the CCS. > I am leery of things that we flat-out *ignore*, as that sort of thing has a history of coming back to bite us. >   > > Why not negotiate that > CCS addition with an extension and have it defined outside the TLS 1.3 > spec? > > > That actually does introduce different state machines. > True, but perhaps still worth thinking about. In some sense, we might not even need an extension; we could take Martin's idea and run with it -- server MUST send CCS if the client sends a sessionID, and server MUST NOT send CCS if the client does not send a sessionID.  This would still make the state machine bigger, but avoids a fork that depends only on "what message do I receive here".  On the other hand, it also places all the burden of deciding when to use the compat scheme on the client, when people are making the case that some servers, at least, have some sense of when they're behind a relevant middlebox.  But I'm not entirely sure how convincing those arguments have been, so far. -Ben > -Ekr > > I understand the concerns of the browser "community" on being > 100% backwards compatible with middle boxes, but the TLS1.3 > standard is > more than just browsers. If 100% compatibility is required, there is a > very simple solution, use TLS 1.2. > > regards, > Nikos > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------0C41299F2A571CAFE3AA3F12 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 11/08/2017 07:34 AM, Eric Rescorla wrote:


On Wed, Nov 8, 2017 at 1:12 AM, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
On Tue, 2017-11-07 at 16:32 -0800, Eric Rescorla wrote:
>
>
> On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd <watsonbladd@gmail.com>
> wrote:
> > On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar <jri@google.com>
> > wrote:
> > > FWIW: In my experience middleboxes don't ossify based on what the
> > spec says,
> > > they ossify based on what they see on the wire. So, if common
> > > implementations send CCS in a particular way, that's what will
> > get --- and,
> > > I'll argue, what has gotten --- ossified. I also agree with David
> > and Eric
> > > that compatibility mode shouldn't be required because QUIC
> > doesn't need it.
> >
> > What does compatibility mode mean here?
>
> It means:
>
> 1. Send the fake session_id
> 2. Send a bunch of spurious CCS values.
>
>
> > If we end up with having two
> > slightly different versions of TLS 1.3, one that looks more like
> > TLS
> > 1.2 and the other that does not, that doesn't seem like a good
> > thing
> > to me.
>
> Well, the idea is that this is a purely local decision by one side.

Which increases the cost of TLS1.3 implementation and testing by
introducing different handshake state machines.

It doesn't introduce different handshake state machines, because you just
ignore the CCS.


I am leery of things that we flat-out *ignore*, as that sort of thing has a history of coming back to bite us.

 
Why not negotiate that
CCS addition with an extension and have it defined outside the TLS 1.3
spec?

That actually does introduce different state machines.


True, but perhaps still worth thinking about.
In some sense, we might not even need an extension; we could take Martin's idea and run with it -- server MUST send CCS if the client sends a sessionID, and server MUST NOT send CCS if the client does not send a sessionID.  This would still make the state machine bigger, but avoids a fork that depends only on "what message do I receive here".  On the other hand, it also places all the burden of deciding when to use the compat scheme on the client, when people are making the case that some servers, at least, have some sense of when they're behind a relevant middlebox.  But I'm not entirely sure how convincing those arguments have been, so far.

-Ben

-Ekr

I understand the concerns of the browser "community" on being
100% backwards compatible with middle boxes, but the TLS1.3 standard is
more than just browsers. If 100% compatibility is required, there is a
very simple solution, use TLS 1.2.

regards,
Nikos




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

--------------0C41299F2A571CAFE3AA3F12-- From nobody Wed Nov 8 06:04:23 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E39127076 for ; Wed, 8 Nov 2017 06:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 G4Xl3fRn6in5 for ; Wed, 8 Nov 2017 06:04:18 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (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 A8830127011 for ; Wed, 8 Nov 2017 06:04:15 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id w2so2346561ywa.9 for ; Wed, 08 Nov 2017 06:04:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Qxi9dMiZgv0rtov8n/yh/3tpyGEGc2uFH6k3LbRJXDo=; b=mDT1oY2dMz0azJY8pXHKsg2zrThMxSFnFzexC7kqQ/EVAKvSTk3xs9abwhlpXUf5Fs 5DNjR/iCpYQVuwXRGTeGzTx5C2CPNPYkORRXVrg0jmbHbD5B/f1xDwHF85stTFnYfZJ2 z9KGVILPtIeAaFyaWRfMAtuRvSyQCee1Nr/YWzG8kebV2KG2qAvjBSXrFwfB0ocpMjrh qSeXUFJJUt7AwbqqPzjgzH1/bklq+wIStTasIXKwFvCxzeffGmquKF3FpuLwvYcaofbt oqdvYFBGNULFauhAuynMR3p4AJfTqoi3xatSNyTrj99mU4OUkB0wzGkqHmnfCOnnO/c8 Tvaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Qxi9dMiZgv0rtov8n/yh/3tpyGEGc2uFH6k3LbRJXDo=; b=nnI/4KVARCatZsGqiTqFihkdq+5njtHD0NxVrLJsP9NpYHa8VadyXhYdmS3UBlRpJ6 kfYTVDGxGDE0APjU9BpcUEvsUhuGXrYpcJNCboA9Xwteyss7c+fmt4IOQSHgNOi1+Yy7 9+crslo82D2CgYIfE+h5YStks3OLDkeb8L3+nm04vb5dEdUT3XxItZuo9xmqcN4df5nD 0eU9bwn+1fv5sZ6/2lb2ornAlIoCOV/4rzCKBjPcTADTUtUvniU7wxB/4E2Jxhsubvfb /5c6DZb20EEBhFPnUmajZJ9+lZbXVuBMJgs2z5J6Q0KHGVDCGIgNbjyiEKywkZiPoW1I 4QXQ== X-Gm-Message-State: AJaThX7ctAVLONIEpwen0xdMD5XSHgLRe4WcvRLuR9eVhO5YHrQ0XYuo +6EIL+sco8U//GERIOOUCElURYc2aaFfs+WBVEk9jg== X-Google-Smtp-Source: ABhQp+QFDG3Z5SJ8N/BlAlQ0ysjpKcgQVTwpeP1eSSvoRAv/pW6TApPD4U+9blt2WyRc0e06nccKhJAgrnZmX08ujgw= X-Received: by 10.37.209.208 with SMTP id i199mr392370ybg.339.1510149854813; Wed, 08 Nov 2017 06:04:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.61.12 with HTTP; Wed, 8 Nov 2017 06:03:34 -0800 (PST) In-Reply-To: <126ede22-36d3-42d5-18fd-511b7e1349c7@akamai.com> References: <4406543.RZChgRkkf9@pintsize.usersys.redhat.com> <6818962.9GzJR6rN5C@pintsize.usersys.redhat.com> <965B995B-A5B3-4322-B13A-A2D82AFD2743@akamai.com> <1510132329.17184.123.camel@redhat.com> <126ede22-36d3-42d5-18fd-511b7e1349c7@akamai.com> From: Eric Rescorla Date: Wed, 8 Nov 2017 06:03:34 -0800 Message-ID: To: Benjamin Kaduk Cc: Nikos Mavrogiannopoulos , "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c05e1a6a77c8b055d792909" Archived-At: Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 14:04:21 -0000 --94eb2c05e1a6a77c8b055d792909 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 8, 2017 at 5:54 AM, Benjamin Kaduk wrote: > On 11/08/2017 07:34 AM, Eric Rescorla wrote: > > > > On Wed, Nov 8, 2017 at 1:12 AM, Nikos Mavrogiannopoulos > wrote: > >> On Tue, 2017-11-07 at 16:32 -0800, Eric Rescorla wrote: >> > >> > >> > On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd >> > wrote: >> > > On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar >> > > wrote: >> > > > FWIW: In my experience middleboxes don't ossify based on what the >> > > spec says, >> > > > they ossify based on what they see on the wire. So, if common >> > > > implementations send CCS in a particular way, that's what will >> > > get --- and, >> > > > I'll argue, what has gotten --- ossified. I also agree with David >> > > and Eric >> > > > that compatibility mode shouldn't be required because QUIC >> > > doesn't need it. >> > > >> > > What does compatibility mode mean here? >> > >> > It means: >> > >> > 1. Send the fake session_id >> > 2. Send a bunch of spurious CCS values. >> > >> > >> > > If we end up with having two >> > > slightly different versions of TLS 1.3, one that looks more like >> > > TLS >> > > 1.2 and the other that does not, that doesn't seem like a good >> > > thing >> > > to me. >> > >> > Well, the idea is that this is a purely local decision by one side. >> >> Which increases the cost of TLS1.3 implementation and testing by >> introducing different handshake state machines. > > > It doesn't introduce different handshake state machines, because you just > ignore the CCS. > > > I am leery of things that we flat-out *ignore*, as that sort of thing has > a history of coming back to bite us. > Well, I suppose that's possible, but given that this is in the plaintext stream, it seems less concerning. > Why not negotiate that >> CCS addition with an extension and have it defined outside the TLS 1.3 >> spec? > > > That actually does introduce different state machines. > > > True, but perhaps still worth thinking about. > In some sense, we might not even need an extension; we could take Martin's > idea and run with it -- server MUST send CCS if the client sends a > sessionID, and server MUST NOT send CCS if the client does not send a > sessionID. This would still make the state machine bigger, but avoids a > fork that depends only on "what message do I receive here". On the other > hand, it also places all the burden of deciding when to use the compat > scheme on the client, when people are making the case that some servers, at > least, have some sense of when they're behind a relevant middlebox. But > I'm not entirely sure how convincing those arguments have been, so far. > Well, at some level the client has to make the initial decision because it has to decide what to put in CH. If you replace your MUST NOT with a MAY, then the server can decide for itself whether to send the CCS, and this works well with "ignore" -Ekr > -Ben > > -Ekr > > I understand the concerns of the browser "community" on being >> 100% backwards compatible with middle boxes, but the TLS1.3 standard is >> more than just browsers. If 100% compatibility is required, there is a >> very simple solution, use TLS 1.2. >> >> regards, >> Nikos >> >> > > > _______________________________________________ > TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls > > > --94eb2c05e1a6a77c8b055d792909 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Nov 8, 2017 at 5:54 AM, Benjamin Kaduk <bkaduk@akamai.com&= gt; wrote:
=20 =20 =20
On 11/08/2017 07:34 AM, Eric Rescorla wrote:
=20


On Wed, Nov 8, 2017 at 1:12 AM, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
On Tue, 2017-11-07 = at 16:32 -0800, Eric Rescorla wrote:
>
>
> On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd <watsonbladd@gmail.co= m>
> wrote:
> > On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar <j= ri@google.com>
> > wrote:
> > > FWIW: In my experience middleboxes don't ossify based on what the
> > spec says,
> > > they ossify based on what they see on the wire. So, if common
> > > implementations send CCS in a particular way, that's what will
> > get --- and,
> > > I'll argue, what has gotten --- ossified. I also agree with David
> > and Eric
> > > that compatibility mode shouldn't be required because QUIC
> > doesn't need it.
> >
> > What does compatibility mode mean here?
>
> It means:
>
> 1. Send the fake session_id
> 2. Send a bunch of spurious CCS values.
>
>
> > If we end up with having two
> > slightly different versions of TLS 1.3, one that looks more like
> > TLS
> > 1.2 and the other that does not, that doesn't seem like a good
> > thing
> > to me.
>
> Well, the idea is that this is a purely local decision by one side.

Which increases the cost of TLS1.3 implementation and testing by
introducing different handshake state machines.

It doesn't introduce different handshake state machines, because you just
ignore the CCS.


I am leery of things that we flat-out *ignore*, as that sort of thing has a history of coming back to bite us.
<= br>
Well, I suppose that's possible, but given that this is i= n the plaintext stream, it seems less concerning.
=C2=A0
Why not negotiate that
CCS addition with an extension and have it defined outside the TLS 1.3
spec?

That actually does introduce different state machines.


True, but perhaps still worth thinking about.
In some sense, we might not even need an extension; we could take Martin's idea and run with it -- server MUST send CCS if the client sends a sessionID, and server MUST NOT send CCS if the client does not send a sessionID.=C2=A0 This would still make the state machine bigger, but avoids a fork that depends only on "what message do I receive here".=C2=A0 On the other hand, it also places all the bur= den of deciding when to use the compat scheme on the client, when people are making the case that some servers, at least, have some sense of when they're behind a relevant middlebox.=C2=A0 But I'm not ent= irely sure how convincing those arguments have been, so far.

Well, at some level the client has to make the initial dec= ision because it has to decide what to put in CH. If you replace your MUST = NOT with a MAY, then the server can decide for itself whether to send the C= CS, and this works well with "ignore"

-E= kr


-Ben

-Ekr

I understand the concerns of the browser "community" = on being
100% backwards compatible with middle boxes, but the TLS1.3 standard is
more than just browsers. If 100% compatibility is required, there is a
very simple solution, use TLS 1.2.

regards,
Nikos




___________________________________=
____________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mai=
lman/listinfo/tls


--94eb2c05e1a6a77c8b055d792909-- From nobody Wed Nov 8 07:29:03 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B4A1275F4 for ; Wed, 8 Nov 2017 07:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 w4VF9lBEDzqD for ; Wed, 8 Nov 2017 07:28:59 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FCEE12711B for ; Wed, 8 Nov 2017 07:28:59 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vA8FSGFu004042 for ; Wed, 8 Nov 2017 15:28:57 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=WKhUPjC/N5s2ueHWYU6hSmTTvbboM0Cx8/z5X2bVceg=; b=JX7/gHSVSCeI2PzJtmFCrf775iOpcSoloGnsmR3YbiRSFVPPYMRmrB9tHVB6bKNK2GpF KQQbWB66AYSUbi7WDQSiBKaPfAWyGywmPcdYQojJ2BRTRcj2ANNV7UeWz+2qso1gOwWC AoXbJYjBFwaXfbHwpJpW4VV59Fi4j1pU1zoiXiyiPJ6u2vXoTMambHhQyH96s/yNVcew hbkAP7Y1TVuTSsHYbL8PFkqCFyQbCmjhls2CzbFXsUJb7ybYuuRE37F4wgXJgLF4IWoD vyn2DqZU63CGWqwAw6FkGUUmOXr6fOBlOoCmKPfKJRVxnTNBIvYWGE1JsgYyNFpoFwiC +A== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2e3nkn31rs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 08 Nov 2017 15:28:57 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vA8FQMIh030877 for ; Wed, 8 Nov 2017 10:28:56 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2e18vudh5y-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 08 Nov 2017 10:28:55 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb3.msg.corp.akamai.com (172.27.123.58) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 8 Nov 2017 10:28:55 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 8 Nov 2017 10:28:54 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 8 Nov 2017 10:28:54 -0500 From: "Salz, Rich" To: "tls@ietf.org" Thread-Topic: [saag] Announcing the PATIENT mailing list & meeting in Singapore Thread-Index: AQHTWKZJTxYMfgYkNUOWtTaS8CQsbg== Date: Wed, 8 Nov 2017 15:28:54 +0000 Message-ID: <5EF76C00-24D5-422E-86F1-A955A1656856@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.67] Content-Type: multipart/mixed; boundary="_004_5EF76C0024D5422E86F1A955A1656856akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-08_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711080207 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-08_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711080207 Archived-At: Subject: [TLS] FW: [saag] Announcing the PATIENT mailing list & meeting in Singapore X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 15:29:02 -0000 --_004_5EF76C0024D5422E86F1A955A1656856akamaicom_ Content-Type: multipart/alternative; boundary="_000_5EF76C0024D5422E86F1A955A1656856akamaicom_" --_000_5EF76C0024D5422E86F1A955A1656856akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T2YgaW50ZXJlc3QgaGVyZQ0KDQpGcm9tOiBCcmlhbiBXaXR0ZW4gPGJyaWFuX3dpdHRlbkBzeW1h bnRlYy5jb20+DQpEYXRlOiBXZWRuZXNkYXksIE5vdmVtYmVyIDgsIDIwMTcgYXQgOToxOCBBTQ0K VG86IHNhYWcgPHNhYWdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbc2FhZ10gQW5ub3VuY2luZyB0aGUg UEFUSUVOVCBtYWlsaW5nIGxpc3QgJiBtZWV0aW5nIGluIFNpbmdhcG9yZQ0KDQpEZWFyIEFsbCwN Cg0KRm9yIGFueW9uZSBpbnRlcmVzdGVkIGluIFByb3RlY3RpbmcgYWdhaW5zdCBBdHRhY2tzIFR1 bm5lbGluZyBJbiBFbmNyeXB0ZWQgTmV0d29yayBUcmFmZmljIChQQVRJRU5UKSwgSeKAmW0gYW5u b3VuY2luZyBib3RoIGEgbWVldGluZyBiZWxvdywgYW5kIG1haWxpbmcgbGlzdCwgZnVydGhlciBi ZWxvdy4gIEludGVudCBvZiBQQVRJRU5UIGlzIHRvIGNyZWF0ZSBhIHNlY3VyZSBtdWx0aS1wYXJ0 eSBwcm90b2NvbCBmb3IgbWFraW5nIHN1Y2ggcHJvdGVjdGlvbiBmYXIgc2FmZXIgd2l0aG91dCBt b2RpZnlpbmcsIGNvbnN0cmFpbmluZywgb3IgYnJlYWtpbmcgVExTIGluIGFueSB3YXksIGEgcHJv dG9jb2wgY29tcGxpbWVudGluZyBjdXJyZW50IFRMUyBpbmNsdWRpbmcgVExTIDEuMy4NCg0KDQpJ bnRlbnQgb2YgUEFUSUVOVCBpcyB0byBkbyBzbyBpbiBsaWdodCBvZiBib3RoIChhKSB2dWxuZXJh YmlsaXRpZXMgaW4gdG9kYXnigJlzIGNvbW1vbiBhcHByb2FjaGVzLCBhbmQgKGIpIGh1Z2UgZ3Jv d2luZyBudW1iZXIgb2YgYXR0YWNrcyB0dW5uZWxpbmcgaW4gZW5jcnlwdGVkIHRyYWZmaWMsIGFs cmVhZHkgaHVydGluZyBiaWxsaW9ucyBvZiBwZW9wbGUsIHNvbWV0aW1lcyB3aXRoIGRpcmUgY29u c2VxdWVuY2VzIGZvciB0aGVpciBwcml2YWN5LCBmcmVlZG9tLCAmIHBoeXNpY2FsIHdlbGwgYmVp bmcuDQoNCg0KVGhlIG1lZXRpbmcgd2lsbCBiZToNCioqIFdoZW46IFdlZG5lc2RheSwgTm92ZW1i ZXIgMTUsIDhwbTx4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzOi8vMD4sIHNob3J0bHkgZm9sbG93aW5n IHRoZSBwbGVuYXJ5Lg0KKiogV2hlcmU6IE9yY2hhcmQgUm9vbSBvZiB0aGUgQ29udmVudGlvbiBD ZW50ZXIgd2hlcmUgdGhlIElFVEYgTWVldGluZ3MgYXJlIGJlaW5nIGhlbGQuDQoNCkkgbm90ZSB0 aGF0IHByZS1jb25jZXB0aW9ucyBoYXZlIHNldmVyZWx5IHBvbGFyaXplZCBhIG51bWJlciBvZiBw YXN0IGF0dGVtcHRzIGF0IHNvbHZpbmcgcHJvYmxlbXMgc2ltaWxhciB0byB0aGlzLCBhbmQgd2l0 aG91dCBiZXR0ZXIgc3RhbmRhcmRzIGZvciBzdWNoIHByb3RlY3Rpb24sIHNlY3VyaXR5IHN1ZmZl cnMgaW4gbWFueSB3YXlzLCBpbmNsdWRpbmcgY2hhbGxlbmdlcyBzYWZlbHkgcm9sbGluZyBvdXQg aW1wb3J0YW50IG5ldyBwcm90b2NvbHMgbGlrZSBUTFMgMS4zIGFzIHF1aWNrbHkgYW5kIGFzIHdp ZGVseSBhcyB3ZeKAmWQgYWxsIGxpa2UuICBXZSBzZWVrIGEg4oCcbWlkZGxl4oCdIGdyb3VuZCB0 aGF0IGlzIG5vdCBhIHNhY3JpZmljZSBieSBlaXRoZXIgc2lkZSBidXQgcmF0aGVyIGhvcGVmdWxs eSBhIGJlc3Qgb2YgYm90aCB3b3JsZHMuDQoNCklmIHlvdSBhcmUgd2FudGluZyB0byBwcm90ZWN0 IGFnYWluc3QgYXR0YWNrcyB0dW5uZWxpbmcgaW4gZW5jcnlwdGVkIHRyYWZmaWMsIGFuZCB3YW50 aW5nIHRvIG1ha2Ugc3VjaCBwcm90ZWN0aW9uIGZhciBzYWZlciBmcm9tIGJvdGggc2VjdXJpdHkg YW5kIHByaXZhY3kgcGVyc3BlY3RpdmVzLCBwbGVhc2Ugam9pbiB1cyBmb3IgdGhpcyBtZWV0aW5n LCBhbmQgcGxlYXNlIGpvaW4gdXMgaW4gaGVscGluZyBrZWVwIGRpc2N1c3Npb24gY29uc3RydWN0 aXZlIGFuZCByZXNwZWN0ZnVsIG9mIHBlb3BsZSB3aXRoIHdpZGVseSBkaWZmZXJpbmcgdmlld3Mu ICBJIGJlbGlldmUgd2UgYWxsIHdhbnQgdG8gbWFrZSB0aGUgSW50ZXJuZXQgYW5kIHdvcmxkIHNh ZmVyLg0KDQpXaXRoIE15IERlZXBlc3QgVGhhbmtzIEZvciBBbGwgVGhhdCBZb3UgRG8gRm9yIFRo ZSBJRVRGLCBBbmQgRm9yIFRoZSBXb3JsZCBUaHJvdWdoIFRoZSBJRVRGLA0KQnJpYW4NCg0KYndp dHRlbkBzeW1hbnRlYy5jb208bWFpbHRvOmJ3aXR0ZW5Ac3ltYW50ZWMuY29tPg0KDQoNCkJlZ2lu IGZvcndhcmRlZCBtZXNzYWdlOg0KRnJvbTogQnJpYW4gV2l0dGVuIDxicmlhbl93aXR0ZW5Ac3lt YW50ZWMuY29tPG1haWx0bzpicmlhbl93aXR0ZW5Ac3ltYW50ZWMuY29tPj4NCkRhdGU6IE5vdmVt YmVyIDgsIDIwMTcgYXQgMTI6NTk6NTUgQU0gUFNUDQpUbzogInBhdGllbnRAaWV0Zi5vcmc8bWFp bHRvOnBhdGllbnRAaWV0Zi5vcmc+IiA8cGF0aWVudEBpZXRmLm9yZzxtYWlsdG86cGF0aWVudEBp ZXRmLm9yZz4+DQpTdWJqZWN0OiBBbm5vdW5jaW5nIHRoZSBQQVRJRU5UIG1lZXRpbmcgaW4gU2lu Z2Fwb3JlDQpEZWFyIEFsbCwNCg0KRm9yIGFueW9uZSBpbnRlcmVzdGVkIGluIFByb3RlY3Rpbmcg YWdhaW5zdCBBdHRhY2tzIFR1bm5lbGluZyBJbiBFbmNyeXB0ZWQgTmV0d29yayBUcmFmZmljIChQ QVRJRU5UKSwgd2UnbGwgYmUgaGF2aW5nIGEgbWVldGluZyBpbiBTaW5nYXBvcmUuDQoqKiBXaGVu OiBXZWRuZXNkYXksIE5vdmVtYmVyIDE1LCA4cG0sIHNob3J0bHkgZm9sbG93aW5nIHRoZSBwbGVu YXJ5Lg0KKiogV2hlcmU6IE9yY2hhcmQgUm9vbSBvZiB0aGUgQ29udmVudGlvbiBDZW50ZXIgd2hl cmUgdGhlIElFVEYgTWVldGluZ3MgYXJlIGJlaW5nIGhlbGQuDQoNClRoaXMgc2lkZSBtZWV0aW5n IGlzIGFraW4gdG8gImJhciBCT0YiIGluIHByZXBhcmF0aW9uIGZvciBob3BlZnVsbHkgaG9zdGlu ZyBhIGZ1bGwgQmlyZHMgb2YgYSBGZWF0aGVyIChCT0YpIG1lZXRpbmcgYXQgSUVURiAxMDEgaW4g TG9uZG9uIGluIGEgZmV3IG1vbnRocy4gIFBsZWFzZSBmZWVsIGZyZWUgdG8gZGlyZWN0bHkgbGV0 IG1lIGtub3cgYW55IHF1ZXN0aW9ucyBvciBjb25jZXJucy4NCg0KV2l0aCBNeSBEZWVwZXN0IFRo YW5rcyBGb3IgQWxsIFRoYXQgWW91IERvIEZvciBUaGUgSUVURiwgQW5kIEZvciBUaGUgV29ybGQg VGhyb3VnaCBUaGUgSUVURiwNCkJyaWFuDQoNCmJ3aXR0ZW5Ac3ltYW50ZWMuY29tPG1haWx0bzpi d2l0dGVuQHN5bWFudGVjLmNvbT4NCg0KRnJvbTogUEFUSUVOVCA8cGF0aWVudC1ib3VuY2VzQGll dGYub3JnPG1haWx0bzpwYXRpZW50LWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgQnJp YW4gV2l0dGVuIDxicmlhbl93aXR0ZW5Ac3ltYW50ZWMuY29tPG1haWx0bzpicmlhbl93aXR0ZW5A c3ltYW50ZWMuY29tPj4NClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgNiwgMjAxNyA0OjI2IFBNDQpU bzogcGF0aWVudEBpZXRmLm9yZzxtYWlsdG86cGF0aWVudEBpZXRmLm9yZz4NClN1YmplY3Q6IFtF WFRdIFtQYXRpZW50XSBXZWxjb21lIHRvIHRoZSBQQVRJRU5UIE1haWxpbmcgTGlzdA0KDQoNCkRl YXIgQWxsLA0KDQpXZWxjb21lIHRvIHRoZSBtYWlsaW5nIGxpc3QgZm9yIFByb3RlY3RpbmcgYWdh aW5zdCBBdHRhY2tzIFR1bm5lbGluZyBJbiBFbmNyeXB0ZWQgTmV0d29yayBUcmFmZmljIChQQVRJ RU5UKS4NCg0KV2UgYXJlIHRocmlsbGVkIHRvIHNlZSBvdmVyIGhhbGYgb2YgdGhlIHdvcmxk4oCZ cyB3ZWIgY29ubmVjdGlvbnMgZW5jcnlwdGVkLCBhbmQgd2UgZG8gbm90IHdhbnQgdG8gd2Vha2Vu IGNyeXB0byBvciBUTFMgaW4gYW55IHdheS4gIEF0IHRoZSBzYW1lIHRpbWUsIGhhbGYgb2YgdGhl IHdvcmxk4oCZcyBhdHRhY2tzIGFyZSBub3cgdHVubmVsaW5nIHRocm91Z2ggZW5jcnlwdGVkIHNl c3Npb25zLCBhbmQgbWFueSBlbmRwb2ludHMgbmVlZCBoZWxwIHByb3RlY3RpbmcgIHRoZW1zZWx2 ZXMgYWdhaW5zdCB0aGVzZSBhdHRhY2tzLiAgT2Z0ZW4gdGhleSBjYW4gb25seSBnZXQgdGhhdCBo ZWxwIGZyb20gdGhlIG5ldHdvcmsuICBGb3J0dW5hdGVseSwgdGhlcmUgYXJlIGluIGZhY3Qgd2F5 cyBmb3IgbmV0d29yayBkZXZpY2VzIHRvIGhlbHAgcHJvdGVjdCBhZ2FpbnN0IHRoZSBmdWxsIHJh bmdlIG9mIGF0dGFja3MgdGhhdCBtaWdodCBiZSB0dW5uZWxpbmcgdGhyb3VnaCBlbmNyeXB0ZWQg c2Vzc2lvbnMuICBTdGlsbCwgZm9yICBlbmRwb2ludHMgdG8gZ2V0IHN1Y2ggaGVscCBvZiBjb3Vy c2UgdGhleSBuZWVkIHRvIFRydXN0IHNvbWUgZW50aXR5IG9yIHNlcnZpY2UgaW4gdGhlIG5ldHdv cmsgdG8gaGVscCBwcm90ZWN0IHRoZW0uICBUaGF0IGVudGl0eSBvciBzZXJ2aWNlIGhlbHBpbmcg cHJvdGVjdCB0aGVtIG1pZ2h0IGJlIG9wZXJhdGluZyBvbiB0aGVpciBiZWhhbGYsIG9yIG9uIGJl aGFsZiBvZiB0aGVpciBlbXBsb3llciwgb3Igc29tZSBvdGhlciBlbnRpdHkgdGhleSBjaG9vc2Ug IHRvIHRydXN0LiAgSG93ZXZlciwgdGhleSBoYXZlIGEgcmlnaHQgdG8gY2hvb3NlIHdobyB0aGV5 IHRydXN0IHRvIHByb3RlY3QgdGhlbS4gIEZvciB0aGVzZSByZWFzb25zLCB3ZSB3YW50IHRvIGNv bGxlY3RpdmVseSBlbmdpbmVlciBhIHNlY3VyZSBtdWx0aS1wYXJ0eSBwcm90b2NvbCB3aGljaDoN Cg0KKGEpIEhlbHBzIGVhY2ggZW5kcG9pbnQgY29udHJvbCB3aGljaCBwYXJ0aWVzIGFuZCBuZXR3 b3JrIGRldmljZXMgYXJlIGVtcG93ZXJlZCB0byBkZWNyeXB0IHRyYWZmaWMgdG8gaGVscCBwcm90 ZWN0IHRoZW0sDQooYikgSGVscHMgZWFjaCBlbmRwb2ludCBzZWUgd2hlbiBvbmUgb2YgdGhvc2Ug cGFydGllcyBvciBkZXZpY2VzIG1vZGlmaWVzIGNvbnRlbnQgY29taW5nIGZyb20gdGhlIG90aGVy IGVuZHBvaW50LCBzdWNoIGFzIHJlbW92aW5nIGF0dGFja3MsIGFuZCBzZWUgdGhhdCB3aXRoIGEg Y3J5cHRvZ3JhcGhpYyBhdWRpdCB0cmFpbCBvZiB3aG8gY2hhbmdlZCB3aGF0IHdoZXJlIHdoZW4g YW5kIHdoeSwgc3VjaCBhcyByZW1vdmluZyBhdHRhY2tzLA0KKGMpIEFuZCBkb2VzIGFsbCBvZiB0 aGUgYWJvdmUgd2l0aG91dCBicmVha2luZyBvciB3ZWFrZW5pbmcgYW55IG9mIHRoZSBjcnlwdG9n cmFwaHkgb3IgY3J5cHRvZ3JhcGhpYyBwcm90b2NvbHMgaW4gYW55IHdheSwgaW5jbHVkaW5nIG5v dCBicmVha2luZyBvciBjaGFuZ2luZyBUTFMuDQoNCkl0IGlzIGltcG9ydGFudCB0byBjb25zaWRl ciB0aGUg4oCcZGVsZWdhdGVkIHByb3RlY3Rpb27igJ0gbW9kZWwuICBJbiBzdWNoIGEgbW9kZWws IHVuYXV0aG9yaXplZCBlYXZlc2Ryb3BwZXJzIHJlcHJlc2VudCBvbmUgb2YgYXQgbGVhc3QgdHdv IGNydWNpYWwgdGhyZWF0cyB3aGljaCBtdXN0IGJlIG1pdGlnYXRlZC4gIEluIHN1Y2ggYSBtb2Rl bCwgdGhlIHJlbW90ZSBlbmRwb2ludCByZXByZXNlbnRzIGFub3RoZXIgY3J1Y2lhbCB0aHJlYXQg d2hpY2ggbXVzdCAgYmUgbWl0aWdhdGVkIGFzIHRoYXQgcmVtb3RlIGVuZHBvaW50IG1pZ2h0IGJl IG1hbGljaW91cyBldmVuIHRob3VnaCB0aGUgZW5kcG9pbnQgb2Ygb3VyIGNhcmUgd2FudHMgb3Ig bmVlZHMgdG8gY29tbXVuaWNhdGUgd2l0aCB0aGF0IHJlbW90ZSBlbmRwb2ludC4gIFRoaXMgbW9k ZWwgaXMgc3VycHJpc2luZ2x5IGNvbW1vbiB0b2RheS4gIEZvciBpbnN0YW5jZSwgc2VydmVyIHRv IGNsaWVudCB3ZWIgYXR0YWNrcyBhcmUgaW5jcmVhc2luZ2x5IGNvbW1vbiAgYnkgbWFsaWNpb3Vz IG9yIGNvbXByb21pc2VkIHdlYnNpdGVzLiAgT2YgY291cnNlLCBjbGllbnQgdG8gc2VydmVyIGF0 dGFja3MgaGF2ZSBiZWVuIGNvbW1vbiBmb3IgeWVhcnMuICBNb3JlIHJlY2VudGx5LCBpdOKAmXMg YmVjb21lIGluY3JlYXNpbmdseSBjb21tb24gZm9yIHNlcnZlcnMgdG8gc3VydmVpbCBhbmQgcHJv ZmlsZSBjbGllbnRzLCBhIHByaXZhY3kgdGhyZWF0IGNvbXBvdW5kZWQgYnkgc2VydmVycyBjb2xs YWJvcmF0aW5nIHRocm91Z2ggIG1hc3NpdmUgYWR2ZXJ0aXNpbmcgKGFkKSBuZXR3b3JrcyBmb3Ig dHJhY2tpbmcgdXNlciBhY3Rpdml0aWVzLiAgU3VjaCBzdXJ2ZWlsbGFuY2UgdGhyb3VnaCBwcm9m aWxpbmcgYW5kIHRyYWNraW5nIHJlcHJlc2VudHMgYSBwcml2YWN5IHRocmVhdCBtYW55IHBlb3Bs ZSB3b3VsZCBsaWtlIHRvIHNlZSBiZXR0ZXIgbWl0aWdhdGVkLiAgSW4gZmFjdCwgaXQgaXMgYWxz byBhIHByaXZhY3kgdGhyZWF0IHRoYXQgY2FuIGJlIHBvdGVudGlhbGx5IG1pdGlnYXRlZCAgYnkg cHJvdGVjdGlvbiBzZXJ2aWNlcyBydW5uaW5nIGluIHRoZSBuZXR3b3JrLiAgSW4gYWxsIHN1Y2gg Y2FzZXMsIGl04oCZcyByZWFzb25hYmxlIGZvciBsaW1pdGVkIGVuZHBvaW50cyB0byBjaG9vc2Ug bW9yZSBwb3dlcmZ1bCBuZXR3b3JrIHNlcnZpY2VzIHRvIHByb3RlY3QgdGhlbSBhZ2FpbnN0IHN1 Y2ggdGhyZWF0cy4NCg0KRm9ydHVuYXRlbHksIHNldmVyYWwgc3RhcnRpbmcgcGxhY2VzIGV4aXN0 IGZvciBwcm90b2NvbHMgdG8gYWNoaWV2ZSByZXF1aXJlbWVudHMgKGEpLCAoYiksIGFuZCAoYykg YWJvdmUuICBGb3IgaW5zdGFuY2UsIHdpdGggc29tZSBtb2RpZmljYXRpb25zLCBpdCB3b3VsZCBi ZSBnb29kIHRvIHVzZSB0aGUgU3RpY2tsZXIgcHJvdG9jb2wgcHJvcG9zZWQgYnkgQS4NCkxldnks IEguIENvcnJpZ2FuLUdpYmJzLCBhbmQgRC4gQm9uZWggaW4gY29uanVuY3Rpb24gd2l0aCBtb2Rp ZmllZCB2YXJpYW50cyBvZiB1bmZvcnR1bmF0ZWx5IG5hbWVkIHByb3RvY29scyBzdWNoIGFzIG1i VExTIGFuZC9vciBUTFMtUkFSLiAgT3VyIHZpc2lvbiBpcyBmb3Igc3VjaCBhIHByb3RvY29sIHRv IHJ1biBpbiBwYXJhbGxlbCB0byBUTFMsIGNvbXBsaW1lbnRpbmcgaXQsIHdpdGhvdXQgbW9kaWZ5 aW5nIG9yIGNvbnN0cmFpbmluZyBUTFMgIHdoaWxlIGhlbHBpbmcgY29vcmRpbmF0ZSBuZXR3b3Jr IHByb3RlY3Rpb24gb2YgZW5kcG9pbnRzLiAgVG8gZG8gc28sIHN1Y2ggYSBwcm90b2NvbCBzaG91 bGQgYWxzbyBiZXR0ZXIgaW5mb3JtIGVuZHBvaW50cyBvZiB0aGUgc3BlY2lmaWNzIG9mIG5ldHdv cmsgZGV2aWNlcyBhdmFpbGFibGUgZm9yIHByb3RlY3Rpb24sIHNwZWNpZmljcyB3aGljaCB0aGUg ZW5kcG9pbnQgbWlnaHQgY2FyZSBhYm91dCBiZWZvcmUgZW1wb3dlcmluZyBzdWNoIG5ldHdvcmsg IGRldmljZXMgYnkgdHJ1c3RpbmcgdGhlbSB0byBoZWxwIHByb3ZpZGUgc3VjaCBwcm90ZWN0aW9u Lg0KDQpXaXRoIHN1Y2ggdmFsdWFibGUgcmVzZWFyY2ggYWNjb21wbGlzaGVkIHRvIGRhdGUgaW4g dGhpcyBzcGFjZSBwcm9wb3NpbmcgYSB2YXJpZXR5IG9mIHBvdGVudGlhbCBwcm90b2NvbHMgYXMg c3RhcnRpbmcgcG9pbnRzLCBpdOKAmXMgaW1wb3J0YW50IHRvIHNvb24gZW5naW5lZXIgYSBzdGFu ZGFyZGl6ZWQgcHJvdG9jb2wgdG8gbWVldCB0aGUgcm91Z2ggY29uc2Vuc3VzIG9mIHRoZSBJRVRG IGZvciBwcm92aWRpbmcgc3VjaCBwcm90ZWN0aW9uIG1vcmUgIHNhZmVseSB0aGFuIHRvZGF54oCZ cyBjb21tb24gcHJhY3RpY2VzLiAgVG9kYXnigJlzIGNvbW1vbiBwcmFjdGljZXMgbm90IG9ubHkg ZmFpbCB0byBtZWV0IHRoZSB0aHJlZSByZXF1aXJlbWVudHMgb3V0bGluZWQgYWJvdmUsIGJ1dCB0 b2RheeKAmXMgY29tbW9uIHByYWN0aWNlcyBhbHNvICgxKSBhbGxvdyBtaWRkbGVib3hlcyB0byBu ZWdvdGlhdGUgd2Vha2VyIFRMUyBzZXNzaW9ucyB3aXRob3V0IGFkdmlzaW5nIHRoZSBlbmRwb2lu dCBvZiB0aGUgcmlza3MgIG9mIHRoZSB3ZWFrZXIgc2Vzc2lvbiBvbiB0aGUgZmFyIHNpZGUgb2Yg dGhlIG1pZGRsZWJveCwgKDIpIGZhaWwgdG8gaW5mb3JtIHRoZSBlbmRwb2ludHMgb2YgaG93IHNl Y3VyZSB0aGUgbWlkZGxlYm94IG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSwgdGhlIG1hbm5lciBpbiB3 aGljaCB0aGUgbWlkZGxlYm94IGl0c2VsZiBpcyBzYWZlZ3VhcmRlZCwgYW5kICgzKSBmYWlsIHRv IGluZm9ybSB0aGUgZW5kcG9pbnRzIG9mIHRoZSBpbmZvcm1hdGlvbiByZXRlbnRpb24gIGFuZCBk aXNjbG9zdXJlIHBvbGljaWVzIHVuZGVyIHdoaWNoIHRoZSBtaWRkbGVib3ggaXMgb3BlcmF0aW5n Lg0KDQpDbGVhcmx5IGEgYmV0dGVyIGFwcHJvYWNoIGlzIG5lZWRlZCwgYW5kIHVyZ2VudGx5LiAg TmV0d29yayBtZWRpYXRpb24gY2FuIHBsYXkgYSBjcnVjaWFsIHJvbGUgaW4gcHJvdGVjdGluZyBw ZW9wbGUgZnJvbSB0aGUgc2VydmVyIHRvIGNsaWVudCBhdHRhY2tzIHRoYXQgaGF2ZSBiZWVuIHVz ZWQgdG8gdW5tYXNrIHRoZSBhbm9ueW1pdHkgb2YgZGlzc2lkZW50cyBzcGVha2luZyB1cCBhZ2Fp bnN0IHJlcHJlc3NpdmUgcmVnaW1lcywgZGlzc2lkZW50cyAgd2hvIHdlcmUgdGhlbiBkaXNhcHBl YXJlZCBhZnRlciB0aGUgc2VydmVyIHRvIGNsaWVudCBhdHRhY2tzIHdlcmUgdXNlZCB0byB1bm1h c2sgdGhlbSBieSBjb21wcm9taXNpbmcgdGhlaXIgbW9iaWxlIGVuZHBvaW50LiAgVHJ1c3R3b3J0 aHkgbmV0d29yayBtZWRpYXRpb24gY2FuIHBsYXkgYSBjcnVjaWFsIHJvbGUgaW4gcHJvdGVjdGlu ZyBwZW9wbGUgYWdhaW5zdCBzdWNoIGF0dGFja3MsIGJ1dCB0b2RheSwgd2hlcmUgZW5kcG9pbnRz IHRydXN0ICBtaWRkbGVib3hlcywgdGhlcmUgaXMgbm90IHlldCBhIHN0YW5kYXJkaXplZCBwcm90 b2NvbCBmb3IgZW5kcG9pbnRzIHRvIHVuZGVyc3RhbmQgd2hlbiB0aG9zZSBtaWRkbGVib3hlcyBh cmUgd2Vha2VuaW5nIHRoZSBjcnlwdG8sIGNoYW5naW5nIHRoZSBjb250ZW50LCB0cnVzdGluZyBv dGhlciBtaWRkbGVib3hlcywgYW5kIGRvaW5nIG90aGVyIHRoaW5ncyB0aGF0IG1pZ2h0IGNhdXNl IHRoZSBlbmRwb2ludCB0byBub3QgdHJ1c3QgdGhlIG1pZGRsZWJveC4NCg0KU3RpbGwsIGVuZ2lu ZWVyaW5nIHN1Y2ggYSBwcm90b2NvbCBpcyBub3QgZWFzeS4gIFN1Y2ggcHJvdG9jb2xzIHdvdWxk IG5lZWQgdG8gYWRkcmVzcyBhIHJhbmdlIG9mIHVzZSBjYXNlcyBpbmNsdWRpbmcgYm90aCByZWFs LXRpbWUgYW5kIHBvc3QtZmFjdG8sIGFsb25nIHdpdGggYm90aCB3aWRlLWFyZWEgYW5kIGRhdGFj ZW50ZXIgdXNlIGNhc2VzLiAgQXMgaW5pdGlhbCB3b3JraW5nIGRpZmZlcmVudGlhdGlvbiBvZiB0 aGVzZSB0ZXJtcywgd2XigJlkICBwcm9wb3NlIHJlYWwtdGltZSB0byBpbmNsdWRlIGJsb2NraW5n IG9mIGF0dGFja3MuIFBvc3QtZmFjdG8gaW5jbHVkZXMgYm90aCBmb3JlbnNpYyBpbnZlc3RpZ2F0 aW9uIG9mIHNvcGhpc3RpY2F0ZWQgYXR0YWNrcyBhbmQgYWxzbyBhdWRpdCBjb21wbGlhbmNlIGFr YSBvdXQtb2YtYmFuZCBkZWNyeXB0aW9uLiBXaWRlLWFyZWEgdXNlIGNhc2VzIGluY2x1ZGUgc2hh cmVkIG5ldHdvcmtzIHdoZXJlIHRoZSBkZXZpY2Ugb3IgZW50aXR5IGhlbHBpbmcgIHByb3ZpZGUg cHJvdGVjdGlvbiBpcyBvbmx5IHJlYWNoZWQgYWNyb3NzIGEgbmV0d29yayBvcGVyYXRlZCBieSBh bmQvb3Igc2hhcmVkIHdpdGggb3RoZXIgdW50cnVzdGVkIHBhcnRpZXMuICBUaGUgZGF0YWNlbnRl ciB1c2UgY2FzZSBpbmNsdWRlcyBuZXR3b3JrcyBhZGphY2VudCB0byB0aGUgZW5kcG9pbnQgYW5k IG93bmVkIGJ5IHRoZSBzYW1lIHBhcnR5IGFzIG93bmluZyB0aGUgZW5kcG9pbnQuDQoNCkluIGVu Z2luZWVyaW5nIHN1Y2ggYSBwcm90b2NvbCwgaXTigJlzIGltcG9ydGFudCB0byByZXNwZWN0IGZ1 bmRhbWVudGFsIHByaW5jaXBsZXMgb2YgZW5kLXRvLWVuZCBlbmNyeXB0aW9uIGFuZCwgYXQgdGlt ZXMsIHNpbWlsYXIgZW5kLXRvLWVuZCBmbGV4aWJpbGl0eSBpbiByb3V0ZSBvcHRpbWl6YXRpb24u ICBPbiBlbmQtdG8tZW5kIGVuY3J5cHRpb24sIHNvbWUgb2YgdGhlIGFwcHJvYWNoZXMgdGhhdCBo YXZlIGJlZW4gcHJvcG9zZWQgaW5jbHVkZSAgbGV2ZXJhZ2luZyB0aGUgc3ltbWV0cmljIGtleSBk ZXRlcm1pbmVkIHN0cmljdGx5IGJldHdlZW4gdGhlIHNlcnZlciBhbmQgY2xpZW50LCBhbmQgdGhl biBoYXZpbmcgdGhlIGVuZHBvaW50IHNoYXJlIHRoYXQgc3ltbWV0cmljIGtleSBvbmx5IHdpdGgg YSBuZXR3b3JrIGRldmljZSBvciBzZXJ2aWNlIHdoaWNoIGl0IHRydXN0cyB0byBoZWxwIHdpdGgg cHJvdGVjdGlvbiBhZ2FpbnN0IHRoZSByZW1vdGUgZW5kcG9pbnQuICBJbiBhZGRpdGlvbiB0byAg cHJlc2VydmluZyBlbmQtdG8tZW5kIGVuY3J5cHRpb24gYW5kIGFjY2VsZXJhdGluZyBkZXBsb3lt ZW50IG9mIHN0cm9uZ2VyIGNyeXB0bywgaXTigJlzIGFsc28gaW1wb3J0YW50IHRvIHByZXNlcnZl IGVuZC10by1lbmQgZmxleGliaWxpdHkgaW4gcm91dGluZyB3aGVuZXZlciBwb3NzaWJsZS4gIEN1 cnJlbnRseSwgZm9yIGF0dGFja3MgdHVubmVsaW5nIHRocm91Z2ggZW5jcnlwdGVkIG5ldHdvcmsg c2Vzc2lvbnMsIG5ldHdvcmsgYmFzZWQgcHJvdGVjdGlvbiAgaXMgb2Z0ZW4gcHJvdmlkZWQgdGhy b3VnaCBwcm94aWVzIGFuZCB0aGUgbGlrZSBlaXRoZXIgZW1iZWRkZWQgaW4gbmV0d29yayBnYXRl d2F5cyBvciBkYXRhY2VudGVycyBob3N0aW5nIHBlcnNvbmFsLVZQTiB0eXBlIGNsb3VkIGJhc2Vk IHNlcnZpY2VzIHRocm91Z2ggd2hpY2ggYWxsIG9mIGEgY2xpZW504oCZcyB0cmFmZmljIGlzIHJv dXRlZC4gIEhvd2V2ZXIsIGxvbmdlciB0ZXJtLCBzdWNoIHByb3RlY3Rpb24gY291bGQgYmUgYWNo aWV2ZWQgYnkgIGhhdmluZyBzdWNoIOKAnHByb3RlY3Rpb24gc2VydmljZXPigJ0gcnVubmluZyBt b3JlIGZsZXhpYmx5IGluIGEgZGlzdHJpYnV0ZWQgbWFubmVyLCBpbiBoYXJkd2FyZSBwcm90ZWN0 ZWQgZW5jbGF2ZXMgYW5kL29yIFRydXN0ZWQgRXhlY3V0aW9uIEVudmlyb25tZW50cyBtaWdyYXRp bmcgdGhlIGZ1bmN0aW9uYWxpdHkgYW1vbmcgU29mdHdhcmUgRGVmaW5lZCBOZXR3b3JraW5nIChT RE4pIGFuZC9vciBOZXR3b3JrIEZ1bmN0aW9uIFZpcnR1YWxpemF0aW9uICAoTkZWKSBlbmFibGVk IGVxdWlwbWVudC4NCg0KDQpGcm9tIGRpc2N1c3Npb25zIHdpdGhpbiBub3Qgb25seSBJRVRGIHBh cnRpY2lwYW50cywgYnV0IGFsc28gcGVvcGxlIGVuZ2FnZWQgaW4gcmVsYXRlZCBkaXNjdXNzaW9u cyBpbiBJRUVFLCBVTi9JVFUsIEVUU0ksIGFuZCBvdGhlcnMgaW4gdGhpcyBhcmVhIGVhZ2VyIHRv IHBhcnRpY2lwYXRlIGluIGFuIElFVEYgcHJvY2VzcyBpbiB0aGlzIGFyZWEsIHdlIGJlbGlldmUg dGhhdCB0aGVyZSBpcyBhIGNyaXRpY2FsIG1hc3Mgb2YgcGFydGljaXBhbnRzICB3aWxsaW5nIHRv IHdvcmsgb24gdGhlIHByb2JsZW0gKGUuZy4sIHdyaXRlIGRyYWZ0cywgcmV2aWV3IGRyYWZ0cywg ZXRjLikgZm9yIG1lZXRpbmcgcmVxdWlyZW1lbnRzIChhKSwgKGIpLCBhbmQgKGMpIGRlc2NyaWJl ZCBhYm92ZS4gIE1hbnkgb2YgdXMgcGVyc29uYWxseSBiZWxpZXZlIHRoYXQgdGhlIElFVEYgaXMg dGhlIHJpZ2h0IGJlc3QgcGxhY2UgZm9yIHN1Y2ggd29yayBmb3IgY291bnRsZXNzIHJlYXNvbnMu IFdlIGFyZSBvZiBjb3Vyc2UgIHZlcnkgZmFtaWxpYXIgd2l0aCBwcmV2aW91cyBhdHRlbXB0cyB3 aXRoaW4gdGhlIElFVEYsIGluY2x1ZGluZyBFeHBsaWNpdGx5IFRydXN0ZWQgUHJveHkgYW5kIFRM UyBQcm94eSBzZXJ2ZXIgYW1vbmcgb3RoZXJzLg0KDQpXZSBhcmUgYWxzbyBhd2FyZSBvZiB0aGUg bmVlZCBmb3IgY29vcmRpbmF0aW9uIG9mIHN1Y2ggd29yayBub3Qgb25seSB3aXRoIHRoZSBUTFMg d29ya2luZyBncm91cCwgYnV0IGFsc28gRFBSSVZFLCBRVUlDLCBJMk5TRiwgYW5kIG90aGVyIElF VEYgZWZmb3J0cywgYW5kIHdlIGJlbGlldmUgdGhhdCBhbiBpbmRlcGVuZGVudCBXRyBjb3VsZCBi ZSBtb3JlIGhlbHBmdWwgdGhhbiB0cnlpbmcgdG8gZG8gYWxsIG9mIHRoaXMgd29yayBpbiBhbnkg ZXhpc3RpbmcgIHdvcmtpbmcgZ3JvdXAgc3VjaCBhcyB0aGUgVExTIFdHLCBwYXJ0aWN1bGFybHkg c2luY2UgdGhlIGJlc3Qgc29sdXRpb24gbWlnaHQgYmUgYSBuZXcgcHJvdG9jb2wgdGhhdCBjb21w bGltZW50cyBUTFMsIHJ1bm5pbmcgaW4gY29uanVuY3Rpb24gd2l0aCBUTFMsIHdpdGhvdXQgZXh0 ZW5kaW5nLCBjaGFuZ2luZywgcmVmaW5pbmcsIG9yIGJyZWFraW5nIGl0LCBvciBhbnkgb3RoZXIg ZXhpc3RpbmcgcHJvdG9jb2xzIGFscmVhZHkgc28gaW1wb3J0YW50ICB0byBzZWN1cml0eSBhbmQg cHJvcGVyIGZ1bmN0aW9uaW5nIG9mIHRoZSBuZXR3b3JrLg0KDQpJbiB0aGF0IHRoZSB3b3JsZCBo YXMgYWxyZWFkeSBzZWVuIGFub255bW91cyBkaXNzaWRlbnRzIGRpc2FwcGVhcmVkIGFmdGVyIHdo YXQgbWFueSB3b3VsZCBjb25zaWRlciByZXByZXNzaXZlIHJlZ2ltZXMgdXNlZCBzb3BoaXN0aWNh dGVkIHNlcnZlci10by1jbGllbnQgYXR0YWNrcyB0byB1bm1hc2sgdGhlaXIgYW5vbnltaXR5LCBJ IGJlbGlldmUgdGhhdCB3ZSBuZWVkIGEgd29ybGQgd2hlcmUgYm90aCAoMSkgdGhlIGNvbm5lY3Rp b25zIGFyZSBzZWN1cmUgIGEgbGEgZ3JlYXQgVExTLCBhbmQgKDIpIHRoZSB0cmFmZmljIGlzIHNh ZmUgdG8gcmVjZWl2ZSwgYXMgdmV0dGVkIGJ5IHNvbWV0aGluZyBvciBzb21lb25lIHRoZSBlbmRw b2ludCBjaG9vc2VzIGZvciBwcm90ZWN0aW9uIGFnYWluc3QgcmVtb3RlIGVuZHBvaW50cy4NCg0K SW4gdGhhdCBjb250ZXh0LCB3ZSBhcmUgZGVlcGx5IGdyYXRlZnVsIHRoYXQgSUVURiBoYXMgYWxs b3dlZCBjcmVhdGlvbiBvZiB0aGlzIG1haWxpbmcgbGlzdCBmb3IgZGlzY3Vzc2lvbiBvZiB0aGVz ZSBpbXBvcnRhbnQgdG9waWNzLiAgUGxlYXNlIGxldCBtZSBrbm93IGFueXRoaW5nIHRoYXQgSSBj YW4gZG8gdG8gaGVscCB5b3Ugb3IgdGhlIElFVEYgb24gdGhpcy4NCg0KV2l0aCBNeSBEZWVwZXN0 IFRoYW5rcyBGb3IgQWxsIFRoYXQgWW91IERvIEZvciBUaGUgSUVURiwgQW5kIEZvciBUaGUgV29y bGQgVGhyb3VnaCBUaGUgSUVURiwNCkJyaWFuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KUEFUSUVOVCBtYWlsaW5nIGxpc3QNClBBVElFTlRAaWV0Zi5v cmc8bWFpbHRvOlBBVElFTlRAaWV0Zi5vcmc+DQo= --_000_5EF76C0024D5422E86F1A955A1656856akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1u YW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PZiBpbnRlcmVzdCBoZXJlPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5CcmlhbiBXaXR0ZW4gJmx0O2JyaWFu X3dpdHRlbkBzeW1hbnRlYy5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwgTm92 ZW1iZXIgOCwgMjAxNyBhdCA5OjE4IEFNPGJyPg0KPGI+VG86IDwvYj5zYWFnICZsdDtzYWFnQGll dGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bc2FhZ10gQW5ub3VuY2luZyB0aGUgUEFU SUVOVCBtYWlsaW5nIGxpc3QgJmFtcDsgbWVldGluZyBpbiBTaW5nYXBvcmU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgQWxs LDxicj4NCjxicj4NCkZvciBhbnlvbmUgaW50ZXJlc3RlZCBpbiBQcm90ZWN0aW5nIGFnYWluc3Qg QXR0YWNrcyBUdW5uZWxpbmcgSW4gRW5jcnlwdGVkIE5ldHdvcmsgVHJhZmZpYyAoUEFUSUVOVCks IEnigJltIGFubm91bmNpbmcgYm90aCBhIG1lZXRpbmcgYmVsb3csIGFuZCBtYWlsaW5nIGxpc3Qs IGZ1cnRoZXIgYmVsb3cuICZuYnNwO0ludGVudCBvZiBQQVRJRU5UIGlzIHRvIGNyZWF0ZSBhIHNl Y3VyZSBtdWx0aS1wYXJ0eSBwcm90b2NvbCBmb3IgbWFraW5nIHN1Y2ggcHJvdGVjdGlvbg0KIGZh ciBzYWZlciB3aXRob3V0IG1vZGlmeWluZywgY29uc3RyYWluaW5nLCBvciBicmVha2luZyBUTFMg aW4gYW55IHdheSwgYSBwcm90b2NvbCBjb21wbGltZW50aW5nIGN1cnJlbnQgVExTIGluY2x1ZGlu ZyBUTFMgMS4zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JbnRlbnQgb2YgUEFUSUVOVCBpcyB0byBkbyBzbyZuYnNwO2luIGxpZ2h0 IG9mIGJvdGggKGEpIHZ1bG5lcmFiaWxpdGllcyBpbiZuYnNwO3RvZGF54oCZcyZuYnNwO2NvbW1v biBhcHByb2FjaGVzLCBhbmQgKGIpIGh1Z2UgZ3Jvd2luZyBudW1iZXIgb2YgYXR0YWNrcyB0dW5u ZWxpbmcgaW4gZW5jcnlwdGVkIHRyYWZmaWMsIGFscmVhZHkgaHVydGluZyBiaWxsaW9ucyBvZiBw ZW9wbGUsIHNvbWV0aW1lcyB3aXRoIGRpcmUgY29uc2VxdWVuY2VzDQogZm9yIHRoZWlyIHByaXZh Y3ksIGZyZWVkb20sICZhbXA7IHBoeXNpY2FsIHdlbGwgYmVpbmcuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBtZWV0aW5nIHdp bGwgYmU6PGJyPg0KKiogV2hlbjombmJzcDs8YSBocmVmPSJ4LWFwcGxlLWRhdGEtZGV0ZWN0b3Jz Oi8vMCI+V2VkbmVzZGF5LCBOb3ZlbWJlciAxNSwgOHBtPC9hPiwgc2hvcnRseSBmb2xsb3dpbmcg dGhlIHBsZW5hcnkuPGJyPg0KKiogV2hlcmU6IE9yY2hhcmQgUm9vbSBvZiB0aGUgQ29udmVudGlv biBDZW50ZXIgd2hlcmUgdGhlIElFVEYgTWVldGluZ3MgYXJlIGJlaW5nIGhlbGQuPGJyPg0KPGJy Pg0KSSBub3RlIHRoYXQmbmJzcDtwcmUtY29uY2VwdGlvbnMmbmJzcDtoYXZlIHNldmVyZWx5IHBv bGFyaXplZCZuYnNwO2EgbnVtYmVyIG9mIHBhc3QgYXR0ZW1wdHMgYXQgc29sdmluZyBwcm9ibGVt cyBzaW1pbGFyIHRvIHRoaXMsIGFuZCB3aXRob3V0IGJldHRlciBzdGFuZGFyZHMgZm9yIHN1Y2gg cHJvdGVjdGlvbiwgc2VjdXJpdHkgc3VmZmVycyBpbiBtYW55IHdheXMsIGluY2x1ZGluZyBjaGFs bGVuZ2VzIHNhZmVseSByb2xsaW5nIG91dCBpbXBvcnRhbnQgbmV3IHByb3RvY29scw0KIGxpa2Ug VExTIDEuMyBhcyBxdWlja2x5IGFuZCBhcyB3aWRlbHkgYXMgd2XigJlkIGFsbCBsaWtlLiAmbmJz cDtXZSBzZWVrIGEg4oCcbWlkZGxl4oCdIGdyb3VuZCB0aGF0IGlzIG5vdCBhIHNhY3JpZmljZSBi eSBlaXRoZXIgc2lkZSBidXQgcmF0aGVyIGhvcGVmdWxseSBhIGJlc3Qgb2YgYm90aCB3b3JsZHMu PGJyPg0KPGJyPg0KSWYgeW91IGFyZSB3YW50aW5nIHRvIHByb3RlY3QgYWdhaW5zdCBhdHRhY2tz IHR1bm5lbGluZyBpbiBlbmNyeXB0ZWQgdHJhZmZpYywgYW5kIHdhbnRpbmcgdG8gbWFrZSBzdWNo IHByb3RlY3Rpb24gZmFyIHNhZmVyIGZyb20gYm90aCBzZWN1cml0eSBhbmQgcHJpdmFjeSBwZXJz cGVjdGl2ZXMsIHBsZWFzZSBqb2luIHVzIGZvciB0aGlzIG1lZXRpbmcsIGFuZCBwbGVhc2Ugam9p biB1cyBpbiBoZWxwaW5nIGtlZXAgZGlzY3Vzc2lvbiBjb25zdHJ1Y3RpdmUNCiBhbmQgcmVzcGVj dGZ1bCBvZiBwZW9wbGUgd2l0aCB3aWRlbHkgZGlmZmVyaW5nIHZpZXdzLiAmbmJzcDtJIGJlbGll dmUgd2UgYWxsIHdhbnQgdG8gbWFrZSB0aGUgSW50ZXJuZXQgYW5kIHdvcmxkIHNhZmVyLjxicj4N Cjxicj4NCldpdGggTXkgRGVlcGVzdCBUaGFua3MgRm9yIEFsbCBUaGF0IFlvdSBEbyBGb3IgVGhl IElFVEYsIEFuZCBGb3IgVGhlIFdvcmxkIFRocm91Z2ggVGhlIElFVEYsPGJyPg0KQnJpYW48YnI+ DQo8YnI+DQo8YSBocmVmPSJtYWlsdG86YndpdHRlbkBzeW1hbnRlYy5jb20iPmJ3aXR0ZW5Ac3lt YW50ZWMuY29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCkJlZ2luIGZvcndh cmRlZCBtZXNzYWdlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPkZyb206PC9iPiBCcmlh biBXaXR0ZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpicmlhbl93aXR0ZW5Ac3ltYW50ZWMuY29tIj5i cmlhbl93aXR0ZW5Ac3ltYW50ZWMuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOjwvYj4gTm92ZW1i ZXIgOCwgMjAxNyBhdCAxMjo1OTo1NSBBTSBQU1Q8YnI+DQo8Yj5Ubzo8L2I+ICZxdW90OzxhIGhy ZWY9Im1haWx0bzpwYXRpZW50QGlldGYub3JnIj5wYXRpZW50QGlldGYub3JnPC9hPiZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnBhdGllbnRAaWV0Zi5vcmciPnBhdGllbnRAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiA8Yj5Bbm5vdW5jaW5nIHRoZSBQQVRJRU5UIG1lZXRp bmcgaW4gU2luZ2Fwb3JlPC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIEFsbCw8YnI+DQo8YnI+DQpGb3Ig YW55b25lIGludGVyZXN0ZWQgaW4gUHJvdGVjdGluZyBhZ2FpbnN0IEF0dGFja3MgVHVubmVsaW5n IEluIEVuY3J5cHRlZCBOZXR3b3JrIFRyYWZmaWMgKFBBVElFTlQpLCB3ZSdsbCBiZSBoYXZpbmcg YSBtZWV0aW5nIGluIFNpbmdhcG9yZS48YnI+DQoqKiBXaGVuOiBXZWRuZXNkYXksIE5vdmVtYmVy IDE1LCA4cG0sIHNob3J0bHkgZm9sbG93aW5nIHRoZSBwbGVuYXJ5Ljxicj4NCioqIFdoZXJlOiBP cmNoYXJkIFJvb20gb2YgdGhlIENvbnZlbnRpb24gQ2VudGVyIHdoZXJlIHRoZSBJRVRGIE1lZXRp bmdzIGFyZSBiZWluZyBoZWxkLjxicj4NCjxicj4NClRoaXMgc2lkZSBtZWV0aW5nIGlzIGFraW4g dG8gJnF1b3Q7YmFyIEJPRiZxdW90OyBpbiBwcmVwYXJhdGlvbiBmb3IgaG9wZWZ1bGx5IGhvc3Rp bmcgYSBmdWxsIEJpcmRzIG9mIGEgRmVhdGhlciAoQk9GKSBtZWV0aW5nIGF0IElFVEYgMTAxIGlu IExvbmRvbiBpbiBhIGZldyBtb250aHMuICZuYnNwO1BsZWFzZSBmZWVsIGZyZWUgdG8gZGlyZWN0 bHkgbGV0IG1lIGtub3cgYW55IHF1ZXN0aW9ucyBvciBjb25jZXJucy48YnI+DQo8YnI+DQpXaXRo IE15IERlZXBlc3QgVGhhbmtzIEZvciBBbGwgVGhhdCBZb3UgRG8gRm9yIFRoZSBJRVRGLCBBbmQg Rm9yIFRoZSBXb3JsZCBUaHJvdWdoIFRoZSBJRVRGLDxicj4NCkJyaWFuPGJyPg0KPGJyPg0KPGEg aHJlZj0ibWFpbHRvOmJ3aXR0ZW5Ac3ltYW50ZWMuY29tIj5id2l0dGVuQHN5bWFudGVjLmNvbTwv YT48YnI+DQo8YnI+DQpGcm9tOiBQQVRJRU5UICZsdDs8YSBocmVmPSJtYWlsdG86cGF0aWVudC1i b3VuY2VzQGlldGYub3JnIj5wYXRpZW50LWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhh bGYgb2YgQnJpYW4gV2l0dGVuICZsdDs8YSBocmVmPSJtYWlsdG86YnJpYW5fd2l0dGVuQHN5bWFu dGVjLmNvbSI+YnJpYW5fd2l0dGVuQHN5bWFudGVjLmNvbTwvYT4mZ3Q7PGJyPg0KU2VudDogTW9u ZGF5LCBOb3ZlbWJlciA2LCAyMDE3IDQ6MjYgUE08YnI+DQpUbzogPGEgaHJlZj0ibWFpbHRvOnBh dGllbnRAaWV0Zi5vcmciPnBhdGllbnRAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogW0VYVF0g W1BhdGllbnRdIFdlbGNvbWUgdG8gdGhlIFBBVElFTlQgTWFpbGluZyBMaXN0PGJyPg0KJm5ic3A7 IDxicj4NCjxicj4NCkRlYXIgQWxsLDxicj4NCjxicj4NCldlbGNvbWUgdG8gdGhlIG1haWxpbmcg bGlzdCBmb3IgUHJvdGVjdGluZyBhZ2FpbnN0IEF0dGFja3MgVHVubmVsaW5nIEluIEVuY3J5cHRl ZCBOZXR3b3JrIFRyYWZmaWMgKFBBVElFTlQpLjxicj4NCjxicj4NCldlIGFyZSB0aHJpbGxlZCB0 byBzZWUgb3ZlciBoYWxmIG9mIHRoZSB3b3JsZOKAmXMgd2ViIGNvbm5lY3Rpb25zIGVuY3J5cHRl ZCwgYW5kIHdlIGRvIG5vdCB3YW50IHRvIHdlYWtlbiBjcnlwdG8gb3IgVExTIGluIGFueSB3YXku Jm5ic3A7IEF0IHRoZSBzYW1lIHRpbWUsIGhhbGYgb2YgdGhlIHdvcmxk4oCZcyBhdHRhY2tzIGFy ZSBub3cgdHVubmVsaW5nIHRocm91Z2ggZW5jcnlwdGVkIHNlc3Npb25zLCBhbmQgbWFueSBlbmRw b2ludHMgbmVlZCBoZWxwIHByb3RlY3RpbmcNCiAmbmJzcDt0aGVtc2VsdmVzIGFnYWluc3QgdGhl c2UgYXR0YWNrcy4mbmJzcDsgT2Z0ZW4gdGhleSBjYW4gb25seSBnZXQgdGhhdCBoZWxwIGZyb20g dGhlIG5ldHdvcmsuJm5ic3A7IEZvcnR1bmF0ZWx5LCB0aGVyZSBhcmUgaW4gZmFjdCB3YXlzIGZv ciBuZXR3b3JrIGRldmljZXMgdG8gaGVscCBwcm90ZWN0IGFnYWluc3QgdGhlIGZ1bGwgcmFuZ2Ug b2YgYXR0YWNrcyB0aGF0IG1pZ2h0IGJlIHR1bm5lbGluZyB0aHJvdWdoIGVuY3J5cHRlZCBzZXNz aW9ucy4mbmJzcDsgU3RpbGwsIGZvcg0KICZuYnNwO2VuZHBvaW50cyB0byBnZXQgc3VjaCBoZWxw IG9mIGNvdXJzZSB0aGV5IG5lZWQgdG8gVHJ1c3Qgc29tZSBlbnRpdHkgb3Igc2VydmljZSBpbiB0 aGUgbmV0d29yayB0byBoZWxwIHByb3RlY3QgdGhlbS4mbmJzcDsgVGhhdCBlbnRpdHkgb3Igc2Vy dmljZSBoZWxwaW5nIHByb3RlY3QgdGhlbSBtaWdodCBiZSBvcGVyYXRpbmcgb24gdGhlaXIgYmVo YWxmLCBvciBvbiBiZWhhbGYgb2YgdGhlaXIgZW1wbG95ZXIsIG9yIHNvbWUgb3RoZXIgZW50aXR5 IHRoZXkNCiBjaG9vc2UgJm5ic3A7dG8gdHJ1c3QuJm5ic3A7IEhvd2V2ZXIsIHRoZXkgaGF2ZSBh IHJpZ2h0IHRvIGNob29zZSB3aG8gdGhleSB0cnVzdCB0byBwcm90ZWN0IHRoZW0uJm5ic3A7IEZv ciB0aGVzZSByZWFzb25zLCB3ZSB3YW50IHRvIGNvbGxlY3RpdmVseSBlbmdpbmVlciBhIHNlY3Vy ZSBtdWx0aS1wYXJ0eSBwcm90b2NvbCB3aGljaDo8YnI+DQo8YnI+DQooYSkgSGVscHMgZWFjaCBl bmRwb2ludCBjb250cm9sIHdoaWNoIHBhcnRpZXMgYW5kIG5ldHdvcmsgZGV2aWNlcyBhcmUgZW1w b3dlcmVkIHRvIGRlY3J5cHQgdHJhZmZpYyB0byBoZWxwIHByb3RlY3QgdGhlbSw8YnI+DQooYikg SGVscHMgZWFjaCBlbmRwb2ludCBzZWUgd2hlbiBvbmUgb2YgdGhvc2UgcGFydGllcyBvciBkZXZp Y2VzIG1vZGlmaWVzIGNvbnRlbnQgY29taW5nIGZyb20gdGhlIG90aGVyIGVuZHBvaW50LCBzdWNo IGFzIHJlbW92aW5nIGF0dGFja3MsIGFuZCBzZWUgdGhhdCB3aXRoIGEgY3J5cHRvZ3JhcGhpYyBh dWRpdCB0cmFpbCBvZiB3aG8gY2hhbmdlZCB3aGF0IHdoZXJlIHdoZW4gYW5kIHdoeSwgc3VjaCBh cyByZW1vdmluZyBhdHRhY2tzLDxicj4NCihjKSBBbmQgZG9lcyBhbGwgb2YgdGhlIGFib3ZlIHdp dGhvdXQgYnJlYWtpbmcgb3Igd2Vha2VuaW5nIGFueSBvZiB0aGUgY3J5cHRvZ3JhcGh5IG9yIGNy eXB0b2dyYXBoaWMgcHJvdG9jb2xzIGluIGFueSB3YXksIGluY2x1ZGluZyBub3QgYnJlYWtpbmcg b3IgY2hhbmdpbmcgVExTLjxicj4NCjxicj4NCkl0IGlzIGltcG9ydGFudCB0byBjb25zaWRlciB0 aGUg4oCcZGVsZWdhdGVkIHByb3RlY3Rpb27igJ0gbW9kZWwuJm5ic3A7IEluIHN1Y2ggYSBtb2Rl bCwgdW5hdXRob3JpemVkIGVhdmVzZHJvcHBlcnMgcmVwcmVzZW50IG9uZSBvZiBhdCBsZWFzdCB0 d28gY3J1Y2lhbCB0aHJlYXRzIHdoaWNoIG11c3QgYmUgbWl0aWdhdGVkLiZuYnNwOyBJbiBzdWNo IGEgbW9kZWwsIHRoZSByZW1vdGUgZW5kcG9pbnQgcmVwcmVzZW50cyBhbm90aGVyIGNydWNpYWwg dGhyZWF0IHdoaWNoIG11c3QNCiAmbmJzcDtiZSBtaXRpZ2F0ZWQgYXMgdGhhdCByZW1vdGUgZW5k cG9pbnQgbWlnaHQgYmUgbWFsaWNpb3VzIGV2ZW4gdGhvdWdoIHRoZSBlbmRwb2ludCBvZiBvdXIg Y2FyZSB3YW50cyBvciBuZWVkcyB0byBjb21tdW5pY2F0ZSB3aXRoIHRoYXQgcmVtb3RlIGVuZHBv aW50LiZuYnNwOyBUaGlzIG1vZGVsIGlzIHN1cnByaXNpbmdseSBjb21tb24gdG9kYXkuJm5ic3A7 IEZvciBpbnN0YW5jZSwgc2VydmVyIHRvIGNsaWVudCB3ZWIgYXR0YWNrcyBhcmUgaW5jcmVhc2lu Z2x5IGNvbW1vbg0KICZuYnNwO2J5IG1hbGljaW91cyBvciBjb21wcm9taXNlZCB3ZWJzaXRlcy4m bmJzcDsgT2YgY291cnNlLCBjbGllbnQgdG8gc2VydmVyIGF0dGFja3MgaGF2ZSBiZWVuIGNvbW1v biBmb3IgeWVhcnMuJm5ic3A7IE1vcmUgcmVjZW50bHksIGl04oCZcyBiZWNvbWUgaW5jcmVhc2lu Z2x5IGNvbW1vbiBmb3Igc2VydmVycyB0byBzdXJ2ZWlsIGFuZCBwcm9maWxlIGNsaWVudHMsIGEg cHJpdmFjeSB0aHJlYXQgY29tcG91bmRlZCBieSBzZXJ2ZXJzIGNvbGxhYm9yYXRpbmcgdGhyb3Vn aA0KICZuYnNwO21hc3NpdmUgYWR2ZXJ0aXNpbmcgKGFkKSBuZXR3b3JrcyBmb3IgdHJhY2tpbmcg dXNlciBhY3Rpdml0aWVzLiZuYnNwOyBTdWNoIHN1cnZlaWxsYW5jZSB0aHJvdWdoIHByb2ZpbGlu ZyBhbmQgdHJhY2tpbmcgcmVwcmVzZW50cyBhIHByaXZhY3kgdGhyZWF0IG1hbnkgcGVvcGxlIHdv dWxkIGxpa2UgdG8gc2VlIGJldHRlciBtaXRpZ2F0ZWQuJm5ic3A7IEluIGZhY3QsIGl0IGlzIGFs c28gYSBwcml2YWN5IHRocmVhdCB0aGF0IGNhbiBiZSBwb3RlbnRpYWxseSBtaXRpZ2F0ZWQNCiAm bmJzcDtieSBwcm90ZWN0aW9uIHNlcnZpY2VzIHJ1bm5pbmcgaW4gdGhlIG5ldHdvcmsuJm5ic3A7 IEluIGFsbCBzdWNoIGNhc2VzLCBpdOKAmXMgcmVhc29uYWJsZSBmb3IgbGltaXRlZCBlbmRwb2lu dHMgdG8gY2hvb3NlIG1vcmUgcG93ZXJmdWwgbmV0d29yayBzZXJ2aWNlcyB0byBwcm90ZWN0IHRo ZW0gYWdhaW5zdCBzdWNoIHRocmVhdHMuPGJyPg0KPGJyPg0KRm9ydHVuYXRlbHksIHNldmVyYWwg c3RhcnRpbmcgcGxhY2VzIGV4aXN0IGZvciBwcm90b2NvbHMgdG8gYWNoaWV2ZSByZXF1aXJlbWVu dHMgKGEpLCAoYiksIGFuZCAoYykgYWJvdmUuJm5ic3A7IEZvciBpbnN0YW5jZSwgd2l0aCBzb21l IG1vZGlmaWNhdGlvbnMsIGl0IHdvdWxkIGJlIGdvb2QgdG8gdXNlIHRoZSBTdGlja2xlciBwcm90 b2NvbCBwcm9wb3NlZCBieSBBLjxicj4NCkxldnksIEguIENvcnJpZ2FuLUdpYmJzLCBhbmQgRC4g Qm9uZWggaW4gY29uanVuY3Rpb24gd2l0aCBtb2RpZmllZCB2YXJpYW50cyBvZiB1bmZvcnR1bmF0 ZWx5IG5hbWVkIHByb3RvY29scyBzdWNoIGFzIG1iVExTIGFuZC9vciBUTFMtUkFSLiZuYnNwOyBP dXIgdmlzaW9uIGlzIGZvciBzdWNoIGEgcHJvdG9jb2wgdG8gcnVuIGluIHBhcmFsbGVsIHRvIFRM UywgY29tcGxpbWVudGluZyBpdCwgd2l0aG91dCBtb2RpZnlpbmcgb3IgY29uc3RyYWluaW5nIFRM Uw0KICZuYnNwO3doaWxlIGhlbHBpbmcgY29vcmRpbmF0ZSBuZXR3b3JrIHByb3RlY3Rpb24gb2Yg ZW5kcG9pbnRzLiZuYnNwOyBUbyBkbyBzbywgc3VjaCBhIHByb3RvY29sIHNob3VsZCBhbHNvIGJl dHRlciBpbmZvcm0gZW5kcG9pbnRzIG9mIHRoZSBzcGVjaWZpY3Mgb2YgbmV0d29yayBkZXZpY2Vz IGF2YWlsYWJsZSBmb3IgcHJvdGVjdGlvbiwgc3BlY2lmaWNzIHdoaWNoIHRoZSBlbmRwb2ludCBt aWdodCBjYXJlIGFib3V0IGJlZm9yZSBlbXBvd2VyaW5nIHN1Y2ggbmV0d29yaw0KICZuYnNwO2Rl dmljZXMgYnkgdHJ1c3RpbmcgdGhlbSB0byBoZWxwIHByb3ZpZGUgc3VjaCBwcm90ZWN0aW9uLjxi cj4NCjxicj4NCldpdGggc3VjaCB2YWx1YWJsZSByZXNlYXJjaCBhY2NvbXBsaXNoZWQgdG8gZGF0 ZSBpbiB0aGlzIHNwYWNlIHByb3Bvc2luZyBhIHZhcmlldHkgb2YgcG90ZW50aWFsIHByb3RvY29s cyBhcyBzdGFydGluZyBwb2ludHMsIGl04oCZcyBpbXBvcnRhbnQgdG8gc29vbiBlbmdpbmVlciBh IHN0YW5kYXJkaXplZCBwcm90b2NvbCB0byBtZWV0IHRoZSByb3VnaCBjb25zZW5zdXMgb2YgdGhl IElFVEYgZm9yIHByb3ZpZGluZyBzdWNoIHByb3RlY3Rpb24gbW9yZQ0KICZuYnNwO3NhZmVseSB0 aGFuIHRvZGF54oCZcyBjb21tb24gcHJhY3RpY2VzLiZuYnNwOyBUb2RheeKAmXMgY29tbW9uIHBy YWN0aWNlcyBub3Qgb25seSBmYWlsIHRvIG1lZXQgdGhlIHRocmVlIHJlcXVpcmVtZW50cyBvdXRs aW5lZCBhYm92ZSwgYnV0IHRvZGF54oCZcyBjb21tb24gcHJhY3RpY2VzIGFsc28gKDEpIGFsbG93 IG1pZGRsZWJveGVzIHRvIG5lZ290aWF0ZSB3ZWFrZXIgVExTIHNlc3Npb25zIHdpdGhvdXQgYWR2 aXNpbmcgdGhlIGVuZHBvaW50IG9mIHRoZSByaXNrcw0KICZuYnNwO29mIHRoZSB3ZWFrZXIgc2Vz c2lvbiBvbiB0aGUgZmFyIHNpZGUgb2YgdGhlIG1pZGRsZWJveCwgKDIpIGZhaWwgdG8gaW5mb3Jt IHRoZSBlbmRwb2ludHMgb2YgaG93IHNlY3VyZSB0aGUgbWlkZGxlYm94IG1pZ2h0IG9yIG1pZ2h0 IG5vdCBiZSwgdGhlIG1hbm5lciBpbiB3aGljaCB0aGUgbWlkZGxlYm94IGl0c2VsZiBpcyBzYWZl Z3VhcmRlZCwgYW5kICgzKSBmYWlsIHRvIGluZm9ybSB0aGUgZW5kcG9pbnRzIG9mIHRoZSBpbmZv cm1hdGlvbiByZXRlbnRpb24NCiAmbmJzcDthbmQgZGlzY2xvc3VyZSBwb2xpY2llcyB1bmRlciB3 aGljaCB0aGUgbWlkZGxlYm94IGlzIG9wZXJhdGluZy48YnI+DQo8YnI+DQpDbGVhcmx5IGEgYmV0 dGVyIGFwcHJvYWNoIGlzIG5lZWRlZCwgYW5kIHVyZ2VudGx5LiZuYnNwOyBOZXR3b3JrIG1lZGlh dGlvbiBjYW4gcGxheSBhIGNydWNpYWwgcm9sZSBpbiBwcm90ZWN0aW5nIHBlb3BsZSBmcm9tIHRo ZSBzZXJ2ZXIgdG8gY2xpZW50IGF0dGFja3MgdGhhdCBoYXZlIGJlZW4gdXNlZCB0byB1bm1hc2sg dGhlIGFub255bWl0eSBvZiBkaXNzaWRlbnRzIHNwZWFraW5nIHVwIGFnYWluc3QgcmVwcmVzc2l2 ZSByZWdpbWVzLCBkaXNzaWRlbnRzDQogJm5ic3A7d2hvIHdlcmUgdGhlbiBkaXNhcHBlYXJlZCBh ZnRlciB0aGUgc2VydmVyIHRvIGNsaWVudCBhdHRhY2tzIHdlcmUgdXNlZCB0byB1bm1hc2sgdGhl bSBieSBjb21wcm9taXNpbmcgdGhlaXIgbW9iaWxlIGVuZHBvaW50LiZuYnNwOyBUcnVzdHdvcnRo eSBuZXR3b3JrIG1lZGlhdGlvbiBjYW4gcGxheSBhIGNydWNpYWwgcm9sZSBpbiBwcm90ZWN0aW5n IHBlb3BsZSBhZ2FpbnN0IHN1Y2ggYXR0YWNrcywgYnV0IHRvZGF5LCB3aGVyZSBlbmRwb2ludHMg dHJ1c3QNCiAmbmJzcDttaWRkbGVib3hlcywgdGhlcmUgaXMgbm90IHlldCBhIHN0YW5kYXJkaXpl ZCBwcm90b2NvbCBmb3IgZW5kcG9pbnRzIHRvIHVuZGVyc3RhbmQgd2hlbiB0aG9zZSBtaWRkbGVi b3hlcyBhcmUgd2Vha2VuaW5nIHRoZSBjcnlwdG8sIGNoYW5naW5nIHRoZSBjb250ZW50LCB0cnVz dGluZyBvdGhlciBtaWRkbGVib3hlcywgYW5kIGRvaW5nIG90aGVyIHRoaW5ncyB0aGF0IG1pZ2h0 IGNhdXNlIHRoZSBlbmRwb2ludCB0byBub3QgdHJ1c3QgdGhlIG1pZGRsZWJveC48YnI+DQo8YnI+ DQpTdGlsbCwgZW5naW5lZXJpbmcgc3VjaCBhIHByb3RvY29sIGlzIG5vdCBlYXN5LiZuYnNwOyBT dWNoIHByb3RvY29scyB3b3VsZCBuZWVkIHRvIGFkZHJlc3MgYSByYW5nZSBvZiB1c2UgY2FzZXMg aW5jbHVkaW5nIGJvdGggcmVhbC10aW1lIGFuZCBwb3N0LWZhY3RvLCBhbG9uZyB3aXRoIGJvdGgg d2lkZS1hcmVhIGFuZCBkYXRhY2VudGVyIHVzZSBjYXNlcy4mbmJzcDsgQXMgaW5pdGlhbCB3b3Jr aW5nIGRpZmZlcmVudGlhdGlvbiBvZiB0aGVzZSB0ZXJtcywgd2XigJlkDQogJm5ic3A7cHJvcG9z ZSByZWFsLXRpbWUgdG8gaW5jbHVkZSBibG9ja2luZyBvZiBhdHRhY2tzLiBQb3N0LWZhY3RvIGlu Y2x1ZGVzIGJvdGggZm9yZW5zaWMgaW52ZXN0aWdhdGlvbiBvZiBzb3BoaXN0aWNhdGVkIGF0dGFj a3MgYW5kIGFsc28gYXVkaXQgY29tcGxpYW5jZSBha2Egb3V0LW9mLWJhbmQgZGVjcnlwdGlvbi4g V2lkZS1hcmVhIHVzZSBjYXNlcyBpbmNsdWRlIHNoYXJlZCBuZXR3b3JrcyB3aGVyZSB0aGUgZGV2 aWNlIG9yIGVudGl0eSBoZWxwaW5nDQogJm5ic3A7cHJvdmlkZSBwcm90ZWN0aW9uIGlzIG9ubHkg cmVhY2hlZCBhY3Jvc3MgYSBuZXR3b3JrIG9wZXJhdGVkIGJ5IGFuZC9vciBzaGFyZWQgd2l0aCBv dGhlciB1bnRydXN0ZWQgcGFydGllcy4mbmJzcDsgVGhlIGRhdGFjZW50ZXIgdXNlIGNhc2UgaW5j bHVkZXMgbmV0d29ya3MgYWRqYWNlbnQgdG8gdGhlIGVuZHBvaW50IGFuZCBvd25lZCBieSB0aGUg c2FtZSBwYXJ0eSBhcyBvd25pbmcgdGhlIGVuZHBvaW50Ljxicj4NCjxicj4NCkluIGVuZ2luZWVy aW5nIHN1Y2ggYSBwcm90b2NvbCwgaXTigJlzIGltcG9ydGFudCB0byByZXNwZWN0IGZ1bmRhbWVu dGFsIHByaW5jaXBsZXMgb2YgZW5kLXRvLWVuZCBlbmNyeXB0aW9uIGFuZCwgYXQgdGltZXMsIHNp bWlsYXIgZW5kLXRvLWVuZCBmbGV4aWJpbGl0eSBpbiByb3V0ZSBvcHRpbWl6YXRpb24uJm5ic3A7 IE9uIGVuZC10by1lbmQgZW5jcnlwdGlvbiwgc29tZSBvZiB0aGUgYXBwcm9hY2hlcyB0aGF0IGhh dmUgYmVlbiBwcm9wb3NlZCBpbmNsdWRlDQogJm5ic3A7bGV2ZXJhZ2luZyB0aGUgc3ltbWV0cmlj IGtleSBkZXRlcm1pbmVkIHN0cmljdGx5IGJldHdlZW4gdGhlIHNlcnZlciBhbmQgY2xpZW50LCBh bmQgdGhlbiBoYXZpbmcgdGhlIGVuZHBvaW50IHNoYXJlIHRoYXQgc3ltbWV0cmljIGtleSBvbmx5 IHdpdGggYSBuZXR3b3JrIGRldmljZSBvciBzZXJ2aWNlIHdoaWNoIGl0IHRydXN0cyB0byBoZWxw IHdpdGggcHJvdGVjdGlvbiBhZ2FpbnN0IHRoZSByZW1vdGUgZW5kcG9pbnQuJm5ic3A7IEluIGFk ZGl0aW9uIHRvDQogJm5ic3A7cHJlc2VydmluZyBlbmQtdG8tZW5kIGVuY3J5cHRpb24gYW5kIGFj Y2VsZXJhdGluZyBkZXBsb3ltZW50IG9mIHN0cm9uZ2VyIGNyeXB0bywgaXTigJlzIGFsc28gaW1w b3J0YW50IHRvIHByZXNlcnZlIGVuZC10by1lbmQgZmxleGliaWxpdHkgaW4gcm91dGluZyB3aGVu ZXZlciBwb3NzaWJsZS4mbmJzcDsgQ3VycmVudGx5LCBmb3IgYXR0YWNrcyB0dW5uZWxpbmcgdGhy b3VnaCBlbmNyeXB0ZWQgbmV0d29yayBzZXNzaW9ucywgbmV0d29yayBiYXNlZCBwcm90ZWN0aW9u DQogJm5ic3A7aXMgb2Z0ZW4gcHJvdmlkZWQgdGhyb3VnaCBwcm94aWVzIGFuZCB0aGUgbGlrZSBl aXRoZXIgZW1iZWRkZWQgaW4gbmV0d29yayBnYXRld2F5cyBvciBkYXRhY2VudGVycyBob3N0aW5n IHBlcnNvbmFsLVZQTiB0eXBlIGNsb3VkIGJhc2VkIHNlcnZpY2VzIHRocm91Z2ggd2hpY2ggYWxs IG9mIGEgY2xpZW504oCZcyB0cmFmZmljIGlzIHJvdXRlZC4mbmJzcDsgSG93ZXZlciwgbG9uZ2Vy IHRlcm0sIHN1Y2ggcHJvdGVjdGlvbiBjb3VsZCBiZSBhY2hpZXZlZCBieQ0KICZuYnNwO2hhdmlu ZyBzdWNoIOKAnHByb3RlY3Rpb24gc2VydmljZXPigJ0gcnVubmluZyBtb3JlIGZsZXhpYmx5IGlu IGEgZGlzdHJpYnV0ZWQgbWFubmVyLCBpbiBoYXJkd2FyZSBwcm90ZWN0ZWQgZW5jbGF2ZXMgYW5k L29yIFRydXN0ZWQgRXhlY3V0aW9uIEVudmlyb25tZW50cyBtaWdyYXRpbmcgdGhlIGZ1bmN0aW9u YWxpdHkgYW1vbmcgU29mdHdhcmUgRGVmaW5lZCBOZXR3b3JraW5nIChTRE4pIGFuZC9vciBOZXR3 b3JrIEZ1bmN0aW9uIFZpcnR1YWxpemF0aW9uDQogJm5ic3A7KE5GVikgZW5hYmxlZCBlcXVpcG1l bnQuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZyb20gZGlzY3Vzc2lvbnMgd2l0aGlu IG5vdCBvbmx5IElFVEYgcGFydGljaXBhbnRzLCBidXQgYWxzbyBwZW9wbGUgZW5nYWdlZCBpbiBy ZWxhdGVkIGRpc2N1c3Npb25zIGluIElFRUUsIFVOL0lUVSwgRVRTSSwgYW5kIG90aGVycyBpbiB0 aGlzIGFyZWEgZWFnZXIgdG8gcGFydGljaXBhdGUgaW4gYW4gSUVURiBwcm9jZXNzIGluIHRoaXMg YXJlYSwgd2UgYmVsaWV2ZSB0aGF0IHRoZXJlIGlzIGEgY3JpdGljYWwNCiBtYXNzIG9mIHBhcnRp Y2lwYW50cyAmbmJzcDt3aWxsaW5nIHRvIHdvcmsgb24gdGhlIHByb2JsZW0gKGUuZy4sIHdyaXRl IGRyYWZ0cywgcmV2aWV3IGRyYWZ0cywgZXRjLikgZm9yIG1lZXRpbmcgcmVxdWlyZW1lbnRzIChh KSwgKGIpLCBhbmQgKGMpIGRlc2NyaWJlZCBhYm92ZS4mbmJzcDsgTWFueSBvZiB1cyBwZXJzb25h bGx5IGJlbGlldmUgdGhhdCB0aGUgSUVURiBpcyB0aGUgcmlnaHQgYmVzdCBwbGFjZSBmb3Igc3Vj aCB3b3JrIGZvciBjb3VudGxlc3MgcmVhc29ucy4NCiBXZSBhcmUgb2YgY291cnNlICZuYnNwO3Zl cnkgZmFtaWxpYXIgd2l0aCBwcmV2aW91cyBhdHRlbXB0cyB3aXRoaW4gdGhlIElFVEYsIGluY2x1 ZGluZyBFeHBsaWNpdGx5IFRydXN0ZWQgUHJveHkgYW5kIFRMUyBQcm94eSBzZXJ2ZXIgYW1vbmcg b3RoZXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpXZSBhcmUgYWxzbyBhd2FyZSBvZiB0aGUgbmVlZCBm b3IgY29vcmRpbmF0aW9uIG9mIHN1Y2ggd29yayBub3Qgb25seSB3aXRoIHRoZSBUTFMgd29ya2lu ZyBncm91cCwgYnV0IGFsc28gRFBSSVZFLCBRVUlDLCBJMk5TRiwgYW5kIG90aGVyIElFVEYgZWZm b3J0cywgYW5kIHdlIGJlbGlldmUgdGhhdCBhbiBpbmRlcGVuZGVudCBXRyBjb3VsZCBiZSBtb3Jl IGhlbHBmdWwgdGhhbiB0cnlpbmcgdG8gZG8gYWxsIG9mIHRoaXMgd29yayBpbiBhbnkgZXhpc3Rp bmcNCiAmbmJzcDt3b3JraW5nIGdyb3VwIHN1Y2ggYXMgdGhlIFRMUyBXRywgcGFydGljdWxhcmx5 IHNpbmNlIHRoZSBiZXN0IHNvbHV0aW9uIG1pZ2h0IGJlIGEgbmV3IHByb3RvY29sIHRoYXQgY29t cGxpbWVudHMgVExTLCBydW5uaW5nIGluIGNvbmp1bmN0aW9uIHdpdGggVExTLCB3aXRob3V0IGV4 dGVuZGluZywgY2hhbmdpbmcsIHJlZmluaW5nLCBvciBicmVha2luZyBpdCwgb3IgYW55IG90aGVy IGV4aXN0aW5nIHByb3RvY29scyBhbHJlYWR5IHNvIGltcG9ydGFudA0KICZuYnNwO3RvIHNlY3Vy aXR5IGFuZCBwcm9wZXIgZnVuY3Rpb25pbmcgb2YgdGhlIG5ldHdvcmsuPGJyPg0KPGJyPg0KSW4g dGhhdCB0aGUgd29ybGQgaGFzIGFscmVhZHkgc2VlbiBhbm9ueW1vdXMgZGlzc2lkZW50cyBkaXNh cHBlYXJlZCBhZnRlciB3aGF0IG1hbnkgd291bGQgY29uc2lkZXIgcmVwcmVzc2l2ZSByZWdpbWVz IHVzZWQgc29waGlzdGljYXRlZCBzZXJ2ZXItdG8tY2xpZW50IGF0dGFja3MgdG8gdW5tYXNrIHRo ZWlyIGFub255bWl0eSwgSSBiZWxpZXZlIHRoYXQgd2UgbmVlZCBhIHdvcmxkIHdoZXJlIGJvdGgg KDEpIHRoZSBjb25uZWN0aW9ucyBhcmUgc2VjdXJlDQogJm5ic3A7YSBsYSBncmVhdCBUTFMsIGFu ZCAoMikgdGhlIHRyYWZmaWMgaXMgc2FmZSB0byByZWNlaXZlLCBhcyB2ZXR0ZWQgYnkgc29tZXRo aW5nIG9yIHNvbWVvbmUgdGhlIGVuZHBvaW50IGNob29zZXMgZm9yIHByb3RlY3Rpb24gYWdhaW5z dCByZW1vdGUgZW5kcG9pbnRzLjxicj4NCjxicj4NCkluIHRoYXQgY29udGV4dCwgd2UgYXJlIGRl ZXBseSBncmF0ZWZ1bCB0aGF0IElFVEYgaGFzIGFsbG93ZWQgY3JlYXRpb24gb2YgdGhpcyBtYWls aW5nIGxpc3QgZm9yIGRpc2N1c3Npb24gb2YgdGhlc2UgaW1wb3J0YW50IHRvcGljcy4mbmJzcDsg UGxlYXNlIGxldCBtZSBrbm93IGFueXRoaW5nIHRoYXQgSSBjYW4gZG8gdG8gaGVscCB5b3Ugb3Ig dGhlIElFVEYgb24gdGhpcy48YnI+DQo8YnI+DQpXaXRoIE15IERlZXBlc3QgVGhhbmtzIEZvciBB bGwgVGhhdCBZb3UgRG8gRm9yIFRoZSBJRVRGLCBBbmQgRm9yIFRoZSBXb3JsZCBUaHJvdWdoIFRo ZSBJRVRGLDxicj4NCkJyaWFuPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpQQVRJRU5UIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpQQVRJRU5UQGlldGYub3JnIj5QQVRJRU5UQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5EF76C0024D5422E86F1A955A1656856akamaicom_-- --_004_5EF76C0024D5422E86F1A955A1656856akamaicom_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=127; creation-date="Wed, 08 Nov 2017 15:28:54 GMT"; modification-date="Wed, 08 Nov 2017 15:28:54 GMT" Content-ID: Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNhYWcgbWFp bGluZyBsaXN0DQpzYWFnQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NhYWcNCg== --_004_5EF76C0024D5422E86F1A955A1656856akamaicom_-- From nobody Wed Nov 8 09:06:05 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A14128D86 for ; Wed, 8 Nov 2017 09:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 OMidb7q-uU6H for ; Wed, 8 Nov 2017 09:06:01 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 954BC1288A9 for ; Wed, 8 Nov 2017 09:06:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15963; q=dns/txt; s=iport; t=1510160761; x=1511370361; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=3aDhirL0/Cq5czGCfoS24CisBjB1GsKvGRpazdm347Q=; b=DqT5O5Xeg1cJ0O79BgULXq0gTqMEjWBwBumnBkpgtVUqsQGyL2XEtlux rkHHefEmWb82xJ7bqGOpMhs1chfsGHfsPnFX2xq55ZIA6fdCUEjzzFajo P7ulTcCPbtBB6TaYE5TIT3T8A/5RgHcr+3RgwzkO/7KVtvnPZh02TSdfn k=; X-IronPort-AV: E=Sophos;i="5.44,365,1505779200"; d="scan'208,217";a="321701165" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Nov 2017 17:05:56 +0000 Received: from [10.118.10.19] (rtp-fandreas-2-8812.cisco.com [10.118.10.19]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vA8H5tu4018569; Wed, 8 Nov 2017 17:05:56 GMT To: Stephen Farrell , Florian Weimer , "Nancy Cam-Winget (ncamwing)" Cc: "tls@ietf.org" References: <895D1206-28D1-43AB-8A45-11DEEC86A71D@cisco.com> <874lq868t3.fsf@mid.deneb.enyo.de> <6966da46-0f07-b518-4b6e-f2b5f599b050@cs.tcd.ie> From: Flemming Andreasen Message-ID: <9107b2dc-1f62-8aa8-645a-98aba623ae8a@cisco.com> Date: Wed, 8 Nov 2017 12:06:46 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A4BD86FEFFB482C795EDA588" Content-Language: en-US Archived-At: Subject: Re: [TLS] network-based security solution use cases X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 17:06:04 -0000 This is a multi-part message in MIME format. --------------A4BD86FEFFB482C795EDA588 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/7/17 7:01 PM, Stephen Farrell wrote: > Hiya, > > On 07/11/17 23:27, Flemming Andreasen wrote: >> Thanks for taking an initial look at the document Stephen - please see >> below for responses so far >> >> On 11/7/17 4:13 AM, Stephen Farrell wrote: >>> Hiya, >>> >>> On 07/11/17 02:48, Flemming Andreasen wrote: >>>> We didn't draw any particular line, but the use case scenarios that we >>>> tried to highlight are those related to overall security and regulatory >>>> requirements (including public sector) >>> I had a quick look at the draft (will try read properly en-route to >>> ietf-100) and I followed the reference to [1] but that only lead to a >>> forest of documents in which I didn't find any reference to breaking >>> TLS so far at least. Can you provide an explicit pointer to the >>> exact document on which that claim is based? >> For NERC, you can look under  "(CIP) Critital Infrastructure >> Protection". CIP-005-5 for example covers the electronic security >> perimeter, which has a couple of relevant requirements and associated text: >> >> http://www.nerc.com/_layouts/PrintStandard.aspx?standardnumber=CIP-005-5&title=Cyber%20Security%20-%20Electronic%20Security%20Perimeter(s)&jurisdiction=United%20States >> > Thanks for that. > > So I didn't see any mention of TLS in that document at all. Correct - the document is not a technical protocol specification but rather provides a set of requirements that have to be satisfied. >> To be clear though, the document does not specifically call out breaking >> TLS, but it does clearly call out the need to detect malicious inbound > For inbound (on page 9) I see it mentions IDSes and application > layer firewalls as examples yes. Given that the latter would not > require any messing with TLS at all, this seems to be a very > clear example of a regulation not requiring breaking TLS. That'd > mean there is no regulatory requirement at all wouldn't it? An application layer firewall (aka NGFW these days) does indeed require you to be involved with TLS. How would you perform application-level inspection without ? Example functions include scanning for malware downloads, URL/application filtering, attack signatures (getting a bit more into the IDS space). > But again, if there are real regulatory requirements there that > really do call for MitM attacks on TLS I'd be glad to look at them > if you want to quote them. Again, the document is not a technical protocol specification, but it clearly describes the notion of an electronic security perimeter with a need for electronic access point and provides IDS/IPS as example instantiations of such a function. Let me quote a bit more from said document: /The standard adds a requirement to detect malicious communications for Control Centers. This// //is in response to FERC Order No. 706, Paragraphs 496-503, where ESPs are required to have two// //distinct security measures such that the BES Cyber Systems do not lose all perimeter protection// //if one measure fails or is misconfigured. The Order makes clear that this is not simply// //redundancy of firewalls, thus the SDT has decided to add the security measure of malicious// //traffic inspection as a requirement for these ESPs. Technologies meeting this requirement// //include Intrusion Detection or Intrusion Prevention Systems (IDS/IPS) or other forms of deep// //packet inspection. These technologies go beyond source/destination/port rule sets and thus// //provide another distinct security measure at the ESP./ I don't know how you can reasonably argue that you satisfy the requirement here if you don't inspect encrypted traffic. >> and outbound communications by leveraging an "Electronic Access Point" >> (e.g. IDS/IPS) to enforce the Electronic Security Perimeter. > Personally, I have to say I find the outbound stuff nonsense. > I know people make money selling product and services for that. It's not nonsense - it's deployed for a reason and it actually blocks a lot of attacks, in no small part by disabling command and control traffic. WannaCry and HeartBleed are just two of the more prominent examples of this, and there are many more where they came from (some encrypted, some not). You may want to take a look at http://blog.talosintelligence.com/2017/05/wannacry.html and http://blog.talosintelligence.com/2014/04/heartbleed-memory-disclosure-upgrade.html for starters. Feel free to browse around for many more. >>> I'd also claim that your reference to PCI-DSS is misleading, as that >>> same spec also explicitly calls for there to be good key management >>> specifically including minimising the number of copies of keys, so >>> at most, one might be able to claim that PCI-DSS is ok with people >>> who break TLS in a nod-and-a-wink manner. But if you do have a real >>> quote from PCI-DSS that calls for breaking TLS then please do also >>> send that (it's been asked for a bunch of times without any answer >>> being provided so far). >> I will need to look more closely for such a quote - if anybody else >> knows of one, please chime in as well. > It's been asked for a number of times without any substantive > response. I would assume that one of the authors of this would > be able to point at the text that caused you to add in a mention > of PCI-DSS. If not, that seems odd. > > I actually looked through the PCI spec myself and found that it > is fairly explicitly asking for good crypto and not bad crypto. > (E.g. as mentioned, saying to minimise the number of copies of > keys that are anywhere.) Let's take the PCI-DSS part on the parallel part of this thread. > > Maybe the ADs ought liaise to some of those organisations and > ask them if they do or do not recognise the claims related to > breaking TLS being attributed to them? I think that's a really good suggestion. Thanks -- Flemming > Or even better, maybe just not making those claims would be > easier all around and more accurate. > > S. > >> Thanks >> >> -- Flemming >> >> >>> Thanks, >>> S. >>> >>> >>> [1] >>> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00.html#ref-NERCCIP >>> >>> >> --------------A4BD86FEFFB482C795EDA588 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 11/7/17 7:01 PM, Stephen Farrell wrote:
Hiya,

On 07/11/17 23:27, Flemming Andreasen wrote:

Thanks for taking an initial look at the document Stephen - please see
below for responses so far

On 11/7/17 4:13 AM, Stephen Farrell wrote:

Hiya,

On 07/11/17 02:48, Flemming Andreasen wrote:

We didn't draw any particular line, but the use case scenarios that we
tried to highlight are those related to overall security and regulatory
requirements (including public sector)

I had a quick look at the draft (will try read properly en-route to
ietf-100) and I followed the reference to [1] but that only lead to a
forest of documents in which I didn't find any reference to breaking
TLS so far at least. Can you provide an explicit pointer to the
exact document on which that claim is based?

For NERC, you can look under  "(CIP) Critital Infrastructure
Protection". CIP-005-5 for example covers the electronic security
perimeter, which has a couple of relevant requirements and associated text:

http://www.nerc.com/_layouts/PrintStandard.aspx?standardnumber=CIP-005-5&title=Cyber%20Security%20-%20Electronic%20Security%20Perimeter(s)&jurisdiction=United%20States


Thanks for that.

So I didn't see any mention of TLS in that document at all.
Correct - the document is not a technical protocol specification but rather provides a set of requirements that have to be satisfied. 

      

        
To be clear though, the document does not specifically call out breaking
TLS, but it does clearly call out the need to detect malicious inbound


      

      
For inbound (on page 9) I see it mentions IDSes and application
layer firewalls as examples yes. Given that the latter would not
require any messing with TLS at all, this seems to be a very
clear example of a regulation not requiring breaking TLS. That'd
mean there is no regulatory requirement at all wouldn't it?


    

    An application layer firewall (aka NGFW these days) does indeed
    require you to be involved with TLS. How would you perform
    application-level inspection without ? Example functions include
    scanning for malware downloads, URL/application filtering, attack
    signatures (getting a bit more into the IDS space). 

    

    

    

      
But again, if there are real regulatory requirements there that
really do call for MitM attacks on TLS I'd be glad to look at them
if you want to quote them.


    

    

    Again, the document is not a technical protocol specification, but
    it clearly describes the notion of an electronic security perimeter
    with a need for electronic access point and provides IDS/IPS as
    example instantiations of such a function. Let me quote a bit more
    from said document:

    <quote>

    The standard adds a requirement to detect malicious
      communications for Control Centers. This

    is in response to FERC Order No. 706, Paragraphs 496-503,
      where ESPs are required to have two

    distinct security measures such that the BES Cyber Systems do
      not lose all perimeter protection

    if one measure fails or is misconfigured. The Order makes
      clear that this is not simply

    redundancy of firewalls, thus the SDT has decided to add the
      security measure of malicious

    traffic inspection as a requirement for these ESPs.
      Technologies meeting this requirement

    include Intrusion Detection or Intrusion Prevention Systems
      (IDS/IPS) or other forms of deep

    packet inspection. These technologies go beyond
      source/destination/port rule sets and thus

    provide another distinct security measure at the ESP.

    </quote>

    

    I don't know how you can reasonably argue that you satisfy the
    requirement here if you don't inspect encrypted traffic. 

    

    

      

      

        
and outbound communications by leveraging an "Electronic Access Point"
(e.g. IDS/IPS) to enforce the Electronic Security Perimeter.


      

      
Personally, I have to say I find the outbound stuff nonsense.
I know people make money selling product and services for that.


    

    It's not nonsense - it's deployed for a reason and it actually
    blocks a lot of attacks, in no small part by disabling command and
    control traffic. WannaCry and HeartBleed are just two of the more
    prominent examples of this, and there are many more where they came
    from (some encrypted, some not). You may want to take a look at
    http://blog.talosintelligence.com/2017/05/wannacry.html and
http://blog.talosintelligence.com/2014/04/heartbleed-memory-disclosure-upgrade.html
    for starters. Feel free to browse around for many more. 

    

    

      

      

        

          
I'd also claim that your reference to PCI-DSS is misleading, as that
same spec also explicitly calls for there to be good key management
specifically including minimising the number of copies of keys, so
at most, one might be able to claim that PCI-DSS is ok with people
who break TLS in a nod-and-a-wink manner. But if you do have a real
quote from PCI-DSS that calls for breaking TLS then please do also
send that (it's been asked for a bunch of times without any answer
being provided so far).


        

        
I will need to look more closely for such a quote - if anybody else
knows of one, please chime in as well.


      

      
It's been asked for a number of times without any substantive
response. I would assume that one of the authors of this would
be able to point at the text that caused you to add in a mention
of PCI-DSS. If not, that seems odd.

I actually looked through the PCI spec myself and found that it
is fairly explicitly asking for good crypto and not bad crypto.
(E.g. as mentioned, saying to minimise the number of copies of
keys that are anywhere.)

    

    Let's take the PCI-DSS part on the parallel part of this thread. 

    

    

      

Maybe the ADs ought liaise to some of those organisations and
ask them if they do or do not recognise the claims related to
breaking TLS being attributed to them?


    

    I think that's a really good suggestion. 

    

    Thanks 

    

    -- Flemming 

    

    

      
Or even better, maybe just not making those claims would be
easier all around and more accurate.

S.



      

        
Thanks

-- Flemming




        

          
Thanks,
S.


[1]
https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00.html#ref-NERCCIP




        

        



      

      

    

    

  


--------------A4BD86FEFFB482C795EDA588--


From nobody Wed Nov  8 09:55:53 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EEF1294C9 for ; Wed,  8 Nov 2017 09:55:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.9
X-Spam-Level: 
X-Spam-Status: No, score=-4.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 J8Wvg-6KuO0p for ; Wed,  8 Nov 2017 09:55:49 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 5E80F128CD5 for ; Wed,  8 Nov 2017 09:55:49 -0800 (PST)
Received: from [192.168.91.204] ([83.175.70.56]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M3RVA-1f3MHH43ii-00qyvA; Wed, 08 Nov 2017 18:55:44 +0100
To: Peter Saint-Andre , tls@ietf.org
References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com>    
From: Hannes Tschofenig 
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <687a48d4-77a2-595b-480b-776293c2fd0d@gmx.net>
Date: Wed, 8 Nov 2017 18:55:43 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:ZF9saeeg/hjSPSvaat+IW0pHgGN4Q8srArRguavVxienQVlL23k 1tCk4a5GKy/n8w4lJKygZGnpKlf7VH/W6033K2+s9uBjbB5OREMMshpb2A/6bdDgxKuAV/f NMFq/aQaXSCXzoUrkQAkEv3x8JBIUrdQZPIVTZZ/1GXH6+CPa2Gx3fhrdsXlvwNUNcPna5T tQvyvZlNEde+bexKyaqHQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:qUwiHVET2Fk=:xNs2uECtEJMODp9KC05D0l ae7lD/1YS3LU+tF8vujthD40981xEvqKN8CqpWZkGK0tIQRzD5urjSi5dgJqIf9CdNsOq1hSf uEzxcJ3fdMHWPK6+4jZwR5TPVqDpc5cKSaXkgwfcQcA//6IVn1cSGpvI3md8x0YE18SpNizfK RFLqx8h7Ho92p802SUluhMc/Yg+LLNarRXDJ/HU6Oc2UE+U3d7U1d8kl0Kn+CpQb8C7rscTd2 jzUMS8IiXo+L9XvP+9BQ+gvDDAx8C6bf2s2dvDU1zliTyu7N9ehVIIT2FTFe0mVv1qppdAHVN VwUT8UBAfOnP4oiPhpG2UZ6lHIK42hKD2Asdezp2jgUqL6qcFkpG/3iOW+qepcsqFc21w4/c8 wckRW428Ooe0GGTYRI+mMz6daRW+Za+hZSMaiierd5m2iB5iEx0uJ2yoK4v0eDOWIlNDYUxpX gTv/HOTVpyLFBMBUjKryJUb9VwXgGEh/XsrYQdA9oP4uzinYXJ1mNtUEXLFkc0CpfPt0YUOHd QCAfJtbeXpkFwVavqTZ+gMJSJ/BeqRLczmp73M6HO6z59HeXo/xOAqwxDpNcoiy7bprRJU37z D6IiLWVRrHCwxZwOh2bIttRRJZ3+Z3p75SKoo8a7GXiXMAKFaAmBz/9wSHQZbq/wMEV/HViB4 EA5/fSwOy7TO7DvW6fsTq6ypvyVZOIKlQa47qwWkAUe6hHGwrD6PpseE9PQiRamAg58O/JZQb MTwAEzVAhheCvMQNFpFBFFnzGYwx7LQGz019EWD7t2wzJ2eaCaUokbcPVcxkPSLxQZD3eJ4+I khHKqTwF15lE9rtYaeij8sut4CiPuV1VL2/RV/Chr77YQ7bvZc=
Archived-At: 
Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Nov 2017 17:55:51 -0000

Hi Peter,

too bad that you are not attending the upcoming IETF meeting in person.
I am sure that others would like to hear your thoughts about an
end-to-end security solution that is even better than the TLS 1.3
protocol. At least I am interested.

Maybe you can share something on the list.

Ciao
Hannes

On 11/07/2017 05:21 PM, Peter Saint-Andre wrote:
> On 11/7/17 8:15 AM, Hannes Tschofenig wrote:
>> FWIW: I can tell you what the threat model was with the layered TLS work.
>>
>> Let me give you a very specific example. Imagine a Bluetooth Low Energy
>> device that communicates via a phone to a cloud-based service. The
>> communication from the phone to the cloud uses HTTPS. The communication
>> from the BLE device to the phone uses ordinary BLE
>> services/characteristics.
>>
>> The Layered TLS/application layer TLS would in this case run from the
>> BLE device all the way to the cloud-based service at the application layer.
>>
>> This allows us to provide end-to-end security across a proxy (in this
>> case the phone) and independent of the underlying protocols.
>>
>> Does this make sense?
> 
> Given your assumptions, yes. Although IMHO there's got to be a better
> way to accomplish the goal of end-to-end security here. If I were going
> to IETF 100, I'd propose getting together for a beer to discuss...
> 
> Peter
> 
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 


From nobody Fri Nov 10 11:39:34 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F3512940D for ; Fri, 10 Nov 2017 11:39:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 6FE2xzz3vHL0 for ; Fri, 10 Nov 2017 11:39:27 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61EF212940B for ; Fri, 10 Nov 2017 11:39:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11294; q=dns/txt; s=iport; t=1510342767; x=1511552367; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zKhLuFi1nDH1etr5po+ivs6NByazloFvuX/8vM3vGqw=; b=NYY1Gu0PqWEfwaP/Y3iOKjq/QgqJTAPiBVkTZTqoAOm2sflxiePtLDSo 6t0hBnKyq9Hn+7+TkLeyEpiKRQFZQxfcueybzJOS9XDq9lpUWqA+/LB+N yws0PMPj8RbJH0MKAZfA9w21WKf1bDIdEbIw+yXFaThw893V4ICxP7tph k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQAe/wVa/5JdJa1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDBy5kbicHg3eZSoFWJpZQghEKHoUdAhqELEEWAQEBAQEBAQE?= =?us-ascii?q?BayiFHgEBAQEBAQEdBhExFBACAQgSBgICJgICAjAVAg4CBAENBRuJfwgQqTCCJ?= =?us-ascii?q?4sQAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYEPgiWCB4M9KQuCdoNEgR8KQYJ+MYI?= =?us-ascii?q?yBaIhAodng2iJL4IVhgeEBIcgjGiJDQIRGQGBOAEmAy6BcnoVH1cBgjYJgk4FH?= =?us-ascii?q?IFndwGLLYERAQEB?=
X-IronPort-AV: E=Sophos;i="5.44,375,1505779200"; d="scan'208";a="29171713"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Nov 2017 19:39:25 +0000
Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id vAAJdOdg012515 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 10 Nov 2017 19:39:25 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 10 Nov 2017 14:39:24 -0500
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Fri, 10 Nov 2017 14:39:24 -0500
From: "Nancy Cam-Winget (ncamwing)" 
To: Stephen Farrell , "Flemming Andreasen (fandreas)" , Florian Weimer 
CC: "tls@ietf.org" 
Thread-Topic: [TLS] network-based security solution use cases
Thread-Index: AQHTVQ82KKjKBkAk5kyjDwLCBqb5H6MF7FPMgAKjMwCAAGt7gIAA7sYA//+BIwCAAIpNAP//fdaAgACLCYCAA9yqgA==
Date: Fri, 10 Nov 2017 19:39:23 +0000
Message-ID: 
References: <895D1206-28D1-43AB-8A45-11DEEC86A71D@cisco.com> <874lq868t3.fsf@mid.deneb.enyo.de>  <6966da46-0f07-b518-4b6e-f2b5f599b050@cs.tcd.ie>  <8448A3AF-CEAF-41F4-A43F-9ED7B209C7B9@cisco.com> <84562f24-7a4f-4a9f-264c-1edf1e41bebe@cs.tcd.ie>  <3db42c7c-2904-f11f-ab8e-116835669816@cs.tcd.ie>
In-Reply-To: <3db42c7c-2904-f11f-ab8e-116835669816@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.1a.0.160910
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.103.178]
Content-Type: text/plain; charset="utf-8"
Content-ID: <050897EA31EB7C45882B9CE09A85E56E@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] network-based security solution use cases
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Nov 2017 19:39:32 -0000

DQpIaSBhbGwsDQoNCkkgdGhpbmsgRmxlbW1pbmcgaGFzIGV4cHJlc3NlZCBvdXIgcG9pbnRzIHdl
bGwuICBCdXQgSSB0aGluayB3ZSBhcmUgbG9zaW5nIHNpZ2h0IG9mIHRoZSBwdXJwb3NlIG9mIHRo
ZSBkcmFmdDogdGhpcyBpcyB3aGF0IGluZHVzdHJ5IGlzIGRvaW5nIHRvZGF5IGluIHJlc3BvbnNl
IHRvIHJlcXVpcmVtZW50czsgd2hldGhlciBpbXBvc2VkIGJ5IGN1c3RvbWVycyBvciByZWd1bGF0
aW9ucy4gIEkgd291bGQgbm90IGV4cGVjdCB0aGVzZSB0byBleHBsaWNpdGx5IHN0YXRlIGhvdyBh
IHNvbHV0aW9uLCBhcmNoaXRlY3R1cmUgYW5kIHByb3RvY29sIGlzIHRvIGJlIGltcGxlbWVudGVk
LCB0aGV5IGRvIGltcG9zZSByZXF1aXJlbWVudHMgdG8gYW4gZXhwZWN0ZWQgb3V0Y29tZS4gIEFz
IHN1Y2gsIHNvbHV0aW9ucyBoYXZlIGVtYnJhY2VkIHRoZSB1c2Ugb2YgVExTIHBlcnZhc2l2ZWx5
IGFuZCBiYWxhbmNlZCB0aGUgcmVxdWlyZW1lbnRzIG9mIGN1c3RvbWVycy9yZWd1bGF0aW9ucyB0
byBwcm92aWRlIGZpcmV3YWxsLCBpbnNwZWN0aW9uIGZvciBtb25pdG9yaW5nIGFuZCB0cm91Ymxl
c2hvb3RpbmcgYnkgdGhlIHVzZSBjYXNlcyBhcyBkb2N1bWVudGVkIGluIHRoZSBkcmFmdC4NCg0K
V2UgYXJlIE5PVCBhZ2FpbnN0IHRoZSB1c2Ugb2YgUEZTIGFuZCBpbXByb3ZlZCBzZWN1cml0eTsg
d2UgY29udGludWUgdG8gbG9vayBmb3J3YXJkIHRvIGV2b2x2aW5nIHNvbHV0aW9ucyB0aGF0IHVz
ZSBUTFMgKDEuMynigKZidXQgaW4gc29tZSBjYXNlcyB0aGVyZSBhcmUgaW1wbGljYXRpb25zIHRo
YXQgd2UgdGhvdWdodCBtZXJpdGVkIGF3YXJlbmVzcyBhbmQgZnVydGhlciBkaXNjdXNzaW9uLg0K
DQpXYXJtIHJlZ2FyZHMsIE5hbmN5DQoNCg0KT24gMTEvNy8xNywgNDo0MCBQTSwgIlN0ZXBoZW4g
RmFycmVsbCIgPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+IHdyb3RlOg0KDQogICAgDQogICAg
SGl5YSwNCiAgICANCiAgICBPbiAwOC8xMS8xNyAwMDoyMywgTmFuY3kgQ2FtLVdpbmdldCAobmNh
bXdpbmcpIHdyb3RlOg0KICAgID4gSGkgU3RlcGhlbiwNCiAgICA+IFBsZWFzZSBzZWUgYmVsb3c6
DQogICAgPiANCiAgICA+IE9uIDExLzcvMTcsIDQ6MDggUE0sICJTdGVwaGVuIEZhcnJlbGwiIDxz
dGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPiB3cm90ZToNCiAgICA+IA0KICAgID4gICAgIA0KICAg
ID4gICAgIEhpeWEsDQogICAgPiAgICAgDQogICAgPiAgICAgT24gMDcvMTEvMTcgMjM6NTMsIE5h
bmN5IENhbS1XaW5nZXQgKG5jYW13aW5nKSB3cm90ZToNCiAgICA+ICAgICA+IEhpIFN0ZXBoZW4s
IEFkZGluZyB0byBGbGVtbWluZ+KAmXMgY29tbWVudCwgIGZpbmRpbmcg4oCcZXhhY3QgcXVvdGVz
4oCdDQogICAgPiAgICAgPiB3aWxsIGJlIGRpZmZpY3VsdCANCiAgICA+ICAgICANCiAgICA+ICAg
ICBJJ20gc29ycnkgYnV0IHdoZW4gbWFraW5nIGEgY2xhaW0gdGhhdCBzdWNoIGFuZCBzdWNoIGEg
cmVndWxhdGlvbg0KICAgID4gICAgICpyZXF1aXJlcyogYnJlYWtpbmcgVExTIHRoZW4geW91IHJl
YWxseSBkbyBuZWVkIHRvIGJlIHRoYXQgcHJlY2lzZS4NCiAgICA+IFtOQ1ddIEluIFRMUyAxLjIs
IG5vdCBzdXJlIHdoeSB5b3Ugc3RhdGUgKnJlcXVpcmVzKiBhcyB0aGVyZSBpcyB0aGUgdmlzaWJp
bGl0eSBhZmZvcmRlZCB0byANCiAgICA+IGF0IGxlYXN0IGFsbG93IGZvciB0aGUgaWRlbnRpdHkg
ZGlzY2xvc3VyZSB0byBlbmFibGUgd2hpdGUgb3IgYmxhY2tsaXN0IGZvciBleGFtcGxlLiAgDQog
ICAgDQogICAgUXVvdGluZyBmcm9tIHlvdXIgZHJhZnQgd3J0IFBDSS1EU1M6DQogICAgDQogICAg
IiBSZXF1aXJlbWVudCAjMiAoYW5kIEFwcGVuZGl4IEEyIGFzIGl0IGNvbmNlcm5zIFRMUykNCiAg
ICAgICBkZXNjcmliZXMgdGhlIG5lZWQgdG8gYmUgYWJsZSB0byBkZXRlY3QgcHJvdG9jb2wgYW5k
IHByb3RvY29sIHVzYWdlDQogICAgICAgY29ycmVjdG5lc3MuIg0KICAgIA0KICAgIFRoYXQgb25l
IGlzIG5pY2UgLSB5b3Ugc2VlbSB0byBiZSBhcmd1aW5nIGZvciBwcm90b2NvbCBub24tY29uZm9y
bWFuY2UNCiAgICAob3IgZm9yIHdlYWtlbmluZyBjb25mb3JtYW50IGltcGxlbWVudGF0aW9ucykg
aW4gb3JkZXIgdG8gaGVscCBlbnN1cmUNCiAgICAicHJvdG9jb2wgdXNhZ2UgY29ycmVjdG5lc3Mu
IiBUaGF0IGtpbmQgb2YgbWFrZXMgbXkgaGVhZCBzcGluLg0KICAgIA0KICAgIEFub3RoZXIgcXVv
dGUgd3J0IE5FUkM6DQogICAgDQogICAgIiBJbiBmYWN0LCByZWd1bGF0b3J5IHN0YW5kYXJkcyBz
dWNoIGFzIE5FUkMgQ0lQDQogICAgICAgW05FUkNDSVBdIHBsYWNlIHN0cm9uZyByZXF1aXJlbWVu
dHMgYWJvdXQgbmV0d29yayBwZXJpbWV0ZXIgc2VjdXJpdHkNCiAgICAgICBhbmQgaXRzIGFiaWxp
dHkgdG8gaGF2ZSB2aXNpYmlsaXR5IHRvIHByb3ZpZGUgc2VjdXJpdHkgaW5mb3JtYXRpb24gdG8N
CiAgICAgICB0aGUgc2VjdXJpdHkgbWFuYWdlbWVudCBhbmQgY29udHJvbCBzeXN0ZW1zLiAiDQog
ICAgDQogICAgV2hlcmUgZXhhY3RseSBkaWQgeW91IHNlZSB0aG9zZSAic3Ryb25nIHJlcXVpcmVt
ZW50cyIgdGhhdCBwcmVzdW1hYmx5DQogICAgKnJlcXVpcmUqIGJyZWFraW5nIFRMUz8NCiAgICAN
CiAgICBJIGRvbid0IHNlZSB0aGVtLg0KICAgIA0KICAgIFdoZW4gSSBvciBvdGhlcnMgYXNrIHRv
IGJlIHNob3duIHRoZW0gd2UgZG9uJ3QgZ2V0IHNob3duIHRoZW0uDQogICAgDQogICAgVG8gbWUg
dGhhdCBtZWFucyB0aG9zZSBhcmUgbm90ICpyZXF1aXJlZCouDQogICAgDQogICAgPiANCiAgICA+
ICAgICA+IGFzIHRoZWlyIGludGVudCBpcyByZWFsbHkgbm90IHRvIGJyZWFrIHRoaW5ncyBidXQN
CiAgICA+ICAgICA+IHJhdGhlciB3YW50IHRvIGVuc3VyZSB0aGF0IGluc3BlY3Rpb24gYW5kIG92
ZXJzaWdodCBpcyBhdmFpbGFibGUgdG8NCiAgICA+ICAgICA+IGFmZmVjdCBndWFyZHMvcHJvdGVj
dGlvbnMgd2l0aGluIGFuIChlbnRlcnByaXNlL2RhdGEgY2VudGVyKQ0KICAgID4gICAgID4gaW5m
cmFzdHJ1Y3R1cmUuICAgVGhhdCBzYWlkLCBQQ0kgYW5kIG90aGVyIHJlZ3VsYXRpb25zIHdpbGwg
aGF2ZSBhDQogICAgPiAgICAgPiBsb3Qgb2YgZG9jdW1lbnRzIHRoYXQgb25lIGhhcyB0byBnbyB0
aHJvdWdo4oCmLm9uZSB0aGF0IGtpbmQtb2YgY2FsbHMNCiAgICA+ICAgICA+IGV4cGxpY2l0bHkg
dG8gdGhlIHVzZSBvZiBwYWNrZXQgaW5zcGVjdGlvbiwgZmlyZXdhbGxpbmcgYW5kIHN1Y2ggaXMN
CiAgICA+ICAgICA+IGluOg0KICAgID4gICAgID4gDQogICAgPiAgICAgPiBodHRwczovL3d3dy5w
Y2lzZWN1cml0eXN0YW5kYXJkcy5vcmcvZG9jdW1lbnRzL1NBUV9EX3YzX01lcmNoYW50LnBkZg0K
ICAgID4gICAgIA0KICAgID4gICAgIFRoZSBmaXJzdCBtZW50aW9uIG9mIFRMUyB0aGVyZSB0YWxr
cyBhYm91dCBwcm90ZWN0aW5nIGFkbWluaXN0cmF0b3INCiAgICA+ICAgICBwYXNzd29yZHMgdmlh
IFRMUy4gVGhhdCB0b3RhbGx5IGFyZ3VlcyBhZ2FpbnN0IGRlcGxveW1lbnQgb2YgYW55IGtpbmQN
CiAgICA+ICAgICBvZiBNaXRNIGluZnJhc3RydWN0dXJlLg0KICAgID4gW05DV10gQWdyZWVkLCB0
aGV5IGFsc28gc3RhdGUgaW4gZW5zdXJpbmcgdGhhdCB0aGUgbmV3ZXN0IFRMUyB2ZXJzaW9uIHdo
ZXJlIA0KICAgID4gcG9zc2libGUgaXMgdXNlZC4gIEJVVCwgdGhleSBhbHNvIGV4cGVjdCBtb25p
dG9yaW5nIGFuZCB0cm91Ymxlc2hvb3RpbmcuDQogICAgDQogICAgU3VyZS4gTm90IGFsbCBtb25p
dG9yaW5nICpyZXF1aXJlcyogYnJlYWtpbmcgVExTLiBTYW1lIGZvcg0KICAgIHRyb3VibGVzaG9v
dGluZy4NCiAgICANCiAgICBPZiBjb3Vyc2UgcGVvcGxlIHdobyBzZWxsIGtpdCBmb3IgdGhhdCBv
ciBoYXZlIGJlZW4gZG9pbmcNCiAgICB0aGF0IGZvciBhIHdoaWxlIG1pZ2h0IHdhbnQgdG8gc2Vl
IHdoYXQgdGhleSBkbyBhcyBiZWluZw0KICAgIG1hbmRhdG9yeS9yZXF1aXJlZC9yZWd1bGF0ZWQt
Zm9yIGJ1dCBJJ20gbm90IHNlZWluZyBpdC4NCiAgICANCiAgICA+ICAgICANCiAgICA+ICAgICA+
IA0KICAgID4gICAgID4gSXQgaXMgYW4gYXNzZXNzbWVudCBxdWVzdGlvbm5haXJlIGZvciB2ZW5k
b3JzIHRvIGV2YWx1YXRlIHRoZWlyDQogICAgPiAgICAgPiBjb21wbGlhbmNlLCB0aGUgcmVxdWly
ZW1lbnRzIHNwZWFrIHRvIHNlY3VyaW5nIHRoZSBuZXR3b3JrIGFuZA0KICAgID4gICAgID4gc3lz
dGVtcyBpbmNsdWRpbmcgZmlyZXdhbGxzLCBETVpzIGFuZCB0aGUgYWJpbGl0eSB0byBkbyBwYWNr
ZXQNCiAgICA+ICAgICA+IGluc3BlY3Rpb24uDQogICAgPiAgICAgDQogICAgPiAgICAgUGxlYXNl
IHBvaW50IG1lIGF0IHRoZSBzcGVjaWZpYyB0ZXh0LiBHaXZlbiB5b3UgYWRkZWQgUENJLURTUyB0
bw0KICAgID4gICAgIHlvdXIgZG9jdW1lbnQgSSB3b3VsZCBhc3N1bWUgeW91IGRpZCB0aGUgd29y
ayBhbHJlYWR5LiBJZiBub3QsDQogICAgPiAgICAgdGhhdCdzIGEgYml0IG9kZC4NCiAgICA+IFtO
Q1ddIEZyb20gdGhlIGxpbmsgYWJvdmUsIHlvdSBjYW4gbG9vayBhdCByZXF1aXJlbWVudHMgaW4g
MS4zLA0KICAgID4gYWxzbyBSZXF1aXJlbWVudCAxMCBkZXRhaWxzIHRoZSBuZWVkIHRvIG1vbml0
b3IgYW5kIHByb3ZpZGUgYXVkaXQgdHJhaWxzDQogICAgPiBmb3IgbmV0d29yayByZXNvdXJjZXMg
YW5kIGNhcmRob2xkZXIgZGF0YQ0KICAgIA0KICAgIFlvdSBtZWFuIDEuMyBvbiBwYWdlIDYgSSBn
dWVzcy4gSSBzZWUgbm90aGluZyBvbiBwYWdlcyA2IG9yIDcNCiAgICB0aGF0IGNhbGwgZm9yIE1p
dE1pbmcgVExTLiBUaGF0IHNlZW1zIHRvIGJlIGFib3V0IGFkZHJlc3NpbmcNCiAgICBhbmQgRE1a
cyBhbmQgZmlyZXdhbGwgYW5kIHJvdXRlciBjb25maWdzLg0KICAgIA0KICAgIFJlcXVpcmVtZW50
IDEwIHNlZW1zIHRvIGJlIGRlYWxpbmcgd2l0aCBhdWRpdCBvZiBhY2Nlc3NlcyB0bw0KICAgIGNh
cmRob2xkZXIgZGF0YSwgbm90IHdpdGggVExTIGF0IGFsbC4gSSByZWFkIHBhZ2VzIDUwLTU1IGZv
cg0KICAgIHRoYXQuDQogICAgDQogICAgSG9uZXN0bHksIHdoYXQgeW91J3JlIHNheWluZyBpcyB0
aGVyZSBkb2VzIG5vdCBzZWVtIHRvIGJlDQogICAgdGhlcmUuDQogICAgDQogICAgUy4NCiAgICAN
CiAgICANCiAgICA+ICAgICANCiAgICA+ICAgICBTLg0KICAgID4gICAgIA0KICAgID4gICAgIA0K
ICAgID4gICAgID4gDQogICAgPiAgICAgPiBUaGFua3MsIE5hbmN5DQogICAgPiAgICAgPiANCiAg
ICA+ICAgICA+IE9uIDExLzcvMTcsIDM6MjcgUE0sICJGbGVtbWluZyBBbmRyZWFzZW4gKGZhbmRy
ZWFzKSINCiAgICA+ICAgICA+IDxmYW5kcmVhc0BjaXNjby5jb20+IHdyb3RlOg0KICAgID4gICAg
ID4gDQogICAgPiAgICAgPiBUaGFua3MgZm9yIHRha2luZyBhbiBpbml0aWFsIGxvb2sgYXQgdGhl
IGRvY3VtZW50IFN0ZXBoZW4gLSBwbGVhc2UNCiAgICA+ICAgICA+IHNlZSBiZWxvdyBmb3IgcmVz
cG9uc2VzIHNvIGZhcg0KICAgID4gICAgID4gDQogICAgPiAgICAgPiBPbiAxMS83LzE3IDQ6MTMg
QU0sIFN0ZXBoZW4gRmFycmVsbCB3cm90ZToNCiAgICA+ICAgICA+PiBIaXlhLA0KICAgID4gICAg
ID4+IA0KICAgID4gICAgID4+IE9uIDA3LzExLzE3IDAyOjQ4LCBGbGVtbWluZyBBbmRyZWFzZW4g
d3JvdGU6DQogICAgPiAgICAgPj4+IFdlIGRpZG4ndCBkcmF3IGFueSBwYXJ0aWN1bGFyIGxpbmUs
IGJ1dCB0aGUgdXNlIGNhc2Ugc2NlbmFyaW9zDQogICAgPiAgICAgPj4+IHRoYXQgd2UgdHJpZWQg
dG8gaGlnaGxpZ2h0IGFyZSB0aG9zZSByZWxhdGVkIHRvIG92ZXJhbGwgc2VjdXJpdHkNCiAgICA+
ICAgICA+Pj4gYW5kIHJlZ3VsYXRvcnkgcmVxdWlyZW1lbnRzIChpbmNsdWRpbmcgcHVibGljIHNl
Y3RvcikNCiAgICA+ICAgICA+PiBJIGhhZCBhIHF1aWNrIGxvb2sgYXQgdGhlIGRyYWZ0ICh3aWxs
IHRyeSByZWFkIHByb3Blcmx5IGVuLXJvdXRlDQogICAgPiAgICAgPj4gdG8gaWV0Zi0xMDApIGFu
ZCBJIGZvbGxvd2VkIHRoZSByZWZlcmVuY2UgdG8gWzFdIGJ1dCB0aGF0IG9ubHkgbGVhZA0KICAg
ID4gICAgID4+IHRvIGEgZm9yZXN0IG9mIGRvY3VtZW50cyBpbiB3aGljaCBJIGRpZG4ndCBmaW5k
IGFueSByZWZlcmVuY2UgdG8NCiAgICA+ICAgICA+PiBicmVha2luZyBUTFMgc28gZmFyIGF0IGxl
YXN0LiBDYW4geW91IHByb3ZpZGUgYW4gZXhwbGljaXQgcG9pbnRlcg0KICAgID4gICAgID4+IHRv
IHRoZSBleGFjdCBkb2N1bWVudCBvbiB3aGljaCB0aGF0IGNsYWltIGlzIGJhc2VkPw0KICAgID4g
ICAgID4gRm9yIE5FUkMsIHlvdSBjYW4gbG9vayB1bmRlciAgIihDSVApIENyaXRpdGFsIEluZnJh
c3RydWN0dXJlIA0KICAgID4gICAgID4gUHJvdGVjdGlvbiIuIENJUC0wMDUtNSBmb3IgZXhhbXBs
ZSBjb3ZlcnMgdGhlIGVsZWN0cm9uaWMgc2VjdXJpdHkgDQogICAgPiAgICAgPiBwZXJpbWV0ZXIs
IHdoaWNoIGhhcyBhIGNvdXBsZSBvZiByZWxldmFudCByZXF1aXJlbWVudHMgYW5kIGFzc29jaWF0
ZWQNCiAgICA+ICAgICA+IHRleHQ6DQogICAgPiAgICAgPiANCiAgICA+ICAgICA+IGh0dHA6Ly93
d3cubmVyYy5jb20vX2xheW91dHMvUHJpbnRTdGFuZGFyZC5hc3B4P3N0YW5kYXJkbnVtYmVyPUNJ
UC0wMDUtNSZ0aXRsZT1DeWJlciUyMFNlY3VyaXR5JTIwLSUyMEVsZWN0cm9uaWMlMjBTZWN1cml0
eSUyMFBlcmltZXRlcihzKSZqdXJpc2RpY3Rpb249VW5pdGVkJTIwU3RhdGVzDQogICAgPiAgICAg
PiANCiAgICA+ICAgICA+IA0KICAgID4gICAgID4gDQogICAgPiAgICAgPiBUbyBiZSBjbGVhciB0
aG91Z2gsIHRoZSBkb2N1bWVudCBkb2VzIG5vdCBzcGVjaWZpY2FsbHkgY2FsbCBvdXQNCiAgICA+
ICAgICA+IGJyZWFraW5nIFRMUywgYnV0IGl0IGRvZXMgY2xlYXJseSBjYWxsIG91dCB0aGUgbmVl
ZCB0byBkZXRlY3QNCiAgICA+ICAgICA+IG1hbGljaW91cyBpbmJvdW5kIGFuZCBvdXRib3VuZCBj
b21tdW5pY2F0aW9ucyBieSBsZXZlcmFnaW5nIGFuDQogICAgPiAgICAgPiAiRWxlY3Ryb25pYyBB
Y2Nlc3MgUG9pbnQiIChlLmcuIElEUy9JUFMpIHRvIGVuZm9yY2UgdGhlIEVsZWN0cm9uaWMNCiAg
ICA+ICAgICA+IFNlY3VyaXR5IFBlcmltZXRlci4NCiAgICA+ICAgICA+PiBJJ2QgYWxzbyBjbGFp
bSB0aGF0IHlvdXIgcmVmZXJlbmNlIHRvIFBDSS1EU1MgaXMgbWlzbGVhZGluZywgYXMNCiAgICA+
ICAgICA+PiB0aGF0IHNhbWUgc3BlYyBhbHNvIGV4cGxpY2l0bHkgY2FsbHMgZm9yIHRoZXJlIHRv
IGJlIGdvb2Qga2V5DQogICAgPiAgICAgPj4gbWFuYWdlbWVudCBzcGVjaWZpY2FsbHkgaW5jbHVk
aW5nIG1pbmltaXNpbmcgdGhlIG51bWJlciBvZiBjb3BpZXMNCiAgICA+ICAgICA+PiBvZiBrZXlz
LCBzbyBhdCBtb3N0LCBvbmUgbWlnaHQgYmUgYWJsZSB0byBjbGFpbSB0aGF0IFBDSS1EU1MgaXMg
b2sNCiAgICA+ICAgICA+PiB3aXRoIHBlb3BsZSB3aG8gYnJlYWsgVExTIGluIGEgbm9kLWFuZC1h
LXdpbmsgbWFubmVyLiBCdXQgaWYgeW91IGRvDQogICAgPiAgICAgPj4gaGF2ZSBhIHJlYWwgcXVv
dGUgZnJvbSBQQ0ktRFNTIHRoYXQgY2FsbHMgZm9yIGJyZWFraW5nIFRMUyB0aGVuDQogICAgPiAg
ICAgPj4gcGxlYXNlIGRvIGFsc28gc2VuZCB0aGF0IChpdCdzIGJlZW4gYXNrZWQgZm9yIGEgYnVu
Y2ggb2YgdGltZXMNCiAgICA+ICAgICA+PiB3aXRob3V0IGFueSBhbnN3ZXIgYmVpbmcgcHJvdmlk
ZWQgc28gZmFyKS4NCiAgICA+ICAgICA+IA0KICAgID4gICAgID4gSSB3aWxsIG5lZWQgdG8gbG9v
ayBtb3JlIGNsb3NlbHkgZm9yIHN1Y2ggYSBxdW90ZSAtIGlmIGFueWJvZHkgZWxzZSANCiAgICA+
ICAgICA+IGtub3dzIG9mIG9uZSwgcGxlYXNlIGNoaW1lIGluIGFzIHdlbGwuDQogICAgPiAgICAg
PiANCiAgICA+ICAgICA+IFRoYW5rcw0KICAgID4gICAgID4gDQogICAgPiAgICAgPiAtLSBGbGVt
bWluZw0KICAgID4gICAgID4gDQogICAgPiAgICAgPiANCiAgICA+ICAgICA+PiBUaGFua3MsIFMu
DQogICAgPiAgICAgPj4gDQogICAgPiAgICAgPj4gDQogICAgPiAgICAgPj4gWzFdIA0KICAgID4g
ICAgID4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW13aW5nZXQtdGxzLXVz
ZS1jYXNlcy0wMC5odG1sI3JlZi1ORVJDQ0lQDQogICAgPiAgICAgPg0KICAgID4gICAgID4+IA0K
ICAgID4gICAgID4gDQogICAgPiAgICAgPiANCiAgICA+ICAgICA+IA0KICAgID4gICAgID4gDQog
ICAgPiAgICAgDQogICAgPiAgICAgDQogICAgPiANCiAgICANCiAgICANCg0K


From nobody Fri Nov 10 17:12:13 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC98127F0E for ; Fri, 10 Nov 2017 17:12:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 IE-YGsQVQhUl for ; Fri, 10 Nov 2017 17:12:07 -0800 (PST)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 A9A9A126D46 for ; Fri, 10 Nov 2017 17:12:07 -0800 (PST)
Received: by mail-yw0-x235.google.com with SMTP id y75so9554124ywg.0 for ; Fri, 10 Nov 2017 17:12:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G8LvO/iFnac7MP6nn9Tk+4M2M5wWj0UauOCPsokj4sM=; b=EnUDoK03tgaAY/TZyaedLlP9LxaHKidBvfHVG81KPCVfK7NlUjp9AhaREaJM6Qtyd9 gRiS3BFBSH9rLwelXepIqTwvNJ/7Tx3j7hAaOHeJVmmcftyCyRFqB0vaGZ7st42IIPL+ gEj6ZvS6R9YaQpS5nUXwparOq3H+IEiCQ6txRocCQ0Xc8T+dQuxDOF0aJw4120ue3XNP af6AFPdCK3LpRhxFt365p48IxpSCi1W0LK7Wft090fiRYSA9qNXM0Jj6Ze47yXLU7Vd7 I4QSI7pRxToXA5R3bP1j/0Gj/P26aUbXAUWrd9v/cOZfKbSh1+U4NoJM5r3oVwAFCc+l 64FA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G8LvO/iFnac7MP6nn9Tk+4M2M5wWj0UauOCPsokj4sM=; b=B22VSO7ID1gCA/nymkwYZchnJ/lvvIiaj3GjfSFSW1R4AANoTUnNINSn1ke4B3mLmK 3lby+DcNe5iS2y2iRoW+ZRS9mm1u2G4rctrmZnYdMAbjj1eIDuYt6Kk2UgYqlR0aFD+s XIxBbv3gZQZn7orYPDAwaXi/SIeheu9tJYtfLiYjnEKr7Ge5Kzn+nPhfQLGUeHp6Nwdt c9mt2mg/Ep853aMqT7loA9T5kKQuQM4JaK1FyubrICtv0BET/YvfFmIxbukLQq+MCVyx ijqlBugLw8aR7vDQ0dpLmdZ5aZfp5Aarr9irEDK9y20N21WLfCCM6BiwyDrBH6UDVswX IZRw==
X-Gm-Message-State: AJaThX7FcuEz7SKBDJoToDngNwXQzCMWyfPSofDFB3O7DjyHEcI76nzF 5XcY8Xf1AnBTyVYqhXPbIJTFFUvXnikCvUibZ47S2A==
X-Google-Smtp-Source: AGs4zManW5sus3davhm4KfMbyRfKlIS00mkq0vBQbzr2pp/4sCP49iHDM6MpaVivPq/Fv9eNOuJCIDl0qzpIJdeZsVE=
X-Received: by 10.37.20.193 with SMTP id 184mr1460384ybu.400.1510362726855; Fri, 10 Nov 2017 17:12:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.61.12 with HTTP; Fri, 10 Nov 2017 17:11:26 -0800 (PST)
In-Reply-To: 
References: <895D1206-28D1-43AB-8A45-11DEEC86A71D@cisco.com> <874lq868t3.fsf@mid.deneb.enyo.de>  <6966da46-0f07-b518-4b6e-f2b5f599b050@cs.tcd.ie>  <8448A3AF-CEAF-41F4-A43F-9ED7B209C7B9@cisco.com> <84562f24-7a4f-4a9f-264c-1edf1e41bebe@cs.tcd.ie>  <3db42c7c-2904-f11f-ab8e-116835669816@cs.tcd.ie> 
From: Eric Rescorla 
Date: Fri, 10 Nov 2017 17:11:26 -0800
Message-ID: 
To: "Nancy Cam-Winget (ncamwing)" 
Cc: Stephen Farrell ,  "Flemming Andreasen (fandreas)" , Florian Weimer , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a113e72b6d10d78055daab95e"
Archived-At: 
Subject: Re: [TLS] network-based security solution use cases
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Nov 2017 01:12:12 -0000

--001a113e72b6d10d78055daab95e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Nov 10, 2017 at 11:39 AM, Nancy Cam-Winget (ncamwing) <
ncamwing@cisco.com> wrote:

>
> Hi all,
>
> I think Flemming has expressed our points well.  But I think we are losin=
g
> sight of the purpose of the draft: this is what industry is doing today i=
n
> response to requirements; whether imposed by customers or regulations.  I
> would not expect these to explicitly state how a solution, architecture a=
nd
> protocol is to be implemented, they do impose requirements to an expected
> outcome.  As such, solutions have embraced the use of TLS pervasively and
> balanced the requirements of customers/regulations to provide firewall,
> inspection for monitoring and troubleshooting by the use cases as
> documented in the draft.
>
> We are NOT against the use of PFS and improved security; we continue to
> look forward to evolving solutions that use TLS (1.3)=E2=80=A6but in some=
 cases
> there are implications that we thought merited awareness and further
> discussion.
>

Nancy,

I don't dispute that some organizations ("industry" seems like a pretty
overbroad term as many organizations do not do these things) engage in some
of the practices that you list. However, as I noted in my review, I think
there are real concerns about whether these practices in fact securely
achieve their stated goals (even ignoring the impact that accommodating
them would have on TLS 1.3).

-Ekr





> Warm regards, Nancy
>
>
> On 11/7/17, 4:40 PM, "Stephen Farrell"  wrote:
>
>
>     Hiya,
>
>     On 08/11/17 00:23, Nancy Cam-Winget (ncamwing) wrote:
>     > Hi Stephen,
>     > Please see below:
>     >
>     > On 11/7/17, 4:08 PM, "Stephen Farrell" 
> wrote:
>     >
>     >
>     >     Hiya,
>     >
>     >     On 07/11/17 23:53, Nancy Cam-Winget (ncamwing) wrote:
>     >     > Hi Stephen, Adding to Flemming=E2=80=99s comment,  finding =
=E2=80=9Cexact
> quotes=E2=80=9D
>     >     > will be difficult
>     >
>     >     I'm sorry but when making a claim that such and such a regulati=
on
>     >     *requires* breaking TLS then you really do need to be that
> precise.
>     > [NCW] In TLS 1.2, not sure why you state *requires* as there is the
> visibility afforded to
>     > at least allow for the identity disclosure to enable white or
> blacklist for example.
>
>     Quoting from your draft wrt PCI-DSS:
>
>     " Requirement #2 (and Appendix A2 as it concerns TLS)
>        describes the need to be able to detect protocol and protocol usag=
e
>        correctness."
>
>     That one is nice - you seem to be arguing for protocol non-conformanc=
e
>     (or for weakening conformant implementations) in order to help ensure
>     "protocol usage correctness." That kind of makes my head spin.
>
>     Another quote wrt NERC:
>
>     " In fact, regulatory standards such as NERC CIP
>        [NERCCIP] place strong requirements about network perimeter securi=
ty
>        and its ability to have visibility to provide security information
> to
>        the security management and control systems. "
>
>     Where exactly did you see those "strong requirements" that presumably
>     *require* breaking TLS?
>
>     I don't see them.
>
>     When I or others ask to be shown them we don't get shown them.
>
>     To me that means those are not *required*.
>
>     >
>     >     > as their intent is really not to break things but
>     >     > rather want to ensure that inspection and oversight is
> available to
>     >     > affect guards/protections within an (enterprise/data center)
>     >     > infrastructure.   That said, PCI and other regulations will
> have a
>     >     > lot of documents that one has to go through=E2=80=A6.one that=
 kind-of
> calls
>     >     > explicitly to the use of packet inspection, firewalling and
> such is
>     >     > in:
>     >     >
>     >     > https://www.pcisecuritystandards.org/
> documents/SAQ_D_v3_Merchant.pdf
>     >
>     >     The first mention of TLS there talks about protecting
> administrator
>     >     passwords via TLS. That totally argues against deployment of an=
y
> kind
>     >     of MitM infrastructure.
>     > [NCW] Agreed, they also state in ensuring that the newest TLS
> version where
>     > possible is used.  BUT, they also expect monitoring and
> troubleshooting.
>
>     Sure. Not all monitoring *requires* breaking TLS. Same for
>     troubleshooting.
>
>     Of course people who sell kit for that or have been doing
>     that for a while might want to see what they do as being
>     mandatory/required/regulated-for but I'm not seeing it.
>
>     >
>     >     >
>     >     > It is an assessment questionnaire for vendors to evaluate the=
ir
>     >     > compliance, the requirements speak to securing the network an=
d
>     >     > systems including firewalls, DMZs and the ability to do packe=
t
>     >     > inspection.
>     >
>     >     Please point me at the specific text. Given you added PCI-DSS t=
o
>     >     your document I would assume you did the work already. If not,
>     >     that's a bit odd.
>     > [NCW] From the link above, you can look at requirements in 1.3,
>     > also Requirement 10 details the need to monitor and provide audit
> trails
>     > for network resources and cardholder data
>
>     You mean 1.3 on page 6 I guess. I see nothing on pages 6 or 7
>     that call for MitMing TLS. That seems to be about addressing
>     and DMZs and firewall and router configs.
>
>     Requirement 10 seems to be dealing with audit of accesses to
>     cardholder data, not with TLS at all. I read pages 50-55 for
>     that.
>
>     Honestly, what you're saying is there does not seem to be
>     there.
>
>     S.
>
>
>     >
>     >     S.
>     >
>     >
>     >     >
>     >     > Thanks, Nancy
>     >     >
>     >     > On 11/7/17, 3:27 PM, "Flemming Andreasen (fandreas)"
>     >     >  wrote:
>     >     >
>     >     > Thanks for taking an initial look at the document Stephen -
> please
>     >     > see below for responses so far
>     >     >
>     >     > On 11/7/17 4:13 AM, Stephen Farrell wrote:
>     >     >> Hiya,
>     >     >>
>     >     >> On 07/11/17 02:48, Flemming Andreasen wrote:
>     >     >>> We didn't draw any particular line, but the use case
> scenarios
>     >     >>> that we tried to highlight are those related to overall
> security
>     >     >>> and regulatory requirements (including public sector)
>     >     >> I had a quick look at the draft (will try read properly
> en-route
>     >     >> to ietf-100) and I followed the reference to [1] but that
> only lead
>     >     >> to a forest of documents in which I didn't find any referenc=
e
> to
>     >     >> breaking TLS so far at least. Can you provide an explicit
> pointer
>     >     >> to the exact document on which that claim is based?
>     >     > For NERC, you can look under  "(CIP) Critital Infrastructure
>     >     > Protection". CIP-005-5 for example covers the electronic
> security
>     >     > perimeter, which has a couple of relevant requirements and
> associated
>     >     > text:
>     >     >
>     >     > http://www.nerc.com/_layouts/PrintStandard.aspx?
> standardnumber=3DCIP-005-5&title=3DCyber%20Security%20-%
> 20Electronic%20Security%20Perimeter(s)&jurisdiction=3DUnited%20States
>     >     >
>     >     >
>     >     >
>     >     > To be clear though, the document does not specifically call o=
ut
>     >     > breaking TLS, but it does clearly call out the need to detect
>     >     > malicious inbound and outbound communications by leveraging a=
n
>     >     > "Electronic Access Point" (e.g. IDS/IPS) to enforce the
> Electronic
>     >     > Security Perimeter.
>     >     >> I'd also claim that your reference to PCI-DSS is misleading,
> as
>     >     >> that same spec also explicitly calls for there to be good ke=
y
>     >     >> management specifically including minimising the number of
> copies
>     >     >> of keys, so at most, one might be able to claim that PCI-DSS
> is ok
>     >     >> with people who break TLS in a nod-and-a-wink manner. But if
> you do
>     >     >> have a real quote from PCI-DSS that calls for breaking TLS
> then
>     >     >> please do also send that (it's been asked for a bunch of tim=
es
>     >     >> without any answer being provided so far).
>     >     >
>     >     > I will need to look more closely for such a quote - if anybod=
y
> else
>     >     > knows of one, please chime in as well.
>     >     >
>     >     > Thanks
>     >     >
>     >     > -- Flemming
>     >     >
>     >     >
>     >     >> Thanks, S.
>     >     >>
>     >     >>
>     >     >> [1]
>     >     >> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-
> 00.html#ref-NERCCIP
>     >     >
>     >     >>
>     >     >
>     >     >
>     >     >
>     >     >
>     >
>     >
>     >
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--001a113e72b6d10d78055daab95e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Fri, Nov 10, 2017 at 11:39 AM, Nancy Cam-Winget (ncamwing) <ncamwi=
ng@cisco.com> wrote:


Hi all,



I think Flemming has expressed our points well.=C2=A0 But I think we are lo=
sing sight of the purpose of the draft: this is what industry is doing toda=
y in response to requirements; whether imposed by customers or regulations.=
=C2=A0 I would not expect these to explicitly state how a solution, archite=
cture and protocol is to be implemented, they do impose requirements to an =
expected outcome.=C2=A0 As such, solutions have embraced the use of TLS per=
vasively and balanced the requirements of customers/regulations to provide =
firewall, inspection for monitoring and troubleshooting by the use cases as=
 documented in the draft.



We are NOT against the use of PFS and improved security; we continue to loo=
k forward to evolving solutions that use TLS (1.3)=E2=80=A6but in some case=
s there are implications that we thought merited awareness and further disc=
ussion.

Nancy,

I don't dispute that some organizations ("industry" seems li=
ke a pretty overbroad term as many organizations do not do these things) en=
gage in some of the practices that you list. However, as I noted in my revi=
ew, I think there are real concerns about whether these practices in fact s=
ecurely achieve their stated goals (even ignoring the impact that accommoda=
ting them would have on TLS 1.3).

-Ekr
<=
br>






Warm regards, Nancy






On 11/7/17, 4:40 PM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:





=C2=A0 =C2=A0 Hiya,



=C2=A0 =C2=A0 On 08/11/17 00:23, Nancy Cam-Winget (ncamwing) wrote:

=C2=A0 =C2=A0 > Hi Stephen,

=C2=A0 =C2=A0 > Please see below:

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 > On 11/7/17, 4:08 PM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie>=
 wrote:

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Hiya,

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0On 07/11/17 23:53, Nancy Cam-Winget (=
ncamwing) wrote:

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> Hi Stephen, Adding to Flemming=
=E2=80=99s comment,=C2=A0 finding =E2=80=9Cexact quotes=E2=80=9D

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> will be difficult

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I'm sorry but when making a claim=
 that such and such a regulation

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0*requires* breaking TLS then you real=
ly do need to be that precise.

=C2=A0 =C2=A0 > [NCW] In TLS 1.2, not sure why you state *requires* as t=
here is the visibility afforded to

=C2=A0 =C2=A0 > at least allow for the identity disclosure to enable whi=
te or blacklist for example.



=C2=A0 =C2=A0 Quoting from your draft wrt PCI-DSS:



=C2=A0 =C2=A0 " Requirement #2 (and Appendix A2 as it concerns TLS)
=C2=A0 =C2=A0 =C2=A0 =C2=A0describes the need to be able to detect protocol=
 and protocol usage

=C2=A0 =C2=A0 =C2=A0 =C2=A0correctness."



=C2=A0 =C2=A0 That one is nice - you seem to be arguing for protocol non-co=
nformance

=C2=A0 =C2=A0 (or for weakening conformant implementations) in order to hel=
p ensure

=C2=A0 =C2=A0 "protocol usage correctness." That kind of makes my=
 head spin.



=C2=A0 =C2=A0 Another quote wrt NERC:



=C2=A0 =C2=A0 " In fact, regulatory standards such as NERC CIP

=C2=A0 =C2=A0 =C2=A0 =C2=A0[NERCCIP] place strong requirements about networ=
k perimeter security

=C2=A0 =C2=A0 =C2=A0 =C2=A0and its ability to have visibility to provide se=
curity information to

=C2=A0 =C2=A0 =C2=A0 =C2=A0the security management and control systems. &qu=
ot;



=C2=A0 =C2=A0 Where exactly did you see those "strong requirements&quo=
t; that presumably

=C2=A0 =C2=A0 *require* breaking TLS?



=C2=A0 =C2=A0 I don't see them.



=C2=A0 =C2=A0 When I or others ask to be shown them we don't get shown =
them.



=C2=A0 =C2=A0 To me that means those are not *required*.



=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> as their intent is really not to=
 break things but

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> rather want to ensure that inspe=
ction and oversight is available to

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> affect guards/protections within=
 an (enterprise/data center)

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> infrastructure.=C2=A0 =C2=A0That=
 said, PCI and other regulations will have a

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> lot of documents that one has to=
 go through=E2=80=A6.one that kind-of calls

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> explicitly to the use of packet =
inspection, firewalling and such is

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> in:

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> https://www.pcisecuritystandards.org/documents/SAQ_D_=
v3_Merchant.pdf

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0The first mention of TLS there talks =
about protecting administrator

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0passwords via TLS. That totally argue=
s against deployment of any kind

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0of MitM infrastructure.

=C2=A0 =C2=A0 > [NCW] Agreed, they also state in ensuring that the newes=
t TLS version where

=C2=A0 =C2=A0 > possible is used.=C2=A0 BUT, they also expect monitoring=
 and troubleshooting.



=C2=A0 =C2=A0 Sure. Not all monitoring *requires* breaking TLS. Same for
=C2=A0 =C2=A0 troubleshooting.



=C2=A0 =C2=A0 Of course people who sell kit for that or have been doing

=C2=A0 =C2=A0 that for a while might want to see what they do as being

=C2=A0 =C2=A0 mandatory/required/regulated-for but I'm not seeing =
it.



=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> It is an assessment questionnair=
e for vendors to evaluate their

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> compliance, the requirements spe=
ak to securing the network and

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> systems including firewalls, DMZ=
s and the ability to do packet

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> inspection.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Please point me at the specific text.=
 Given you added PCI-DSS to

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0your document I would assume you did =
the work already. If not,

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0that's a bit odd.

=C2=A0 =C2=A0 > [NCW] From the link above, you can look at requirements =
in 1.3,

=C2=A0 =C2=A0 > also Requirement 10 details the need to monitor and prov=
ide audit trails

=C2=A0 =C2=A0 > for network resources and cardholder data



=C2=A0 =C2=A0 You mean 1.3 on page 6 I guess. I see nothing on pages 6 or 7=


=C2=A0 =C2=A0 that call for MitMing TLS. That seems to be about addressing<=
br>
=C2=A0 =C2=A0 and DMZs and firewall and router configs.



=C2=A0 =C2=A0 Requirement 10 seems to be dealing with audit of accesses to<=
br>
=C2=A0 =C2=A0 cardholder data, not with TLS at all. I read pages 50-55 for<=
br>
=C2=A0 =C2=A0 that.



=C2=A0 =C2=A0 Honestly, what you're saying is there does not seem to be=


=C2=A0 =C2=A0 there.



=C2=A0 =C2=A0 S.





=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0S.

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> Thanks, Nancy

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> On 11/7/17, 3:27 PM, "Flemm=
ing Andreasen (fandreas)"

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> <fandreas@cisco.com> wrote:

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> Thanks for taking an initial loo=
k at the document Stephen - please

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> see below for responses so far
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> On 11/7/17 4:13 AM, Stephen Farr=
ell wrote:

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>> Hiya,

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>>

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>> On 07/11/17 02:48, Flemming =
Andreasen wrote:

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>>> We didn't draw any p=
articular line, but the use case scenarios

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>>> that we tried to highlig=
ht are those related to overall security

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>>> and regulatory requireme=
nts (including public sector)

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>> I had a quick look at the dr=
aft (will try read properly en-route

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>> to ietf-100) and I followed =
the reference to [1] but that only lead

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>> to a forest of documents in =
which I didn't find any reference to

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>> breaking TLS so far at least=
. Can you provide an explicit pointer

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>> to the exact document on whi=
ch that claim is based?

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> For NERC, you can look under=C2=
=A0 "(CIP) Critital Infrastructure

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> Protection". CIP-005-5 for =
example covers the electronic security

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> perimeter, which has a couple of=
 relevant requirements and associated

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> text:

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> http://www.nerc.com/_layou=
ts/PrintStandard.aspx?standardnumber=3DCIP-005-5&title=
=3DCyber%20Security%20-%20Electronic%20Security%20Perimeter(s)&am=
p;jurisdiction=3DUnited%20States

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> To be clear though, the document=
 does not specifically call out

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> breaking TLS, but it does clearl=
y call out the need to detect

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> malicious inbound and outbound c=
ommunications by leveraging an

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> "Electronic Access Point&qu=
ot; (e.g. IDS/IPS) to enforce the Electronic

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> Security Perimeter.

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>> I'd also claim that your=
 reference to PCI-DSS is misleading, as

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>> that same spec also explicit=
ly calls for there to be good key

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>> management specifically incl=
uding minimising the number of copies

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>> of keys, so at most, one mig=
ht be able to claim that PCI-DSS is ok

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>> with people who break TLS in=
 a nod-and-a-wink manner. But if you do

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>> have a real quote from PCI-D=
SS that calls for breaking TLS then

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>> please do also send that (it=
's been asked for a bunch of times

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>> without any answer being pro=
vided so far).

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> I will need to look more closely=
 for such a quote - if anybody else

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> knows of one, please chime in as=
 well.

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> Thanks

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> -- Flemming

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>> Thanks, S.

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>>

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>>

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>> [1]

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>> https://tools.ietf.org/html/draft-camwinget-tl=
s-use-cases-00.html#ref-NERCCIP

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>>

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>

=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 >








_______________________=
________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--001a113e72b6d10d78055daab95e--


From nobody Fri Nov 10 23:10:43 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E52D129411 for ; Fri, 10 Nov 2017 23:10:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
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 YoeFM047JmkW for ; Fri, 10 Nov 2017 23:10:40 -0800 (PST)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 207EB12706D for ; Fri, 10 Nov 2017 23:10:40 -0800 (PST)
Received: by mail-pf0-x22e.google.com with SMTP id u70so3460037pfa.7 for ; Fri, 10 Nov 2017 23:10:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=1VA6dge/ravGjvprkgCTBH5RLg7zL84LmhJNXbYZxM4=; b=PTnvKkfF3ECCtbnduq6UtchHBC6r5YhTc2yhgRrnTFClAcI2JwEvNTu8gsUP6NGJw/ 3Y2bnb0/E1+HB5Uh86qsmdtp8MSdfZyvDn08/HdiAHsKWPsH7w2jMnCW7JlIHwnqG3F9 3FuzFEZeNw0nMB7CrI9ZiysPR0CYwtArKG+Hc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=1VA6dge/ravGjvprkgCTBH5RLg7zL84LmhJNXbYZxM4=; b=oONQPEMJNSJRduC8fuuuwqkGgGTEM2uzhxxHIRfyD0P6Gluf86LE7IyobWehlsA2Sr SMm2aBJuJ4MlGWbfxXruolCUqDwzPbtZvhTbBwaodTW9nAfeRaW3pjUj4uyul0VwP0oX yLlnLs4Z2JDV0oaxMKnT7fJgxhn7IKAuuUeyspiDQNPY2ufbKDNKiSBrejcpzDim4XA2 zi1r8eoD3DQh9I/x+H9sPVifheGZ3GHEQmjmk6d+PMjjNrmscwLl8mY3PY3dm/RfYNzj VZOk1qEcp4EG6AjT3n9CJapT3D6TqyjXpwCkeX37Lc18atQiWtU+c2Y5PCHajs9BJIZY kBBA==
X-Gm-Message-State: AJaThX44+g9JI4dTZ9PrKkLd6YJ3u63DnIsjmIA9iZE874e/ae8pIkrL ebr1IFR5sc+AnqHWj2kTvJPGiSjktwU=
X-Google-Smtp-Source: AGs4zMYj52FAqPvQ+BEvXO5z/kYFTTSnbgpiTr9mwi+d5Iz3TCIbXWjNyGNk7llUtlN1iRM+hcjJgg==
X-Received: by 10.159.250.132 with SMTP id k4mr2829955pls.61.1510384239403; Fri, 10 Nov 2017 23:10:39 -0800 (PST)
Received: from ?IPv6:2001:67c:1232:144:6976:11e9:872a:d627? ([2001:67c:1232:144:6976:11e9:872a:d627]) by smtp.gmail.com with ESMTPSA id x6sm11645308pfx.15.2017.11.10.23.10.38 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Nov 2017 23:10:38 -0800 (PST)
From: Sean Turner 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <3ABD5F6F-8CA7-4349-AA05-3D413B2346A5@sn3rd.com>
Date: Sat, 11 Nov 2017 15:10:34 +0800
To: "" 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: [TLS] TLS@IETF100: Monday Session Canceled
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Nov 2017 07:10:41 -0000

Based on the number of agenda requests we received, we=E2=80=99ve =
decided to cancel Monday=E2=80=99s session.

spt=


From nobody Sat Nov 11 01:21:17 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828D81294B9 for ; Sat, 11 Nov 2017 01:21:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level: 
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 FVJRfAMiLpAc for ; Sat, 11 Nov 2017 01:21:14 -0800 (PST)
Received: from mail-in1.asia.apple.com (mail-out.asia.apple.com [17.82.254.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E98712949F for ; Sat, 11 Nov 2017 01:21:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1510392071; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=TDXiU6L93aAaMEbltReZ7/Jkr4wJrxbqVkrrh78v2ho=; b=2mn/b+/mNE8nxtrJXR5ag3wQEzBP1OewEpDqGchnKYxlP1s0mSnT4Sg5EXdHaztg x8FXM7OhHhRFMhAanNkpjMsiCZphrw0SLzmzH9K/3yJ6H0+y8O5BRYP+ATNfQvGt x9UeWN1DDV6j17/mKxLpdKSllPBoshSCG2K1V5kRgV+bRON0BOXWw/H8zSFRV5lW UGcNebN5fw+mOrWmjLdZ/0E/ygRh4L/7WbBiCYrbxQ4M8gjo7EwQxgfXVNjALpjX xeqd2qwn5zrf7e+zpDdSLYVFXsDpAYAK/YcbbMOgHIE0cD+2yOUorXwJbiz8GVTi XbKYsB/ItGB+eH/yXDQOrA==;
Received: from relay2.asia.apple.com ( [17.82.200.16]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in1.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id 67.39.07591.701C60A5; Sat, 11 Nov 2017 17:21:11 +0800 (MYT)
X-AuditID: 1152fe11-8cbff70000001da7-54-5a06c107914c
Received: from mmp3.asia.apple.com ( [17.84.76.250]) by relay2.asia.apple.com (Apple Singapore relay) with SMTP id 92.39.31851.701C60A5; Sat, 11 Nov 2017 17:21:11 +0800 (MYT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_2Mp+PFhWOsbjWXj1wK7AxQ)"
Received: from dhcp-88ad.meeting.ietf.org (dhcp-88ad.meeting.ietf.org [31.133.136.173]) by mmp3.asia.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OZ800AEZXZB1970@mmp3.asia.apple.com> for tls@ietf.org; Sat, 11 Nov 2017 17:21:11 +0800 (SGT)
Sender: dschinazi@apple.com
From: David Schinazi 
Message-id: 
Date: Sat, 11 Nov 2017 17:21:11 +0800
To: tls@ietf.org
X-Mailer: Apple Mail (2.3445.1.6)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUiGHRCQJf9IFuUQecODYtP57sYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsbL3K1PBP/2KmZM2sDQwvtDoYuTkkBAwkfh8/BtbFyMXh5DA SiaJA1/eM3cxcoAlvnwRhohvYJToOnaEDaSBV0BQ4sfkeywgNrNAmMTMz0/ZIYp2M0m0fnvN DpIQFpCW6LpwlxVkEJuAlsSBNUYQYUWJfy8mMkHMsZH413AGzGYRUJX4fPsSI0i5iICARPNL MYjbFCWOzJzDDDJeQuAlq8Sss89ZJjDyz0JyxiwkZ8wCamcWUJeYMiUXIqwt8eTdBVYIW01i 4e9FTMjiCxjZVjGK5yZm5uhm5hnqJRZnJuolFhTkpOol5+duYgQH7T/BHYxTFxoeYhTgYFTi 4c1bwBYlxJpYVlyZe4hRgoNZSYSXLQwoxJuSWFmVWpQfX1Sak1p8iFGag0VJnLcv8lOkkEB6 YklqdmpqQWoRTJaJg1OqgXHKiqUPoqJ2rP0/uX9aePX7TTE6b6S2/5Wd+P/dE5+ZAgx/LM12 iWkwur3I4DGpVy9PYTq/5d7ZDR7p/OdnnJ9v+3nu/EUCHj/c81SnCNsbaDeztsdfPHFxllGX /moFu1hprlMzup3sZAx1Tv0quLTt6LsZPnc8brjUPduw7s7Et175v6ZvydyuxFKckWioxVxU nAgAuhWD51YCAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUiGOLzS5f9IFuUwew/ChafzncxOjB6LFny kymAMYrLJiU1J7MstUjfLoErY2XvV6aCf/oVMydtYGlgfKHRxcjBISFgIvHli3AXIxeHkMAG RomuY0fYuhg5OXgFBCV+TL7HAmIzC4RJzPz8lB2iaDeTROu31+wgCWEBaYmuC3dZQQaxCWhJ HFhjBBFWlPj3YiITxBwbiX8NZ8BsFgFVic+3LzGClIsICEg0vxQDCUsAlR+ZOYd5AiPPLCSb ZyHZPAuog1lAXWLKlFyIsLbEk3cXWCFsNYmFvxcxIYsvYGRbxShalJqTWGmkl1icmaiXWFCQ k6qXnJ+7iREUZEEnBHYwzjpkcIhRgINRiYc3bwFblBBrYllxZe4hRgkOZiURXrYwoBBvSmJl VWpRfnxRaU5q8SFGaQ4WJXFezahPkUIC6YklqdmpqQWpRTBZJg5OqQbGJY1+6tIBpV9m1pop LstSv6Oe8/TmHjXBIDlDztMXs+6GM29YFN/j+1KtQ3iy49JfObfvi8/maGftsevnds2yei7F YPfQqz/9XM2qWn09uaepsp2Hz1o4qeVNVt3/m6ly6yZ7peAGWTHf7IiyHL9JThOSj5/7KDtl O3Pqhk9FeTnTHI5cTVFiKc5INNRiLipOBAC4kjlkLgIAAA==
Archived-At: 
Subject: [TLS] close_notify and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Nov 2017 09:21:16 -0000

--Boundary_(ID_2Mp+PFhWOsbjWXj1wK7AxQ)
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: quoted-printable

Hello all,

Currently TLS 1.3 specifies close_notify in the same way that TLS 1.2 =
did.
I believe that has issues and this might be the right time to fix them.
The purpose of close_notify is to protect against data truncation =
attacks,
each side is required to send close_notify before closing the write side =
of
the transport connection so the other side knows that the data was not =
truncated.
As such, close_notify only needs half-close semantics to prevent =
truncation.

However, the specification contains the following text:
<< Each party MUST send a =E2=80=9Cclose_notify=E2=80=9D alert before =
closing the write side
    of the connection, unless some other fatal alert has been =
transmitted.
    The other party MUST respond with a =E2=80=9Cclose_notify=E2=80=9D =
alert of its own and close
    down the connection immediately, discarding any pending writes. >>

This means that an application-layer client can't send a query then =
close their
write transport when they know that they're done, because the server =
would
terminate the TLS session before sending the reply. On top of this, when
the server receives the close_notify, it may have already sent part of =
the reply
(or wrote it to the socket send buffer) so the responding close_notify =
would
in effect be inflicting a truncation attack on the client.

This doesn't make much difference for HTTP because clients already
don't close their write transport after sending a reply, however having =
the
option do do this could allow innovation in new protocols that can =
define
the semantics of when they use close_notify. An example is DNS PUSH:
https://tools.ietf.org/html/draft-ietf-dnssd-push =


A proposal to solve this problem would be to give close_notify =
half-close
semantics: we keep the requirements that a close_notify be sent before
closing the transport, and that any data received after a close_notify =
is
ignored, but we simply remove the requirement to immediately reply
with a close_notify. This has the advantage that current implementations
are already compliant but future ones can leverage this improvement.

What do you think? Is this worth discussing on Thursday?

Thanks,
David Schinazi=

--Boundary_(ID_2Mp+PFhWOsbjWXj1wK7AxQ)
Content-type: text/html; charset=utf-8
Content-transfer-encoding: quoted-printable

Hello=
 all,

Currently TLS =
1.3 specifies close_notify in the same way that TLS 1.2 did.
I believe that has issues and this might be the right time to =
fix them.
The purpose of close_notify is to protect =
against data truncation attacks,
each side is =
required to send close_notify before closing the write side of
the transport connection so the other side knows that the =
data was not truncated.
As such, close_notify only =
needs half-close semantics to prevent truncation.
However, the specification contains =
the following text:
<< Each party MUST send a =
=E2=80=9Cclose_notify=E2=80=9D alert before closing the write =
side
    of the connection, unless some =
other fatal alert has been transmitted.
  =
  The other party MUST respond with a =E2=80=9Cclose_notify=E2=80=9D =
alert of its own and close
    down the =
connection immediately, discarding any pending writes. =
>>

This =
means that an application-layer client can't send a query then close =
their
write transport when they know that they're =
done, because the server would
terminate the TLS =
session before sending the reply. On top of this, when
the server receives the close_notify, it may have already =
sent part of the reply
(or wrote it to the socket =
send buffer) so the responding close_notify would
in =
effect be inflicting a truncation attack on the client.

This doesn't make much =
difference for HTTP because clients already
don't =
close their write transport after sending a reply, however having =
the
option do do this could allow innovation in new =
protocols that can define
the semantics of when =
they use close_notify. An example is DNS PUSH:
https://tools.ietf.org/html/draft-ietf-dnssd-push

A proposal to solve =
this problem would be to give close_notify half-close
semantics: we keep the requirements that a close_notify be =
sent before
closing the transport, and that any =
data received after a close_notify is
ignored, but =
we simply remove the requirement to immediately reply
with a close_notify. This has the advantage that current =
implementations
are already compliant but future =
ones can leverage this improvement.

What do you think? Is this worth =
discussing on Thursday?

Thanks,
David =
Schinazi
=

--Boundary_(ID_2Mp+PFhWOsbjWXj1wK7AxQ)--


From nobody Sat Nov 11 02:42:30 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357C61294CF for ; Sat, 11 Nov 2017 02:42:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 x7YEXFfNKNBj for ; Sat, 11 Nov 2017 02:42:26 -0800 (PST)
Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 AC751120725 for ; Sat, 11 Nov 2017 02:42:26 -0800 (PST)
Received: by mail-ua0-x22c.google.com with SMTP id 108so3193916uaf.2 for ; Sat, 11 Nov 2017 02:42:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sCJk9DwUOVM87SF9qnqgln4vZRVuGycPwo4xxufxyUc=; b=HA8CrhLfNBNyvlP91y63eZ2eYok8SuM4UaxVzKB8DFBy5uBAT+xjL/dtoswRa+Icfv rjKj4lKIovNM/aT/paHh9wDLih9UyoXpbW7HCuabcOCSaHqufCoC1zuRdSu4mJ63unVD rtvhdi2TZkbMJbRRME9s/y7I4nDY0OsiVr9xcPD6e5SK88SN5zS9qsKc+xROk0DZheuj amrUDFpJiZog9aAFWkkdP9m1MxPwGiMYXT2u14BUGvV215BzIOLc7XBXivTmfFIcUnBY SPpvBsDAmQLo8TaYN7r+NHq0J/ZO2pimN8lpAbEWXyuqrySimYSCgH3pnkzv7h/u3M0k AUGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sCJk9DwUOVM87SF9qnqgln4vZRVuGycPwo4xxufxyUc=; b=Fu8pbvofL2YvqIHb877PQaE70W1Ly93mx23IaDresKWaGw6j/K6/+jgATgByt1rMvm mQwKxKP1NyzDs5ylQWQzk6FGVMBc5Q8h2P1NOn3y58xhgDxv9FYHbAlJaCMYnKDS16ho BHVyCaWFso+fWeIxBak1TSQCjZnbBed9u4RGGXoDviVv0ybCHo4cybonKdJMP/6AfTk0 oGG4d0KOfajhx4C62h8+jojVaOGMjBXJ7df46BmIQ7SF9UZlo0FwYNCxWRwRhwB/buDW XYk16YvR/NGaWZ6WABL901ii4qcUd5nnMwF4p5apaKu4r/S1GpB+s9vSfStNWTJi31hB 23xg==
X-Gm-Message-State: AJaThX6BLDKorVNSKsUn4c2NSBBaCkJP+r/xiX5usvc9a1TEMIrZLuQe Za5NemBlkpyOFDWpIer6qLA3mtfOUTfJdYasEIkjx4zk
X-Google-Smtp-Source: AGs4zMbywC+JdTBx8C1javftwEOqV0NJn43wHW02Yh+93VX+7DIW6oWq3lavq2RCv4keYJeT6z0QOdl67szHVeEPyJw=
X-Received: by 10.176.82.205 with SMTP id w13mr2679020uaw.174.1510396945267; Sat, 11 Nov 2017 02:42:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.48.85 with HTTP; Sat, 11 Nov 2017 02:42:24 -0800 (PST)
In-Reply-To: <3ABD5F6F-8CA7-4349-AA05-3D413B2346A5@sn3rd.com>
References: <3ABD5F6F-8CA7-4349-AA05-3D413B2346A5@sn3rd.com>
From: Ben Schwartz 
Date: Sat, 11 Nov 2017 18:42:24 +0800
Message-ID: 
To: Sean Turner 
Cc: "" 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c190e7e6ca4b4055db2b14c"
Archived-At: 
Subject: Re: [TLS] TLS@IETF100: Monday Session Canceled
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Nov 2017 10:42:29 -0000

--94eb2c190e7e6ca4b4055db2b14c
Content-Type: multipart/alternative; boundary="94eb2c190e7e64d92b055db2b1c2"

--94eb2c190e7e64d92b055db2b1c2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi TLS,

It seems like encrypted SNI doesn't have any agenda time.  Now that the
Monday session is cancelled, would anyone like to meet in that slot to
discuss SNI encryption possibilities?

--Ben

On Sat, Nov 11, 2017 at 3:10 PM, Sean Turner  wrote:

> Based on the number of agenda requests we received, we=E2=80=99ve decided=
 to
> cancel Monday=E2=80=99s session.
>
> spt
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--94eb2c190e7e64d92b055db2b1c2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi TLS,

It seems like encrypted SNI doe=
sn't have any agenda time.=C2=A0 Now that the Monday session is cancell=
ed, would anyone like to meet in that slot to discuss SNI encryption possib=
ilities?

--Ben

On Sat, Nov 11, 2017 at 3:10 PM, Sean Tur=
ner <sean@sn3rd.com> wrote:
B=
ased on the number of agenda requests we received, we=E2=80=99ve decided to=
 cancel Monday=E2=80=99s session.



spt

_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--94eb2c190e7e64d92b055db2b1c2--

--94eb2c190e7e6ca4b4055db2b14c
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg
ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE
BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy
c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw
NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG
A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F
GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes
BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3
Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6
6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB
/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB
ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt
r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n
c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG
CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG
9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse
Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x
t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h
isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA
NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA
AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt
IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw
MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g
bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB
MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB
Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge
C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2
52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua
eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD
rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C
AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG
CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E
LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY
MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt
7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e
oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7
qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT
Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk
WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw
TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x
EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw
HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG
A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi
FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X
17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm
KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp
sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7
DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF
MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL
QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s
bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV
3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr
VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E
7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMEWk1v8tAoqKgb7TXMA0G
CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw
IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDcxNjE4MDA1N1oXDTE4MDEx
MjE4MDA1N1owIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDrrvmiOAZVIqT/TMjrb2h2F3pRDbwPjoYSzvDlNRXLUzcCg2CJ
l36iW3dmk3Uk0b5/75WIQYoQmadF45yr6fGoxDn9+Qu6hik36Cfrnb8Ch8pnX2jC4gYmE91pm30t
/WRb0Bfowu4grOB/zO0vDUZdjFxN/dji7A/mdsk7P5PGcnYxdpnjXSlPTEVxhmheji+DGiCJasrp
NNm4883FD4rFnanXYdnCq7Aku1rkA++G+fTQd+9HxlypxSnhExAit0HqOIyCgajEMb+xtkNCHjDH
FsOH9ruRqlSKc7FlOLvm2RALFx+U9AqWWx28lyEVhsdeFh6hpLEo+Ae8z8CJYs3zAgMBAAGjggFu
MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB
BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j
cnQwHQYDVR0OBBYEFBe3U8DtRm5koQ3yzeR81BIU+BjrMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz
IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v
d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j
cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l
BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQBRIW5hM7R7/1ED1m6w
QFXdOIBKubSej9FmVfD+f9Wv/6ak/8Fbk6ByRSzsScPGnkDT2U3MD20bGa+qp5BbEc3gFMi26AIo
7e/G5NlFY6ejl0qKt0xDqbTC+dBYocL/iEYEoAcr0ddFmnIm+tYzXSqSS9dLxPG/dlRo6OTLqtOm
9mExKPl/poRX59vajzNtGnR8gjHIKYCSsG9DdpYMxdQjbyLe71wv/ehtAUO5TcFQshSTtkqkL0y/
UJn76TjASXDDQE0Ndax1+xKdXaNBXFkhh7s/spJxkTrWAYIR+6Vs11eyRKxHo6yMHV+rN71AQm+P
dXTVU6D7/eZUZaWxeAc+MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv
YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMEWk1v8tA
oqKgb7TXMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCA+6HNb+ma7NJJlTiRDkEet
uDjMWlACl5kN9u1RuFvghjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNzExMTExMDQyMjVaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB
FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg
hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAiVoywgQxPjQgdxAd1dA7rgGPY3lBd0zFI0Ll79dx
MraVBfVbLY7LPm2DA1YbWQoPI2GUXuHZpqt805F4vqF0fU0NGeLijTJd7J7gx+aRM9c+soTlcpv2
PKw5UdHRnuKYbMq2anv7CrzGSpavoSTVMG30VozQPhKHpUCM10WW6guGhJzd/tU5yFm834yaBH7R
8/lowY+M44m354zBQtxECFReBg85FBLtx/mmw1WCHYiipEmBDEYsRoBRXXkkOHHBQye6zJxPRYbQ
PXiL5YPI2Vzg0J+LKknYU5HNU/26mAs1/Yh/UkqS/sArmNYaUsnlWOzKvNxyJE1nQiPBu4t95Q==
--94eb2c190e7e6ca4b4055db2b14c--


From nobody Sat Nov 11 07:18:25 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3065B129A99 for ; Sat, 11 Nov 2017 07:18:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 1BvqPfn5nJpC for ; Sat, 11 Nov 2017 07:18:21 -0800 (PST)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 7F8EF1298BA for ; Sat, 11 Nov 2017 07:18:21 -0800 (PST)
Received: by mail-oi0-x230.google.com with SMTP id q4so8687730oic.7 for ; Sat, 11 Nov 2017 07:18:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=AZwAslj/2QK1osKIWzVDenmoHFDb07+sFj+Kj6qlnBg=; b=mBKKQBhT39/Lpse4LGgjw8n8jqgN/xJ0rigX4JqLuUx/Bj6BbJpxsrn822l27vwCWL 5aVOUe2vQPw7FoMrXvXsn8rg5nS95KYZZM6L8zF0RY6hF5hFOGe8kuQ9aaljLgGvrIXD 51evF1qP6s8mDICBpe/7JGP1onRkAqweQv3r7ZVFT4lOhmKR3qQlFBez8Wmk10ojg7LR qVAk5Ro/3YphHqNjW1zb9gJeJVfalewL5d/ntUWxQXIOsYcI8u5MzjUDvdunvBOxSQ+e skoHLp6WOYP980b7XMuL+J41hcRRaEa3hpXBnIWeKkVwzFwmE6U3ZEKNIa8Z7p2Er+c3 MX4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=AZwAslj/2QK1osKIWzVDenmoHFDb07+sFj+Kj6qlnBg=; b=lTkG8FBcvbc8RYQET+MW3Gdm/p/+sGUDaoui6niHCd7RkhcTcUIpC47UxznAlmZ9pE UpDxqlY7EL/LD01t4kZUAAkOwGLiqVeB1gtlbebQIwUne9laYsvxNimTYreBs4ig7LPZ /EkrVPdmOWLCBivG6zjny4AK4DEFgzM872GwQ0h4kCg5hj+0Zleq+DxDU0tufstNATjy Ft8dKthNpPicPRHeChannYR3MHIJefSQ79K4eii86s71WcUqFQgsD/Kkhb/Cl2kvYTFO lDL96PDz1X00zfylui6o0eHNRC5jW3ksEVb0iKds+8CB11BD+DjQEzZJcPwN8ImR4wRo 2NCA==
X-Gm-Message-State: AJaThX5PtUb08f/u5rww0cPz5a+ZHQv2+sVRxYnVdvx8+jbdphCHNpON EAqpzE6m0L2ZZ0dHDHSfktbc7t5UsmxpfqGlIzklKA==
X-Google-Smtp-Source: AGs4zMbgvIiA4/fkXVfXxkNsPfGAc3hYylxvDkCGvkAvwnW31bqrNB/uMSx2sORlPpqnWKcTkEdgQCGx+AKxV4nCegw=
X-Received: by 10.202.225.130 with SMTP id y124mr2192138oig.88.1510413500787;  Sat, 11 Nov 2017 07:18:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.8.11 with HTTP; Sat, 11 Nov 2017 07:18:20 -0800 (PST)
In-Reply-To: 
References: 
From: Martin Thomson 
Date: Sat, 11 Nov 2017 23:18:20 +0800
Message-ID: 
To: David Schinazi 
Cc: "tls@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [TLS] close_notify and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Nov 2017 15:18:23 -0000

This seems like it might be worth looking at.  This seems to be
something that harks back to SSL3 or even earlier.  We aren't going to
make it so that you can rely on this behaviour, but we might be able
to make it possible to half-close, which for new protocols using TLS
could be hugely useful.

On Sat, Nov 11, 2017 at 5:21 PM, David Schinazi  wrote=
:
> Hello all,
>
> Currently TLS 1.3 specifies close_notify in the same way that TLS 1.2 did=
.
> I believe that has issues and this might be the right time to fix them.
> The purpose of close_notify is to protect against data truncation attacks=
,
> each side is required to send close_notify before closing the write side =
of
> the transport connection so the other side knows that the data was not
> truncated.
> As such, close_notify only needs half-close semantics to prevent truncati=
on.
>
> However, the specification contains the following text:
> << Each party MUST send a =E2=80=9Cclose_notify=E2=80=9D alert before clo=
sing the write side
>     of the connection, unless some other fatal alert has been transmitted=
.
>     The other party MUST respond with a =E2=80=9Cclose_notify=E2=80=9D al=
ert of its own and
> close
>     down the connection immediately, discarding any pending writes. >>
>
> This means that an application-layer client can't send a query then close
> their
> write transport when they know that they're done, because the server woul=
d
> terminate the TLS session before sending the reply. On top of this, when
> the server receives the close_notify, it may have already sent part of th=
e
> reply
> (or wrote it to the socket send buffer) so the responding close_notify wo=
uld
> in effect be inflicting a truncation attack on the client.
>
> This doesn't make much difference for HTTP because clients already
> don't close their write transport after sending a reply, however having t=
he
> option do do this could allow innovation in new protocols that can define
> the semantics of when they use close_notify. An example is DNS PUSH:
> https://tools.ietf.org/html/draft-ietf-dnssd-push
>
> A proposal to solve this problem would be to give close_notify half-close
> semantics: we keep the requirements that a close_notify be sent before
> closing the transport, and that any data received after a close_notify is
> ignored, but we simply remove the requirement to immediately reply
> with a close_notify. This has the advantage that current implementations
> are already compliant but future ones can leverage this improvement.
>
> What do you think? Is this worth discussing on Thursday?
>
> Thanks,
> David Schinazi
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


From nobody Sat Nov 11 15:46:25 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F12A1293E1 for ; Sat, 11 Nov 2017 15:46:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 myrrUm2UHVLT for ; Sat, 11 Nov 2017 15:46:22 -0800 (PST)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 2A62B1293DF for ; Sat, 11 Nov 2017 15:46:21 -0800 (PST)
Received: by mail-qk0-x22a.google.com with SMTP id v137so15976267qkb.1 for ; Sat, 11 Nov 2017 15:46:21 -0800 (PST)
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 :cc; bh=AsQgNd5jMRuFE1gGzWKGz4aPQrbJAYMjX4DaToQ5sRk=; b=fP+f1oXl/4BoS28I67hrTIuHD1r9q/hDaPQXXA1ktfFB3ezbCqP8H7i20F1zHQvm99 14ndhGYF2alUXjKLDgmG7Gpili686qeG+mvX9WHwqX504rGjEqb/E+w2VCzOiN6t31k5 HVb5JfdOyBp6YH5VSb/9h+a5MbDtpT9sPZ/Xo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AsQgNd5jMRuFE1gGzWKGz4aPQrbJAYMjX4DaToQ5sRk=; b=kHhthEwKX+u/jz5KBwpJNXG500iu3eApEiExSOHJBnzsSou0kKR5k3h/Cftn2R1j8E Cmp/QAJ2D+nTfzs/KMbRmDWFgEPmV8uqRaowHrjdWETFLrs2Lz4BUODkcJLBAxSUUR/G gjegjnswgdpcBuW8p4k4/n/ttO8H3gI8z6l8jclWP6vM8fr4Xvg77osvabT7EmqHRtUv 8ukBblM1BKPFAjueJYpUXHvSp7uT7ZaO8lDoq3jT8vqR1kkJiVwm4fa9FAAFGgfX0JFQ 27xB2cSJMwf/H61TsqF/OsjM+g5WLFZRDBe8BycyjZY0t5MJwdPkCSMZ9A7Om1O8Yr45 gguQ==
X-Gm-Message-State: AJaThX6iRpbPqbUEQoJp18CiX92Kxu3Qgw7iEZT0Sn+4n9pivnnYD/e+ nkkuweNflQV19Bz2YSi/RLv3yllANh+ek23HD2Rc
X-Google-Smtp-Source: AGs4zMYb7ZpQI60+ea1d0rSwVNTrHFsqbIkikDyXGShiwG2dObnmgZlfZ+/XDjB+EtcC46kxi9GMyLwZtXmVyLZ6UxE=
X-Received: by 10.55.3.130 with SMTP id 124mr4154147qkd.197.1510443980925; Sat, 11 Nov 2017 15:46:20 -0800 (PST)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: David Benjamin 
Date: Sat, 11 Nov 2017 23:46:08 +0000
Message-ID: 
To: Martin Thomson 
Cc: David Schinazi , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114c96e4f05733055dbda48b"
Archived-At: 
Subject: Re: [TLS] close_notify and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 11 Nov 2017 23:46:24 -0000

--001a114c96e4f05733055dbda48b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I think this change is a good idea.

Our implementation actually does this already anyway. We are happy to
continue servicing writes even when the read half has consumed a
close_notify. I believe we inherited this behavior from OpenSSL, so it
should be there too. Go's crypto/tls implementation appears to also already
do this.

We don't have a particular need for the half-close semantics that I know
of, but I don't care for the current spec text (it requires yet another
undesirable read/write sync point). Aligning with TCP's semantics is also
generally a good default.

On Sat, Nov 11, 2017 at 11:18 PM Martin Thomson 
wrote:

> This seems like it might be worth looking at.  This seems to be
> something that harks back to SSL3 or even earlier.  We aren't going to
> make it so that you can rely on this behaviour, but we might be able
> to make it possible to half-close, which for new protocols using TLS
> could be hugely useful.
>
> On Sat, Nov 11, 2017 at 5:21 PM, David Schinazi 
> wrote:
> > Hello all,
> >
> > Currently TLS 1.3 specifies close_notify in the same way that TLS 1.2
> did.
> > I believe that has issues and this might be the right time to fix them.
> > The purpose of close_notify is to protect against data truncation
> attacks,
> > each side is required to send close_notify before closing the write sid=
e
> of
> > the transport connection so the other side knows that the data was not
> > truncated.
> > As such, close_notify only needs half-close semantics to prevent
> truncation.
> >
> > However, the specification contains the following text:
> > << Each party MUST send a =E2=80=9Cclose_notify=E2=80=9D alert before c=
losing the write
> side
> >     of the connection, unless some other fatal alert has been
> transmitted.
> >     The other party MUST respond with a =E2=80=9Cclose_notify=E2=80=9D =
alert of its own
> and
> > close
> >     down the connection immediately, discarding any pending writes. >>
> >
> > This means that an application-layer client can't send a query then clo=
se
> > their
> > write transport when they know that they're done, because the server
> would
> > terminate the TLS session before sending the reply. On top of this, whe=
n
> > the server receives the close_notify, it may have already sent part of
> the
> > reply
> > (or wrote it to the socket send buffer) so the responding close_notify
> would
> > in effect be inflicting a truncation attack on the client.
> >
> > This doesn't make much difference for HTTP because clients already
> > don't close their write transport after sending a reply, however having
> the
> > option do do this could allow innovation in new protocols that can defi=
ne
> > the semantics of when they use close_notify. An example is DNS PUSH:
> > https://tools.ietf.org/html/draft-ietf-dnssd-push
> >
> > A proposal to solve this problem would be to give close_notify half-clo=
se
> > semantics: we keep the requirements that a close_notify be sent before
> > closing the transport, and that any data received after a close_notify =
is
> > ignored, but we simply remove the requirement to immediately reply
> > with a close_notify. This has the advantage that current implementation=
s
> > are already compliant but future ones can leverage this improvement.
> >
> > What do you think? Is this worth discussing on Thursday?
> >
> > Thanks,
> > David Schinazi
> >
> > _______________________________________________
> > 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
>

--001a114c96e4f05733055dbda48b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I think this change is a good idea.

Our implementation actually does this already anyway. We are happy =
to continue servicing writes even when the read half has consumed a close_n=
otify. I believe we inherited this behavior from OpenSSL, so it should be t=
here too. Go's crypto/tls implementation appears to also already do thi=
s.

We don't have a particular need for the=
 half-close semantics that I know of, but I don't care for the current =
spec text (it requires yet another undesirable read/write sync point). Alig=
ning with TCP's semantics is also generally a good default.
<=
br>
On Sat, Nov 11, 2017 at 11:18 PM Martin Thomson <<=
a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson=
@gmail.com> wrote:
This see=
ms like it might be worth looking at.=C2=A0 This seems to be

something that harks back to SSL3 or even earlier.=C2=A0 We aren't goin=
g to

make it so that you can rely on this behaviour, but we might be able

to make it possible to half-close, which for new protocols using TLS

could be hugely useful.



On Sat, Nov 11, 2017 at 5:21 PM, David Schinazi <dschinazi@apple.com> wrote:

> Hello all,

>

> Currently TLS 1.3 specifies close_notify in the same way that TLS 1.2 =
did.

> I believe that has issues and this might be the right time to fix them=
.

> The purpose of close_notify is to protect against data truncation atta=
cks,

> each side is required to send close_notify before closing the write si=
de of

> the transport connection so the other side knows that the data was not=


> truncated.

> As such, close_notify only needs half-close semantics to prevent trunc=
ation.

>

> However, the specification contains the following text:

> << Each party MUST send a =E2=80=9Cclose_notify=E2=80=9D alert b=
efore closing the write side

>=C2=A0 =C2=A0 =C2=A0of the connection, unless some other fatal alert ha=
s been transmitted.

>=C2=A0 =C2=A0 =C2=A0The other party MUST respond with a =E2=80=9Cclose_=
notify=E2=80=9D alert of its own and

> close

>=C2=A0 =C2=A0 =C2=A0down the connection immediately, discarding any pen=
ding writes. >>

>

> This means that an application-layer client can't send a query the=
n close

> their

> write transport when they know that they're done, because the serv=
er would

> terminate the TLS session before sending the reply. On top of this, wh=
en

> the server receives the close_notify, it may have already sent part of=
 the

> reply

> (or wrote it to the socket send buffer) so the responding close_notify=
 would

> in effect be inflicting a truncation attack on the client.

>

> This doesn't make much difference for HTTP because clients already=


> don't close their write transport after sending a reply, however h=
aving the

> option do do this could allow innovation in new protocols that can def=
ine

> the semantics of when they use close_notify. An example is DNS PUSH:
> https://tools.ietf.org/html/draft-ietf-dnssd-p=
ush

>

> A proposal to solve this problem would be to give close_notify half-cl=
ose

> semantics: we keep the requirements that a close_notify be sent before=


> closing the transport, and that any data received after a close_notify=
 is

> ignored, but we simply remove the requirement to immediately reply

> with a close_notify. This has the advantage that current implementatio=
ns

> are already compliant but future ones can leverage this improvement.
>

> What do you think? Is this worth discussing on Thursday?

>

> Thanks,

> David Schinazi

>

> _______________________________________________

> 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




--001a114c96e4f05733055dbda48b--


From nobody Sat Nov 11 17:13:59 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BE8127076 for ; Sat, 11 Nov 2017 17:13:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 uY-NTQkt4HRr for ; Sat, 11 Nov 2017 17:13:55 -0800 (PST)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 6FA751252BA for ; Sat, 11 Nov 2017 17:13:55 -0800 (PST)
Received: by mail-yw0-x229.google.com with SMTP id y75so10965324ywg.0 for ; Sat, 11 Nov 2017 17:13:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IhMBGGdforyhqeYhxNlhLpUQMVqiN5BAXV5rq9YFLxA=; b=BgpjIO5eS1exB7/sMRr5BAMoP8EkCpfGzz71uJMD8IjWXgUy+coRepn5fwA8nA8acs tHEr+rDL9cOpX8/CJl8vWgZJXgPgdjPu3pvMSAdNpW47WFLoWALw2hB2FtcQwNWRlAbw rUJNk95nFjUhCnZG5qNpOAJMjujv7BrHwu3Ra0Glq+nYVfUsioeMr4yViQ5x4GapQMZX Sw/kPABiIRnINXiu9eZQaB9/C5B3RlYBR7Xn4qUiZZXhkrMM94hXYiryvfIM5sU0M2yU sxvUrSQPJ1Ob4eo1bMYvTM1bhZYTqt6coIshmY57ggyfV8T+DF1FtzhIn4ZebFna/s25 dBag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IhMBGGdforyhqeYhxNlhLpUQMVqiN5BAXV5rq9YFLxA=; b=sJYCs4VW/xiPe2HKzATEKAKc5I7qI/ztIK8L66/NgA++iYZH3X3oIJHBH9hNLN+188 lisF58Aju16LLWHQxHIi55wdzcl6tHoUSkBsMQApVZN2phuAdjK2TFU8e+RM9az8KVwa w5R4fEK2rz7OX6+3nA8eg9Rh1DLrIZuwh/q6HRlZx5j+bznMImdletFUcd9bibU1IVTo TyIovD8p8URiIqOF4v6+oUm3lG8M2o4BUkSWub073Ql3jWBO0D4ZnjzNfrUwyjGDcEP3 qv8KayU3kDk4R/mmEMBhai6Fuw8U6TH2Oj4qnrhN5Nsm1gLr1CVmqXBgBgRdLZiy51wD luug==
X-Gm-Message-State: AJaThX6oJmA77uOhPCqsxzSx3QLTbcVD5MtD+RV7LveRSPC2vWA2Ax2M GBdfUTIbMTehY4LhO+vKsW3LVYqwKWiMlKwakK5umw==
X-Google-Smtp-Source: AGs4zMZV7E+l4YR7bGZpYgotIcBJBSsFc/CoKIMvCca6TyEGWrlFad+5+R7HDd+ErfW4P3Sa8vzIkSRN8mZK7kvuKjQ=
X-Received: by 10.13.192.196 with SMTP id b187mr3417336ywd.416.1510449234641;  Sat, 11 Nov 2017 17:13:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.61.12 with HTTP; Sat, 11 Nov 2017 17:13:14 -0800 (PST)
In-Reply-To: 
References:   
From: Eric Rescorla 
Date: Sat, 11 Nov 2017 17:13:14 -0800
Message-ID: 
To: David Benjamin 
Cc: Martin Thomson , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114edd48151fce055dbeded0"
Archived-At: 
Subject: Re: [TLS] close_notify and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Nov 2017 01:13:58 -0000

--001a114edd48151fce055dbeded0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Initial inspection suggests that NSS behaves the same way, so I would be
fine with this change.

-Ekr


On Sat, Nov 11, 2017 at 3:46 PM, David Benjamin 
wrote:

> I think this change is a good idea.
>
> Our implementation actually does this already anyway. We are happy to
> continue servicing writes even when the read half has consumed a
> close_notify. I believe we inherited this behavior from OpenSSL, so it
> should be there too. Go's crypto/tls implementation appears to also alrea=
dy
> do this.
>
> We don't have a particular need for the half-close semantics that I know
> of, but I don't care for the current spec text (it requires yet another
> undesirable read/write sync point). Aligning with TCP's semantics is also
> generally a good default.
>
> On Sat, Nov 11, 2017 at 11:18 PM Martin Thomson 
> wrote:
>
>> This seems like it might be worth looking at.  This seems to be
>> something that harks back to SSL3 or even earlier.  We aren't going to
>> make it so that you can rely on this behaviour, but we might be able
>> to make it possible to half-close, which for new protocols using TLS
>> could be hugely useful.
>>
>> On Sat, Nov 11, 2017 at 5:21 PM, David Schinazi 
>> wrote:
>> > Hello all,
>> >
>> > Currently TLS 1.3 specifies close_notify in the same way that TLS 1.2
>> did.
>> > I believe that has issues and this might be the right time to fix them=
.
>> > The purpose of close_notify is to protect against data truncation
>> attacks,
>> > each side is required to send close_notify before closing the write
>> side of
>> > the transport connection so the other side knows that the data was not
>> > truncated.
>> > As such, close_notify only needs half-close semantics to prevent
>> truncation.
>> >
>> > However, the specification contains the following text:
>> > << Each party MUST send a =E2=80=9Cclose_notify=E2=80=9D alert before =
closing the write
>> side
>> >     of the connection, unless some other fatal alert has been
>> transmitted.
>> >     The other party MUST respond with a =E2=80=9Cclose_notify=E2=80=9D=
 alert of its own
>> and
>> > close
>> >     down the connection immediately, discarding any pending writes. >>
>> >
>> > This means that an application-layer client can't send a query then
>> close
>> > their
>> > write transport when they know that they're done, because the server
>> would
>> > terminate the TLS session before sending the reply. On top of this, wh=
en
>> > the server receives the close_notify, it may have already sent part of
>> the
>> > reply
>> > (or wrote it to the socket send buffer) so the responding close_notify
>> would
>> > in effect be inflicting a truncation attack on the client.
>> >
>> > This doesn't make much difference for HTTP because clients already
>> > don't close their write transport after sending a reply, however havin=
g
>> the
>> > option do do this could allow innovation in new protocols that can
>> define
>> > the semantics of when they use close_notify. An example is DNS PUSH:
>> > https://tools.ietf.org/html/draft-ietf-dnssd-push
>> >
>> > A proposal to solve this problem would be to give close_notify
>> half-close
>> > semantics: we keep the requirements that a close_notify be sent before
>> > closing the transport, and that any data received after a close_notify
>> is
>> > ignored, but we simply remove the requirement to immediately reply
>> > with a close_notify. This has the advantage that current implementatio=
ns
>> > are already compliant but future ones can leverage this improvement.
>> >
>> > What do you think? Is this worth discussing on Thursday?
>> >
>> > Thanks,
>> > David Schinazi
>> >
>> > _______________________________________________
>> > 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
>>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--001a114edd48151fce055dbeded0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Initial inspection suggests that NSS behaves the same way,=
 so I would be fine with this change.

-Ekr

On S=
at, Nov 11, 2017 at 3:46 PM, David Benjamin <davidben@chromium.org> wrote:
I think this change is a good idea.

Our implemen=
tation actually does this already anyway. We are happy to continue servicin=
g writes even when the read half has consumed a close_notify. I believe we =
inherited this behavior from OpenSSL, so it should be there too. Go's c=
rypto/tls implementation appears to also already do this.
We don't have a particular need for the half-close semantic=
s that I know of, but I don't care for the current spec text (it requir=
es yet another undesirable read/write sync point). Aligning with TCP's =
semantics is also generally a good default.

This s=
eems like it might be worth looking at.=C2=A0 This seems to be

something that harks back to SSL3 or even earlier.=C2=A0 We aren't goin=
g to

make it so that you can rely on this behaviour, but we might be able

to make it possible to half-close, which for new protocols using TLS

could be hugely useful.



On Sat, Nov 11, 2017 at 5:21 PM, David Schinazi <dschinazi@apple.com> wrote:

> Hello all,

>

> Currently TLS 1.3 specifies close_notify in the same way that TLS 1.2 =
did.

> I believe that has issues and this might be the right time to fix them=
.

> The purpose of close_notify is to protect against data truncation atta=
cks,

> each side is required to send close_notify before closing the write si=
de of

> the transport connection so the other side knows that the data was not=


> truncated.

> As such, close_notify only needs half-close semantics to prevent trunc=
ation.

>

> However, the specification contains the following text:

> << Each party MUST send a =E2=80=9Cclose_notify=E2=80=9D alert b=
efore closing the write side

>=C2=A0 =C2=A0 =C2=A0of the connection, unless some other fatal alert ha=
s been transmitted.

>=C2=A0 =C2=A0 =C2=A0The other party MUST respond with a =E2=80=9Cclose_=
notify=E2=80=9D alert of its own and

> close

>=C2=A0 =C2=A0 =C2=A0down the connection immediately, discarding any pen=
ding writes. >>

>

> This means that an application-layer client can't send a query the=
n close

> their

> write transport when they know that they're done, because the serv=
er would

> terminate the TLS session before sending the reply. On top of this, wh=
en

> the server receives the close_notify, it may have already sent part of=
 the

> reply

> (or wrote it to the socket send buffer) so the responding close_notify=
 would

> in effect be inflicting a truncation attack on the client.

>

> This doesn't make much difference for HTTP because clients already=


> don't close their write transport after sending a reply, however h=
aving the

> option do do this could allow innovation in new protocols that can def=
ine

> the semantics of when they use close_notify. An example is DNS PUSH:
> https://tools.ietf.org/html/draft-ietf-dn=
ssd-push

>

> A proposal to solve this problem would be to give close_notify half-cl=
ose

> semantics: we keep the requirements that a close_notify be sent before=


> closing the transport, and that any data received after a close_notify=
 is

> ignored, but we simply remove the requirement to immediately reply

> with a close_notify. This has the advantage that current implementatio=
ns

> are already compliant but future ones can leverage this improvement.
>

> What do you think? Is this worth discussing on Thursday?

>

> Thanks,

> David Schinazi

>

> _______________________________________________

> 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




_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--001a114edd48151fce055dbeded0--


From nobody Sat Nov 11 17:24:35 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF73128B88 for ; Sat, 11 Nov 2017 17:24:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 5vgDBUudCzo4 for ; Sat, 11 Nov 2017 17:24:31 -0800 (PST)
Received: from mail-in2.asia.apple.com (mail-out.asia.apple.com [17.82.254.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57AD51271FD for ; Sat, 11 Nov 2017 17:24:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1510449868; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1nki0P2+WRoNM4+JcahB//+mpYswXb4SFMZZKxkMJyI=; b=D1ypzUZLqVVQc1WX9NHlRrqZ4i7yoLXeowRWnaQ1nri+iYkqywq2XFYC6xP92auV S1nUo2NwXfRpapFUID6uKkwP8nfOI4FHo6NmPRnwU8v3lJRhgwobYgPOKScojhhh 01HdWsAD9LbtMLWSFRCoHI7N+elQOHHqFjEt/caVVMJWpX6Eeo0w5ZFawh2GGJ3k OgQRS1xholjoOH9M0ipQ90kreW5e48zE5Bs4dkIItTRIi7F2fS+oPjqBAGJ4jKhJ AqYyCGyBogLH1dkf2ZFbI+e2RwqnhGzRdM4cDudLXlnv5bKqqiJPBv7D2H4LRnBw s999Kz1JHFcftikd27yeQw==;
Received: from relay2.asia.apple.com ( [17.82.200.16]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id 91.20.05091.CC2A70A5; Sun, 12 Nov 2017 09:24:28 +0800 (MYT)
X-AuditID: 1152fe06-5e5ff700000013e3-50-5a07a2cc7810
Received: from mmp3.asia.apple.com ( [17.84.76.250]) by relay2.asia.apple.com (Apple Singapore relay) with SMTP id 39.60.31851.CC2A70A5; Sun, 12 Nov 2017 09:24:28 +0800 (MYT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_G0vADIm6elDlz6QiWbIMQw)"
Received: from [IPv6:2001:67c:370:1998:e0f4:6d59:e5c5:47fd] (nat64-46.meeting.ietf.org [31.130.238.70]) by mmp3.asia.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OZA00EGZ6KRJE20@mmp3.asia.apple.com>; Sun, 12 Nov 2017 09:24:28 +0800 (SGT)
Sender: dschinazi@apple.com
From: David Schinazi 
Message-id: 
Date: Sun, 12 Nov 2017 09:24:28 +0800
In-reply-to: 
Cc: David Benjamin , "tls@ietf.org" 
To: Eric Rescorla 
References:    
X-Mailer: Apple Mail (2.3445.1.6)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUiGHRCQPfMIvYog0MzDC12fzW1WPH6HLvF p/NdjA7MHrMbLrJ4LFnyk8lj8uM25gDmKC6blNSczLLUIn27BK6Ms6evsxScyajo+qfbwPgm oouRk0NCwERi7/0Wpi5GLg4hgZVMEnvbD7HBJL6eucgIkdjAKPH6WxMjSIJXQFDix+R7LCA2 s0CYxKlvd6CKdjFJfP73AaxbWEBaouvCXdYuRg4ONgEtiQNrjCB6bSQ2v3vKDlGiLbG+6SUT SAmLgKrEl39g4zkFgiVW/1nBBjHeU+Lbq01MILaIgILErz8nWCBWTWSSuP5gGzPEoYoSR2bO YQZJSAisYZM4POEc6wRGoVlIbp2F5NZZQPuYBdQlpkzJhQhrSzx5d4EVwlaTWPh7EROy+AJG tlWM4rmJmTm6mXlGeonFmYl6iQUFOal6yfm5mxjBUfKPbQfjgteGhxgFOBiVeHhPTGGPEmJN LCuuzD3EKMHBrCTCWyIEFOJNSaysSi3Kjy8qzUktPsQozcGiJM7bG/kpUkggPbEkNTs1tSC1 CCbLxMEp1cC4+9J6PYGjlzg27Ak/0e9uMMOD5W3CmyO3bZ4/vPtG7uO81l8SPcm6quuSYkW8 drbduPPP7PgG0QKD1uYlXw1mKzoZnQxvb0hfnKill2svcNza06p85W/16vIv8hOL3S7fZ2ER XMKzsrEnvVyi48/6Iwd0Dz77eIdJ7mi5JlPOmRaeWU05hf5KLMUZiYZazEXFiQB26Z0LjgIA AA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUiGOLzS/fMIvYog7cbNCx2fzW1WPH6HLvF p/NdjA7MHrMbLrJ4LFnyk8lj8uM25gDmKC6blNSczLLUIn27BK6Ms6evsxScyajo+qfbwPgm oouRk0NCwETi65mLjF2MXBxCAhsYJV5/a2IESfAKCEr8mHyPBcRmFgiTOPXtDlTRLiaJz/8+ sIEkhAWkJbou3GXtYuTgYBPQkjiwxgii10Zi87un7BAl2hLrm14ygZSwCKhKfPkHNp5TIFhi 9Z8VbBDjPSW+vdrEBGKLCChI/PpzggVi1UQmiesPtjFDHKoocWTmHOYJjPyzkJw3C8l5s4BW MAuoS0yZkgsR1pZ48u4CK4StJrHw9yImZPEFjGyrGEWLUnMSK430EoszE/USCwpyUvWS83M3 MYKCOuiEwA7GWYcMDjEKcDAq8fCemMIeJcSaWFZcmXuIUYKDWUmEt0QIKMSbklhZlVqUH19U mpNafIhRmoNFSZxXM+pTpJBAemJJanZqakFqEUyWiYNTqoHRe1njx7RrCwOtytRmSJ3eObNu 8om0Vkul7UWXrzaVbwvwaZQXX7X736mtSg859GeuKwxmmDtx72LmV1ML1F96Hf3M/q9C5XJU 6u+Q2Xmc1T4CBxO9IoR4wne/YDj5k1Pv5qFbmy6HKh9Q29xruzytRaG4Kv9Dz5TafadD9kWJ x5yUbrg9//ZsJZbijERDLeai4kQAgTzWqWYCAAA=
Archived-At: 
Subject: Re: [TLS] close_notify and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Nov 2017 01:24:34 -0000

--Boundary_(ID_G0vADIm6elDlz6QiWbIMQw)
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: quoted-printable

Thanks for checking gents!

Would you like me to send a PR?

David


> On Nov 12, 2017, at 09:13, Eric Rescorla  wrote:
>=20
> Initial inspection suggests that NSS behaves the same way, so I would =
be fine with this change.
>=20
> -Ekr
>=20
>=20
> On Sat, Nov 11, 2017 at 3:46 PM, David Benjamin > wrote:
> I think this change is a good idea.
>=20
> Our implementation actually does this already anyway. We are happy to =
continue servicing writes even when the read half has consumed a =
close_notify. I believe we inherited this behavior from OpenSSL, so it =
should be there too. Go's crypto/tls implementation appears to also =
already do this.
>=20
> We don't have a particular need for the half-close semantics that I =
know of, but I don't care for the current spec text (it requires yet =
another undesirable read/write sync point). Aligning with TCP's =
semantics is also generally a good default.
>=20
> On Sat, Nov 11, 2017 at 11:18 PM Martin Thomson =
> wrote:
> This seems like it might be worth looking at.  This seems to be
> something that harks back to SSL3 or even earlier.  We aren't going to
> make it so that you can rely on this behaviour, but we might be able
> to make it possible to half-close, which for new protocols using TLS
> could be hugely useful.
>=20
> On Sat, Nov 11, 2017 at 5:21 PM, David Schinazi > wrote:
> > Hello all,
> >
> > Currently TLS 1.3 specifies close_notify in the same way that TLS =
1.2 did.
> > I believe that has issues and this might be the right time to fix =
them.
> > The purpose of close_notify is to protect against data truncation =
attacks,
> > each side is required to send close_notify before closing the write =
side of
> > the transport connection so the other side knows that the data was =
not
> > truncated.
> > As such, close_notify only needs half-close semantics to prevent =
truncation.
> >
> > However, the specification contains the following text:
> > << Each party MUST send a =E2=80=9Cclose_notify=E2=80=9D alert =
before closing the write side
> >     of the connection, unless some other fatal alert has been =
transmitted.
> >     The other party MUST respond with a =E2=80=9Cclose_notify=E2=80=9D=
 alert of its own and
> > close
> >     down the connection immediately, discarding any pending writes. =
>>
> >
> > This means that an application-layer client can't send a query then =
close
> > their
> > write transport when they know that they're done, because the server =
would
> > terminate the TLS session before sending the reply. On top of this, =
when
> > the server receives the close_notify, it may have already sent part =
of the
> > reply
> > (or wrote it to the socket send buffer) so the responding =
close_notify would
> > in effect be inflicting a truncation attack on the client.
> >
> > This doesn't make much difference for HTTP because clients already
> > don't close their write transport after sending a reply, however =
having the
> > option do do this could allow innovation in new protocols that can =
define
> > the semantics of when they use close_notify. An example is DNS PUSH:
> > https://tools.ietf.org/html/draft-ietf-dnssd-push =

> >
> > A proposal to solve this problem would be to give close_notify =
half-close
> > semantics: we keep the requirements that a close_notify be sent =
before
> > closing the transport, and that any data received after a =
close_notify is
> > ignored, but we simply remove the requirement to immediately reply
> > with a close_notify. This has the advantage that current =
implementations
> > are already compliant but future ones can leverage this improvement.
> >
> > What do you think? Is this worth discussing on Thursday?
> >
> > Thanks,
> > David Schinazi
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org 
> > https://www.ietf.org/mailman/listinfo/tls =

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

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

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


--Boundary_(ID_G0vADIm6elDlz6QiWbIMQw)
Content-type: text/html; charset=utf-8
Content-transfer-encoding: quoted-printable

Thanks for checking gents!

Would you like me to send a =
PR?

David


On Nov =
12, 2017, at 09:13, Eric Rescorla <ekr@rtfm.com> wrote:

Initial inspection suggests that NSS behaves the same way, so =
I would be fine with this change.

-Ekr


On Sat, =
Nov 11, 2017 at 3:46 PM, David Benjamin <davidben@chromium.org> wrote:
I think this change is a good idea.

Our implementation =
actually does this already anyway. We are happy to continue servicing =
writes even when the read half has consumed a close_notify. I believe we =
inherited this behavior from OpenSSL, so it should be there too. Go's =
crypto/tls implementation appears to also already do this.

We =
don't have a particular need for the half-close semantics that I know =
of, but I don't care for the current spec text (it requires yet another =
undesirable read/write sync point). Aligning with TCP's semantics is =
also generally a good default.

On Sat, Nov 11, 2017 =
at 11:18 PM Martin Thomson <martin.thomson@gmail.com> wrote:
This seems like it =
might be worth looking at.  This seems to be

something that harks back to SSL3 or even earlier.  We aren't going =
to

make it so that you can rely on this behaviour, but we might be able

to make it possible to half-close, which for new protocols using TLS

could be hugely useful.



On Sat, Nov 11, 2017 at 5:21 PM, David Schinazi <dschinazi@apple.com> wrote:

> Hello all,

>

> Currently TLS 1.3 specifies close_notify in the same way that TLS =
1.2 did.

> I believe that has issues and this might be the right time to fix =
them.

> The purpose of close_notify is to protect against data truncation =
attacks,

> each side is required to send close_notify before closing the write =
side of

> the transport connection so the other side knows that the data was =
not

> truncated.

> As such, close_notify only needs half-close semantics to prevent =
truncation.

>

> However, the specification contains the following text:

> << Each party MUST send a =E2=80=9Cclose_notify=E2=80=9D =
alert before closing the write side

>     of the connection, unless some other fatal alert =
has been transmitted.

>     The other party MUST respond with a =
=E2=80=9Cclose_notify=E2=80=9D alert of its own and

> close

>     down the connection immediately, discarding any =
pending writes. >>

>

> This means that an application-layer client can't send a query then =
close

> their

> write transport when they know that they're done, because the =
server would

> terminate the TLS session before sending the reply. On top of this, =
when

> the server receives the close_notify, it may have already sent part =
of the

> reply

> (or wrote it to the socket send buffer) so the responding =
close_notify would

> in effect be inflicting a truncation attack on the client.

>

> This doesn't make much difference for HTTP because clients =
already

> don't close their write transport after sending a reply, however =
having the

> option do do this could allow innovation in new protocols that can =
define

> the semantics of when they use close_notify. An example is DNS =
PUSH:

> https://tools.ietf.org/html/draft-ietf-dnssd-push

>

> A proposal to solve this problem would be to give close_notify =
half-close

> semantics: we keep the requirements that a close_notify be sent =
before

> closing the transport, and that any data received after a =
close_notify is

> ignored, but we simply remove the requirement to immediately =
reply

> with a close_notify. This has the advantage that current =
implementations

> are already compliant but future ones can leverage this =
improvement.

>

> What do you think? Is this worth discussing on Thursday?

>

> Thanks,

> David Schinazi

>

> _______________________________________________

> 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




_______________________________________________

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

=

--Boundary_(ID_G0vADIm6elDlz6QiWbIMQw)--


From nobody Sat Nov 11 17:29:52 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3C9129415 for ; Sat, 11 Nov 2017 17:29:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 XjZA0u4YKBQI for ; Sat, 11 Nov 2017 17:29:45 -0800 (PST)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 99DB7128D16 for ; Sat, 11 Nov 2017 17:29:45 -0800 (PST)
Received: by mail-yw0-x22b.google.com with SMTP id x20so3989657ywg.4 for ; Sat, 11 Nov 2017 17:29:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lrlMVFila4D5jfHPv+W7dKtLw2Uzo6N6EuNTQvFu2YY=; b=ZH/AKIp6ahaGt2Dekh2RXkW3TKH88eMSE+GKyFPk+pBclKlH7gsZh/E5K9igbl/EI9 Qj74UGxdw2ttyEk/ChVP/o7Hy0rALan8g92AAatnpE46kuS09ocOUdYM1kk5rhHnxCi9 hilf5KC7CBdGUUP69BASyvFtqslmbgXYYY3vF+OUwrwlaN+JP0kQGdSpV71O7qKeIgxk 7jR224Mpq8i6nEl0oTCU17DUmjP827QOe7XGBQuclgTL32VBl0Ww/Doc+Pk3MCLCZaTv TLhAc252LjxVOAt/TasUh5FADP0Lh0c0f6+DbupdRpaVQ9TA9CSXPGH1aTI95y7Fu/LW 01yA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lrlMVFila4D5jfHPv+W7dKtLw2Uzo6N6EuNTQvFu2YY=; b=Vz93/Qab1WDVvY3/WQYh5rx0Vu1OzxQ0H5V9xoc6fLBK6u3UchU8iVt/Pp3aGYf07Z bbxprVk/ZoEnBLFxfXfYWiOG4/5fTN3IqZfItlHFBcD8Qnz+XGUENfnFBcOii7e4bOKz 7ubSv08i3p+/FKLZhwQw9KdPsdBdqBMZ2IKemQrnyUCm4LYVds8hssmIVR+C/QExUkXJ qkkrYqXCxZz3UG0OOZE8TO/76iZvJdxZZVt8boiZLpwlAEqS+RGYz+YhaM20alRu4BZX UjqAW4v0aJRCVolIDe6gbeSDvZUZWVMzQ+jHkVj+OsTUMvhpsejIiqX9zmrUOUBMIRk+ 7mBw==
X-Gm-Message-State: AJaThX6QzsEaHb8EfpQsNAD9FauvILQqtbFnBNPAfSrLLy14ZTB2GECH gqyfltv7xT1cLWVo+XDBiljv+ewcUHYsmkTeyGjC9Q==
X-Google-Smtp-Source: AGs4zMb4snaK+wjoMqPcW/PzRTwu/yiLIC6FWuz9MPuromVH/fyr4DfgAtay6BxbYvy881tFbkXgs4rKVILYOBqtENQ=
X-Received: by 10.129.172.25 with SMTP id k25mr1830486ywh.155.1510450184871; Sat, 11 Nov 2017 17:29:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.61.12 with HTTP; Sat, 11 Nov 2017 17:29:04 -0800 (PST)
In-Reply-To: 
References:     
From: Eric Rescorla 
Date: Sat, 11 Nov 2017 17:29:04 -0800
Message-ID: 
To: David Schinazi 
Cc: David Benjamin , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c1badfcb87852055dbf166c"
Archived-At: 
Subject: Re: [TLS] close_notify and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Nov 2017 01:29:50 -0000

--94eb2c1badfcb87852055dbf166c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Please.

-Ekr


On Sat, Nov 11, 2017 at 5:24 PM, David Schinazi  wrote=
:

> Thanks for checking gents!
>
> Would you like me to send a PR?
>
> David
>
>
> On Nov 12, 2017, at 09:13, Eric Rescorla  wrote:
>
> Initial inspection suggests that NSS behaves the same way, so I would be
> fine with this change.
>
> -Ekr
>
>
> On Sat, Nov 11, 2017 at 3:46 PM, David Benjamin 
> wrote:
>
>> I think this change is a good idea.
>>
>> Our implementation actually does this already anyway. We are happy to
>> continue servicing writes even when the read half has consumed a
>> close_notify. I believe we inherited this behavior from OpenSSL, so it
>> should be there too. Go's crypto/tls implementation appears to also alre=
ady
>> do this.
>>
>> We don't have a particular need for the half-close semantics that I know
>> of, but I don't care for the current spec text (it requires yet another
>> undesirable read/write sync point). Aligning with TCP's semantics is als=
o
>> generally a good default.
>>
>> On Sat, Nov 11, 2017 at 11:18 PM Martin Thomson 
>> wrote:
>>
>>> This seems like it might be worth looking at.  This seems to be
>>> something that harks back to SSL3 or even earlier.  We aren't going to
>>> make it so that you can rely on this behaviour, but we might be able
>>> to make it possible to half-close, which for new protocols using TLS
>>> could be hugely useful.
>>>
>>> On Sat, Nov 11, 2017 at 5:21 PM, David Schinazi 
>>> wrote:
>>> > Hello all,
>>> >
>>> > Currently TLS 1.3 specifies close_notify in the same way that TLS 1.2
>>> did.
>>> > I believe that has issues and this might be the right time to fix the=
m.
>>> > The purpose of close_notify is to protect against data truncation
>>> attacks,
>>> > each side is required to send close_notify before closing the write
>>> side of
>>> > the transport connection so the other side knows that the data was no=
t
>>> > truncated.
>>> > As such, close_notify only needs half-close semantics to prevent
>>> truncation.
>>> >
>>> > However, the specification contains the following text:
>>> > << Each party MUST send a =E2=80=9Cclose_notify=E2=80=9D alert before=
 closing the
>>> write side
>>> >     of the connection, unless some other fatal alert has been
>>> transmitted.
>>> >     The other party MUST respond with a =E2=80=9Cclose_notify=E2=80=
=9D alert of its
>>> own and
>>> > close
>>> >     down the connection immediately, discarding any pending writes. >=
>
>>> >
>>> > This means that an application-layer client can't send a query then
>>> close
>>> > their
>>> > write transport when they know that they're done, because the server
>>> would
>>> > terminate the TLS session before sending the reply. On top of this,
>>> when
>>> > the server receives the close_notify, it may have already sent part o=
f
>>> the
>>> > reply
>>> > (or wrote it to the socket send buffer) so the responding close_notif=
y
>>> would
>>> > in effect be inflicting a truncation attack on the client.
>>> >
>>> > This doesn't make much difference for HTTP because clients already
>>> > don't close their write transport after sending a reply, however
>>> having the
>>> > option do do this could allow innovation in new protocols that can
>>> define
>>> > the semantics of when they use close_notify. An example is DNS PUSH:
>>> > https://tools.ietf.org/html/draft-ietf-dnssd-push
>>> >
>>> > A proposal to solve this problem would be to give close_notify
>>> half-close
>>> > semantics: we keep the requirements that a close_notify be sent befor=
e
>>> > closing the transport, and that any data received after a close_notif=
y
>>> is
>>> > ignored, but we simply remove the requirement to immediately reply
>>> > with a close_notify. This has the advantage that current
>>> implementations
>>> > are already compliant but future ones can leverage this improvement.
>>> >
>>> > What do you think? Is this worth discussing on Thursday?
>>> >
>>> > Thanks,
>>> > David Schinazi
>>> >
>>> > _______________________________________________
>>> > 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
>>>
>>
>> _______________________________________________
>> 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
>
>
>

--94eb2c1badfcb87852055dbf166c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Please.

-Ekr

=


On Sat, Nov 11, 2=
017 at 5:24 PM, David Schinazi <dschinazi@apple.com> wrote=
:
Thanks for checking gents!

Wou=
ld you like me to send a PR?

David
<=
div>

On Nov 12, 2017, at 09:13, =
Eric Rescorla <ekr@rtf=
m.com> wrote:

Initial inspection suggests that NSS beh=
aves the same way, so I would be fine with this change.

=
-Ekr


On Sat, Nov 11, 2017 at 3:46 PM, David Benjamin <davidbe=
n@chromium.org> wrote:
I think this change is a good idea.

<=
div>Our implementation actually does this already anyway. We are happy to c=
ontinue servicing writes even when the read half has consumed a close_notif=
y. I believe we inherited this behavior from OpenSSL, so it should be there=
 too. Go's crypto/tls implementation appears to also already do this.

We don't have a particular need for the hal=
f-close semantics that I know of, but I don't care for the current spec=
 text (it requires yet another undesirable read/write sync point). Aligning=
 with TCP's semantics is also generally a good default.

On Sat, Nov =
11, 2017 at 11:18 PM Martin Thomson <martin.thomson@gmail.com> wrote:
This seems like it might be worth looking a=
t.=C2=A0 This seems to be

something that harks back to SSL3 or even earlier.=C2=A0 We aren't goin=
g to

make it so that you can rely on this behaviour, but we might be able

to make it possible to half-close, which for new protocols using TLS

could be hugely useful.



On Sat, Nov 11, 2017 at 5:21 PM, David Schinazi <dschinazi@apple.com> wrote:

> Hello all,

>

> Currently TLS 1.3 specifies close_notify in the same way that TLS 1.2 =
did.

> I believe that has issues and this might be the right time to fix them=
.

> The purpose of close_notify is to protect against data truncation atta=
cks,

> each side is required to send close_notify before closing the write si=
de of

> the transport connection so the other side knows that the data was not=


> truncated.

> As such, close_notify only needs half-close semantics to prevent trunc=
ation.

>

> However, the specification contains the following text:

> << Each party MUST send a =E2=80=9Cclose_notify=E2=80=9D alert b=
efore closing the write side

>=C2=A0 =C2=A0 =C2=A0of the connection, unless some other fatal alert ha=
s been transmitted.

>=C2=A0 =C2=A0 =C2=A0The other party MUST respond with a =E2=80=9Cclose_=
notify=E2=80=9D alert of its own and

> close

>=C2=A0 =C2=A0 =C2=A0down the connection immediately, discarding any pen=
ding writes. >>

>

> This means that an application-layer client can't send a query the=
n close

> their

> write transport when they know that they're done, because the serv=
er would

> terminate the TLS session before sending the reply. On top of this, wh=
en

> the server receives the close_notify, it may have already sent part of=
 the

> reply

> (or wrote it to the socket send buffer) so the responding close_notify=
 would

> in effect be inflicting a truncation attack on the client.

>

> This doesn't make much difference for HTTP because clients already=


> don't close their write transport after sending a reply, however h=
aving the

> option do do this could allow innovation in new protocols that can def=
ine

> the semantics of when they use close_notify. An example is DNS PUSH:
> https://tools.ietf.org/html/draft-ietf-dn=
ssd-push

>

> A proposal to solve this problem would be to give close_notify half-cl=
ose

> semantics: we keep the requirements that a close_notify be sent before=


> closing the transport, and that any data received after a close_notify=
 is

> ignored, but we simply remove the requirement to immediately reply

> with a close_notify. This has the advantage that current implementatio=
ns

> are already compliant but future ones can leverage this improvement.
>

> What do you think? Is this worth discussing on Thursday?

>

> Thanks,

> David Schinazi

>

> _______________________________________________

> 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




_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls




_______________________________________________
TLS mailing listTLS@ietf.org
https:/=
/www.ietf.org/mailman/listinfo/tls



--94eb2c1badfcb87852055dbf166c--


From nobody Sat Nov 11 17:47:41 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407BD124BFA for ; Sat, 11 Nov 2017 17:47:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 BFqIIX3TZg8z for ; Sat, 11 Nov 2017 17:47:38 -0800 (PST)
Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (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 53C28126E7A for ; Sat, 11 Nov 2017 17:47:38 -0800 (PST)
Received: by mail-ot0-x22d.google.com with SMTP id 105so1998626oth.10 for ; Sat, 11 Nov 2017 17:47:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mkPCBdM8d3KmEG/DqjeP7xsUFIQxJfOv8yJAudZWmxk=; b=ELlJ3dlg8z+gQymZXqICiGXLI4ncG0mYanQVBDS7Ym5UpRNh6BmY5Lmhia7KUOluCO PxPYY/QAzCEBqICrtpNKfTzaGCeZ+5ZDgu151KuhiKQavW6ep/jZkkR7+nGcQW5TpTCH frdJ62/2V+lYAiAVEpISVzi3Gc0Ghn7pFEmMFMUkOK4VPUil6NtXOiFj67jVQA3x9B4j 93Fviz+BGq1gfJNmrK+p2/zUK3VwxztODAmJuxrSUMCmOPW6+5B2OQ2RtA2VB7cPyxwc 4onY9NruDfyuqSM+Rt5CODSxwUhb1Z1oosYkdcS+WL54RwNYCi/TizyeJH52IXBW+r3t yWiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mkPCBdM8d3KmEG/DqjeP7xsUFIQxJfOv8yJAudZWmxk=; b=Ii70TW5PZVtGsxFlPUNb6GMFyQ7lyiUvsEnXo651mmQlCG0LHwvVQA56qoAwSgRUIq dGM0wypyM8Z+/+spKi2nNtrINU170iL68xmO1NisTVKdfLvXwIRnZbonKslJLZuTa705 zSJ1+BeJ7diqaSAxLngKH7gTA0j6e3103lJQNfY9CUH6qcDVVHBGkMDDyEHvjdFpkuba zV8hTrLzMxPB2AqANxxqd7J4NizrIHugJbgpMOIJx5ltkwyKrr/CnIrqcT84QhyfMNHA CTUiVlAScdXlUKS7m4qHZEWuITo5gNFycIbisqgClvz9i3+Z6gXklGNI86I9O+eiVMQw GnSg==
X-Gm-Message-State: AJaThX45pQzm3fdfkIB+/IuX+ZTP5Icz0SdG/qFvwpuFrfuNIuGIcLLz e62WPU1iR5FnC4qZWVOZonEep+LlHo2hgQ7uCWg=
X-Google-Smtp-Source: AGs4zMaJy9KNWrNsrMsS8WZtymmQwOcc0CZ0iaNgpKrMUwaAXKoJINQAIlNopssxiOsKQxH3mJtLOxOCY7nH7uG1la0=
X-Received: by 10.157.53.8 with SMTP id o8mr3411270otc.35.1510451257609; Sat, 11 Nov 2017 17:47:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.8.11 with HTTP; Sat, 11 Nov 2017 17:47:37 -0800 (PST)
In-Reply-To: 
References:    
From: Martin Thomson 
Date: Sun, 12 Nov 2017 09:47:37 +0800
Message-ID: 
To: Eric Rescorla 
Cc: David Benjamin , "tls@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [TLS] close_notify and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Nov 2017 01:47:40 -0000

We suppress the sending of a close_notify if we have received one, but
that's a fairly simple thing to correct.

On Sun, Nov 12, 2017 at 9:13 AM, Eric Rescorla  wrote:
> Initial inspection suggests that NSS behaves the same way, so I would be
> fine with this change.
>
> -Ekr
>
>
> On Sat, Nov 11, 2017 at 3:46 PM, David Benjamin 
> wrote:
>>
>> I think this change is a good idea.
>>
>> Our implementation actually does this already anyway. We are happy to
>> continue servicing writes even when the read half has consumed a
>> close_notify. I believe we inherited this behavior from OpenSSL, so it
>> should be there too. Go's crypto/tls implementation appears to also alre=
ady
>> do this.
>>
>> We don't have a particular need for the half-close semantics that I know
>> of, but I don't care for the current spec text (it requires yet another
>> undesirable read/write sync point). Aligning with TCP's semantics is als=
o
>> generally a good default.
>>
>> On Sat, Nov 11, 2017 at 11:18 PM Martin Thomson 
>> wrote:
>>>
>>> This seems like it might be worth looking at.  This seems to be
>>> something that harks back to SSL3 or even earlier.  We aren't going to
>>> make it so that you can rely on this behaviour, but we might be able
>>> to make it possible to half-close, which for new protocols using TLS
>>> could be hugely useful.
>>>
>>> On Sat, Nov 11, 2017 at 5:21 PM, David Schinazi 
>>> wrote:
>>> > Hello all,
>>> >
>>> > Currently TLS 1.3 specifies close_notify in the same way that TLS 1.2
>>> > did.
>>> > I believe that has issues and this might be the right time to fix the=
m.
>>> > The purpose of close_notify is to protect against data truncation
>>> > attacks,
>>> > each side is required to send close_notify before closing the write
>>> > side of
>>> > the transport connection so the other side knows that the data was no=
t
>>> > truncated.
>>> > As such, close_notify only needs half-close semantics to prevent
>>> > truncation.
>>> >
>>> > However, the specification contains the following text:
>>> > << Each party MUST send a =E2=80=9Cclose_notify=E2=80=9D alert before=
 closing the write
>>> > side
>>> >     of the connection, unless some other fatal alert has been
>>> > transmitted.
>>> >     The other party MUST respond with a =E2=80=9Cclose_notify=E2=80=
=9D alert of its own
>>> > and
>>> > close
>>> >     down the connection immediately, discarding any pending writes. >=
>
>>> >
>>> > This means that an application-layer client can't send a query then
>>> > close
>>> > their
>>> > write transport when they know that they're done, because the server
>>> > would
>>> > terminate the TLS session before sending the reply. On top of this,
>>> > when
>>> > the server receives the close_notify, it may have already sent part o=
f
>>> > the
>>> > reply
>>> > (or wrote it to the socket send buffer) so the responding close_notif=
y
>>> > would
>>> > in effect be inflicting a truncation attack on the client.
>>> >
>>> > This doesn't make much difference for HTTP because clients already
>>> > don't close their write transport after sending a reply, however havi=
ng
>>> > the
>>> > option do do this could allow innovation in new protocols that can
>>> > define
>>> > the semantics of when they use close_notify. An example is DNS PUSH:
>>> > https://tools.ietf.org/html/draft-ietf-dnssd-push
>>> >
>>> > A proposal to solve this problem would be to give close_notify
>>> > half-close
>>> > semantics: we keep the requirements that a close_notify be sent befor=
e
>>> > closing the transport, and that any data received after a close_notif=
y
>>> > is
>>> > ignored, but we simply remove the requirement to immediately reply
>>> > with a close_notify. This has the advantage that current
>>> > implementations
>>> > are already compliant but future ones can leverage this improvement.
>>> >
>>> > What do you think? Is this worth discussing on Thursday?
>>> >
>>> > Thanks,
>>> > David Schinazi
>>> >
>>> > _______________________________________________
>>> > 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
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>


From nobody Sat Nov 11 18:39:52 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5A5128CDC for ; Sat, 11 Nov 2017 18:39:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 wGAeqAbD2wiQ for ; Sat, 11 Nov 2017 18:39:49 -0800 (PST)
Received: from mail-in1.asia.apple.com (mail-out.asia.apple.com [17.82.254.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75B86128B90 for ; Sat, 11 Nov 2017 18:39:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1510454381; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZOzIUSY/mvT+6z40Osr/aLJNUtYkC8xIhAb5ZBsANuM=; b=XpEe1TXUWlaUVnWiLDigL4kSNK6+huU68F9DBk1X5rnCa1T8k44grJ/TPFRXCcPS CEQoBQn/OpE4FhvsE+KHscEKuwv4y19j+A8HcyiFlfqDXnuglcP8ZqKhWNQpFhDh uFzkvaXQib7h1O2G232hSJTyOutmo8XpLz+lkcj2mACk8ybPPCyzcDdIjDS8DKp9 XHXBAimtNzkwoDFHGRhm6/IhPNjZH20UQfEYWRY/yHCtNxY3WTOoRCtAFddNzy0c 0XdMwO+V06ibFZ/W19i9lurElMZbWossTzq5/mTRNtf92U1pzjS+3/M1Ve0t2iyn 66l41F+GWpZvO9uQKQPz2w==;
Received: from relay2.asia.apple.com ( [17.82.200.16]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in1.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id 77.AD.07591.D64B70A5; Sun, 12 Nov 2017 10:39:41 +0800 (MYT)
X-AuditID: 1152fe11-8cbff70000001da7-f0-5a07b46d6ea3
Received: from mmp3.asia.apple.com ( [17.84.76.250]) by relay2.asia.apple.com (Apple Singapore relay) with SMTP id C8.31.31851.D64B70A5; Sun, 12 Nov 2017 10:39:41 +0800 (MYT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_3CI51gpQ6nD4ouILePymKQ)"
Received: from [IPv6:2001:67c:370:1998:e0f4:6d59:e5c5:47fd] (nat64-46.meeting.ietf.org [31.130.238.70]) by mmp3.asia.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OZA00E4KA24JE40@mmp3.asia.apple.com>; Sun, 12 Nov 2017 10:39:41 +0800 (SGT)
Sender: dschinazi@apple.com
From: David Schinazi 
Message-id: <3C858B74-DCEA-4FA2-88B3-0FF1242CC0E8@apple.com>
Date: Sun, 12 Nov 2017 10:39:41 +0800
In-reply-to: 
Cc: Eric Rescorla , "tls@ietf.org" 
To: Martin Thomson 
References:     
X-Mailer: Apple Mail (2.3445.1.6)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUiGHRCQDd3C3uUwZcv4hYrXp9jt7h25h+j xafzXYwOzB47Z91l91iy5CeTx+THbcwBzFFcNimpOZllqUX6dglcGXO3zGQseJtR8XR9G2MD 4+nILkYODgkBE4n7tzO6GLk4hARWMkkc7/3B2MXICRbvu3STHSKxgVHi3dznYAleAUGJH5Pv sYDYzAJhEjMOboIq2sUk8enGZbAiYQFpia4Ld1lBNrAJaEkcWGME0Wsj8WzZExaIEm2J9U0v mUBsFgFVifU928HinALBEtN/PWeDmG8vsaT7KSuILSKgK7Ho7AOoXTeYJA7snMwMcamixJGZ c5hBEhICa9gkzp7bwD6BUWgWkmNnITl2FtBNzALqElOm5EKEtSWevLvACmGrSSz8vYgJWXwB I9sqRvHcxMwc3cw8Q73E4sxEvcSCgpxUveT83E2M4Ej5J7iDcepCw0OMAhyMSjy8fsAIEmJN LCuuzD3EKMHBrCTCWyIEFOJNSaysSi3Kjy8qzUktPsQozcGiJM7bF/kpUkggPbEkNTs1tSC1 CCbLxMEp1cAoOjvu3P7Lqxuy1zMv8mH8bXMo6v3ax6FLJ0huOv+h7/2Tp03COQubY0s3dBn/ FXHuE6pYuv/XOtmF/IaTU02kTspW9/49s3CW3AFrkWVrGj6JTWTLrvhqsEfQ0GVNjsSc/78i 29VETnz/f9Sw+KU5Q/yKtXVSEhuku29wba78L3lt/5knbUs+KrEUZyQaajEXFScCAM4pnG6Q AgAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUiGOLzSzd3C3uUQeN8AYsVr8+xW1w784/R 4tP5LkYHZo+ds+6yeyxZ8pPJY/LjNuYA5igum5TUnMyy1CJ9uwSujLlbZjIWvM2oeLq+jbGB 8XRkFyMnh4SAiUTfpZvsXYxcHEICGxgl3s19zgiS4BUQlPgx+R4LiM0sECYx4+AmqKJdTBKf blwGKxIWkJbounCXtYuRg4NNQEviwBojiF4biWfLnrBAlGhLrG96yQRiswioSqzv2Q4W5xQI lpj+6zkbxHx7iSXdT1lBbBEBXYlFZx9A7brBJHFg52RmiEsVJY7MnMM8gZF/FpL7ZiG5bxbQ GcwC6hJTpuRChLUlnry7wAphq0ks/L2ICVl8ASPbKkbRotScxEojvcTizES9xIKCnFS95Pzc TYyg0A46IbCDcdYhg0OMAhyMSjy8yRvZo4RYE8uKK3MPMUpwMCuJ8JYIAYV4UxIrq1KL8uOL SnNSiw8xSnOwKInzakZ9ihQSSE8sSc1OTS1ILYLJMnFwSjUwZs/66v6gRNrBouJ6veRynpMM gvNP8BrdYdNexXTuvs2NQ9W+U7fmV2x6WzE9N/fC/o9LH/Qr/RcUfZ08K9Y0lplJ8b3Pe9VI xozLTPNZnlophJX479CetLndpo5Jbdb+TXdi2ELd9jcm8D69ZqA6838Dx+3cVF9zb8M1GnH6 507P6bx7htVHiaU4I9FQi7moOBEAi+HYO2kCAAA=
Archived-At: 
Subject: Re: [TLS] close_notify and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Nov 2017 02:39:51 -0000

--Boundary_(ID_3CI51gpQ6nD4ouILePymKQ)
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: quoted-printable

I've sent out a PR:
https://github.com/tlswg/tls13-spec/pull/1092 =


It might be a little verbose but I think it explains and solves the =
problem.
Please let me know what you think!

Thanks,
David Schinazi


> On Nov 12, 2017, at 09:47, Martin Thomson  =
wrote:
>=20
> We suppress the sending of a close_notify if we have received one, but
> that's a fairly simple thing to correct.
>=20
> On Sun, Nov 12, 2017 at 9:13 AM, Eric Rescorla  wrote:
>> Initial inspection suggests that NSS behaves the same way, so I would =
be
>> fine with this change.
>>=20
>> -Ekr
>>=20
>>=20
>> On Sat, Nov 11, 2017 at 3:46 PM, David Benjamin =

>> wrote:
>>>=20
>>> I think this change is a good idea.
>>>=20
>>> Our implementation actually does this already anyway. We are happy =
to
>>> continue servicing writes even when the read half has consumed a
>>> close_notify. I believe we inherited this behavior from OpenSSL, so =
it
>>> should be there too. Go's crypto/tls implementation appears to also =
already
>>> do this.
>>>=20
>>> We don't have a particular need for the half-close semantics that I =
know
>>> of, but I don't care for the current spec text (it requires yet =
another
>>> undesirable read/write sync point). Aligning with TCP's semantics is =
also
>>> generally a good default.
>>>=20
>>> On Sat, Nov 11, 2017 at 11:18 PM Martin Thomson =

>>> wrote:
>>>>=20
>>>> This seems like it might be worth looking at.  This seems to be
>>>> something that harks back to SSL3 or even earlier.  We aren't going =
to
>>>> make it so that you can rely on this behaviour, but we might be =
able
>>>> to make it possible to half-close, which for new protocols using =
TLS
>>>> could be hugely useful.
>>>>=20
>>>> On Sat, Nov 11, 2017 at 5:21 PM, David Schinazi =

>>>> wrote:
>>>>> Hello all,
>>>>>=20
>>>>> Currently TLS 1.3 specifies close_notify in the same way that TLS =
1.2
>>>>> did.
>>>>> I believe that has issues and this might be the right time to fix =
them.
>>>>> The purpose of close_notify is to protect against data truncation
>>>>> attacks,
>>>>> each side is required to send close_notify before closing the =
write
>>>>> side of
>>>>> the transport connection so the other side knows that the data was =
not
>>>>> truncated.
>>>>> As such, close_notify only needs half-close semantics to prevent
>>>>> truncation.
>>>>>=20
>>>>> However, the specification contains the following text:
>>>>> << Each party MUST send a =E2=80=9Cclose_notify=E2=80=9D alert =
before closing the write
>>>>> side
>>>>>    of the connection, unless some other fatal alert has been
>>>>> transmitted.
>>>>>    The other party MUST respond with a =E2=80=9Cclose_notify=E2=80=9D=
 alert of its own
>>>>> and
>>>>> close
>>>>>    down the connection immediately, discarding any pending writes. =
>>
>>>>>=20
>>>>> This means that an application-layer client can't send a query =
then
>>>>> close
>>>>> their
>>>>> write transport when they know that they're done, because the =
server
>>>>> would
>>>>> terminate the TLS session before sending the reply. On top of =
this,
>>>>> when
>>>>> the server receives the close_notify, it may have already sent =
part of
>>>>> the
>>>>> reply
>>>>> (or wrote it to the socket send buffer) so the responding =
close_notify
>>>>> would
>>>>> in effect be inflicting a truncation attack on the client.
>>>>>=20
>>>>> This doesn't make much difference for HTTP because clients already
>>>>> don't close their write transport after sending a reply, however =
having
>>>>> the
>>>>> option do do this could allow innovation in new protocols that can
>>>>> define
>>>>> the semantics of when they use close_notify. An example is DNS =
PUSH:
>>>>> https://tools.ietf.org/html/draft-ietf-dnssd-push
>>>>>=20
>>>>> A proposal to solve this problem would be to give close_notify
>>>>> half-close
>>>>> semantics: we keep the requirements that a close_notify be sent =
before
>>>>> closing the transport, and that any data received after a =
close_notify
>>>>> is
>>>>> ignored, but we simply remove the requirement to immediately reply
>>>>> with a close_notify. This has the advantage that current
>>>>> implementations
>>>>> are already compliant but future ones can leverage this =
improvement.
>>>>>=20
>>>>> What do you think? Is this worth discussing on Thursday?
>>>>>=20
>>>>> Thanks,
>>>>> David Schinazi
>>>>>=20
>>>>> _______________________________________________
>>>>> TLS mailing list
>>>>> TLS@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> TLS mailing list
>>>> TLS@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tls
>>>=20
>>>=20
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>=20
>>=20
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


--Boundary_(ID_3CI51gpQ6nD4ouILePymKQ)
Content-type: text/html; charset=utf-8
Content-transfer-encoding: quoted-printable

I've =
sent out a PR:
https://github.com/tlswg/tls13-spec/pull/1092

It might be a little =
verbose but I think it explains and solves the problem.
Please let me know what you think!

Thanks,
David =
Schinazi


On Nov =
12, 2017, at 09:47, Martin Thomson <martin.thomson@gmail.com> wrote:

We =
suppress the sending of a close_notify if we have received one, but
that's a fairly simple thing to correct.

On Sun, Nov 12, 2017 at 9:13 AM, Eric Rescorla <ekr@rtfm.com> wrote:
Initial inspection =
suggests that NSS behaves the same way, so I would be
fine =
with this change.

-Ekr


On Sat, Nov 11, 2017 at 3:46 PM, David =
Benjamin <davidben@chromium.org>
wrote:

I think =
this change is a good idea.

Our =
implementation actually does this already anyway. We are happy to
continue servicing writes even when the read half has =
consumed a
close_notify. I believe we inherited this =
behavior from OpenSSL, so it
should be there too. Go's =
crypto/tls implementation appears to also already
do =
this.

We don't have a particular need for =
the half-close semantics that I know
of, but I don't care =
for the current spec text (it requires yet another
undesirable read/write sync point). Aligning with TCP's =
semantics is also
generally a good default.

On Sat, Nov 11, 2017 at 11:18 PM Martin =
Thomson <martin.thomson@gmail.com>
wrote:

This =
seems like it might be worth looking at.  This seems to be
something that harks back to SSL3 or even earlier.  We =
aren't going to
make it so that you can rely on this =
behaviour, but we might be able
to make it possible to =
half-close, which for new protocols using TLS
could be =
hugely useful.

On Sat, Nov 11, 2017 at 5:21 =
PM, David Schinazi <dschinazi@apple.com>
wrote:
Hello all,

Currently TLS 1.3 specifies close_notify in =
the same way that TLS 1.2
did.
I believe =
that has issues and this might be the right time to fix them.
The purpose of close_notify is to protect against data =
truncation
attacks,
each side is required to =
send close_notify before closing the write
side of
the transport connection so the other side knows that the =
data was not
truncated.
As such, =
close_notify only needs half-close semantics to prevent
truncation.

However, the =
specification contains the following text:
<< Each =
party MUST send a =E2=80=9Cclose_notify=E2=80=9D alert before closing =
the write
side
    of the =
connection, unless some other fatal alert has been
transmitted.
    The other party =
MUST respond with a =E2=80=9Cclose_notify=E2=80=9D alert of its own
and
close
    down =
the connection immediately, discarding any pending writes. >>

This means that an application-layer client =
can't send a query then
close
their
write transport when they know that they're done, because the =
server
would
terminate the TLS session =
before sending the reply. On top of this,
when
the server receives the close_notify, it may have already =
sent part of
the
reply
(or =
wrote it to the socket send buffer) so the responding close_notify
would
in effect be inflicting a truncation =
attack on the client.

This doesn't make =
much difference for HTTP because clients already
don't =
close their write transport after sending a reply, however having
the
option do do this could allow innovation in =
new protocols that can
define
the semantics =
of when they use close_notify. An example is DNS PUSH:
https://tools.ietf.org/html/draft-ietf-dnssd-push

A proposal to solve this problem would be to =
give close_notify
half-close
semantics: we =
keep the requirements that a close_notify be sent before
closing the transport, and that any data received after a =
close_notify
is
ignored, but we simply =
remove the requirement to immediately reply
with a =
close_notify. This has the advantage that current
implementations
are already compliant but =
future ones can leverage this improvement.

What do you think? Is this worth discussing on Thursday?

Thanks,
David Schinazi

_______________________________________________
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


_______________________________________________
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

=

--Boundary_(ID_3CI51gpQ6nD4ouILePymKQ)--


From nobody Sat Nov 11 21:57:39 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EB7126DED for ; Sat, 11 Nov 2017 21:57:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level: 
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Qqb1cTeBPDXy for ; Sat, 11 Nov 2017 21:57:36 -0800 (PST)
Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (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 A579A1200C1 for ; Sat, 11 Nov 2017 21:57:36 -0800 (PST)
Received: by mail-pg0-x236.google.com with SMTP id o7so10381305pgc.4 for ; Sat, 11 Nov 2017 21:57:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:content-transfer-encoding:mime-version:date:subject:message-id :to; bh=HbHzRdJb7cG4pAi/poXjQzUmGjk8W36d15H+mgqswwQ=; b=clJGn2fkul0x6mO7LFYYePR9+sAfWCJyfjcposoDJ6X+0biRlvgvCOwNJLgUUgo28p LK6ENO8l8LEJbBkJ7LdqShpxpej7qOFXH+uiXtaqKHK5pRpqCbzU3lK1BMiM722omT/K ORb0edqdjhfkURz1yvfk8EPm8x9zVRkcaOIG9nVoNmA8WQfwZPGSkKxGzzCVX2wXFzb4 RqR8LJyimwF6FPqhZrK7XiFtrysWboJkLIak9iU9dwLt9T+dRYrGV3+rfJWl/wv5uJ+7 WWhv84PFvdR2DS9XgZBMK3sj+gy7ZrrjV7WUKQd+uIiN2e7Jj7zBlLNBKrjd2xh6394B BCYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:to; bh=HbHzRdJb7cG4pAi/poXjQzUmGjk8W36d15H+mgqswwQ=; b=Ar/pX1EMXUteH+oDspSGYGdwwACLyMVNnQbq4sK5o6eDppI2y3hrSsfobJ5vSKzmkD Iw+A86etdAdfZUdCoERp8NhvBFtAw755YU3L3CWEDB7PchUWezbZBpr8etuat9naDpcj ULHJBDjqqVXyoPWw+pZzZVS/mziZnIV3GpDIdwlxamHi051nQDipNOtXBny3Mfdfjbvu BD1j7Bmtfe2uCt6MjePoXhTe0p3r3u+YBuzyBhlqtq6XzYzDZHp+qmz6cq+7WK9u6VAz ZDBl2LgsQQtb46Yp91doxkX72yVVie6Y8lX40LyKoiFfC0o0bsfmnNUDh6fNQiz83jAi 3dpg==
X-Gm-Message-State: AJaThX6BJerx41aOFuiVXY4pHIe6KceuOyt4UD/q+vF1wKJ5bcdYkZ4z VlWeTqF/gr/N3MpPt74sSLMuBW3O
X-Google-Smtp-Source: AGs4zMbjZhyPGObu6eLFwPVqi73X9GaD23nCTdfJaGoV2fiIMWSDwsuWjDEF4eCRanruCMqe8n6F8Q==
X-Received: by 10.84.168.132 with SMTP id f4mr4000527plb.234.1510466255987; Sat, 11 Nov 2017 21:57:35 -0800 (PST)
Received: from ?IPv6:2001:67c:1232:144:8d33:b55b:14d0:7268? ([2001:67c:1232:144:8d33:b55b:14d0:7268]) by smtp.gmail.com with ESMTPSA id p21sm29592867pfk.185.2017.11.11.21.57.34 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Nov 2017 21:57:35 -0800 (PST)
From: Bret Jordan 
Content-Type: multipart/alternative; boundary=Apple-Mail-17885731-7E67-4616-83AC-8823CA7B054A
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Date: Sun, 12 Nov 2017 13:57:28 +0800
Message-Id: <6B1040C5-7182-4D6E-9D12-B2C5EA99D601@gmail.com>
To: tls@ietf.org
X-Mailer: iPhone Mail (15A432)
Archived-At: 
Subject: [TLS] Encrypted SNI hangout
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Nov 2017 05:57:38 -0000

--Apple-Mail-17885731-7E67-4616-83AC-8823CA7B054A
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

All,

Since the TLS session on Monday got canceled what would people think about u=
sing that time to talk about encrypted SNI? =20

Bret=20

Sent from my Commodore 128D

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050=

--Apple-Mail-17885731-7E67-4616-83AC-8823CA7B054A
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

All,

Since the TLS sessi=
on on Monday got canceled what would people think about using that time to t=
alk about encrypted SNI?  

Bret 

<=
div id=3D"AppleMailSignature">Sent from my Commodore 128D

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 7=
4F8 ACAE 7415 0050
=

--Apple-Mail-17885731-7E67-4616-83AC-8823CA7B054A--


From nobody Sun Nov 12 00:58:41 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B356A126CF6 for ; Sun, 12 Nov 2017 00:58:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 E1UXY8Rj3OVi for ; Sun, 12 Nov 2017 00:58:37 -0800 (PST)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A54241204DA for ; Sun, 12 Nov 2017 00:58:37 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id D1EC5B524E for ; Sun, 12 Nov 2017 10:58:34 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id GFYw0dfbjKnl for ; Sun, 12 Nov 2017 10:58:34 +0200 (EET)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id A72952315 for ; Sun, 12 Nov 2017 10:58:33 +0200 (EET)
Date: Sun, 12 Nov 2017 10:58:33 +0200
From: Ilari Liusvaara 
To: "tls@ietf.org" 
Message-ID: <20171112085833.evhtju2f3r5bji6f@LK-Perkele-VII>
References:    
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] close_notify and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Nov 2017 08:58:40 -0000

On Sat, Nov 11, 2017 at 05:13:14PM -0800, Eric Rescorla wrote:
> Initial inspection suggests that NSS behaves the same way, so I would be
> fine with this change.

My implementation also has half-close semantics for close_notify
(both TLS 1.2 and 1.3).


This does not address beyond-TCP semantics some applications need, but
those applications are unlikely to run directly on top of TLS without
some layer in between, so getting those semantics from TLS would not
be useful.


-Ilari


From nobody Sun Nov 12 06:16:25 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECD2129432 for ; Sun, 12 Nov 2017 06:16:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 DrNzhAhlaapX for ; Sun, 12 Nov 2017 06:16:21 -0800 (PST)
Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 8E6DA1200F1 for ; Sun, 12 Nov 2017 06:16:21 -0800 (PST)
Received: by mail-ua0-x22a.google.com with SMTP id u13so8752376uaf.6 for ; Sun, 12 Nov 2017 06:16:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=32lfFUDyScmqwhlNcaKOeDJIGKlqp2VT7yeXT6qFJe8=; b=ZubVDBPk9O9OgmqW4275iau6KiBEJBOnP3mvsEgPNUI1LlJdoMbIuGxHSI1DRILuQW 2NYFkv2uF0k5FvH/Pn71CumYKlF/ZwHElQi8dcQPbXVwtBV/jNWSJsfUwW40Jt77L4LC QZsO2zVrHZPlSnqw5Q3oD+kpxKCeAnl1Ys8XM8myevkDHYNP6cnuapmg0pqr55m3iUGH rrvc2h3K+fiyz5dJmz0Qp+JDsSU4oueQU2zUYpyEnC9+5HBmSIozX+h5Tr331nZYl4T9 jadSB4qpI742I3yS9NTasvyR5bVmqrdaQuixjpWNOB8S3dzpPjj3Z6k9HFfRzFddFrmq zi8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=32lfFUDyScmqwhlNcaKOeDJIGKlqp2VT7yeXT6qFJe8=; b=tZpBhlDtdZwXNdmIgGoY0mjJLBpj/r2VNKWFO1ZbaJRb3e9PypmOUyxaPWVwKpQWlw yLrKBRBMcAxJrA3o+35yJqtg/GQYLjjtp2snU6Ya4U6ND23P2pTKzy35dJeKB6f1HqYH tSsCsPfnaKRKnXKw3l40j6uIABInG8eyUwsGTnMtuTNQGwiuJbLEqaX3HGUVEI88ZNAe fAF535cWP3abcnNRZXdEDZpYCoJFSmHfrQZODjV5bbtMEK1y5fSLDyLiFHu/Sui8Z545 ONPLHxTTf5a0Z0ZlCqH6Twp1ouqfSmYurI1WaY/0qiGosaw/u3TQNoMRcjRszcIrO3fG l5LA==
X-Gm-Message-State: AJaThX7girHH/wjchQd8DsZJsG2P5yp68P6QkdvO4NfqOold+caxISvj iudWfws0SXQMYH40D8uf6jQgu8tzUSNKzM3AkonLsQ==
X-Google-Smtp-Source: AGs4zMaDm/Rnb779mR3CBEvfMX2RSsPjnvyFCrWih3Ob9/4Bnd7Uo/KDs4BxwT8ipa6qTfhzWLAv8ZcEaih8/L+RLoc=
X-Received: by 10.176.89.81 with SMTP id o17mr5130795uad.12.1510496180141; Sun, 12 Nov 2017 06:16:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.48.85 with HTTP; Sun, 12 Nov 2017 06:16:19 -0800 (PST)
In-Reply-To: <6B1040C5-7182-4D6E-9D12-B2C5EA99D601@gmail.com>
References: <6B1040C5-7182-4D6E-9D12-B2C5EA99D601@gmail.com>
From: Ben Schwartz 
Date: Sun, 12 Nov 2017 09:16:19 -0500
Message-ID: 
To: Bret Jordan 
Cc: "" 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a11465c364a87b8055dc9ccb2"
Archived-At: 
Subject: Re: [TLS] Encrypted SNI hangout
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 12 Nov 2017 14:16:23 -0000

--001a11465c364a87b8055dc9ccb2
Content-Type: multipart/alternative; boundary="001a11465c364127f0055dc9ccb0"

--001a11465c364127f0055dc9ccb0
Content-Type: text/plain; charset="UTF-8"

Let's meet in the room TLS would have had (Padang) for an informal
discussion about encrypted SNI.

On Sun, Nov 12, 2017 at 12:57 AM, Bret Jordan  wrote:

> All,
>
> Since the TLS session on Monday got canceled what would people think about
> using that time to talk about encrypted SNI?
>
> Bret
>
> Sent from my Commodore 128D
>
> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--001a11465c364127f0055dc9ccb0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Let's meet in the room TLS would have had (Padang) for=
 an informal discussion about encrypted SNI.

On Sun, Nov 12, 2017 at 12:57 AM, Bret Jor=
dan <jordan2175@gmail.com> wrote:
All,

Since the TLS session =
on Monday got canceled what would people think about using that time to tal=
k about encrypted SNI? =C2=A0

Bret=C2=A0

Sent from my Commodore 128D

PGP Fingerprint:=C2=A063B4 FC53 680A 6B7D 1447 =
=C2=A0F2C0 74F8 ACAE=C2=A07415 0050

____=
___________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--001a11465c364127f0055dc9ccb0--

--001a11465c364a87b8055dc9ccb2
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg
ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE
BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy
c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw
NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG
A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F
GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes
BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3
Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6
6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB
/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB
ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt
r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n
c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG
CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG
9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse
Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x
t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h
isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA
NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA
AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt
IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw
MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g
bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB
MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB
Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge
C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2
52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua
eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD
rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C
AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG
CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E
LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY
MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt
7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e
oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7
qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT
Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk
WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw
TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x
EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw
HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG
A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi
FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X
17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm
KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp
sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7
DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF
MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL
QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s
bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV
3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr
VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E
7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMEWk1v8tAoqKgb7TXMA0G
CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw
IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDcxNjE4MDA1N1oXDTE4MDEx
MjE4MDA1N1owIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDrrvmiOAZVIqT/TMjrb2h2F3pRDbwPjoYSzvDlNRXLUzcCg2CJ
l36iW3dmk3Uk0b5/75WIQYoQmadF45yr6fGoxDn9+Qu6hik36Cfrnb8Ch8pnX2jC4gYmE91pm30t
/WRb0Bfowu4grOB/zO0vDUZdjFxN/dji7A/mdsk7P5PGcnYxdpnjXSlPTEVxhmheji+DGiCJasrp
NNm4883FD4rFnanXYdnCq7Aku1rkA++G+fTQd+9HxlypxSnhExAit0HqOIyCgajEMb+xtkNCHjDH
FsOH9ruRqlSKc7FlOLvm2RALFx+U9AqWWx28lyEVhsdeFh6hpLEo+Ae8z8CJYs3zAgMBAAGjggFu
MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB
BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j
cnQwHQYDVR0OBBYEFBe3U8DtRm5koQ3yzeR81BIU+BjrMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz
IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v
d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j
cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l
BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQBRIW5hM7R7/1ED1m6w
QFXdOIBKubSej9FmVfD+f9Wv/6ak/8Fbk6ByRSzsScPGnkDT2U3MD20bGa+qp5BbEc3gFMi26AIo
7e/G5NlFY6ejl0qKt0xDqbTC+dBYocL/iEYEoAcr0ddFmnIm+tYzXSqSS9dLxPG/dlRo6OTLqtOm
9mExKPl/poRX59vajzNtGnR8gjHIKYCSsG9DdpYMxdQjbyLe71wv/ehtAUO5TcFQshSTtkqkL0y/
UJn76TjASXDDQE0Ndax1+xKdXaNBXFkhh7s/spJxkTrWAYIR+6Vs11eyRKxHo6yMHV+rN71AQm+P
dXTVU6D7/eZUZaWxeAc+MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv
YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMEWk1v8tA
oqKgb7TXMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCB0hiwBbTRRe7z9rX5cQqJN
v77g0D1jI6bdV49EH31ejzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNzExMTIxNDE2MjBaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB
FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg
hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAxwKQOkqOtAX9mRI1P/WdExJPvWNG0wdFkkDVt4AT
QZdb6QcsOYlaPqjKsFoHAQD1ZZw+8gb/D3qOXCHpZn/5x1pXiig0nciaDlX1sESY+mnyH7s4xyN+
H/UkcB51cKiFOvcPTwGt0nCNJQFsbaxLb/cSBuU4TeT/6rpvJt0zJUqEhp+lcdczl4mf6dcJhGFP
5l+u0ZW72BttrY2vXyiXRx9+dTR7ehWv7cTjb/P04fqkuGMyAuaaRrEiVMmK45oMqXjukAM1IKjd
CqhitaQDf8WVup305wRF9s7yAS7H6gVUq8yiPV242/iH8o0xj1AMuq8YT4QBOY3Wyc5MBGw4Zg==
--001a11465c364a87b8055dc9ccb2--


From nobody Sun Nov 12 16:54:24 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E173D1201F2 for ; Sun, 12 Nov 2017 16:54:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
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 2OrTCnlFYvpA for ; Sun, 12 Nov 2017 16:54:21 -0800 (PST)
Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 647651200C5 for ; Sun, 12 Nov 2017 16:54:21 -0800 (PST)
Received: by mail-pf0-x236.google.com with SMTP id i15so352699pfa.3 for ; Sun, 12 Nov 2017 16:54:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zqOagoJIQW5qTKgqHQFHsUfKl3Sqn7TN2QnNqsnnKuY=; b=Gv5dglKGEXWm4ojkKxdmRYAvF60pM5pNHLx48qK7ZpDwSoMFgrMTeWdCEsgyLa8yj/ iVG2cO3+W+5rfKKcSedaDTvppwhB57rwpSz/bX9PmyPGxys51AuEaoiJWMG2ZhShfywk iJtuW7HMKnxiIGwWLcnoWyABQfjKxbNC863YI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zqOagoJIQW5qTKgqHQFHsUfKl3Sqn7TN2QnNqsnnKuY=; b=Kv/k6m6NmMpQCPtd/XgQ8nisZpz5F5yDYrPbuyb98VjYY5DOT4a4et+Lr6I6HJ7ogL GQpiWr0tvBxfL/QQy0aCxieOOA4Lr6cp9JMlyhV8ViaRth66RrRU6fEFvnjRjyrwUETy 5WcP6s/F/VU6IqIUYoVhjrw5CYlh+CSM3wGsjfp9myb2DAJL0rbtgKU52axcdX342B3H a8tnosp9bs9uBt2xxg/kzY3/3QVt91KtJdvMmhgQsvgpaX4EVTvHa9f8RURC1swcMUvk TuZ/iSMHlvYXG5IhKOPT82W0Ai6XfjlSmDF3IlyN2WBH4jUWg1h5oKIdaRijvqwJTrBU 5bLg==
X-Gm-Message-State: AJaThX7kGIHug1p9UlEwwxOnhWxfMFl+mT2BGFNDE1nfxQI71ttmdeWo YQ0YrulHLuS9zcaz7c/NAo5mDZolOT0=
X-Google-Smtp-Source: AGs4zMbzoDmizqwCMz3k3zD3i1C064Qb5Na99h73Z3JwoKpXzNzGUzuNG4Te/J4eqwPMVoIcrIiAIA==
X-Received: by 10.84.233.10 with SMTP id j10mr7464516plk.14.1510534460781; Sun, 12 Nov 2017 16:54:20 -0800 (PST)
Received: from ?IPv6:2001:67c:370:1999:ccf0:581d:3d91:9a18? ([2001:67c:370:1999:ccf0:581d:3d91:9a18]) by smtp.gmail.com with ESMTPSA id d2sm3620779pfe.164.2017.11.12.16.54.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 16:54:20 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Sean Turner 
In-Reply-To: 
Date: Mon, 13 Nov 2017 08:54:15 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <851B5DF7-E4EB-4DA2-852B-956905032D8C@sn3rd.com>
References: <6B1040C5-7182-4D6E-9D12-B2C5EA99D601@gmail.com> 
To: "" 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] Encrypted SNI hangout
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 00:54:23 -0000

Hi!  I applaud the initiative for suggesting the hangout [0].  Squatting =
in that room ought to be okay but in case the secretariat ends up =
scheduling another IETF session in that room the 12 person room =
(Butterworth) is still available during that time:
=
https://www.ietf.org/registration/MeetingWiki/wiki/doku.php?id=3D100sideme=
etings2
It can be scheduled through the following link:
https://ietf.org/meeting/amreq.html

Cheers,

spt

[0] For those more process oriented folks, Ben and Bret correctly =
identified this as a hangout.  it=E2=80=99s not a WG session that got =
canceled.

> On Nov 12, 2017, at 22:16, Ben Schwartz  wrote:
>=20
> Let's meet in the room TLS would have had (Padang) for an informal =
discussion about encrypted SNI.
>=20
> On Sun, Nov 12, 2017 at 12:57 AM, Bret Jordan  =
wrote:
> All,
>=20
> Since the TLS session on Monday got canceled what would people think =
about using that time to talk about encrypted SNI? =20
>=20
> Bret=20
>=20
> Sent from my Commodore 128D
>=20
> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>=20
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Sun Nov 12 17:16:57 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC319126D85 for ; Sun, 12 Nov 2017 17:16:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 JJ5xNhRX6grK for ; Sun, 12 Nov 2017 17:16:55 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6C4E126CB6 for ; Sun, 12 Nov 2017 17:16:54 -0800 (PST)
Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx6.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eE3Mq-0005IH-7A for tls@ietf.org; Mon, 13 Nov 2017 02:16:53 +0100
Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eE3Mk-0003HV-5y for tls@ietf.org; Sun, 12 Nov 2017 20:16:50 -0500
Received: (qmail 14166 invoked from network); 13 Nov 2017 01:16:44 -0000
Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.39]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 13 Nov 2017 01:16:44 -0000
To: tls@ietf.org
References: <6B1040C5-7182-4D6E-9D12-B2C5EA99D601@gmail.com>  <851B5DF7-E4EB-4DA2-852B-956905032D8C@sn3rd.com>
From: Christian Huitema 
Message-ID: <4dd34215-2e44-94de-ff6d-37c860bb36b0@huitema.net>
Date: Sun, 12 Nov 2017 17:16:40 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <851B5DF7-E4EB-4DA2-852B-956905032D8C@sn3rd.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Originating-IP: 168.144.250.223
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.16)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5gkveBU9aac52n+/EDxkpQsXv9krsgRhBn0ayn6qsUc7RO6saVKtiei5 uUZjs8uJrOfHzJ6mVE7ewsipSVIfs4afHrhBiERUXOOrOgGRA/XFLB67TLnlh9i6Dr2tTQ7u+ixV sSqK0uY3IHbIgqpZAbEhEWyJzIkwSFAW0Pw8uiKe2NqE3QwrymzzH8LWqGR1m7I2v6y+lYBzzWMa L0utsL7rCEQHM1+f3IUKUB9wWYovzx6vjqN+txcrZT5UQnqhoJ5wbg2Zp4DEfSsPKFbX0jWPj+FO ubXhT3IXOeSutdn/GgSV6Ni8cJcVFhcEOifEfOMrNv4muc5NuXwVinsIhaOgGU9UYQoAp/lNIqn2 okjxMFhQHK3JmZta3vargAm/1OHbITKTVSQKTAFVA8cFJettrXEpYYIuwf4B2A6gOnpwQp8yzyqN Ah52fPHg5t2q2BqZR3KVQgqF/fPYYAfEfsiiCi+/WFq5w5MWJsVe3U/6k1n+SYDehzxY5H9Qen7M zw+aFDjdN1FpQsfh3LRAVyaBQ5eKj6MUa9KfPAvxvWyWT4RXC/v261lNS3iZqUf5OA4U9Xw5Uo2K LQdKsYidsA0RFZ4oobg8BBg3Jq+ntzj0oIACrlaKZSLGHkJ0OuOy7AQQ/nsetUhuYMuf7MD+Xorw XiYVHQrUkmU6nslDePGmc5DI/exkFeviC3xuclri+Yool8X0+BvzGRRfxR+ffyg7ic0+wIe9JFgm Iv/ATh4OEdUkKn9HjbaNbvTm+oyyXzRvQg0kSsqDHFL51WJsx88DO2rOsK3hNn/Au26Nj+2lUGlP 9nCUO1/T3hbtM3dprmUVrBsPGnNiJ83AD/4JscDdpjPAXF36ccukK2jUdhJTBUmsltvK9h2NrJzJ uG6g9+lNC4wc2LkM7XQE4YLVklOcIA9nWuJMoxLUn/yzif+v
X-Report-Abuse-To: spam@quarantine6.antispamcloud.com
Archived-At: 
Subject: Re: [TLS] Encrypted SNI hangout
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 01:16:57 -0000

On 11/12/2017 4:54 PM, Sean Turner wrote:

> Hi!  I applaud the initiative for suggesting the hangout [0].  Squatting in that room ought to be okay but in case the secretariat ends up scheduling another IETF session in that room the 12 person room (Butterworth) is still available during that time:
> https://www.ietf.org/registration/MeetingWiki/wiki/doku.php?id=100sidemeetings2
> It can be scheduled through the following link:
> https://ietf.org/meeting/amreq.html
>
> Cheers,
>
> spt
>
> [0] For those more process oriented folks, Ben and Bret correctly identified this as a hangout.  it’s not a WG session that got canceled.
>

The SNI Encryption draft is maintained on the TLS WG Github, at
https://github.com/tlswg/sniencryption. It would be really nice if after
or during the discussions someone opened issues and possibly PR.

Thanks, and sorry I could not join you in Singapore

-- Christian Huitema


From nobody Sun Nov 12 19:58:19 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBA7129437 for ; Sun, 12 Nov 2017 19:58:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 vPtFZXsEY6kk for ; Sun, 12 Nov 2017 19:58:10 -0800 (PST)
Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (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 DF81B126DCA for ; Sun, 12 Nov 2017 19:58:09 -0800 (PST)
Received: by mail-ua0-x234.google.com with SMTP id r11so2893472uah.12 for ; Sun, 12 Nov 2017 19:58:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to;  bh=db0yhqUAyNR8Z8s3sq9eEGHiPMqd7uRc7R2JaVkYNOg=; b=bmK7vRjzDOXSoF5sL2WKri6cKVNdaKF6GtvMZ/jjl6gtrcCF7gJLy6wuPB+tFFyPS5 4h6SoF9opWEaF36ijHGWDcRBwecYzA0VKMdiGVN8NLR8F1q45KcAlGEZQiKiVlvnAdq8 d+/WFTXHQ7szB4j8+sI7msBZiX/E5A2GBlPdJi5i6I9b21OZ2oc435+c5Ap38IBBIlUi t2hY6ZxTnFwLs80jjA+UK4ZliiMmIqWvQqtCxN0QYvLmGMlNgN/GNsAqOnD3UNIA/dLz Fqb5KcFO1xQkjVQszTA30UOh7/S+xm81Ad9zcYBGpxucY0obYlC187TnizfwsBYy1Csk m+HA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=db0yhqUAyNR8Z8s3sq9eEGHiPMqd7uRc7R2JaVkYNOg=; b=Z2b2Xgu2z4QnhYUx2wMsR8bahbxvCAf0ldVppc/av5DI/L3CGo7IaYilNqsMlOHoPX Sdx7OuZv4/qJIaZy36teQ1i6CkSIgtKcPgzQ8xU1rZWMzXsMv5uWEiPY0XXE2xVMMHbQ DzHtgrZuihjCYkU5ApNq0FP7H2jr4r+Tcr4AKFPPEP6+cgxPoApBAj+kLmtVoy3pehXe o2bhQynrvyG4fxU4q8TP5l2OGTFssArrG1rCKSAxA1V238i4D0SN/K0Y3TAkAYkm5i15 eVE6d6Gmb+N3gKNVOaVufoVEtw/LmyUH46aETr6//KIzWeXoxDKivVZHGU4vrlL9TLVk 9NXg==
X-Gm-Message-State: AJaThX6bV2Gw59YDBXz/L3kRQE9kjqyAjy5YhUnF2ZFMcEhuuAZECnIg 3eTOTXAA5dsjfuXW5RdRWwTtZm0CWpbu5KJlIM4=
X-Google-Smtp-Source: AGs4zMbI9q2Rp7mIA9pQq/44T4z13Nb+5B9FYAHzrWUoXDLb1HcUNgMhn4OALXmsa1eIkUNzJxJENyqMW25HUnrp4EA=
X-Received: by 10.176.83.132 with SMTP id k4mr5814295uaa.144.1510545489082; Sun, 12 Nov 2017 19:58:09 -0800 (PST)
MIME-Version: 1.0
References: <6B1040C5-7182-4D6E-9D12-B2C5EA99D601@gmail.com>  <851B5DF7-E4EB-4DA2-852B-956905032D8C@sn3rd.com> <4dd34215-2e44-94de-ff6d-37c860bb36b0@huitema.net>
In-Reply-To: <4dd34215-2e44-94de-ff6d-37c860bb36b0@huitema.net>
From: Darin Pettis 
Date: Mon, 13 Nov 2017 03:57:58 +0000
Message-ID: 
To: Christian Huitema , tls@ietf.org
Content-Type: multipart/alternative; boundary="f403045e3db04b3be3055dd547b2"
Archived-At: 
Subject: Re: [TLS] Encrypted SNI hangout
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 03:58:18 -0000

--f403045e3db04b3be3055dd547b2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Sean - thank you for the update and options on rooms.

Ben and Brett - which room should we meet in?

Initially opposed to encrypting SNI as it appears to break many services
that utilize it but curious to hear more.   Thx

On Mon, Nov 13, 2017 at 9:17 AM Christian Huitema 
wrote:

> On 11/12/2017 4:54 PM, Sean Turner wrote:
>
> > Hi!  I applaud the initiative for suggesting the hangout [0].  Squattin=
g
> in that room ought to be okay but in case the secretariat ends up
> scheduling another IETF session in that room the 12 person room
> (Butterworth) is still available during that time:
> >
> https://www.ietf.org/registration/MeetingWiki/wiki/doku.php?id=3D100sidem=
eetings2
> > It can be scheduled through the following link:
> > https://ietf.org/meeting/amreq.html
> >
> > Cheers,
> >
> > spt
> >
> > [0] For those more process oriented folks, Ben and Bret correctly
> identified this as a hangout.  it=E2=80=99s not a WG session that got can=
celed.
> >
>
> The SNI Encryption draft is maintained on the TLS WG Github, at
> https://github.com/tlswg/sniencryption. It would be really nice if after
> or during the discussions someone opened issues and possibly PR.
>
> Thanks, and sorry I could not join you in Singapore
>
> -- Christian Huitema
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--f403045e3db04b3be3055dd547b2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Sean - thank you for the update and options on rooms=
. =C2=A0

Ben and Brett -=
 which room should we meet in?

Initially opposed to encrypting SNI as it appears to break many serv=
ices that utilize it but curious to hear more. =C2=A0 Thx

On Mon, Nov 13, 2017 at 9:17 AM Christian Huitema &=
lt;huitema@huitema.net> wrote=
:
On 11/12/2017 4:54 PM, Sean Turne=
r wrote:



> Hi!=C2=A0 I applaud the initiative for suggesting the hangout [0].=C2=
=A0 Squatting in that room ought to be okay but in case the secretariat end=
s up scheduling another IETF session in that room the 12 person room (Butte=
rworth) is still available during that time:

> https://www.ie=
tf.org/registration/MeetingWiki/wiki/doku.php?id=3D100sidemeetings2

> It can be scheduled through the following link:

> https://ietf.org/meeting/amreq.html

>

> Cheers,

>

> spt

>

> [0] For those more process oriented folks, Ben and Bret correctly iden=
tified this as a hangout.=C2=A0 it=E2=80=99s not a WG session that got canc=
eled.

>



The SNI Encryption draft is maintained on the TLS WG Github, at

https://github.com/tlswg/sniencryption. It would be really=
 nice if after

or during the discussions someone opened issues and possibly PR.



Thanks, and sorry I could not join you in Singapore



-- Christian Huitema



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls




--f403045e3db04b3be3055dd547b2--


From nobody Sun Nov 12 21:57:57 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41A41287A5 for ; Sun, 12 Nov 2017 21:57:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 KbNzWCEN4cKC for ; Sun, 12 Nov 2017 21:57:54 -0800 (PST)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 D0805127977 for ; Sun, 12 Nov 2017 21:57:53 -0800 (PST)
Received: by mail-yw0-x236.google.com with SMTP id k191so4129459ywe.1 for ; Sun, 12 Nov 2017 21:57:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/9T4d8YLwAOyZdAhhAPYx9DferlrGDsAU/by+5duCFQ=; b=gJIeOndTFIXQ8KDRbfz2mjNC67Z7weJK2n8lIhu9vKE7H31p8WnjRsYN0ADzrYzuYR AHeL2jlpJ8t5ZEPLghuGpLm0rdZyW9Nr7OjIK+lJLVix0MNJJvDWXkwZ0anjqELKW4f1 Z5tzd6MLT/e77kH8dogNQyaTQsdXEO4yDB/GqJSfp8vA4LTV+YJ9wiqQiAnU0nVnYxoL MwzoCWpZOKYYQSeifTFfyE802xwEaX/wqtjVPdEaEbuoPDB8SVtsLpN8aLLeo3EAUuR5 B+jzTVoYGP4WH9WeWVK+qP7Auaa3g6JXgufzckTNTXToqP+ulP4r7ZWtQfTJrOazRudF QFzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/9T4d8YLwAOyZdAhhAPYx9DferlrGDsAU/by+5duCFQ=; b=tmAk1sNy387Zmu6DOyV6ISUdd7i1n1+Kl8kj+V8sULeSdE0DhX4+Z/PdKf4J1zahBI yQdZGGifgKwww+zDwzFP1vaRq30jIiZdzsthrZTeBtvGcNgn0acE5YPLiMWKOKW5ijPB gDHpv/PobtupuyMmK6e1o9ag5/yU8XQ5DYX/aZf6seldK6S81YPdXglAvFjxOIFiMXY5 4DFO9dYi8vYKQM4pxqQUf6n4OE11sv/1zIwvtod1OderwBfSQXeoTB4PK4gD1VlROjoT Q7lVXCLcIUbWlqEvBKPoS5JuIWwIyXVpZMsRikrHOiyhgI17Oh9X9lDcPeW6Q0CLwq7R 1+2g==
X-Gm-Message-State: AJaThX7YAze7DrKx4qTS5jLGpMOrLkk+KF0aMLxWcp++R397RCSORehW hdPu7HjeNgRdquTM+fqabq5+S+Ua41+Lky5Cqwk80g==
X-Google-Smtp-Source: AGs4zMY0IIaTxPcKlRm0p2Fh1x47gY+YyVM2HCSNHX4FEIFhquUDwQofP/nJgk0JQZqyBwCktKSboLfCPZDAZ7ir2Vk=
X-Received: by 10.37.119.65 with SMTP id s62mr5049983ybc.339.1510552673141; Sun, 12 Nov 2017 21:57:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.61.12 with HTTP; Sun, 12 Nov 2017 21:57:12 -0800 (PST)
In-Reply-To: 
References: <6B1040C5-7182-4D6E-9D12-B2C5EA99D601@gmail.com>  <851B5DF7-E4EB-4DA2-852B-956905032D8C@sn3rd.com> <4dd34215-2e44-94de-ff6d-37c860bb36b0@huitema.net> 
From: Eric Rescorla 
Date: Mon, 13 Nov 2017 05:57:12 +0000
Message-ID: 
To: Darin Pettis 
Cc: Christian Huitema , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114ba4447f4aff055dd6f3c1"
Archived-At: 
Subject: Re: [TLS] Encrypted SNI hangout
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 05:57:56 -0000

--001a114ba4447f4aff055dd6f3c1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I already have a conflict for this, so I will not be attending.

-Ekr


On Mon, Nov 13, 2017 at 3:57 AM, Darin Pettis  wrote:

> Sean - thank you for the update and options on rooms.
>
> Ben and Brett - which room should we meet in?
>
> Initially opposed to encrypting SNI as it appears to break many services
> that utilize it but curious to hear more.   Thx
>
> On Mon, Nov 13, 2017 at 9:17 AM Christian Huitema 
> wrote:
>
>> On 11/12/2017 4:54 PM, Sean Turner wrote:
>>
>> > Hi!  I applaud the initiative for suggesting the hangout [0].
>> Squatting in that room ought to be okay but in case the secretariat ends=
 up
>> scheduling another IETF session in that room the 12 person room
>> (Butterworth) is still available during that time:
>> > https://www.ietf.org/registration/MeetingWiki/wiki/
>> doku.php?id=3D100sidemeetings2
>> > It can be scheduled through the following link:
>> > https://ietf.org/meeting/amreq.html
>> >
>> > Cheers,
>> >
>> > spt
>> >
>> > [0] For those more process oriented folks, Ben and Bret correctly
>> identified this as a hangout.  it=E2=80=99s not a WG session that got ca=
nceled.
>> >
>>
>> The SNI Encryption draft is maintained on the TLS WG Github, at
>> https://github.com/tlswg/sniencryption. It would be really nice if after
>> or during the discussions someone opened issues and possibly PR.
>>
>> Thanks, and sorry I could not join you in Singapore
>>
>> -- Christian Huitema
>>
>> _______________________________________________
>> 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
>
>

--001a114ba4447f4aff055dd6f3c1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I already have a conflict for this, so I will not be atten=
ding.

-Ekr


On Mon, Nov 13, 2017 at 3:57 AM, Dar=
in Pettis <dpp.edco@gmail.com> wrote:
Sean - thank you for the update and op=
tions on rooms. =C2=A0

B=
en and Brett - which room should we meet in?

Initially opposed to encrypting SNI as it appears to b=
reak many services that utilize it but curious to hear more. =C2=A0 Thx

On Mon, Nov 13=
, 2017 at 9:17 AM Christian Huitema <huitema@huitema.net> wrote:
On 11/12/2017 4:54 PM, Sean Turner wrote:



> Hi!=C2=A0 I applaud the initiative for suggesting the hangout [0].=C2=
=A0 Squatting in that room ought to be okay but in case the secretariat end=
s up scheduling another IETF session in that room the 12 person room (Butte=
rworth) is still available during that time:

> https://www.ie=
tf.org/registration/MeetingWiki/wiki/doku.php?id=3D100sidemeeting=
s2

> It can be scheduled through the following link:

> https://ietf.org/meeting/amreq.html

>

> Cheers,

>

> spt

>

> [0] For those more process oriented folks, Ben and Bret correctly iden=
tified this as a hangout.=C2=A0 it=E2=80=99s not a WG session that got canc=
eled.

>



The SNI Encryption draft is maintained on the TLS WG Github, at

https://github.com/tlswg/sniencryption. It would be r=
eally nice if after

or during the discussions someone opened issues and possibly PR.



Thanks, and sorry I could not join you in Singapore



-- Christian Huitema



_______________________________________________

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





--001a114ba4447f4aff055dd6f3c1--


From nobody Mon Nov 13 03:37:26 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42D6126CD8 for ; Mon, 13 Nov 2017 03:37:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level: 
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 fNIHuTTNWBuk for ; Mon, 13 Nov 2017 03:37:22 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DF19124BFA for ; Mon, 13 Nov 2017 03:37:22 -0800 (PST)
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 002A72CE92F; Mon, 13 Nov 2017 11:37:22 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C20E570A1E; Mon, 13 Nov 2017 11:37:21 +0000 (UTC)
From: Hubert Kario 
To: tls@ietf.org
Date: Mon, 13 Nov 2017 12:37:15 +0100
Message-ID: <3025542.QI1GADQRnG@pintsize.usersys.redhat.com>
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2265732.qeKQ7pAz3o"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Mon, 13 Nov 2017 11:37:22 +0000 (UTC)
Archived-At: 
Subject: Re: [TLS] close_notify and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 11:37:24 -0000

--nextPart2265732.qeKQ7pAz3o
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Saturday, 11 November 2017 10:21:11 CET David Schinazi wrote:
> Hello all,
>=20
> Currently TLS 1.3 specifies close_notify in the same way that TLS 1.2 did.
> I believe that has issues and this might be the right time to fix them.
> The purpose of close_notify is to protect against data truncation attacks,
> each side is required to send close_notify before closing the write side =
of
> the transport connection so the other side knows that the data was not
> truncated. As such, close_notify only needs half-close semantics to preve=
nt
> truncation.
>=20
> However, the specification contains the following text:
> << Each party MUST send a =E2=80=9Cclose_notify=E2=80=9D alert before clo=
sing the write side
> of the connection, unless some other fatal alert has been transmitted. The
> other party MUST respond with a =E2=80=9Cclose_notify=E2=80=9D alert of i=
ts own and close
> down the connection immediately, discarding any pending writes. >>
>=20
> This means that an application-layer client can't send a query then close
> their write transport when they know that they're done, because the server
> would terminate the TLS session before sending the reply. On top of this,
> when the server receives the close_notify, it may have already sent part =
of
> the reply (or wrote it to the socket send buffer) so the responding
> close_notify would in effect be inflicting a truncation attack on the
> client.
>=20
> This doesn't make much difference for HTTP because clients already
> don't close their write transport after sending a reply, however having t=
he
> option do do this could allow innovation in new protocols that can define
> the semantics of when they use close_notify. An example is DNS PUSH:
> https://tools.ietf.org/html/draft-ietf-dnssd-push
> 
>=20
> A proposal to solve this problem would be to give close_notify half-close
> semantics: we keep the requirements that a close_notify be sent before
> closing the transport, and that any data received after a close_notify is
> ignored, but we simply remove the requirement to immediately reply
> with a close_notify. This has the advantage that current implementations
> are already compliant but future ones can leverage this improvement.
>=20
> What do you think? Is this worth discussing on Thursday?

what about alerts?

if you half-closed the connection for write and then received key-update, o=
r=20
message with an invalid tag, how are you supposed to react to it?

=2D-=20
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00  Brno, Czech Republic
--nextPart2265732.qeKQ7pAz3o
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCgAGBQJaCYPrAAoJEJKo0bgB0vX1UUQP/RZXggjfuitg8Gorx4QJ5u40
156M6e1VosYPjzswfzirfM0GnezOuLaNogwfiZC+lu7FpLehfxvssd9EV97anSeW
xfhuE1Xq1g3tA67v+RhFbrzNwTSFRb3Zzqi9bHYXcZcqMP2hhpNrPYmJ+0OS1Ci5
mxpJzFCUOHr1hRgnpNr6liXp9/SIJ9cUoP7cPwA9G+1HU70JC3PBO+c8e9AiYuGl
nM4xLZLwZOU+yNd4c8x1HrES72V68eeRgzigrsAko6/m+/oRtG+oeeX5ImihiZn6
oXDkA4TS38ELjKe2NnM+7OE1KU8OpFmBCGcAYUfP5A6+FRBNehTX0JnDKedig1Lj
AycRn+I4dyY7H9y9apeQAInAdWNSoEsh6pRbR5Eu8dQTukh6itq+mph9QtRSK/km
D3oJ0/QOCcq/Pi7KPJTBuDd7oojDrMt38YagjnbPmRjMhkoj0VGtw5VCY1FfElou
4mOxw98xAfKOE3ZHPSAku7CGb8a9H/Pbt+y4TnrrlUT4btezCFQSDpTv9ToksQBT
NfovkQhHdfb5AFZ/OJZeeAnN2FlqZfTIm8rzJwTfiE1PZeirVp8VuUaipXHLBz2E
JLvZDONWuZ472lbst4jwpLsjxvA3UmfN/0EYHnUykcT9nfCoMRQQcIvX5QIRhnX4
g/4wQPYQjHoV1hNGF8HS
=Rzzi
-----END PGP SIGNATURE-----

--nextPart2265732.qeKQ7pAz3o--


From nobody Mon Nov 13 04:25:52 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33FE6128959 for ; Mon, 13 Nov 2017 04:25:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 fdZDkE-t-HeG for ; Mon, 13 Nov 2017 04:25:49 -0800 (PST)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 09ED4124BFA for ; Mon, 13 Nov 2017 04:25:49 -0800 (PST)
Received: by mail-yw0-x236.google.com with SMTP id d2so8706569ywb.11 for ; Mon, 13 Nov 2017 04:25:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XdgaFkPDBHUin70YOjtsxuXPY4ckUqIuR7v4K3Rl4dQ=; b=QOI3Jd6EoWaTHKbB59uv+v8CmF2/gl3xntXRrW9GtlV6DWjB4ZxIeE0Ajvg5pXYLjq 8eh59LKB3ZqO6yxmBIRVhBmw6IwilGsinu8znIgxejB2zKbT7pnjkHpIV0de2HbYZxhe Xa65paut0ZRgZuMcdmAo9uFupa4fnZSP/11jFe3tG42HtEheAHTcyLNuLT7ty1rCQ+D4 BIxJmfsxlLoeFqpwqk3G4LGk8O6Grm6vn5szAkNYx+H3FVoRok95efoxr0tz62vQG3iq IX3rQKo83N/kYY5/RuakVe0rrIASNvnQankbZcxmyCELLGzzmaZ3uEmbxigLwpP+6dWl ZzPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XdgaFkPDBHUin70YOjtsxuXPY4ckUqIuR7v4K3Rl4dQ=; b=nxzrz+kqrnhPkvF8DIAssHwR1WGeH5jf4+lloWQpCQ5JBTB9YZbmEiHqW2QADdFGyF 5EgAQQ1/RGc05iS+n3/FwWpS47oNUK/tGRVStjIC47c6Dv3Eo486mHTiMvO63IrlpwgV iZawng3NDSHwD5KIsAC3nzWhHJWNCIF2jdPBgR3yYubOVu3dvKWOot2VaAXDG0inYkGl XAZN25TYeRjXWbzMkcvKLz5262RqDucEEo+Pcp3pHfeo+4FUbFqGU8gsQytEYYa3cKRh 9ITfYma2xeX5fgJN9b+0pQtCYF8i9fH4Qdq0IVCSSwzjc0thm0/ys7S9rfoD44cKdpeZ qqvQ==
X-Gm-Message-State: AJaThX6xdhqQ0rbagvOKayS7N8aDKifE6HcjlZD5+kwGkCIWpsAp+sNX Ktk5Oljis//tJ5jXKw/EnYAvazk9vyHV3Q2Sc0TDQQ==
X-Google-Smtp-Source: AGs4zMYNs+UiJYQIVYtySv7JsmPU2p7S/SVqr1eCthqIcX9Zmmi+Zq0uYSE6Hcqpp+kp0mjhydXwqKjA25s7dHuKxAk=
X-Received: by 10.13.192.196 with SMTP id b187mr5823950ywd.416.1510575948313;  Mon, 13 Nov 2017 04:25:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.61.12 with HTTP; Mon, 13 Nov 2017 04:25:07 -0800 (PST)
In-Reply-To: <3025542.QI1GADQRnG@pintsize.usersys.redhat.com>
References:  <3025542.QI1GADQRnG@pintsize.usersys.redhat.com>
From: Eric Rescorla 
Date: Mon, 13 Nov 2017 12:25:07 +0000
Message-ID: 
To: Hubert Kario 
Cc: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114edd48ce5aae055ddc5e67"
Archived-At: 
Subject: Re: [TLS] close_notify and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 12:25:51 -0000

--001a114edd48ce5aae055ddc5e67
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 13, 2017 at 11:37 AM, Hubert Kario  wrote:

> On Saturday, 11 November 2017 10:21:11 CET David Schinazi wrote:
> > Hello all,
> >
> > Currently TLS 1.3 specifies close_notify in the same way that TLS 1.2
> did.
> > I believe that has issues and this might be the right time to fix them.
> > The purpose of close_notify is to protect against data truncation
> attacks,
> > each side is required to send close_notify before closing the write sid=
e
> of
> > the transport connection so the other side knows that the data was not
> > truncated. As such, close_notify only needs half-close semantics to
> prevent
> > truncation.
> >
> > However, the specification contains the following text:
> > << Each party MUST send a =E2=80=9Cclose_notify=E2=80=9D alert before c=
losing the write
> side
> > of the connection, unless some other fatal alert has been transmitted.
> The
> > other party MUST respond with a =E2=80=9Cclose_notify=E2=80=9D alert of=
 its own and close
> > down the connection immediately, discarding any pending writes. >>
> >
> > This means that an application-layer client can't send a query then clo=
se
> > their write transport when they know that they're done, because the
> server
> > would terminate the TLS session before sending the reply. On top of thi=
s,
> > when the server receives the close_notify, it may have already sent par=
t
> of
> > the reply (or wrote it to the socket send buffer) so the responding
> > close_notify would in effect be inflicting a truncation attack on the
> > client.
> >
> > This doesn't make much difference for HTTP because clients already
> > don't close their write transport after sending a reply, however having
> the
> > option do do this could allow innovation in new protocols that can defi=
ne
> > the semantics of when they use close_notify. An example is DNS PUSH:
> > https://tools.ietf.org/html/draft-ietf-dnssd-push
> > 
> >
> > A proposal to solve this problem would be to give close_notify half-clo=
se
> > semantics: we keep the requirements that a close_notify be sent before
> > closing the transport, and that any data received after a close_notify =
is
> > ignored, but we simply remove the requirement to immediately reply
> > with a close_notify. This has the advantage that current implementation=
s
> > are already compliant but future ones can leverage this improvement.
> >
> > What do you think? Is this worth discussing on Thursday?
>
> what about alerts?


> if you half-closed the connection for write and then received key-update,


I assume you mean with update_requested set. in any case, you do nothing:

If the request_update field is set to "update_requested" then the receiver
MUST
send a KeyUpdate of its own with request_update set to
"update_not_requested" prior
to sending its next application data record.



> or
> message with an invalid tag, how are you supposed to react to it?
>

I think it would be fine to either silently tear down the connection or to
send an alert.

-Ekr


>
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00  Brno, Czech Republic
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--001a114edd48ce5aae055ddc5e67
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Nov 13, 2017 at 11:37 AM, Hubert Kario <hkario@redhat.com&=
gt; wrote:
On Saturday, 11 November 20=
17 10:21:11 CET David Schinazi wrote:

> Hello all,

>

> Currently TLS 1.3 specifies close_notify in the same way that TLS 1.2 =
did.

> I believe that has issues and this might be the right time to fix them=
.

> The purpose of close_notify is to protect against data truncation atta=
cks,

> each side is required to send close_notify before closing the write si=
de of

> the transport connection so the other side knows that the data was not=


> truncated. As such, close_notify only needs half-close semantics to pr=
event

> truncation.

>

> However, the specification contains the following text:

> << Each party MUST send a =E2=80=9Cclose_notify=E2=80=9D alert b=
efore closing the write side

> of the connection, unless some other fatal alert has been transmitted.=
 The

> other party MUST respond with a =E2=80=9Cclose_notify=E2=80=9D alert o=
f its own and close

> down the connection immediately, discarding any pending writes. >&g=
t;

>

> This means that an application-layer client can't send a query the=
n close

> their write transport when they know that they're done, because th=
e server

> would terminate the TLS session before sending the reply. On top of th=
is,

> when the server receives the close_notify, it may have already sent pa=
rt of

> the reply (or wrote it to the socket send buffer) so the responding
> close_notify would in effect be inflicting a truncation attack on the<=
br>
> client.

>

> This doesn't make much difference for HTTP because clients already=


> don't close their write transport after sending a reply, however h=
aving the

> option do do this could allow innovation in new protocols that can def=
ine

> the semantics of when they use close_notify. An example is DNS PUSH:
> https://tools.ietf.org/html/draft-ietf-dn=
ssd-push

> <https://tools.ietf.org/html/draft-ie=
tf-dnssd-push>

>

> A proposal to solve this problem would be to give close_notify half-cl=
ose

> semantics: we keep the requirements that a close_notify be sent before=


> closing the transport, and that any data received after a close_notify=
 is

> ignored, but we simply remove the requirement to immediately reply

> with a close_notify. This has the advantage that current implementatio=
ns

> are already compliant but future ones can leverage this improvement.
>

> What do you think? Is this worth discussing on Thursday?




what about alerts?



if you half-closed the connection for write and then received key-update,

I assume you mean with update_requested set.=
 in any case, you do nothing:

If the request_=
update field is set to "update_requested" then the receiver MUST<=
/div>
send a KeyUpdate of its own with request_update set to "upda=
te_not_requested" prior
to sending its next application data=
 record.

=C2=A0
 or

message with an invalid tag, how are you supposed to react to it?

I think it would be fine to either silently tear=
 down the connection or to send an alert.

-Ekr
=C2=A0



--

Regards,

Hubert Kario

Senior Quality Engineer, QE BaseOS Security team

Web: www.cz.redhat.com

Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech Republic=

_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--001a114edd48ce5aae055ddc5e67--


From jordan.ietf@gmail.com  Mon Nov 13 05:28:26 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1684C1243F3 for ; Mon, 13 Nov 2017 05:28:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 bg02lh28E4tF for ; Mon, 13 Nov 2017 05:28:24 -0800 (PST)
Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 57EB3129445 for ; Mon, 13 Nov 2017 05:28:24 -0800 (PST)
Received: by mail-it0-x234.google.com with SMTP id b5so3029249itc.3 for ; Mon, 13 Nov 2017 05:28:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=fv1OY5YeIN8XHQgSM4My09fkR+fNRbtAOPgDaXCy01o=; b=o2LmwHclGSxxjXbvVxEpYbf8wuoQUjSQ5EtBn5qkLIolvt9kIeY66oZgTk3v8iajgi s7RsMbG7qprp6VafNHuiJ8aiSGQN3Mg/YBhvLgj/URxuY4Y8ZNTzSa/XHzxanMs44IrN jHuvtgge/nfAR/oavy22qnRUcHrWQIohutPyQNSULKEw7WSDskLr7eK1d3bLhx/bJq8T SBZJc6KUL/CiWAuCtuKHpBufQ6ZMSeAuyma0OzENoBUyqBtqBTWnQPGZ1/Qe9avLsOIF zZlABXpbiIdRg0Bq2H4GCAx1MElZSBvttK60C4Ip8pjCsyHKt6Q+qhYaftoOCNsr9x95 IoHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=fv1OY5YeIN8XHQgSM4My09fkR+fNRbtAOPgDaXCy01o=; b=t6fM5q2UqUZNel3l+mCmnKIX9WSvlucj1nJT2KK1OHeX1nWKMiQaKaD3wj+MBwxD5w n7qcqpDFXqHxUGjjCZHlivaO/V/qq356UT0Z4cCAM2NXHwRH6AvZccYqhzQuWDUikA8B cQnnyAkG1+dawPxRxHJZhrLB3qHKFFnv5DxTkd3MvBMKceLfCHlCznYeaV05nn/Oj9XT g46UCNVhT4zzboDcprUwj93XHP3tiXyZIpf+cSAg4eHN+lCf+lifz3/0iC2mk2RIQp9V hctlqFk3YIifSSSbYauLd9DtFtJCT9mF/t91KGHisVUtqmGeTan8NWshEVLMEs9j5C7Y dDCg==
X-Gm-Message-State: AJaThX5lHrPJDMNL60QnlgBF4y+nQusVYfb4rX/95zURdLdhO4CL/XvI lozt941iO3xbwJ1Wt6zA2r1au+f/6/ZeJkmSi5wdOA==
X-Google-Smtp-Source: AGs4zMYOq3kXT+DGiPjIIrnANqXnEgg5EgWNyql2AbAwsxnkriC1wFJNL79rhrfEsard7uWPvK2RpivlrPYGkRG2DOY=
X-Received: by 10.36.250.72 with SMTP id v69mr4713647ith.120.1510579703600; Mon, 13 Nov 2017 05:28:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.47.141 with HTTP; Mon, 13 Nov 2017 05:28:23 -0800 (PST)
From: Bret Jordan 
Date: Mon, 13 Nov 2017 21:28:23 +0800
Message-ID: 
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c030cc8a35b9d055ddd3ebf"
Archived-At: 
Subject: [TLS] Tonight's Encrypted SNI Hangout Session
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 13:35:17 -0000

--94eb2c030cc8a35b9d055ddd3ebf
Content-Type: text/plain; charset="UTF-8"

All,

We had a great turnout tonight for the encrypted SNI hangout session.
Everyone seemed open and willing to work together to understand the
complexities that sit before us. Several interesting and important views
were expressed, and I feel that the meeting was ultimately a success. In
fact, I believe we should do more hangout sessions like this.

Take aways from the meeting:
1) We are starting to understand the problem that we are trying to solve

2) We need to ensure that any potential solution will in fact solve the
problems as we understand it and not make the problem worse

3) We need to compile a list of use cases and scenarios in a draft document
that talk about how the SNI (for good or for bad) is being used today and
what an encrypted SNI will mean for these use cases.

4) We need to make sure we get feedback and information from at least the
telco sector, large enterprise, financial sector, and the health care
sector.


I believe this information will help us better understand both sides of the
issue, shed light in to what it will mean, help us define the "why" we are
doing this, and ultimately feed and foster a better technological solution.
If you have or know of scenarios or use-cases where the SNI is being used
by network operators, system administrators, security engineers, products,
etc, please send them to me so I can start compiling them in to a draft
document.

Side question, it feels like this effort could represent a lot of work and
require a lot of dedicated cycles. Does it make sense to continue this
effort inside of the TLS WG?  If it does, will the WG give us the time,
mindshare, and cycles to focus on it (just asking the hard question)?

Once again, thanks all for attending the session tonight.

Bret

-- 

Sent from my TI-99/4A

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

--94eb2c030cc8a35b9d055ddd3ebf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


All,

We had a great turnout =
tonight for the encrypted SNI hangout session. Everyone seemed open and wil=
ling to work together to understand the complexities that sit before us. Se=
veral interesting and important views were expressed, and I feel that the m=
eeting was ultimately a success. In fact, I believe we should do more hango=
ut sessions like this.

Take aways from the meeting=
:
1) We are starting to understand the problem that we are trying=
 to solve

2) We need to ensure that any potential =
solution will in fact solve the problems as we understand it and not make t=
he problem worse

3) We need to compile a list of u=
se cases and scenarios in a draft document that talk about how the SNI (for=
 good or for bad) is being used today and what an encrypted SNI will mean f=
or these use cases.=C2=A0

4) We need to make sure =
we get feedback and information from at least the telco sector, large enter=
prise, financial sector, and the health care sector.=C2=A0


I believe this information will help us better unde=
rstand both sides of the issue, shed light in to what it will mean, help us=
 define the "why" we are doing this, and ultimately feed and fost=
er a better technological solution. If you have or know of scenarios or use=
-cases where the SNI is being used by network operators, system administrat=
ors, security engineers, products, etc, please send them to me so I can sta=
rt compiling them in to a draft document.=C2=A0

Si=
de question, it feels like this effort could represent a lot of work and re=
quire a lot of dedicated cycles. Does it make sense to continue this effort=
 inside of the TLS WG?=C2=A0 If it does, will the WG give us the time, mind=
share, and cycles to focus on it (just asking the hard question)?

Once again, thanks all for attending the session tonight.

Bret

-- 

Sent fr=
om my TI-99/4A

PGP Fingerprint:=C2=A0=
63B4 FC53 680A 6B7D 1447 =C2=A0F2C0=
 74F8 ACAE=C2=A07415 0050




--94eb2c030cc8a35b9d055ddd3ebf--


From nobody Mon Nov 13 05:38:08 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC2C1296D2 for ; Mon, 13 Nov 2017 05:38:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 jOzILgAh0rSJ for ; Mon, 13 Nov 2017 05:38:03 -0800 (PST)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 E3C44129584 for ; Mon, 13 Nov 2017 05:38:02 -0800 (PST)
Received: by mail-qt0-x232.google.com with SMTP id v41so19462667qtv.12 for ; Mon, 13 Nov 2017 05:38:02 -0800 (PST)
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 :cc; bh=0WMI/FyifQAB7AW8EVpX+jQOqOrysCdrALyRRcpiX4Y=; b=aNLvYHvj3qDm981atUKtvdED58+pQZsO4XCkaEJ3y3y8vVHVXviHfPdT+GQcOkNKio fkJWY1geKvfOFPCGZtyy2XUSmGtfoH9acWkRK2Fpsp9j4L9PuoeA2ldbTsYAvnmN2Ilf 9DifW9TftCGNSUuCCqTrshiRC8gGZbGmVdCS0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0WMI/FyifQAB7AW8EVpX+jQOqOrysCdrALyRRcpiX4Y=; b=hXdT4oWu/4CH+LLm2OhNf9H3ACjSyKSbPO3IbPzQ5orob2h0pQ2utpuamRhMFcgSWb 61ejOuvC+LeYPZSDnytRBMRY9cARHTfD1TJ+Rnr9kgzIZicoPiB++640YzvsKleIIgnb VvUqDfsZLRvO3cC8z7pYZWTyfHl2aJHn5/0i6MbJRA0u7y5Fl0T010Hv/rhklouw53Nc OEqRpL3bE/RTZk+Fny3mflgzeoZaSqHyt/wpw4O+DuPYJzMCi1EdMazE1FLDS11PQecX l5qVlOImxh7QV4YsZ6klwb6XuWtULi9rs78ob2lFa3S4YRBb3Z6VQGbbMscprXN466uO vBfQ==
X-Gm-Message-State: AJaThX5f240zaD1KP/VXOwpPVRCIgB2znLCkPXNdC/tYsTdiWelugJVm lI551F8ZUGDiYjjnIlGEZrq8iigCyxMXdySxUlLW
X-Google-Smtp-Source: AGs4zMY/J2LrC5hDhGChbveHP0gd3GfGAAZF2X+FHNg6UBSgH0+UfhgS3YPI5VEH5DSW6yhZvu15TPOvd2eXGzOQgVc=
X-Received: by 10.237.34.151 with SMTP id p23mr922264qtc.194.1510580281908; Mon, 13 Nov 2017 05:38:01 -0800 (PST)
MIME-Version: 1.0
References:  <3025542.QI1GADQRnG@pintsize.usersys.redhat.com> 
In-Reply-To: 
From: David Benjamin 
Date: Mon, 13 Nov 2017 13:37:49 +0000
Message-ID: 
To: Eric Rescorla 
Cc: Hubert Kario , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a113c721c1c1b11055ddd618c"
Archived-At: 
Subject: Re: [TLS] close_notify and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 13:38:06 -0000

--001a113c721c1c1b11055ddd618c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 13, 2017 at 8:25 PM Eric Rescorla  wrote:

> On Mon, Nov 13, 2017 at 11:37 AM, Hubert Kario  wrote:
>
>> On Saturday, 11 November 2017 10:21:11 CET David Schinazi wrote:
>> > Hello all,
>> >
>> > Currently TLS 1.3 specifies close_notify in the same way that TLS 1.2
>> did.
>> > I believe that has issues and this might be the right time to fix them=
.
>> > The purpose of close_notify is to protect against data truncation
>> attacks,
>> > each side is required to send close_notify before closing the write
>> side of
>> > the transport connection so the other side knows that the data was not
>> > truncated. As such, close_notify only needs half-close semantics to
>> prevent
>> > truncation.
>> >
>> > However, the specification contains the following text:
>> > << Each party MUST send a =E2=80=9Cclose_notify=E2=80=9D alert before =
closing the write
>> side
>> > of the connection, unless some other fatal alert has been transmitted.
>> The
>> > other party MUST respond with a =E2=80=9Cclose_notify=E2=80=9D alert o=
f its own and
>> close
>> > down the connection immediately, discarding any pending writes. >>
>> >
>> > This means that an application-layer client can't send a query then
>> close
>> > their write transport when they know that they're done, because the
>> server
>> > would terminate the TLS session before sending the reply. On top of
>> this,
>> > when the server receives the close_notify, it may have already sent
>> part of
>> > the reply (or wrote it to the socket send buffer) so the responding
>> > close_notify would in effect be inflicting a truncation attack on the
>> > client.
>> >
>> > This doesn't make much difference for HTTP because clients already
>> > don't close their write transport after sending a reply, however havin=
g
>> the
>> > option do do this could allow innovation in new protocols that can
>> define
>> > the semantics of when they use close_notify. An example is DNS PUSH:
>> > https://tools.ietf.org/html/draft-ietf-dnssd-push
>> > 
>> >
>> > A proposal to solve this problem would be to give close_notify
>> half-close
>> > semantics: we keep the requirements that a close_notify be sent before
>> > closing the transport, and that any data received after a close_notify
>> is
>> > ignored, but we simply remove the requirement to immediately reply
>> > with a close_notify. This has the advantage that current implementatio=
ns
>> > are already compliant but future ones can leverage this improvement.
>> >
>> > What do you think? Is this worth discussing on Thursday?
>>
>> what about alerts?
>
>
>> if you half-closed the connection for write and then received key-update=
,
>
>
> I assume you mean with update_requested set. in any case, you do nothing:
>
> If the request_update field is set to "update_requested" then the receive=
r
> MUST
> send a KeyUpdate of its own with request_update set to
> "update_not_requested" prior
> to sending its next application data record.
>
>
>
>> or
>> message with an invalid tag, how are you supposed to react to it?
>>
>
> I think it would be fine to either silently tear down the connection or t=
o
> send an alert.
>

The latter seems better to me. The peer isn't going to parse it anyway,
since it was preceded by a closure alert, and it keeps the invariant that
one does not send anything after a closure alert.

But this problem isn't caused by this proposal and exists regardless. The
proposal is about whether the party which closes *second* must *send* a
close_notify after *receiving* one. This problem is if the party which
closes *first* *receives* garbage after *sending* a close_notify and
waiting for the corresponding one. That case is unavoidable so long as
waiting for the peer's close_notify after sending one is a supported
operation. The peer may send garbage.

David

--001a113c721c1c1b11055ddd618c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Mon, Nov 13=
, 2017 at 8:25 PM Eric Rescorla <ekr@rtf=
m.com> wrote:
On Mon, Nov 13, 20=
17 at 11:37 AM, Hubert Kario <hkario@redhat.com> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">
On Sa=
turday, 11 November 2017 10:21:11 CET David Schinazi wrote:

> Hello all,

>

> Currently TLS 1.3 specifies close_notify in the same way that TLS 1.2 =
did.

> I believe that has issues and this might be the right time to fix them=
.

> The purpose of close_notify is to protect against data truncation atta=
cks,

> each side is required to send close_notify before closing the write si=
de of

> the transport connection so the other side knows that the data was not=


> truncated. As such, close_notify only needs half-close semantics to pr=
event

> truncation.

>

> However, the specification contains the following text:

> << Each party MUST send a =E2=80=9Cclose_notify=E2=80=9D alert b=
efore closing the write side

> of the connection, unless some other fatal alert has been transmitted.=
 The

> other party MUST respond with a =E2=80=9Cclose_notify=E2=80=9D alert o=
f its own and close

> down the connection immediately, discarding any pending writes. >&g=
t;

>

> This means that an application-layer client can't send a query the=
n close

> their write transport when they know that they're done, because th=
e server

> would terminate the TLS session before sending the reply. On top of th=
is,

> when the server receives the close_notify, it may have already sent pa=
rt of

> the reply (or wrote it to the socket send buffer) so the responding
> close_notify would in effect be inflicting a truncation attack on the<=
br>
> client.

>

> This doesn't make much difference for HTTP because clients already=


> don't close their write transport after sending a reply, however h=
aving the

> option do do this could allow innovation in new protocols that can def=
ine

> the semantics of when they use close_notify. An example is DNS PUSH:
> https://tools.ietf.org/html/draft-ietf-dnssd-p=
ush

> <https://tools.ietf.org/html/draft-ietf-dn=
ssd-push>

>

> A proposal to solve this problem would be to give close_notify half-cl=
ose

> semantics: we keep the requirements that a close_notify be sent before=


> closing the transport, and that any data received after a close_notify=
 is

> ignored, but we simply remove the requirement to immediately reply

> with a close_notify. This has the advantage that current implementatio=
ns

> are already compliant but future ones can leverage this improvement.
>

> What do you think? Is this worth discussing on Thursday?




what about alerts?



if you half-closed the connection for write and then received key-update,

I assume you mean with update_=
requested set. in any case, you do nothing:

I=
f the request_update field is set to "update_requested" then the =
receiver MUST
send a KeyUpdate of its own with request_update set=
 to "update_not_requested" prior
to sending its next ap=
plication data record.

=C2=A0<=
/div>
 or

message with an invalid tag, how are you supposed to react to it?

I think it would be fine to either=
 silently tear down the connection or to send an alert.

The latter seems better to me. The pee=
r isn't going to parse it anyway, since it was preceded by a closure al=
ert, and it keeps the invariant that one does not send anything after a clo=
sure alert.

But this problem isn't caused by t=
his proposal and exists regardless.=C2=A0The proposal is about whether the =
party which closes *second* must *send* a close_notify after=C2=A0*receivin=
g* one. This problem is if the party which closes *first* *receives* garbag=
e after *sending* a close_notify and waiting for the corresponding one. Tha=
t case is unavoidable so long as waiting for the peer's close_notify af=
ter sending one is a supported operation. The peer may send garbage.
<=
div>
David


--001a113c721c1c1b11055ddd618c--


From nobody Mon Nov 13 06:38:57 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BAC8129AAA for ; Mon, 13 Nov 2017 06:38:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level: 
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 b3ABcJv3jmSJ for ; Mon, 13 Nov 2017 06:38:54 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A119F124D37 for ; Mon, 13 Nov 2017 06:38:54 -0800 (PST)
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4D2D1642; Mon, 13 Nov 2017 14:38:54 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E947480621; Mon, 13 Nov 2017 14:38:53 +0000 (UTC)
From: Hubert Kario 
To: Eric Rescorla 
Cc: "tls@ietf.org" 
Date: Mon, 13 Nov 2017 15:38:46 +0100
Message-ID: <1553712.MIZnC4Bnhv@pintsize.usersys.redhat.com>
In-Reply-To: 
References:  <3025542.QI1GADQRnG@pintsize.usersys.redhat.com> 
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1594484.yiQ46WnH02"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Mon, 13 Nov 2017 14:38:54 +0000 (UTC)
Archived-At: 
Subject: Re: [TLS] close_notify and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 14:38:56 -0000

--nextPart1594484.yiQ46WnH02
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Monday, 13 November 2017 13:25:07 CET Eric Rescorla wrote:
> On Mon, Nov 13, 2017 at 11:37 AM, Hubert Kario  wrote:
> > On Saturday, 11 November 2017 10:21:11 CET David Schinazi wrote:
> > > Hello all,
> > >=20
> > > Currently TLS 1.3 specifies close_notify in the same way that TLS 1.2
> >=20
> > did.
> >=20
> > > I believe that has issues and this might be the right time to fix the=
m.
> > > The purpose of close_notify is to protect against data truncation
> >=20
> > attacks,
> >=20
> > > each side is required to send close_notify before closing the write s=
ide
> >=20
> > of
> >=20
> > > the transport connection so the other side knows that the data was not
> > > truncated. As such, close_notify only needs half-close semantics to
> >=20
> > prevent
> >=20
> > > truncation.
> > >=20
> > > However, the specification contains the following text:
> > > << Each party MUST send a =E2=80=9Cclose_notify=E2=80=9D alert before=
 closing the write
> >=20
> > side
> >=20
> > > of the connection, unless some other fatal alert has been transmitted.
> >=20
> > The
> >=20
> > > other party MUST respond with a =E2=80=9Cclose_notify=E2=80=9D alert =
of its own and
> > > close
> > > down the connection immediately, discarding any pending writes. >>
> > >=20
> > > This means that an application-layer client can't send a query then
> > > close
> > > their write transport when they know that they're done, because the
> >=20
> > server
> >=20
> > > would terminate the TLS session before sending the reply. On top of
> > > this,
> > > when the server receives the close_notify, it may have already sent p=
art
> >=20
> > of
> >=20
> > > the reply (or wrote it to the socket send buffer) so the responding
> > > close_notify would in effect be inflicting a truncation attack on the
> > > client.
> > >=20
> > > This doesn't make much difference for HTTP because clients already
> > > don't close their write transport after sending a reply, however havi=
ng
> >=20
> > the
> >=20
> > > option do do this could allow innovation in new protocols that can
> > > define
> > > the semantics of when they use close_notify. An example is DNS PUSH:
> > > https://tools.ietf.org/html/draft-ietf-dnssd-push
> > > 
> > >=20
> > > A proposal to solve this problem would be to give close_notify
> > > half-close
> > > semantics: we keep the requirements that a close_notify be sent before
> > > closing the transport, and that any data received after a close_notify
> > > is
> > > ignored, but we simply remove the requirement to immediately reply
> > > with a close_notify. This has the advantage that current implementati=
ons
> > > are already compliant but future ones can leverage this improvement.
> > >=20
> > > What do you think? Is this worth discussing on Thursday?
> >=20
> > what about alerts?
> >=20
> >=20
> > if you half-closed the connection for write and then received key-updat=
e,
>=20
> I assume you mean with update_requested set. in any case, you do nothing:
>=20
> If the request_update field is set to "update_requested" then the receiver
> MUST
> send a KeyUpdate of its own with request_update set to
> "update_not_requested" prior
> to sending its next application data record.

how "MUST send a KeyUpdate of its own" is "you do nothing"?

Either you "MUST" act on received control messages or you do not.
If not, then the handling of errors by closing the read side (and NOT sendi=
ng=20
fatal alerts) should be specified.

Sending bad_record_mac while not replying to KeyUpdate seems very ugly to m=
e;=20
if the rest of the document is not updated in PR#1092.

> > or
> > message with an invalid tag, how are you supposed to react to it?
>=20
> I think it would be fine to either silently tear down the connection or to
> send an alert.

sending alerts after close_notify goes against the semantics of TCP half-
close. If the intention is to support TCP half-close-like mechanism in TLS,=
 we=20
need to document when and where that abstraction is broken. In particular -=
=20
that sending close_notify shouldn't be followed by closing the write side o=
f=20
the connection (be it TCP or Unix socket). Only that application_data packe=
ts=20
are disallowed after close_notify.
=2D-=20
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00  Brno, Czech Republic
--nextPart1594484.yiQ46WnH02
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCgAGBQJaCa52AAoJEJKo0bgB0vX10igQAJ4AM8cmvGRz8Ri34NBZ3FDG
RebXWc/07csIMgFBtgFEY7FLkM6CmPhPSxHkf9+/n1O9j+tA6QKU3r8GZFwxgOKl
qCuxZx1Y3SKqtCeXI7eI1ckFRerly7KAgov1Idh7o/w+W4vZcPccnFTraokiY7xB
0BxPUl8BZ6bCqzJIJg9sP6NtvPfvIgbGuiJwcwxv6dnT1WCTf1tGr1V4XbKrEBC2
G+CuTu1WFybEOyffkGgoIEeVGp8FXokEXRNpIoTxI2a6RShBadFG78ZUFG2xEZI9
JNm/dZ0dJLBjTKYURiLx9nAywuZDBr26cNo08T+IQY+uUBugrB36Njf5O3cKOXFW
hCH0bvPbxKEY7ly2IBS3JwYrSBWexRmGCGY6zzetS1SJ+npywyQ3Ia0Uwsj3pXV3
Kmo5w+mq0YyOEe1YiMjnFyXZJ2ix3tKlF75TPBXiLphO8Vl0Dppxd5zq08pI+qxV
AjR5UfKvO4XiAn/IU7zcKnSMYz96Wq+txT803MIk6xdtoA/8rj1Bk1MRFwrthz8A
rHF4Kqu1aqr2pFLRM3U9idIxwvkWJtKU60eFuzrh210aAubF9gDHMf/K4xOlpkb7
rScdRjfmA44pXqR3N8/UAWIyK/oxNpn1OHh44D0Grx5OS4a68AN3m5JtmAUWmRzx
bnGuU1QLcIeiy78nv3Sn
=xhgg
-----END PGP SIGNATURE-----

--nextPart1594484.yiQ46WnH02--


From nobody Mon Nov 13 08:00:52 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCE01200FC for ; Mon, 13 Nov 2017 08:00:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ritter.vg
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 0DNw4qG6dRlb for ; Mon, 13 Nov 2017 08:00:44 -0800 (PST)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 B1507127843 for ; Mon, 13 Nov 2017 08:00:44 -0800 (PST)
Received: by mail-qt0-x22f.google.com with SMTP id e19so15280087qte.8 for ; Mon, 13 Nov 2017 08:00:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ws1OROSsJ6LfbPfJmrWfSq5rsWZuQWrEzqo4f6DUPFs=; b=eB/galv1kHHt0hGK92kYzglm7zIAJy18NR1uwPM7mTp4CTBNgDXhA9mL8cwMUoVt58 oFHUDmDG8GFZlmeiRds5vyYCENwQYHRMZmYKpV19+K1iwit7sJrB1SZY63PvBz3OPKIu pFtg2jfU8h3WjxXQ5FmYpmyLXLBHuTcg2tUj8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ws1OROSsJ6LfbPfJmrWfSq5rsWZuQWrEzqo4f6DUPFs=; b=Uu3Baz7umXhEBKE2O+folsLcEPMXNIoIBH9d+hNUA/04u1rsHqlAl1AQe/HSH9QjMI BGWc/f796b76kA2i+j7UpgCRbSlps9ohNZT6vppNHax4RaciWUWXSm0thCny7LkmjJAl lmVMMbrtje4wMc7jxzNtzfv8VpMOObBCNHtD1iDMQzHwFK7jS+U7yfL/KrXuNkKlRmgt 7FmLJv56QYUZvs4F/HuIw2O6bt1LaRguV75xzfQokvsq8pRLcz8FmdI8k1ai8Vt4ouCv B1eDD8+nZYvfR7PakcZaSCB8Go1S6A3xIeXzUCHG+skREXgOP4vvAqowovXmoIGW3Vhw wX/A==
X-Gm-Message-State: AJaThX5Y9ulNUyaQD95TRaSBhI1vIVXxiRpUsAbup0L9NBH4wXi7nauH oxWm3Dispqzzac/wNprGjFYKmy5R4wkoZ9f/RrZtT7mtp5s=
X-Google-Smtp-Source: AGs4zMbbkQu2puEPxT1Hqo3eXaz6nQl5fDgJKVZ5ZJOEpXfEOtpgJeqxyZjmrr2rc1WMD1PjQ2zo5XDmLbTeos1yt9Q=
X-Received: by 10.200.22.168 with SMTP id r37mr13881446qtj.21.1510588843646; Mon, 13 Nov 2017 08:00:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.92.130 with HTTP; Mon, 13 Nov 2017 08:00:23 -0800 (PST)
In-Reply-To: 
References: 
From: Tom Ritter 
Date: Mon, 13 Nov 2017 10:00:23 -0600
Message-ID: 
To: Bret Jordan 
Cc: "tls@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] Tonight's Encrypted SNI Hangout Session
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 16:00:51 -0000

On 13 November 2017 at 07:28, Bret Jordan  wrote:
> All,
>
> We had a great turnout tonight for the encrypted SNI hangout session.
> Everyone seemed open and willing to work together to understand the
> complexities that sit before us. Several interesting and important views
> were expressed, and I feel that the meeting was ultimately a success. In
> fact, I believe we should do more hangout sessions like this.
>
> Take aways from the meeting:
> 1) We are starting to understand the problem that we are trying to solve
>
> 2) We need to ensure that any potential solution will in fact solve the
> problems as we understand it and not make the problem worse
>
> 3) We need to compile a list of use cases and scenarios in a draft document
> that talk about how the SNI (for good or for bad) is being used today and
> what an encrypted SNI will mean for these use cases.
>
> 4) We need to make sure we get feedback and information from at least the
> telco sector, large enterprise, financial sector, and the health care
> sector.
>
>
> I believe this information will help us better understand both sides of the
> issue, shed light in to what it will mean, help us define the "why" we are
> doing this, and ultimately feed and foster a better technological solution.
> If you have or know of scenarios or use-cases where the SNI is being used by
> network operators, system administrators, security engineers, products, etc,
> please send them to me so I can start compiling them in to a draft document.

Are you also interested in collecting reports of where SNI is used to
censor? Or the list of network vendors that support filtering and
manipulating traffic based on the value?

In general, the bad uses of SNI are harder to enumerate because people
aren't willing to come to the WG and explain how they use SNI to
selectively break or censor the internet for their citizens/users. We
have a few confirmed cases, anecdotal evidence, and lots of evidence
of censors being technically applied by whatever means is available.

But when you pile up all the administrators who will come to the WG
and say "This really frustrates me and makes my job harder" you're
going to have a much bigger pile than the users (or even technical
advocates like myself) we can bring in and say "Plaintext SNI is
harming the Internet".

> Side question, it feels like this effort could represent a lot of work and
> require a lot of dedicated cycles. Does it make sense to continue this
> effort inside of the TLS WG?  If it does, will the WG give us the time,
> mindshare, and cycles to focus on it (just asking the hard question)?

In August we adopted the draft, so the answer is "Yes".

-tom


From nobody Mon Nov 13 09:55:40 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8AA128768 for ; Mon, 13 Nov 2017 09:55:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 zDO_GtqUDYEk for ; Mon, 13 Nov 2017 09:55:38 -0800 (PST)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB53C129B1E for ; Mon, 13 Nov 2017 09:55:37 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 60039B529E; Mon, 13 Nov 2017 19:55:36 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id 7_84i83Gko1o; Mon, 13 Nov 2017 19:55:36 +0200 (EET)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 15DF028B; Mon, 13 Nov 2017 19:55:34 +0200 (EET)
Date: Mon, 13 Nov 2017 19:55:33 +0200
From: Ilari Liusvaara 
To: Bret Jordan 
Cc: tls@ietf.org
Message-ID: <20171113175533.d2ncygry5imzqdw3@LK-Perkele-VII>
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] Tonight's Encrypted SNI Hangout Session
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 17:55:40 -0000

On Mon, Nov 13, 2017 at 09:28:23PM +0800, Bret Jordan wrote:
> 
> 3) We need to compile a list of use cases and scenarios in a draft document
> that talk about how the SNI (for good or for bad) is being used today and
> what an encrypted SNI will mean for these use cases.

What I think SNI is mainly (legimately) used for:

- Specify the certificate.
- Specify the next service (both before and after TLS termination).

Ideally, specifying certificate would be enough to specify the next
service. But we all know reality is not ideal, so it might not be.
In the converse direction, having multiple certificates all covering
the same next service is very common (e.g., it would requre special
setup with common webservers not to have it this way).

As to specifying certificate, there are many reasons why a server
might want multiple certificates:

- There are too many names to put into one certificate.
- Putting all the names into one certificate would be difficult to
  manage.
- The server wants to make some separation between the names.
- The names have different next service.


One can note that both uses are really just to save IP address space.
There are two main reasons why one would want to do that:

- Conserving address space (IPv4!!!).
- Avoiding adminstrative overhead of multiple IP addresses.


Easier way to partially solve this would be to reduce the granularity
of data. Does not work with all servers.


The more difficult way would be to actually encrypt the SNI value
(bound to the client public key to avoid a nasty attack that breaks
the entiere scheme). This would make SNI before-termination routing
more difficult, and absent something nontrivial, would increase the
server handshake cost by over a half.


However, much of the "encrypted SNI" discusion has been about different
thing, namely proxying. Which is whole another can of worms, and is
also a three-party protocol, not two-party.




-Ilari


From dbpaull1@gmail.com  Mon Nov 13 10:45:55 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF31129B4C for ; Mon, 13 Nov 2017 10:45:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 VgujnDPpLPoS for ; Mon, 13 Nov 2017 10:45:54 -0800 (PST)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 C50DA129B49 for ; Mon, 13 Nov 2017 10:45:53 -0800 (PST)
Received: by mail-qt0-x236.google.com with SMTP id 8so20834013qtv.1 for ; Mon, 13 Nov 2017 10:45:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vSu2ln8dpINvW1/tLcLGsqROhcZSGATJ3fxyhIZ1UpE=; b=N4eFWWjKYpkcVWi9DiiAMgMpWkiluEk2DAd+fR/5ri51iqBuQljlDfMr46D7WW7Ax5 8IfT/bUYNnsi3BIx5SYrSs25PXGhp6iC5y9xRalTX1o1S5RWXDMow2wH3VnWLIKZKckG fBISuoQQIFYCt7pM3Bqt+3bLCLmo4ORy7numIkg89RfZCDSnSyUGu/Njf0EtbsJMevqk eWe/rWiHzWBAtO1KAHC3ClLh8yj0J576/Dx/kdfjD7OJLE9sr9qidTXidxyLu8jFifDL phl/WNVG18glEg/I+Y1umaKI5KWIqPFjkvh1Ky4DYbczH+rE8e3gjxJh4WwgmR+0fp+z h4LQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vSu2ln8dpINvW1/tLcLGsqROhcZSGATJ3fxyhIZ1UpE=; b=XP39NZcVg93CJpK0XfUP8g+zAj/SH0RtI7fjqg8eew0BNJNIiAvEs2QB5hduiSsCPS ENWalWafRBjLr4XbFSt727GxYTpzZRpHcow3WpqzzxPumCzYFIhBKV2g4we3bGBYedNf hu+CCgOxc+8SI7bBDSh37WaLqfag1Sv3FSp2M6X5PsukukILlUNRR98j3JSRKOGRexNf g8BYOtN2vdQ3D9fC7g1G39hgBHNhcIQ5eoMxNcw/AjNlQPCTeXzaTGgbGBYWbE2+wOpJ 7q/D4kcyq6FbLZro3QLSLc3FfKMWkGC0FhCvvfjTZaihF8bvhYjm4ReIqvGZgvqbdnDR 46dQ==
X-Gm-Message-State: AJaThX5J9yUTynTKh+z7ttgZ9W++06Ko3HYQU5QchOv7zG40/lcd5hih 8ZIdDbGUegng1ATxp6BjU6505LISfYo=
X-Google-Smtp-Source: AGs4zMYOlR/qYHih6yVMHsUH9WG1XGLXAlQmHb9BKIUk2fL9VKWzxtp4hccZC8vVf3BGaq+87lQJNQ==
X-Received: by 10.200.12.193 with SMTP id o1mr15396270qti.254.1510598752917; Mon, 13 Nov 2017 10:45:52 -0800 (PST)
Received: from [28.175.224.223] (99-203-16-116.pools.spcsdns.net. [99.203.16.116]) by smtp.gmail.com with ESMTPSA id y62sm11013688qkb.92.2017.11.13.10.45.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 10:45:52 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: David P 
X-Mailer: iPhone Mail (15A432)
In-Reply-To: <20171113175533.d2ncygry5imzqdw3@LK-Perkele-VII>
Date: Mon, 13 Nov 2017 13:45:51 -0500
Cc: Bret Jordan , tls@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <6FEBB0BE-24F1-4902-893B-7900A78E5625@gmail.com>
References:  <20171113175533.d2ncygry5imzqdw3@LK-Perkele-VII>
To: Ilari Liusvaara 
Archived-At: 
Subject: Re: [TLS] Tonight's Encrypted SNI Hangout Session
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 19:06:52 -0000

New here.

What about a use case (for SNI) of different teams (or budgets) procuring ce=
rtificates for different sites housed on either the same server, or at least=
 in the same data center behind the same load balancing device?  And SNI bei=
ng used at a gateway, or entry point to that enterprise=E2=80=99s WAN.=20

Sent from my iPhone

> On Nov 13, 2017, at 12:55 PM, Ilari Liusvaara  w=
rote:
>=20
>> On Mon, Nov 13, 2017 at 09:28:23PM +0800, Bret Jordan wrote:
>>=20
>> 3) We need to compile a list of use cases and scenarios in a draft docume=
nt
>> that talk about how the SNI (for good or for bad) is being used today and=

>> what an encrypted SNI will mean for these use cases.
>=20
> What I think SNI is mainly (legimately) used for:
>=20
> - Specify the certificate.
> - Specify the next service (both before and after TLS termination).
>=20
> Ideally, specifying certificate would be enough to specify the next
> service. But we all know reality is not ideal, so it might not be.
> In the converse direction, having multiple certificates all covering
> the same next service is very common (e.g., it would requre special
> setup with common webservers not to have it this way).
>=20
> As to specifying certificate, there are many reasons why a server
> might want multiple certificates:
>=20
> - There are too many names to put into one certificate.
> - Putting all the names into one certificate would be difficult to
>  manage.
> - The server wants to make some separation between the names.
> - The names have different next service.
>=20
>=20
> One can note that both uses are really just to save IP address space.
> There are two main reasons why one would want to do that:
>=20
> - Conserving address space (IPv4!!!).
> - Avoiding adminstrative overhead of multiple IP addresses.
>=20
>=20
> Easier way to partially solve this would be to reduce the granularity
> of data. Does not work with all servers.
>=20
>=20
> The more difficult way would be to actually encrypt the SNI value
> (bound to the client public key to avoid a nasty attack that breaks
> the entiere scheme). This would make SNI before-termination routing
> more difficult, and absent something nontrivial, would increase the
> server handshake cost by over a half.
>=20
>=20
> However, much of the "encrypted SNI" discusion has been about different
> thing, namely proxying. Which is whole another can of worms, and is
> also a three-party protocol, not two-party.
>=20
>=20
>=20
>=20
> -Ilari
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Mon Nov 13 11:11:21 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D52B126B6D for ; Mon, 13 Nov 2017 11:11:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 VAb9DqRlyuDI for ; Mon, 13 Nov 2017 11:11:17 -0800 (PST)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B584D120721 for ; Mon, 13 Nov 2017 11:11:17 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 4B2BC5DE8D; Mon, 13 Nov 2017 21:11:15 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id AZAP7P79Aabx; Mon, 13 Nov 2017 21:11:15 +0200 (EET)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id EADB327F; Mon, 13 Nov 2017 21:11:11 +0200 (EET)
Date: Mon, 13 Nov 2017 21:11:11 +0200
From: Ilari Liusvaara 
To: David P 
Cc: Bret Jordan , tls@ietf.org
Message-ID: <20171113191111.6gf2iigtbg4qqg5w@LK-Perkele-VII>
References:  <20171113175533.d2ncygry5imzqdw3@LK-Perkele-VII> <6FEBB0BE-24F1-4902-893B-7900A78E5625@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <6FEBB0BE-24F1-4902-893B-7900A78E5625@gmail.com>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] Tonight's Encrypted SNI Hangout Session
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 19:11:20 -0000

On Mon, Nov 13, 2017 at 01:45:51PM -0500, David P wrote:
> 
> > On Nov 13, 2017, at 12:55 PM, Ilari Liusvaara  wrote:
> > 
> >> On Mon, Nov 13, 2017 at 09:28:23PM +0800, Bret Jordan wrote:
> >> 
> >> 3) We need to compile a list of use cases and scenarios in a draft document
> >> that talk about how the SNI (for good or for bad) is being used today and
> >> what an encrypted SNI will mean for these use cases.
> > 
> > What I think SNI is mainly (legimately) used for:
> > 
> > - Specify the certificate.
> > - Specify the next service (both before and after TLS termination).
> > 
> > Ideally, specifying certificate would be enough to specify the next
> > service. But we all know reality is not ideal, so it might not be.
> > In the converse direction, having multiple certificates all covering
> > the same next service is very common (e.g., it would requre special
> > setup with common webservers not to have it this way).
> > 
> > As to specifying certificate, there are many reasons why a server
> > might want multiple certificates:
> > 
> > - There are too many names to put into one certificate.
> > - Putting all the names into one certificate would be difficult to
> >  manage.
> > - The server wants to make some separation between the names.
> > - The names have different next service.
> > 
> 
> What about a use case (for SNI) of different teams (or budgets) procuring
> certificates for different sites housed on either the same server, or at
> least in the same data center behind the same load balancing device? 
> And SNI being used at a gateway, or entry point to that enterprise’s WAN. 

AFAICT, that would fall into "too difficult to manage with one
certificate" and "next service before TLS termination".

And yes, genuine encrypted SNI could be somewhat nasty for routing
before terminating TLS. And if one tries to simply use public-key
encryption, AFAICT, all the known ways are either slower than
ECDH-ES or have much larger size overhead (heck, ECDH-ES itself is
either optimal size-wise or close to it). Also, DH-ES type schemes do
not work with PQC (which is starting to be a concern).


-Ilari


From nobody Mon Nov 13 11:55:19 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBFF3129601 for ; Mon, 13 Nov 2017 11:55:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 hfndVZ1aGcvv for ; Mon, 13 Nov 2017 11:55:16 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65131241F3 for ; Mon, 13 Nov 2017 11:55:15 -0800 (PST)
Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx44.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eEKp6-0007DG-Br for tls@ietf.org; Mon, 13 Nov 2017 20:55:13 +0100
Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eEKoz-0000hZ-9f for tls@ietf.org; Mon, 13 Nov 2017 14:55:09 -0500
Received: (qmail 8191 invoked from network); 13 Nov 2017 19:55:03 -0000
Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.39]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 13 Nov 2017 19:55:03 -0000
To: tls@ietf.org
References:  <20171113175533.d2ncygry5imzqdw3@LK-Perkele-VII> <6FEBB0BE-24F1-4902-893B-7900A78E5625@gmail.com> <20171113191111.6gf2iigtbg4qqg5w@LK-Perkele-VII>
From: Christian Huitema 
Message-ID: 
Date: Mon, 13 Nov 2017 11:54:59 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171113191111.6gf2iigtbg4qqg5w@LK-Perkele-VII>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 168.144.250.190
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.28)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5qTpo3psabwjYwhu6FVK6CkXv9krsgRhBn0ayn6qsUc7RO6saVKtiei5 uUZjs8uJrOfHzJ6mVE7ewsipSVIfs4ZaBy1gWP4lJKnrCob7yd4mLB67TLnlh9i6Dr2tTQ7u+oqs y1PKTVoO8Zj6z/ewaDOZ3JKVmi72ocgY5kMQSjs7Pk8VxOtUn7O9m8cCuN8HIa1B2N+xwNIm4bky rJMaAA/itEW1aHIJYDvx6uGLOm1Bi99Or0uXh6FskGQ3mtr4LUU/Qweyn+lg7TbDa2rNOWNaHCnN rMSSA7xor9tnUlOY8pSJo/Vkdr+FbBdda40x5B/NGyVcjXsZLVHUb2pmaEmDh4PRiBbRliPgaurB TRjstfheF24EjrGuHVHIMu1lYZhMr2sR3cQs/oU/axm99b2jdwip2wrbEvxHA2swIjN6PhFSfsse t38tyDP81cDf6vvg7iEFLP+SSY+Av5+AiC4SKZ4XAkDTqt5ctPp8cLLgmjn7L5t7To3abBdiYtm1 8d3OLxVbVvBI1Bn6ZETDJ4pZ0VwEd+iNUj65ezw/iijHw95cPWLsHiU6tFs2fFlaJuRMyksc0Dx4 iQa9AzGuG3nTPpuFqUUQz+mM8JAD4ECWWHzJf22XqcXsJzuDdEgoxaf4b0gaZx7Nq9QqOn1O3qTB NY7E/+ds1swbTxxbyGWfEug0a3yzaqY4/fzPDRH3NCG7X+t1TW39Ja77LGPpOwDCYR4kEX6t994C WVS20AAhVdgmqeRHVgu2HeXOPcfcJVAxXqQU4SUCmX1X8Fu4HDEINFmBCcViSrRI4uua/GkXQk2H BukllN/eBZD4GGbFsCT/dtMIs/LqOU9hZ/v31oRzg7QgpumQxgT4IcKeAlfy/bB/laLK9WZp+I7d gzC3lLdvK/cKOEqlCIPGIfYQDNKLLI6rY1d8Qdsix0hWyXbo
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: 
Subject: Re: [TLS] Tonight's Encrypted SNI Hangout Session
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 19:55:18 -0000

On 11/13/2017 11:11 AM, Ilari Liusvaara wrote:

> And yes, genuine encrypted SNI could be somewhat nasty for routing
> before terminating TLS. And if one tries to simply use public-key
> encryption, AFAICT, all the known ways are either slower than
> ECDH-ES or have much larger size overhead (heck, ECDH-ES itself is
> either optimal size-wise or close to it). Also, DH-ES type schemes do
> not work with PQC (which is starting to be a concern).

The current draft
(https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/)
studies this problem and describes classes of solutions. The solutions
are certainly imperfect, but they address the use case where a
"multiplexed server" receives requests for a hidden service, when the
SNI in the client hello describes a forwarding service. The draft does
not give examples of what the "multiplexed server"might be, but the
common implementation in our mind is a set of servers behind a load
balancer.

-- Christian Huitema


From nobody Mon Nov 13 12:35:21 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0BAE129B1B for ; Mon, 13 Nov 2017 12:35:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 BO0vH8qOcPjC for ; Mon, 13 Nov 2017 12:35:17 -0800 (PST)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 6D2951201F8 for ; Mon, 13 Nov 2017 12:35:17 -0800 (PST)
Received: by mail-yw0-x22e.google.com with SMTP id k3so14537828ywk.8 for ; Mon, 13 Nov 2017 12:35:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PnPyqpB3rAtBaWchMZ8s+jvh7OhwmUxKSzrBysGEqZk=; b=oTo7VEz83wFEjqOaIfSR9CfTZrfSX97PyTjCXKyYmNFc0CujKfQCwLkbvy9WN9N8QT owNsoEHfcMJHN2CunvjUUQlLQFxgwgytiVMXQxCn83C/KFRxpwFBBzGDxmfeHlu7Uf5j m8mbS0dGnpZMREQenj82OA3xJEdt7619qIjXjv5gIs598P2VWuv6lLxTvNXXwSixGINT VBSAcHaIObYnvFAoXTGqCM3znmaXHAlERnPj5/SRGb0h2/TXxWhC6SQwakcJYbfB4GiH 1RCVqaWpuUfI8aWpmEcXUIsvznrasPh/TzrNw6Y5t9+ZglbbiH1KdVjJkrulLXScMlhE eU0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PnPyqpB3rAtBaWchMZ8s+jvh7OhwmUxKSzrBysGEqZk=; b=fra+TtXFqVm30lE7nLqvYJRZpUCJ62+G0ZyL9FtIWguw3IlO1WOQoT6d8wM0UDiE+3 vZ8jVa0DPah3a04BkCqlg062/4BT4GDEEuqdyUrmJs0T08JGDOPCzxbraz8jPON1gOCM fa8Yh+XaPdL7Cy16Na3mOeLFeazw4T50cHyttLAruFPgY8TA5nSSWOINs1b0FwqzHUWV 92u6oyuMTIMQqRWaOEPjLOiezMRULNkk0shR05qck/NoGhtmnuQFUAYWRTFXU1n5EXC9 45m7+VoTRrZmIZ5h80yrtQaiCUUAnAdZvPr2G2gD1d4BAA78CYwo+qRUc5NwkcTS7ken +/+w==
X-Gm-Message-State: AJaThX4VCTrbayRfddDTNvnOUmffAE9gP5dKOnTZXxiIee5N+dhCDdPq 6zjyNa44IGYp+piV/Dz90tAUTzVvcHL5rfhavZrydSwB
X-Google-Smtp-Source: AGs4zMavrenAw9K0nKFDUF5xPb/uyEviqumkqKUB+5kyJUautblPmEF2+RjalQg7/NOSfJ+WsuKOVt7tPIOFpFSM0VE=
X-Received: by 10.129.172.25 with SMTP id k25mr5160295ywh.155.1510605316653; Mon, 13 Nov 2017 12:35:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.61.12 with HTTP; Mon, 13 Nov 2017 12:34:36 -0800 (PST)
In-Reply-To: <1553712.MIZnC4Bnhv@pintsize.usersys.redhat.com>
References:  <3025542.QI1GADQRnG@pintsize.usersys.redhat.com>  <1553712.MIZnC4Bnhv@pintsize.usersys.redhat.com>
From: Eric Rescorla 
Date: Mon, 13 Nov 2017 20:34:36 +0000
Message-ID: 
To: Hubert Kario 
Cc: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c1badfc4b8b67055de335a3"
Archived-At: 
Subject: Re: [TLS] close_notify and TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 20:35:20 -0000

--94eb2c1badfc4b8b67055de335a3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 13, 2017 at 2:38 PM, Hubert Kario  wrote:

> On Monday, 13 November 2017 13:25:07 CET Eric Rescorla wrote:
> > On Mon, Nov 13, 2017 at 11:37 AM, Hubert Kario 
> wrote:
> > > On Saturday, 11 November 2017 10:21:11 CET David Schinazi wrote:
> > > > Hello all,
> > > >
> > > > Currently TLS 1.3 specifies close_notify in the same way that TLS 1=
.2
> > >
> > > did.
> > >
> > > > I believe that has issues and this might be the right time to fix
> them.
> > > > The purpose of close_notify is to protect against data truncation
> > >
> > > attacks,
> > >
> > > > each side is required to send close_notify before closing the write
> side
> > >
> > > of
> > >
> > > > the transport connection so the other side knows that the data was
> not
> > > > truncated. As such, close_notify only needs half-close semantics to
> > >
> > > prevent
> > >
> > > > truncation.
> > > >
> > > > However, the specification contains the following text:
> > > > << Each party MUST send a =E2=80=9Cclose_notify=E2=80=9D alert befo=
re closing the
> write
> > >
> > > side
> > >
> > > > of the connection, unless some other fatal alert has been
> transmitted.
> > >
> > > The
> > >
> > > > other party MUST respond with a =E2=80=9Cclose_notify=E2=80=9D aler=
t of its own and
> > > > close
> > > > down the connection immediately, discarding any pending writes. >>
> > > >
> > > > This means that an application-layer client can't send a query then
> > > > close
> > > > their write transport when they know that they're done, because the
> > >
> > > server
> > >
> > > > would terminate the TLS session before sending the reply. On top of
> > > > this,
> > > > when the server receives the close_notify, it may have already sent
> part
> > >
> > > of
> > >
> > > > the reply (or wrote it to the socket send buffer) so the responding
> > > > close_notify would in effect be inflicting a truncation attack on t=
he
> > > > client.
> > > >
> > > > This doesn't make much difference for HTTP because clients already
> > > > don't close their write transport after sending a reply, however
> having
> > >
> > > the
> > >
> > > > option do do this could allow innovation in new protocols that can
> > > > define
> > > > the semantics of when they use close_notify. An example is DNS PUSH=
:
> > > > https://tools.ietf.org/html/draft-ietf-dnssd-push
> > > > 
> > > >
> > > > A proposal to solve this problem would be to give close_notify
> > > > half-close
> > > > semantics: we keep the requirements that a close_notify be sent
> before
> > > > closing the transport, and that any data received after a
> close_notify
> > > > is
> > > > ignored, but we simply remove the requirement to immediately reply
> > > > with a close_notify. This has the advantage that current
> implementations
> > > > are already compliant but future ones can leverage this improvement=
.
> > > >
> > > > What do you think? Is this worth discussing on Thursday?
> > >
> > > what about alerts?
> > >
> > >
> > > if you half-closed the connection for write and then received
> key-update,
> >
> > I assume you mean with update_requested set. in any case, you do nothin=
g:
> >
> > If the request_update field is set to "update_requested" then the
> receiver
> > MUST
> > send a KeyUpdate of its own with request_update set to
> > "update_not_requested" prior
> > to sending its next application data record.
>
> how "MUST send a KeyUpdate of its own" is "you do nothing"?
>

You need to read to the end of the sentence
"prior to sending its next application data record". As no such record is
sent, you don't need to do anything.


> > or
> > > message with an invalid tag, how are you supposed to react to it?
> >
> > I think it would be fine to either silently tear down the connection or
> to
> > send an alert.
>
> sending alerts after close_notify goes against the semantics of TCP half-
> close. If the intention is to support TCP half-close-like mechanism in
> TLS, we
> need to document when and where that abstraction is broken. In particular=
 -
> that sending close_notify shouldn't be followed by closing the write side
> of
> the connection (be it TCP or Unix socket). Only that application_data
> packets
> are disallowed after close_notify.
>

As David says, this problem already exists.

-Ekr

--
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00  Brno, Czech Republic
>

--94eb2c1badfc4b8b67055de335a3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Nov 13, 2017 at 2:38 PM, Hubert Kario <hkario@redhat.com&g=
t; wrote:
On Monday, 13 November 2017 13:25:07 CET Eric Rescorla wrot=
e:

> On Mon, Nov 13, 2017 at 11:37 AM, Hubert Kario <hkario@redhat.com> wrote:

> > On Saturday, 11 November 2017 10:21:11 CET David Schinazi wrote:<=
br>
> > > Hello all,

> > >

> > > Currently TLS 1.3 specifies close_notify in the same way tha=
t TLS 1.2

> >

> > did.

> >

> > > I believe that has issues and this might be the right time t=
o fix them.

> > > The purpose of close_notify is to protect against data trunc=
ation

> >

> > attacks,

> >

> > > each side is required to send close_notify before closing th=
e write side

> >

> > of

> >

> > > the transport connection so the other side knows that the da=
ta was not

> > > truncated. As such, close_notify only needs half-close seman=
tics to

> >

> > prevent

> >

> > > truncation.

> > >

> > > However, the specification contains the following text:

> > > << Each party MUST send a =E2=80=9Cclose_notify=E2=80=
=9D alert before closing the write

> >

> > side

> >

> > > of the connection, unless some other fatal alert has been tr=
ansmitted.

> >

> > The

> >

> > > other party MUST respond with a =E2=80=9Cclose_notify=E2=80=
=9D alert of its own and

> > > close

> > > down the connection immediately, discarding any pending writ=
es. >>

> > >

> > > This means that an application-layer client can't send a=
 query then

> > > close

> > > their write transport when they know that they're done, =
because the

> >

> > server

> >

> > > would terminate the TLS session before sending the reply. On=
 top of

> > > this,

> > > when the server receives the close_notify, it may have alrea=
dy sent part

> >

> > of

> >

> > > the reply (or wrote it to the socket send buffer) so the res=
ponding

> > > close_notify would in effect be inflicting a truncation atta=
ck on the

> > > client.

> > >

> > > This doesn't make much difference for HTTP because clien=
ts already

> > > don't close their write transport after sending a reply,=
 however having

> >

> > the

> >

> > > option do do this could allow innovation in new protocols th=
at can

> > > define

> > > the semantics of when they use close_notify. An example is D=
NS PUSH:

> > > https://tools.ietf.org/html/dra=
ft-ietf-dnssd-push

> > > <https://tools.ietf.org/html/draft-ietf-dnssd-push>

> > >

> > > A proposal to solve this problem would be to give close_noti=
fy

> > > half-close

> > > semantics: we keep the requirements that a close_notify be s=
ent before

> > > closing the transport, and that any data received after a cl=
ose_notify

> > > is

> > > ignored, but we simply remove the requirement to immediately=
 reply

> > > with a close_notify. This has the advantage that current imp=
lementations

> > > are already compliant but future ones can leverage this impr=
ovement.

> > >

> > > What do you think? Is this worth discussing on Thursday?

> >

> > what about alerts?

> >

> >

> > if you half-closed the connection for write and then received key=
-update,

>

> I assume you mean with update_requested set. in any case, you do nothi=
ng:

>

> If the request_update field is set to "update_requested" the=
n the receiver

> MUST

> send a KeyUpdate of its own with request_update set to

> "update_not_requested" prior

> to sending its next application data record.




how "MUST send a KeyUpdate of its own" is "you d=
o nothing"?

You need to read to th=
e end of the sentence
"prior to sending its next application=
 data record". As no such record is sent, you don't need to do any=
thing.



> > or

> > message with an invalid tag, how are you supposed to react to it?=


>

> I think it would be fine to either silently tear down the connection o=
r to

> send an alert.



sending alerts after close_notify goes against the semantics of TCP =
half-

close. If the intention is to support TCP half-close-like mechanism in TLS,=
 we

need to document when and where that abstraction is broken. In particular -=


that sending close_notify shouldn't be followed by closing the write si=
de of

the connection (be it TCP or Unix socket). Only that application_data packe=
ts

are disallowed after close_notify.

As D=
avid says, this problem already exists.

-Ekr
=




--

Regards,

Hubert Kario

Senior Quality Engineer, QE BaseOS Security team

Web: www.cz.redhat.com

Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech Republic=




--94eb2c1badfc4b8b67055de335a3--


From nobody Mon Nov 13 14:40:47 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB3B126CB6 for ; Mon, 13 Nov 2017 14:40:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
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 kfpiVF2uLCtF for ; Mon, 13 Nov 2017 14:40:44 -0800 (PST)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8CCC124239 for ; Mon, 13 Nov 2017 14:40:43 -0800 (PST)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vADMb2Od008012; Mon, 13 Nov 2017 22:40:40 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=BckMX3bGkOK1ES8O0kcL3rIve2E1yvcNvxeB8F+iirg=; b=U7vmmmYK1zmITajzwT3Wz5YDD8qoGpV4wFTRqJ50LtSU2waahy/NYaRVWn9HdQlSZow8 5vUns2y9m9TttQ1eiZGFpvZ3zC4ydtv1sllJNremuVKhSugi4hRY8WvKlPZXgYIErXum Yh1QxzVxD0pGE6eCzzR6TEnNLr0fi2PB0nvmwrxAWcZSJj8X2QfkCB9CmD/g3viHbv/J eCVFcHHktRqmTApu2HkrI7hO05TqV6XWNsaK4AIZ0zafWRcRvJPfrjNRg1ADbRGioNL7 1YKjrEuIO9KFr8nZ13dx0S8MIQhpjfVgHdlHCuZ5eBMRCbka88XuqythlLVIKJq8ES1R fA== 
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050102.ppops.net-00190b01. with ESMTP id 2e7m0pr23s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Nov 2017 22:40:40 +0000
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vADMeauX022769; Mon, 13 Nov 2017 17:40:39 -0500
Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2e5wdye73m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 13 Nov 2017 17:40:39 -0500
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 13 Nov 2017 17:40:31 -0500
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 13 Nov 2017 17:40:31 -0500
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 13 Nov 2017 17:40:31 -0500
From: "Salz, Rich" 
To: Ilari Liusvaara , David P 
CC: "tls@ietf.org" 
Thread-Topic: [TLS] Tonight's Encrypted SNI Hangout Session
Thread-Index: AQHTXIRIpM84fsnFfEemkDeHk+AsBaMS6/yAgAAODoCAAAcUgIAAOnqA
Date: Mon, 13 Nov 2017 22:40:30 +0000
Message-ID: <44058361-FA9C-4DAF-87F6-7198B78D2C44@akamai.com>
References:  <20171113175533.d2ncygry5imzqdw3@LK-Perkele-VII> <6FEBB0BE-24F1-4902-893B-7900A78E5625@gmail.com> <20171113191111.6gf2iigtbg4qqg5w@LK-Perkele-VII>
In-Reply-To: <20171113191111.6gf2iigtbg4qqg5w@LK-Perkele-VII>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.27.0.171010
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.147.22]
Content-Type: text/plain; charset="utf-8"
Content-ID: <0E9B28800A2F934FBE7170EE8173A9F7@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-13_13:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711130315
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-13_13:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711130314
Archived-At: 
Subject: Re: [TLS] Tonight's Encrypted SNI Hangout Session
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Nov 2017 22:40:45 -0000

TG9vayBhdCBDaHJpc3RpYW7igJlzIGRyYWZ0LCBpdCBjYXB0dXJlcyB0aGUgdXNlLWNhc2Uocykg
YW5kIHRyYWRlLW9mZnMgcHJldHR5IHdlbGwuDQoNCg0K


From nobody Mon Nov 13 17:16:07 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52981126E7A for ; Mon, 13 Nov 2017 17:16:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 CalUvAG5hcvM for ; Mon, 13 Nov 2017 17:16:04 -0800 (PST)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 7FC31126D74 for ; Mon, 13 Nov 2017 17:16:04 -0800 (PST)
Received: by mail-lf0-x22e.google.com with SMTP id m1so4449382lfj.9 for ; Mon, 13 Nov 2017 17:16:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lYMwUVghO3TLtUruulXKcGFwLuMeQfAdNw0s75KyZrg=; b=BIiJhpzMCb2pC0vPokz7sOY90voll3morAAEvorkeLkHyvafkeNTQoOeMyvIHFr/Yl jCBFnauJbVcZlAK6BlQPYUP5aAfPlWd/GbRQV79j4R/zXg/tl9fVhmYq3m8wSuvgodOi lj8PAj/6/6xBQKt6yOAgnlfLIUYrXK0eJvUj5OnpvBYZqernU8A3Gn4XkOdfV4DJwpxn EpXShn+8nLmS9/wP5s0wWC8Rjr+Syg25oxPIQ0DGJ10yTnZDLa9Qq+uDeYEHHR01goiZ 3o0W+Z1c1rlbgFb9kB61XJqjgWT78EuGU+O3SAxCWOAZrEUWxN5xExt4TH3pZDXPDLnx YmhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lYMwUVghO3TLtUruulXKcGFwLuMeQfAdNw0s75KyZrg=; b=d9zxSHAFkzVXaFvZPNJTBwrO7o5NK4XxCpsvkzPVjdwolCzt2uScwvLJ3PXvt3/0FX Kg+RnUp2vTpQtp05j3IcWbl5T/fMvai1uoEDytVpz33Hstu3thlGlbusL2YY3vNU+Qqe 7auxRrfzSyTbY3Rj16HpTDkwxodxUTHJeYhKIe/tOIS2d57BNbd6qeMa8A7jZUEFHNLe m8g8qDjHR9zCK4s+zb2osG37yW6zkF0TJOfK3pPqe4gl4+gUTHnqcP6DSH56SEgOE+mG 0oiYHlC6v52kykDfbbaLC13NsDi5h06DlXOgk6npsteRzY1PfigYPs0OmWVRdxA5g2Qc dZPA==
X-Gm-Message-State: AJaThX4kMU4lFlNfK2+75zyXveVpFOlNWjQJP1wKhkWvJ28rlId/1NEI urjMJzd0Z44yL4Pt0NXDINlWZ1e9RO4XWt3faFQ=
X-Google-Smtp-Source: AGs4zMaC0tT6fxEvJtF1omLu2M9P5VOgZLlWKLFN7Lw+3kY/ePgPkpsE6ty7P3CzspYWAtsrY2J93qmKd7Lwa+VDuXs=
X-Received: by 10.46.88.92 with SMTP id x28mr1175089ljd.138.1510622162895; Mon, 13 Nov 2017 17:16:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.83.155 with HTTP; Mon, 13 Nov 2017 17:16:02 -0800 (PST)
In-Reply-To: <44058361-FA9C-4DAF-87F6-7198B78D2C44@akamai.com>
References:  <20171113175533.d2ncygry5imzqdw3@LK-Perkele-VII> <6FEBB0BE-24F1-4902-893B-7900A78E5625@gmail.com> <20171113191111.6gf2iigtbg4qqg5w@LK-Perkele-VII> <44058361-FA9C-4DAF-87F6-7198B78D2C44@akamai.com>
From: Bret Jordan 
Date: Tue, 14 Nov 2017 09:16:02 +0800
Message-ID: 
To: "Salz, Rich" 
Cc: Ilari Liusvaara , David P ,  "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="f4030438698c68c660055de72166"
Archived-At: 
Subject: Re: [TLS] Tonight's Encrypted SNI Hangout Session
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 01:16:06 -0000

--f4030438698c68c660055de72166
Content-Type: text/plain; charset="UTF-8"

What I think I am more worried about right now is jumping in to designing a
technological solution before we know and understand what is going to break
and is a solution going to actually solve the perceived problem(s) or make
them worse. Technological changes do not always make things better.

Open Questions:
1) Is encrypted SNI the best solution to address the perceived problem(s)?
2) Do we fully understand the problems we are trying to solve and
understand the best way of solving them?
3) Will this make things better or worse for the majority of use-cases?
4) Does it incur so much collateral damage that it hurts the average user?
5) If we make it client opt-in (which seems like a fundamental
requirement), does this single out the client for extra scrutiny by a well
funded threat actor or nation state?

Just some food for thought

Bret

Sent from my TI-99/4A

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

--f4030438698c68c660055de72166
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


What I think I am more worried about right now is jumping =
in to designing a technological solution before we know and understand what=
 is going to break and is a solution going to actually solve the perceived =
problem(s) or make them worse. Technological changes do not always make thi=
ngs better.=C2=A0

Open Questions:
1) Is encryp=
ted SNI the best solution to address the perceived problem(s)?
2)=
 Do we fully understand the problems we are trying to solve and understand =
the best way of solving them?
3) Will this make things better or =
worse for the majority of use-cases?
4) Does it incur so much col=
lateral damage that it hurts the average user?
5) If we make it c=
lient opt-in (which seems like a fundamental requirement), does this single=
 out the client for extra scrutiny by a well funded threat actor or nation =
state?

Just some food for thought=C2=A0
Bret

=

Sent from my TI-99/4A
<=
span style=3D"background-color:rgba(255,255,255,0)">
PGP Fingerprint:=C2=A063B4 FC53 680A 6B7D 1447 =C2=A0F2C0 74F8 A=
CAE=C2=A07415 0050




--f4030438698c68c660055de72166--


From nobody Mon Nov 13 18:43:36 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B3C129B4D for ; Mon, 13 Nov 2017 18:43:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 RSg7P5Pm443O for ; Mon, 13 Nov 2017 18:43:33 -0800 (PST)
Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::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 BC62B129B97 for ; Mon, 13 Nov 2017 18:43:07 -0800 (PST)
Received: by mail-pg0-x22f.google.com with SMTP id t10so13199440pgo.3 for ; Mon, 13 Nov 2017 18:43:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=z1WzCs8SsZMUurSHuYvUwdI1zQnYCP2zIztMIFujoEw=; b=LxQ115W2akF7weIgwvvyyHeUuyubHlBcgBtC5m+7So2cW2XH5kEe3ulcf4XDbGRpEb 4g4aBe5zwqjxkxJOykSWuqRLma3ughF7pHEd/mnizsdHz8YwrudLF03qKZvvzu4Ixu9W Oh8OmoQ3uJIIYzJK6+nj8HE/snnY53a6HrWOLxd3NZj3760GGtzDyrHfVRziYUK8d/9c LxcNhAklNSd5KuNJ8NSmBYvzai1J+5NK+YUegKm4yuxMQM4mG/wI0aGyGZH56cWO+r9I 0oJiMcazK+nqQYnYe4bRsu3olcYtvx7jyx5rB503VDBn6bXyeF+xsG2isz31H5/EUGno NJJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=z1WzCs8SsZMUurSHuYvUwdI1zQnYCP2zIztMIFujoEw=; b=om9gQ7gs+BxkoDVYdvTPUE1ZprqxRsCQVaVmF65/LgOZnq7/oE3JY4wYOuX/Ux+jCz Vf2bz+1de6yYjTZ8SuO80NV7sZW/qq/dsMLIE4rke/Om6qckFG8w0lncW55JDp/sf3Xe XmkII6pX4n6z1THxSQMzX5YuxJwa2+cd6dmvo1ETFvv8aaZtOkP+oqdgx7v0nVCB1JW4 JdGw87sgJyS1RifRa2vPQx0PHfEkMu/6oUMoPz7AmxaPfOIpSfejKx2XGBSO6rNCKV7F KqT62ggKMF0Gx8qV1DSAWV4fbUU6lBJzn54G5kAdNl3hGaC0yjjt5Sb8HAdzp5TvabBW Pl0Q==
X-Gm-Message-State: AJaThX4snH5mbHkohEt5tbnsl2adadiPb3WCDZCGpaz9O2HD662Nmady R7HH5rcKuDoOJ9lVaptoBFceFs9J
X-Google-Smtp-Source: AGs4zMY8ez99eoaI7B4E0h/2vVcpWSG4ljPDSUF23CDCoyApE4hYFrB3CCsyb/npbVH2wt96qrmobw==
X-Received: by 10.84.129.195 with SMTP id b61mr10916728plb.82.1510627387307; Mon, 13 Nov 2017 18:43:07 -0800 (PST)
Received: from ?IPv6:2001:67c:370:128:ac00:6e53:e446:745? ([2001:67c:370:128:ac00:6e53:e446:745]) by smtp.gmail.com with ESMTPSA id o88sm18342794pfj.175.2017.11.13.18.43.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 18:43:06 -0800 (PST)
From: Yoav Nir 
Message-Id: <4890DB57-90E8-4F95-8DAF-1765CF491588@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_E678F8C9-25DE-4093-92F4-6289747147F7"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Date: Tue, 14 Nov 2017 10:43:20 +0800
In-Reply-To: 
Cc: Bret Jordan , "tls@ietf.org" 
To: Tom Ritter 
References:  
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
Subject: Re: [TLS] Tonight's Encrypted SNI Hangout Session
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 02:43:35 -0000

--Apple-Mail=_E678F8C9-25DE-4093-92F4-6289747147F7
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_CCCD2C60-C684-432D-833C-4113487D00F2"


--Apple-Mail=_CCCD2C60-C684-432D-833C-4113487D00F2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 14 Nov 2017, at 0:00, Tom Ritter  wrote:
>=20
> Are you also interested in collecting reports of where SNI is used to
> censor? Or the list of network vendors that support filtering and
> manipulating traffic based on the value?

I don=E2=80=99t think naming and shaming is a goal here.

> In general, the bad uses of SNI are harder to enumerate because people
> aren't willing to come to the WG and explain how they use SNI to
> selectively break or censor the internet for their citizens/users.

I don=E2=80=99t think that=E2=80=99s true. I used to work for a vendor =
of a network firewall, and I can explain how this is done.

Inspecting the ClientHello to find the SNI for filtering is a weak way =
to do filtering. It=E2=80=99s also a light-weight way.  So if I want to =
filter Wikipedia, I match SNIs to "*.wikipedia.org=E2=80=9D and I have =
my filtering. Depending on how many cycles I can spare, this is a =
cost-effective method. We have evidence that it=E2=80=99s been used for =
filtering, but sophisticated users can circumvent this - they can =
configure the browser to use TLS 1.0 and not send SNI at all.

More modern firewalls make a probing connection to the server, sending a =
ClientHello that is almost identical to the one sent by the real client =
and checking the returned certificate.  The names specified in that =
certificate are used for the filtering. That information is cached so =
that not every real ClientHello has to wait for a probing connection.  I =
don=E2=80=99t know if any vendor has made this scale to filter an entire =
country=E2=80=99s browsing, but this is considered to be more reliable =
than filtering by SNI.

> We
> have a few confirmed cases, anecdotal evidence, and lots of evidence
> of censors being technically applied by whatever means is available.
>=20
> But when you pile up all the administrators who will come to the WG
> and say "This really frustrates me and makes my job harder" you're
> going to have a much bigger pile than the users (or even technical
> advocates like myself) we can bring in and say "Plaintext SNI is
> harming the Internet=E2=80=9D.

IMO the real game-changer will be having an encrypted part to the =
ClientHello. If all ClientHellos are different, this defeats caching.

>=20
>> Side question, it feels like this effort could represent a lot of =
work and
>> require a lot of dedicated cycles. Does it make sense to continue =
this
>> effort inside of the TLS WG?  If it does, will the WG give us the =
time,
>> mindshare, and cycles to focus on it (just asking the hard question)?
>=20
> In August we adopted the draft, so the answer is "Yes".
>=20
> -tom


--Apple-Mail=_CCCD2C60-C684-432D-833C-4113487D00F2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On 14 Nov 2017, at 0:00, Tom Ritter <tom@ritter.vg> =
wrote:

Are you also interested in =
collecting reports of where SNI is used to
censor? Or the list of network =
vendors that support filtering and
manipulating traffic based on =
the value?

I don=E2=80=99t think naming and shaming is a goal =
here.

In general, the bad uses of SNI are harder to =
enumerate because people
aren't willing to come to the WG =
and explain how they use SNI to
selectively break or censor the =
internet for their citizens/users. 

I don=E2=80=99t think that=E2=80=99s true. I used =
to work for a vendor of a network firewall, and I can explain how this =
is done.  

Inspecting the =
ClientHello to find the SNI for filtering is a weak way to do filtering. =
It=E2=80=99s also a light-weight way.  So if I want to filter =
Wikipedia, I match SNIs to "*.wikipedia.org=E2=80=9D and I have my filtering. Depending =
on how many cycles I can spare, this is a cost-effective method. We have =
evidence that it=E2=80=99s been used for filtering, but sophisticated =
users can circumvent this - they can configure the browser to use TLS =
1.0 and not send SNI at all.

More =
modern firewalls make a probing connection to the server, sending a =
ClientHello that is almost identical to the one sent by the real client =
and checking the returned certificate.  The names specified in that =
certificate are used for the filtering. That information is cached so =
that not every real ClientHello has to wait for a probing connection. =
 I don=E2=80=99t know if any vendor has made this scale to filter =
an entire country=E2=80=99s browsing, but this is considered to be more =
reliable than filtering by SNI.

We
have a few confirmed cases, =
anecdotal evidence, and lots of evidence
of censors being technically =
applied by whatever means is available.

But when you pile up all the administrators who =
will come to the WG
and say "This really frustrates =
me and makes my job harder" you're
going to have a much bigger pile =
than the users (or even technical
advocates like myself) we can =
bring in and say "Plaintext SNI is
harming the =
Internet=E2=80=9D.

IMO the real game-changer will be having an =
encrypted part to the ClientHello. If all ClientHellos are different, =
this defeats caching.


Side question, it feels like =
this effort could represent a lot of work and
require a =
lot of dedicated cycles. Does it make sense to continue this
effort inside of the TLS WG?  If it does, will the WG =
give us the time,
mindshare, and cycles to focus on it =
(just asking the hard question)?

In August we adopted the draft, so the answer is =
"Yes".

-tom

=

--Apple-Mail=_CCCD2C60-C684-432D-833C-4113487D00F2--

--Apple-Mail=_E678F8C9-25DE-4093-92F4-6289747147F7
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAloKWEgACgkQuEkLFQpY
zJkrCwf+OwOVgMGZ9W6FVm4hSKaF6vTFUxFgDpkYfOC/ibIEpi0sNHTM2iOKye8i
7M1a2kL1yUx+IK7YCq7gQ9ltm5jZr8Iw6PENWP1KmphujZJG8d7wGg1kOuVv5i5T
IxnWHnbFNSAmcmYHZsQ9cPbmVxh20l9OUYPSC48FD6+TP8EPtBtCS6s3vs00SO5j
CcFfLjOCUuqUhatKyUkX4RU4olnr2UgNsKNiPoNZmMTwMqRP1UciJe0x3WwaI3Eq
MZVqAhCjNUoAZxSxa1/HbA2JFoAhjvoRaATp41LFZZqUHiDqWYdUBiVlnMHuo3oE
JiiU6PFwLcJrUHPeb34qyveQ3bxfBg==
=VgwY
-----END PGP SIGNATURE-----

--Apple-Mail=_E678F8C9-25DE-4093-92F4-6289747147F7--


From nobody Mon Nov 13 20:05:03 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96BCC128AFE for ; Mon, 13 Nov 2017 20:04:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 5O-kzy_8tc48 for ; Mon, 13 Nov 2017 20:04:49 -0800 (PST)
Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 65E6712704A for ; Mon, 13 Nov 2017 20:04:49 -0800 (PST)
Received: by mail-pf0-x241.google.com with SMTP id i15so3140384pfa.3 for ; Mon, 13 Nov 2017 20:04:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ePMKm3169NEcGF+88YxWCHn//nRGGUXlne02ao7BD7w=; b=mULoNKdkZF2aCgDYbC0l3MGAUqhC7eaayEvhgQwSu2kETTcsZZnMubTN0L+EijbQgf ey1U+R/QUIysGC0lgraf3YnZ3xTt+lx9f3Oe1UBiUuw07F7yUZuLpntQl46eAUBNFNFr 2EJBTVnB4TyZWIQvHfo+GV70bH+dVg549dp2zjezutCbMIfUCuT4u0fGTenAwFjbCk3j ehWcQT3F+CA0itRS6lKKeEWRjn/FkEMMZp9DTpAPKCFgrjXMtE8kGVt86Ys431eeSUYj LJP+ifF0yP2IbC6FQ1AYegO/GMWytUgfoMEuiao2CT+WtFNr6gANntPosSQzC/u27KfH K/Zg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ePMKm3169NEcGF+88YxWCHn//nRGGUXlne02ao7BD7w=; b=m6gUjP+IIkNJ8UUuAlNxuCp2R4qlNIAi74IQlVRmTnoDBZuTuwDpBkyi8y9+tnS/jo 42pQ1SSUAex/KWTq85r6DWY0FSe6UXBi3McXLLx/L6Kt67eB0PAksz00jCuYm5ZMrOea m44Yb6ZBlh+LQoLN/guYRXMIlhiOnrbAwf7aqaDWiQXpDDUWP+CScvk1MONwQyLXHhei hJdT8HuoLr2Bgto8sH6eC/aQdt4QbSZmucsoQfvjKeDXVesuUFR4gNYV8yIngvKEg/xY Uxk3xK1x5Uyau8st5/ZhwEv49EqKStMW+xpeaC5l9g5ckxcTVh+JYlvi0eDgT0j9f3E3 vaNQ==
X-Gm-Message-State: AJaThX6SYW643Ov4LfDiH4taRz/W6E8IJF/NmmX3Xjy3wfsxeUjK12TO gYKj7aDghDATtTJP02ee6J0=
X-Google-Smtp-Source: AGs4zMaIpdGVuczxGuro93yEP+EaWOeGtdYdEZk6yHYSrosj5Kqb2ui6iojGoY41/Mqqb053r0Ming==
X-Received: by 10.98.38.70 with SMTP id m67mr12255697pfm.131.1510632289042; Mon, 13 Nov 2017 20:04:49 -0800 (PST)
Received: from ?IPv6:2001:67c:1232:144:8c20:fee5:e56:ecb6? ([2001:67c:1232:144:8c20:fee5:e56:ecb6]) by smtp.gmail.com with ESMTPSA id 125sm33961770pff.14.2017.11.13.20.04.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 20:04:47 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-86A97394-1505-42E7-935F-24BB441E11FC
Mime-Version: 1.0 (1.0)
From: Bret Jordan 
X-Mailer: iPhone Mail (15A432)
In-Reply-To: <4890DB57-90E8-4F95-8DAF-1765CF491588@gmail.com>
Date: Tue, 14 Nov 2017 12:04:44 +0800
Cc: Tom Ritter , "tls@ietf.org" 
Content-Transfer-Encoding: 7bit
Message-Id: 
References:   <4890DB57-90E8-4F95-8DAF-1765CF491588@gmail.com>
To: Yoav Nir 
Archived-At: 
Subject: Re: [TLS] Tonight's Encrypted SNI Hangout Session
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 04:04:56 -0000

--Apple-Mail-86A97394-1505-42E7-935F-24BB441E11FC
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Great comments and feedback. Thank you. =20

Bret=20

Sent from my Commodore 128D

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

> On Nov 14, 2017, at 10:43 AM, Yoav Nir  wrote:
>=20
>=20
>=20
>> On 14 Nov 2017, at 0:00, Tom Ritter  wrote:
>>=20
>> Are you also interested in collecting reports of where SNI is used to
>> censor? Or the list of network vendors that support filtering and
>> manipulating traffic based on the value?
>=20
> I don=E2=80=99t think naming and shaming is a goal here.
>=20
>> In general, the bad uses of SNI are harder to enumerate because people
>> aren't willing to come to the WG and explain how they use SNI to
>> selectively break or censor the internet for their citizens/users.
>=20
> I don=E2=80=99t think that=E2=80=99s true. I used to work for a vendor of a=
 network firewall, and I can explain how this is done. =20
>=20
> Inspecting the ClientHello to find the SNI for filtering is a weak way to d=
o filtering. It=E2=80=99s also a light-weight way.  So if I want to filter W=
ikipedia, I match SNIs to "*.wikipedia.org=E2=80=9D and I have my filtering.=
 Depending on how many cycles I can spare, this is a cost-effective method. W=
e have evidence that it=E2=80=99s been used for filtering, but sophisticated=
 users can circumvent this - they can configure the browser to use TLS 1.0 a=
nd not send SNI at all.
>=20
> More modern firewalls make a probing connection to the server, sending a C=
lientHello that is almost identical to the one sent by the real client and c=
hecking the returned certificate.  The names specified in that certificate a=
re used for the filtering. That information is cached so that not every real=
 ClientHello has to wait for a probing connection.  I don=E2=80=99t know if a=
ny vendor has made this scale to filter an entire country=E2=80=99s browsing=
, but this is considered to be more reliable than filtering by SNI.
>=20
>> We
>> have a few confirmed cases, anecdotal evidence, and lots of evidence
>> of censors being technically applied by whatever means is available.
>>=20
>> But when you pile up all the administrators who will come to the WG
>> and say "This really frustrates me and makes my job harder" you're
>> going to have a much bigger pile than the users (or even technical
>> advocates like myself) we can bring in and say "Plaintext SNI is
>> harming the Internet=E2=80=9D.
>=20
> IMO the real game-changer will be having an encrypted part to the ClientHe=
llo. If all ClientHellos are different, this defeats caching.
>=20
>>=20
>>> Side question, it feels like this effort could represent a lot of work a=
nd
>>> require a lot of dedicated cycles. Does it make sense to continue this
>>> effort inside of the TLS WG?  If it does, will the WG give us the time,
>>> mindshare, and cycles to focus on it (just asking the hard question)?
>>=20
>> In August we adopted the draft, so the answer is "Yes".
>>=20
>> -tom
>=20

--Apple-Mail-86A97394-1505-42E7-935F-24BB441E11FC
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Great comments and feedback. Thank you. &nb=
sp;

Bret 

Sent from my Commodore=
 128D
<=
br>
PGP Fingerprint:&n=
bsp;63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

On Nov 14, 2017, at 10:43 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
<=
br>


On 14 Nov 2017, at 0:00, To=
m Ritter <tom@ritter.vg&g=
t; wrote:

Are you also interested in colle=
cting reports of where SNI is used to
censor? Or the list=
 of network vendors that support filtering and
manipulati=
ng traffic based on the value?

I don=E2=80=
=99t think naming and shaming is a goal here.

I=
n general, the bad uses of SNI are harder to enumerate because people=

aren't willing to come to the WG and explain how they use SNI to=

selectively break or censor the internet for their citize=
ns/users. 

I don=E2=80=
=99t think that=E2=80=99s true. I used to work for a vendor of a network fir=
ewall, and I can explain how this is done.  

<=
/div>
Inspecting the ClientHello to find the SNI for filtering is a weak=
 way to do filtering. It=E2=80=99s also a light-weight way.  So if I wa=
nt to filter Wikipedia, I match SNIs to "*.wikipedia.org=E2=80=9D and I have my filtering. Depending on h=
ow many cycles I can spare, this is a cost-effective method. We have evidenc=
e that it=E2=80=99s been used for filtering, but sophisticated users can cir=
cumvent this - they can configure the browser to use TLS 1.0 and not send SN=
I at all.

More modern firewalls make a p=
robing connection to the server, sending a ClientHello that is almost identi=
cal to the one sent by the real client and checking the returned certificate=
.  The names specified in that certificate are used for the filtering. T=
hat information is cached so that not every real ClientHello has to wait for=
 a probing connection.  I don=E2=80=99t know if any vendor has made thi=
s scale to filter an entire country=E2=80=99s browsing, but this is consider=
ed to be more reliable than filtering by SNI.

We
have a few confirmed cases, anecdotal evidence, and lots of evi=
dence
of censors being technically applied by whatever me=
ans is available.

But when you pile up all the administrators who will co=
me to the WG
and say "This really frustrates me and makes m=
y job harder" you're
going to have a much bigger pile than=
 the users (or even technical
advocates like myself) we ca=
n bring in and say "Plaintext SNI is
harming the Internet=E2=
=80=9D.

IMO the real game-changer wi=
ll be having an encrypted part to the ClientHello. If all ClientHellos are d=
ifferent, this defeats caching.


Side question, it feels like this effort could represent a lot of work an=
d
require a lot of dedicated cycles. Does it make sense to con=
tinue this
effort inside of the TLS WG?  If it does, will=
 the WG give us the time,
mindshare, and cycles to focus on it=
 (just asking the hard question)?

In=
 August we adopted the draft, so the answer is "Yes".

-tom

=

--Apple-Mail-86A97394-1505-42E7-935F-24BB441E11FC--


From nobody Mon Nov 13 21:50:05 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8615D128D69 for ; Mon, 13 Nov 2017 21:50:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 p95xiH1tDDOM for ; Mon, 13 Nov 2017 21:50:03 -0800 (PST)
Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 53FE6124B0A for ; Mon, 13 Nov 2017 21:50:03 -0800 (PST)
Received: by mail-qt0-x230.google.com with SMTP id v41so22862981qtv.12 for ; Mon, 13 Nov 2017 21:50:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=hOLRNV3Xl7e9Rn+p5gvIJDUlWbnGe4pMUQUpaiAWS/o=; b=rB/1t+psEzzuzEzdLSukxmIviCpiXKQR2zAaq809NcsSXOgnsL8oB/EnS1braX1Gqk TkWA/C7kbcBLeuPOWgB8AGbMnlTKMSRr0KUJsRvpcHyTmcuB/IclJUiwcTXSnMlI/53O EtmcIVqUl5rFZBXvVDU8QOsgJm/fcaIhcYh/OXmBwykxrfC11vqQjMqgjVIB+qb46XsX aEgk3JqyrfTyavVFzjT2mIBy921XMUIDaxNi0mpMc3jMEWBZeGCYdu/tkXl3wW9xSbVP bzUqR+pjd41Af3aThfIYPuSrpc51wj9yYHnsStbxF6ayImIc8dUa0uU0ygaafu184P0u duwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=hOLRNV3Xl7e9Rn+p5gvIJDUlWbnGe4pMUQUpaiAWS/o=; b=Dq3xw7YGqB3ZQVHklarGFTjgtM8P8jEMUjzBS4ORujqY05ReSvBebyB3/d3s3fKPhC p82Ne5W5W293V3Vz0CcAIrG1fBXPOaGtB1OSDe+0Vuf9AcAW1UANJPMYBFW+/kFWE77V YnBLSpw8shhUYS6BxpdtFq5MI36VkWHgfkwjI0lTYpeqIEnHdtT5gnn+mqak2KuFL/eB FqpCen5VlLj5+oy5Pyer3JCoftMx9rsDebs67mafMa2SuiJ94HFRZSQLeMIEacaSocJ4 yI9XfG/bhW5JoQLiEoKhHGs3NoiNLtu+yFPJ2wPTEIcc1CrAmFmyoZJekIXxHqUTeGo1 QvyA==
X-Gm-Message-State: AJaThX6MnyKfQbboVBnTnpZW3suBtQxmVlk8wZ9+8HcaD5DJmcTbXUKT dODdod2MACR4n7IxyJyElUspe4zNYDtNv+R/WAvLgFtT
X-Google-Smtp-Source: AGs4zMYlxL6cUE7TtzRTh6RRGATPcPgv9DDbFKBvymYMZKIq8dhTeB1eca1RR5XqeRjAwNhadThhsI3E8CrOlbl53jA=
X-Received: by 10.129.114.10 with SMTP id n10mr7133619ywc.327.1510638602187; Mon, 13 Nov 2017 21:50:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.61.12 with HTTP; Mon, 13 Nov 2017 21:49:21 -0800 (PST)
From: Eric Rescorla 
Date: Tue, 14 Nov 2017 13:49:21 +0800
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11473894448cae055deaf5e7"
Archived-At: 
Subject: [TLS] PR#1093: server_certificate_type
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Nov 2017 05:50:04 -0000

--001a11473894448cae055deaf5e7
Content-Type: text/plain; charset="UTF-8"

In Prague, we discussed moving server_certificate_type to EE, so that all
the
certificates in the server's Certificate message had to be of the same type.
I don't think anyone objected and this is implemented in PR#1093.

I don't plan to discuss this on Thursday. Unless someone objects, I'll just
merge this and it will be in -22.

-Ekr

--001a11473894448cae055deaf5e7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


In Prague, we discussed moving server_certificate_type to =
EE, so that all the
certificates in the server's Certificate messag=
e had to be of the same type.
I don't think anyone objected a=
nd this is implemented in PR#1093.

I don't pla=
n to discuss this on Thursday. Unless someone objects, I'll just
<=
div>merge this and it will be in -22.

-Ekr



--001a11473894448cae055deaf5e7--


From nobody Tue Nov 14 19:16:08 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67B31252BA for ; Tue, 14 Nov 2017 19:16:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level: 
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 sd18760hZFTY for ; Tue, 14 Nov 2017 19:16:05 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1647A12711E for ; Tue, 14 Nov 2017 19:16:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5616; q=dns/txt; s=iport; t=1510715765; x=1511925365; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=ORchBVYrfpqrTNGq6ncfNtOfWmYA1xMBqsslC4P1vkA=; b=YykE9X+v6FS5nb02GN3Mx/91pvEftxXKX3H2pr5SH1x0rYRqLEEr6Lxm sh/KnzuS/tbkfPgG2iefSrlRNP3gT44YTkUl1xI0Ijl2X5BsE08HciQ1b n2jgHg+1FuLWdFD2vxfkEOVa1TYcmU26d7XhqZ/swEhEph48iM3+PeP7k Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CmAAAhsAta/4YNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJERC5kbieDfoofjzGBfZEOhUmCEQoYAQqFGAKFAT8YAQEBAQE?= =?us-ascii?q?BAQEBayiFHwEBAQMBASFLCxALGCoCAicwBg0GAgEBF4l7DRCqW4InJopyAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARoFgzSBZiGBVYFpKYF0gQ2ILYJjBZMDjzGVBoIVhgi?= =?us-ascii?q?DYIdFliuBOR84gXNVJRVJgmSEfSM2AYhmAQEB?=
X-IronPort-AV: E=Sophos; i="5.44,398,1505779200"; d="scan'208,217"; a="31559595"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Nov 2017 03:16:04 +0000
Received: from [10.82.171.139] ([10.82.171.139]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vAF3G1tT020363; Wed, 15 Nov 2017 03:16:02 GMT
To: Bret Jordan , "Salz, Rich" 
Cc: "tls@ietf.org" 
References:  <20171113175533.d2ncygry5imzqdw3@LK-Perkele-VII> <6FEBB0BE-24F1-4902-893B-7900A78E5625@gmail.com> <20171113191111.6gf2iigtbg4qqg5w@LK-Perkele-VII> <44058361-FA9C-4DAF-87F6-7198B78D2C44@akamai.com> 
From: Flemming Andreasen 
Message-ID: <91f25af9-68f2-e91c-da17-50d22d9f5582@cisco.com>
Date: Tue, 14 Nov 2017 22:16:02 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------C813BEDC81EFAFC0752A2FF5"
Content-Language: en-US
Archived-At: 
Subject: Re: [TLS] Tonight's Encrypted SNI Hangout Session
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 03:16:07 -0000

This is a multi-part message in MIME format.
--------------C813BEDC81EFAFC0752A2FF5
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Please see https://www.ietf.org/id/draft-camwinget-tls-use-cases-00.txt 
for some example use case scenarios impacted by encrypted SNI.

As Ekr subsequently pointed out, it would be useful to make a 
distinction between conformant and non-conformant use case scenarios 
(which we plan to do in the next version).

Thanks

-- Flemming



On 11/13/17 8:16 PM, Bret Jordan wrote:
> What I think I am more worried about right now is jumping in to 
> designing a technological solution before we know and understand what 
> is going to break and is a solution going to actually solve the 
> perceived problem(s) or make them worse. Technological changes do not 
> always make things better.
>
> Open Questions:
> 1) Is encrypted SNI the best solution to address the perceived problem(s)?
> 2) Do we fully understand the problems we are trying to solve and 
> understand the best way of solving them?
> 3) Will this make things better or worse for the majority of use-cases?
> 4) Does it incur so much collateral damage that it hurts the average user?
> 5) If we make it client opt-in (which seems like a fundamental 
> requirement), does this single out the client for extra scrutiny by a 
> well funded threat actor or nation state?
>
> Just some food for thought
>
> Bret
>
> Sent from my TI-99/4A
>
> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


--------------C813BEDC81EFAFC0752A2FF5
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Please see
    https://www.ietf.org/id/draft-camwinget-tls-use-cases-00.txt for
    some example use case scenarios impacted by encrypted SNI. 

    

    As Ekr subsequently pointed out, it would be useful to make a
    distinction between conformant and non-conformant use case scenarios
    (which we plan to do in the next version). 

    

    Thanks 

    

    -- Flemming 

    

    

    

    
On 11/13/17 8:16 PM, Bret Jordan wrote:

    

    

      
      
What I think I am more worried about right now is
        jumping in to designing a technological solution before we know
        and understand what is going to break and is a solution going to
        actually solve the perceived problem(s) or make them worse.
        Technological changes do not always make things better. 
        


        

        
Open Questions:

        
1) Is encrypted SNI the best solution to address the
          perceived problem(s)?

        
2) Do we fully understand the problems we are trying to
          solve and understand the best way of solving them?

        
3) Will this make things better or worse for the majority
          of use-cases?

        
4) Does it incur so much collateral damage that it hurts
          the average user?

        
5) If we make it client opt-in (which seems like a
          fundamental requirement), does this single out the client for
          extra scrutiny by a well funded threat actor or nation state?

        


        

        
Just some food for thought 

          


          

          
Bret
            

              


              

              

                

                  
Sent
                      from my TI-99/4A
                    


                      

                    
PGP Fingerprint: 63B4 FC53 680A
                          6B7D 1447  F2C0 74F8 ACAE 7415 0050

                  

                

              

            

          

        

      

      

      

      

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


    

    

  


--------------C813BEDC81EFAFC0752A2FF5--


From nobody Wed Nov 15 04:25:31 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC9A127775; Wed, 15 Nov 2017 04:25:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 pdketfcDNNLn; Wed, 15 Nov 2017 04:25:28 -0800 (PST)
Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (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 BFDD8124D68; Wed, 15 Nov 2017 04:25:27 -0800 (PST)
Received: by mail-wr0-x236.google.com with SMTP id o88so20283707wrb.6; Wed, 15 Nov 2017 04:25:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0VwzI7bJ9hHc7Oq45wGIuexsYDeMbLnFc3zfYpOoi5Q=; b=HG8jr0kEBC9vgE2lG9OuC1wppKcfyD2lTBP8wGwIhZJpGmK4S9V7gMRKd3YeCAeLHI k5wPeRFoa09BYzv8pNNGaDtNdAOyGxy2i3mHRfhkQ/wZfc4dWQS6Dt1bKVuszvsUHaIk kiULYfEAcYbj7RTHdWdEfzM7UspFMLk4d29/FHJj3w4GAcRLl4gZViINk8/VLvo78nVn aTe2Q62e8ZmKHxql8Lm50WeUJTiaGHC/gw6xJUzGHWqML9ZbMD1ShMlq66SZtwkfd5j0 8ZjBkYqc+fj6Jfrw6lj+7d25VKnNnfJKjVm59AlTnGevOGU2kbZc8RFOxmyzTbBa6l5/ 9hyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0VwzI7bJ9hHc7Oq45wGIuexsYDeMbLnFc3zfYpOoi5Q=; b=Rdq7e0/L4kJr2WiNgjXYaM7sgFlbpJRnDca+xbKYeACJ7B8Yy6yBA0ONFcwcm3F6KZ KwOsxpXgn3VpXFbXUwzufrDNnK4cZrqHjFpKOrNrnpIw8sp07CNvXuOwD0TBLTKDgT3c V4kTP+f0Z7F5BjbfuDV/zR99ZiUzZhqakMwOhWtTpa092AAVOfhpywe7Exc0rw7fUFT5 QeY07t/NsCiQ1GK0yWGiSKnAmAS38Hbn1V0+Hqc9N0SP4XSCIsEkZdPvOm918msn2poY ZDDXcAnUPaKI+ypvuKIZoS9qT1VLZELy3z38OubWWe6Lko1PubTc1yE8z9uZxzmwgROV aSEQ==
X-Gm-Message-State: AJaThX6JpCHnAL2Acbu6RzjKOHjGGfo288cuBHvMuKoO+KS+MbyOBzez aGXrUKqtMwx53x3PQE2QgOnNireCw5GGyDL8JPA=
X-Google-Smtp-Source: AGs4zMZ/hMP/oJFLGvfgpAWvTO7+Vb8nBhxiYJ+WEtXjqOqematjTLBy/883Adj7kLGsPiFxcZf3NdSHgVMWLcSBtKE=
X-Received: by 10.223.169.135 with SMTP id b7mr12364945wrd.171.1510748725638;  Wed, 15 Nov 2017 04:25:25 -0800 (PST)
MIME-Version: 1.0
References: <150939987158.7857.14302357156892186600@ietfa.amsl.com>
In-Reply-To: <150939987158.7857.14302357156892186600@ietfa.amsl.com>
From: Nick Sullivan 
Date: Wed, 15 Nov 2017 12:25:14 +0000
Message-ID: 
To: internet-drafts@ietf.org
Cc: i-d-announce@ietf.org, tls@ietf.org
Content-Type: multipart/alternative; boundary="001a113c180622f9dd055e049909"
Archived-At: 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-exported-authenticator-04.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Nov 2017 12:25:30 -0000

--001a113c180622f9dd055e049909
Content-Type: text/plain; charset="UTF-8"

After some discussion on Github leading up to IETF 100, we discovered a few
drawbacks of the current draft that can be addressed by the following
change:
https://github.com/tlswg/tls-exported-authenticator/pull/9

The change introduces the concept of an *authenticator request,* which is
based on the CertificateRequest message in TLS. This change is motivated by
the following goals:
- Provide a way to bind authenticators to requests
- Move the certificate and extension selection logic from the application
into the TLS library, where code and logic can be reused

A consequence of this change is that it no longer allows "spontaneous"
client authentication, which did not have a compelling use case to begin
with.

Nick

On Tue, Oct 31, 2017 at 5:46 AM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Transport Layer Security WG of the IETF.
>
>         Title           : Exported Authenticators in TLS
>         Author          : Nick Sullivan
>         Filename        : draft-ietf-tls-exported-authenticator-04.txt
>         Pages           : 7
>         Date            : 2017-10-30
>
> Abstract:
>    This document describes a mechanism in Transport Layer Security (TLS)
>    to provide an exportable proof of ownership of a certificate that can
>    be transmitted out of band and verified by the other party.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-04
>
> https://datatracker.ietf.org/doc/html/draft-ietf-tls-exported-authenticator-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-exported-authenticator-04
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--001a113c180622f9dd055e049909
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


After some discussion on Github leading up to IETF 10=
0, we discovered a few drawbacks of the current draft that can be addressed=
 by the following change:
https://github.com/tlswg/tls-exported-authenticato=
r/pull/9

The change introduces the concept of =
an authenticator request, which is based on the CertificateRequest m=
essage in TLS. This change is motivated by the following goals:
-=
 Provide a way to bind authenticators to requests
- Move the cert=
ificate and extension selection logic from the application into the TLS lib=
rary, where code and logic can be reused

A con=
sequence of this change is that it no longer allows "spontaneous"=
 client authentication, which did not have a compelling use case to begin w=
ith.

Nick

On Tue, Oct 31, 2017 at 5:46 AM <internet-drafts@ietf.org> wrote:


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.

This draft is a work item of the Transport Layer Security WG of the IETF.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 Exported Authenticators in TLS

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Nick=
 Sullivan

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet=
f-tls-exported-authenticator-04.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 7

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=
 2017-10-30



Abstract:

=C2=A0 =C2=A0This document describes a mechanism in Transport Layer Securit=
y (TLS)

=C2=A0 =C2=A0to provide an exportable proof of ownership of a certificate t=
hat can

=C2=A0 =C2=A0be transmitted out of band and verified by the other party.




The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/=
doc/draft-ietf-tls-exported-authenticator/



There are also htmlized versions available at:

https://tools.ietf.org/html/draf=
t-ietf-tls-exported-authenticator-04

https://datatracker.ie=
tf.org/doc/html/draft-ietf-tls-exported-authenticator-04



A diff from the previous version is available at:

https://www.ietf.org/rfc=
diff?url2=3Ddraft-ietf-tls-exported-authenticator-04





Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at tools.ietf.org.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls




--001a113c180622f9dd055e049909--


From nobody Wed Nov 15 16:19:31 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31F3126DFE for ; Wed, 15 Nov 2017 16:19:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
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 azG5BAISrzXg for ; Wed, 15 Nov 2017 16:19:28 -0800 (PST)
Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (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 F3A8C120721 for ; Wed, 15 Nov 2017 16:19:27 -0800 (PST)
Received: by mail-pf0-x22d.google.com with SMTP id r62so5656921pfd.5 for ; Wed, 15 Nov 2017 16:19:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=X3TC90OAzLQtQgEmQw+e5K5hgmBlXkfxfbYHHzY57/o=; b=NH6ic0h2Qdtgygt7B+Bjk01Ef0jDu56GdtwxeI7SOvrt74seL9g9/Au2dsFV3OJNFg tXJLwjMPVMQNSIH8fNO+K6/+pMBruc2UnhKxMbPiD5FLf863MkQfv5x5+rxEVDobf3hw Sc6O+vSh9KQZUtke8WYNXF1q1i6C4v3E9BtoA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=X3TC90OAzLQtQgEmQw+e5K5hgmBlXkfxfbYHHzY57/o=; b=oyyrkWHA5iBqtXJooYs6LJYyNMCbMTn0asYEqdP2l6npl9hIrmcGkzawQhIHj+cR4T s2uaqVzvzeoErU3zDbXEQCI3WUB+j6KYO/uq+kGF6x1X1Dgw5ra42NiH2PEHEz60wwUV e6vHZ9Jv9G2y69QsJjtrnFH9dZxQgJL2CBLLNA57hzr4v+M5M8lzf3PqLcIgkRNZlUmh sv78TP1fGw00ApQJO68JcpOFXvCEE3oV7u2042Paj7k7efiZSSFS2WKPl9t9YfmaoMiG PGfSdJ8sZcCR2WwNdGcB6GpagQIoeWOtqr8VACVEwDcWqEk7HwnSZZNaoVtT2kyU3WZH Dehg==
X-Gm-Message-State: AJaThX4MAo0reIx/VEu9zdF/o/n2CUXpQBv6fiD/MK0PSNkS0E5Py5r4 g2ENfctPqwvbMIhUXtJcoR7I7EFo618=
X-Google-Smtp-Source: AGs4zMb02tEiHG9TYTL/nYrlMyZ377xr/QYpp9Kwn+clcrfz3B3ghItAgAAhbARPLGnFLsfe0g9zvg==
X-Received: by 10.99.119.15 with SMTP id s15mr17189321pgc.90.1510791567469; Wed, 15 Nov 2017 16:19:27 -0800 (PST)
Received: from ?IPv6:2001:67c:370:128:80bc:9e69:db5:f607? ([2001:67c:370:128:80bc:9e69:db5:f607]) by smtp.gmail.com with ESMTPSA id y83sm29944864pfd.66.2017.11.15.16.19.26 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 16:19:26 -0800 (PST)
From: Sean Turner 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <319271E2-F88E-429B-9369-6CA24A5C803E@sn3rd.com>
Date: Thu, 16 Nov 2017 08:19:24 +0800
To: "" 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: [TLS] TLS@IETF100: Slides Up
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 00:19:30 -0000

Slides have been posted and are available @:
https://datatracker.ietf.org/meeting/100/session/tls
If you downloaded slides from earlier this morning, the ConnectionID and =
TLS1.3 slides have been recently updated.

spt=


From nobody Wed Nov 15 16:53:00 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98504127978 for ; Wed, 15 Nov 2017 16:52:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
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 roD0kqZzcG60 for ; Wed, 15 Nov 2017 16:52:57 -0800 (PST)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 1B235120227 for ; Wed, 15 Nov 2017 16:52:57 -0800 (PST)
Received: by mail-pf0-x22e.google.com with SMTP id l24so5875902pfj.6 for ; Wed, 15 Nov 2017 16:52:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eW1M+thkKw9JTeiK314qNJnW4NfO/t6oLUJXHmww9mY=; b=B/1l9VNxMGIUPMW/ef+sENn3SJuWg6CXL7H4XkM8JT/bBHT3Uch7+tL+FxQlfMOfvK HbcC5fctwjIcVg6kOvdwlnFyq92b1cse8W4DYIozC3EtUzzrL6FbrzLn9r3waoRazQ9N McMLPaFtrxsp5Kvj4FQ2A/yFeS7wmMKvt/BAc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eW1M+thkKw9JTeiK314qNJnW4NfO/t6oLUJXHmww9mY=; b=ROUFJjdLf8GH+3jhQj2FxHztd7I9j5YYuiybDwKWfsmlLEkQrrE1SLI3o4Sjv+Y6hm pik7Dqp1DVYW2T2+iZhW8f3snVOuJI0K+v5hk0CWVv3kiBbqJ4CHA9DMRISk0Th/eJre gj+alr9vQAFwfdsFyjGz5t0HLnBZKTAnOwhLNBI3rmWf6nUtG2Ip53AnwmKTn5ODwH5L SKKs41hKYR1PXEWllXwK9mow3Dbw2I8lALmIiGAOPH4K4MLxV6faMzsfb8dn8DHLTVgn 5JDWqnKu43EurxqNXwzls7ndgdyNV7NflstW/KC7sCcM9hUaCtUBsXZvH5hIU2kcdgvl 5jNg==
X-Gm-Message-State: AJaThX7YEdgIwU5yzBQmAeWVLFoN3tgemNTFDmAW1aFQ7JUBKG4ciSI9 XPDD220SJT2l08EcytJ5eK1qAA==
X-Google-Smtp-Source: AGs4zMahiLCgYA1yaxoYYX5fx3x+yFWEEzoy5vjt5Sn32opzUrle2as78ZVjZrXhX8BrLHNSfXeG0Q==
X-Received: by 10.84.178.4 with SMTP id y4mr17593052plb.266.1510793576724; Wed, 15 Nov 2017 16:52:56 -0800 (PST)
Received: from ?IPv6:2001:67c:370:128:80bc:9e69:db5:f607? ([2001:67c:370:128:80bc:9e69:db5:f607]) by smtp.gmail.com with ESMTPSA id 140sm15514851pgd.85.2017.11.15.16.52.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 16:52:56 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Sean Turner 
In-Reply-To: 
Date: Thu, 16 Nov 2017 08:52:53 +0800
Cc: "tls@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <2E82F699-9A76-469F-95C9-67EC95CB689F@sn3rd.com>
References:  
To: Bret Jordan 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] Tonight's Encrypted SNI Hangout Session
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 00:52:58 -0000

> On Nov 14, 2017, at 00:00, Tom Ritter  wrote:
>=20
>> Side question, it feels like this effort could represent a lot of =
work and
>> require a lot of dedicated cycles. Does it make sense to continue =
this
>> effort inside of the TLS WG?  If it does, will the WG give us the =
time,
>> mindshare, and cycles to focus on it (just asking the hard question)?
>=20
> In August we adopted the draft, so the answer is "Yes".

The answer is definitely yes; but, the WG has already spent literally =
days of WG f2f time on this particular topic.  As Rich points out, =
Christian=E2=80=99s draft pretty much captures the use-case(s) and =
trade-offs that we=E2=80=99ve talked about over the last two years.  Now =
we just need to keep the discussions moving.

spt=


From nobody Wed Nov 15 17:14:37 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5421293EC for ; Wed, 15 Nov 2017 17:14:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
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 s911rwILWIyG for ; Wed, 15 Nov 2017 17:14:32 -0800 (PST)
Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (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 5B671126B71 for ; Wed, 15 Nov 2017 17:14:32 -0800 (PST)
Received: by mail-pg0-x229.google.com with SMTP id 4so10436705pge.1 for ; Wed, 15 Nov 2017 17:14:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=L/ms2DOfDHwyEmKsuPa3rk5Wduk3FFsvrCgcEdVOqVs=; b=hqzLfT98GG0XD9mMrToOzWxZs/mkcoQQLGq5mh/D3grcLqnxFrF4s2Z+Y0224yYyh/ 3cFk391VbRhwWEklti4lm41A78rcByOXmUBUD/OrJcypIobXOpE1QhEAonPwP8TjvXAs eTZGjtiBkNSqiCE+0LyeXYCIFOciPNGxTI+5E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=L/ms2DOfDHwyEmKsuPa3rk5Wduk3FFsvrCgcEdVOqVs=; b=e8/CDh1SyCy9mGroHOx7VPwAs2e9b3rd0yIcBoxKqWQvHlLjQaZFeMdQ59/6bIAgIb 6gWIZCUeqPGKyATXa0bZoyhnkDKjZs0ejUz+YvkFqA443GaYi4/YSDxDhZpKuvXgCcuS V+nLeXPDDY6XEt1SGZfDykhXg6ZBp27Nj3OPOUJIeGmjDI/HcrixRwF272hm+eqqbx04 Xi8PAZ/6XjCyaq9KfswKpfcPPkvUIkXiYgpCjYgJXu7LrUkXNdY51LFceCsyO4H1w2hl ejJfff7LJa3+90qBIL48m3eaqctXwtmqU97MPbO0xZBmniI57EngRipWjqRdadEQOhld NRKg==
X-Gm-Message-State: AJaThX6PiL9iLNbRurl0HBaxkODUVyhCCT9FRwK/KRCPS4/pH8svO0Iv n/prtCPGD07hYdBegtylnB8ZvBta1Xk=
X-Google-Smtp-Source: AGs4zMYye+S2pTpdt1Vvi4Ekk9hk6/rxMS7p/uFFHDvKDBaKVrDD2LItwFmnW0XPLjxiphSKAbxSRg==
X-Received: by 10.84.168.5 with SMTP id e5mr18009205plb.150.1510794871872; Wed, 15 Nov 2017 17:14:31 -0800 (PST)
Received: from [5.5.33.227] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id e8sm16073200pfk.6.2017.11.15.17.14.29 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 17:14:31 -0800 (PST)
From: Sean Turner 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 16 Nov 2017 09:14:25 +0800
References: <319271E2-F88E-429B-9369-6CA24A5C803E@sn3rd.com>
To: "" 
In-Reply-To: <319271E2-F88E-429B-9369-6CA24A5C803E@sn3rd.com>
Message-Id: 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] TLS@IETF100: Slides Up
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 01:14:35 -0000

I posted another set of updated TLS1.3 slides.

spt

> On Nov 16, 2017, at 08:19, Sean Turner  wrote:
>=20
> Slides have been posted and are available @:
> https://datatracker.ietf.org/meeting/100/session/tls
> If you downloaded slides from earlier this morning, the ConnectionID =
and TLS1.3 slides have been recently updated.
>=20
> spt


From nobody Wed Nov 15 19:13:40 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFBA126E7A for ; Wed, 15 Nov 2017 19:13:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 l7overk5Fb6S for ; Wed, 15 Nov 2017 19:13:37 -0800 (PST)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 437C512940E for ; Wed, 15 Nov 2017 19:13:37 -0800 (PST)
X-AuditID: 12074424-e55ff70000001373-bc-5a0d025d7d40
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id A8.72.04979.E520D0A5; Wed, 15 Nov 2017 22:13:35 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id vAG3DV3W003568 for ; Wed, 15 Nov 2017 22:13:32 -0500
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vAG3DSt3005645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 15 Nov 2017 22:13:30 -0500
Date: Wed, 15 Nov 2017 21:13:28 -0600
From: Benjamin Kaduk 
To: tls@ietf.org
Message-ID: <20171116031327.GJ82825@kduck.kaduk.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLIsWRmVeSWpSXmKPExsUixG6nohvPxBtlMPGMssWn812MDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKWLy+j7HgDXPFq+/2DYwTmLsYOTkkBEwkLv9ezdjFyMUhJLCY SWLVvK1MEM4RRokF6w4xQzgvmCRenuhjAWlhEVCVuHZsAxOIzSagItHQfRmoiINDREBAovml GEhYWEBPom/OGrASXqANK2fcZ4ewBSVOznwCNoZZQEvixr+XTCCtzALSEsv/cYCERQWUJfb2 HWKfwMg7C0nHLCQdsxA6FjAyr2KUTcmt0s1NzMwpTk3WLU5OzMtLLdI118vNLNFLTSndxAgO IxeVHYzdPd6HGAU4GJV4eC/E80QJsSaWFVfmHmKU5GBSEuV1/s0dJcSXlJ9SmZFYnBFfVJqT WnyIUYKDWUmEN3IhUDlvSmJlVWpRPkxKmoNFSZx3W9CuSCGB9MSS1OzU1ILUIpisDAeHkgSv KiNvlJBgUWp6akVaZk4JQpqJgxNkOA/Q8C4GoBre4oLE3OLMdIj8KUZjjhsPr/9h4ng283UD sxBLXn5eqpQ4rzbIOAGQ0ozSPLhpoFQgkb2/5hWjONBzwrz6IFU8wDQCN+8V0ComoFU2N7hB VpUkIqSkGhh5HgiH2p/UjEx6EDH5Dt/sRtW5FnNZjz2/oWjZ/Mpo9Ua5tWqXEpYUnl76wmRb ROmt7pmP2sM7uUueJMiYzZ+7OcGIqbnuf5FKnI39xNms3EufMpybbD6XMdQ+in+CLfOf63uN Zs3xtGOrvik2bcFFmSVRcu8K5+1fN+VF61rB+zsuTFxpURigxFKckWioxVxUnAgAUSkiz+AC AAA=
Archived-At: 
Subject: [TLS] draft-ietf-tls-exported-authenticator
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 03:13:39 -0000

In the exported authenticators draft we claim that "The
application layer protocol used to send the authenticator SHOULD
use TLS as its underlying transport."  This is of course natural --
why would you be using TLS authenticators if you were not using TLS
-- but it seems that we would also benefit from saying what
properties are actually *required* of the channel used to transport
the authenticator.  (Confidentiality?  Binding to the key material
of the TLS connection?)

-Ben


From nobody Wed Nov 15 20:01:08 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0706F12025C for ; Wed, 15 Nov 2017 20:01:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
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 PchlqCJt-Tom for ; Wed, 15 Nov 2017 20:00:56 -0800 (PST)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A22751294A1 for ; Wed, 15 Nov 2017 20:00:56 -0800 (PST)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAG3vfBO029594 for ; Thu, 16 Nov 2017 04:00:55 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=izwvb0OJZTUNLrj+Jw4U/RvPBjDxiilpwXIGxwULPnU=; b=dRMyqxLpVWQyHFpvETy0D6sl1TFmnUu7BbklAa9bPRGnTX+9Zq48qeuxKpObrnWswQSw Z67Pg4eRi0XyyMKaWeFkDnKpyESaxQu8bIieUgn8ofce7ukNgyMT4F4njZqsXcJsP63m WdxsevmNrrnnO2stFm8/QnGJ+LQ27e2qJlZ53TTO5IwA+HV9g+VS1YUTg/rqc4xS0J87 GAwCd6IT2NaW8DOyZRIa5NGkdrTPFEyTFntaros1bi7Idd/MQ1zaOqw69wtZ66g1N+Xi iuZpxItDGcNMcqnyX1dUOovaKvwH8+KPBmscdnQ/BnGOJy2Su2teiAqsPEfM+6GLGwnT 6Q== 
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050095.ppops.net-00190b01. with ESMTP id 2e8d5kkehe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 16 Nov 2017 04:00:54 +0000
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vAG40aQb019358 for ; Wed, 15 Nov 2017 23:00:53 -0500
Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2e7p3wr052-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 15 Nov 2017 23:00:52 -0500
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 15 Nov 2017 23:00:42 -0500
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 15 Nov 2017 23:00:42 -0500
From: "Salz, Rich" 
To: "tls@ietf.org" 
Thread-Topic: Drafts minutes for TLS at IETF-100
Thread-Index: AQHTXo94TPBM6UzK1E6RM2QmxSbw5w==
Date: Thu, 16 Nov 2017 04:00:42 +0000
Message-ID: <3B3E6451-82A1-42CB-9448-DDE486B4C5C7@akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.27.0.171010
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.147.53]
Content-Type: multipart/alternative; boundary="_000_3B3E645182A142CB9448DDE486B4C5C7akamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-16_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711160055
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-16_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711160054
Archived-At: 
Subject: [TLS] Drafts minutes for TLS at IETF-100
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Nov 2017 04:01:07 -0000

--_000_3B3E645182A142CB9448DDE486B4C5C7akamaicom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VExTIFdHIEAgSUVURiAxMDANCkNoYWlyczogSm9lIFNhbG93ZXkNCiAgICAgICAgU2VhbiBUdXJu
ZXINCk1pbnV0ZXMgUmljaCBTYWx6LCA/DQpKYWJiZXIgPw0KVGh1cnNkYXksIE5vdmVtYmVyIDE2
LCAyMDE3DQowOTMwLTEyMDAgKFVUQyswOCkNCg0KRm9yIGJhY2tncm91bmQsIHNlZSBodHRwczov
L2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTAwL3Nlc3Npb24vdGxzDQoNCkFkbWluaXN0
cml2aWEgKDEwbWluKQ0KDQpEb2N1bWVudCAgU3RhdHVzICg1bWluKQ0KUmVjb3JkIHNpemUgSS1E
IHRvIGdvIHRvIFdHTEMNCg0KVExTMS4zICg0MG1pbikNCkVrcjogSG9wZWZ1bGx5IHRoZSByZWFs
bHkgbGFzdCB0aW1lIEkgaGF2ZSB0byBzdGFuZCB1cCBhbmQgdGFsayBhYm91dCBUTFMgMS4zDQpE
aXNjdXNzaW9uIG9mIGNoYW5nZXMgcmVxdWlyZWQsIGFuZCBvcHRpb25hbCwgdG8gd29yayBhcm91
bmQgbWlkZGxlYm94IGludG9sZXJhbmNlICh3aGljaCBhY3R1YWxseSBtZWFucyBhbnlvbmUgY2Fu
IGZvcmNlIGEgZG93bmdyYWRlIHRvIFRMIDEuMikgYW5kIGdldCB0aGUgb2JzZXJ2ZWQgVExTIDEu
MyBmYWlsdXJlIHJhdGVzIGRvd24gdG8gbGV2ZWxzIGNvbXBhcmFibGUgdG8gcHJldmlvdXMgdmVy
c2lvbnMuICBTdHJvbmcgY29uc2Vuc3VzICh2aWEgaHVtKSBpbiB0aGUgcm9vbSB0byBvdmVyYWxs
IHN1cHBvcnQgdGhlc2UgY2hhbmdlcy4gU3Ryb25nIGNvbnNlbnN1cyAodmlhIGh1bSkgdG8gbm90
IHJlcXVpcmUg4oCcY29tcGF0aWJpbGl0eSBtb2Rl4oCdIGFzIGRlc2NyaWJlZCBvbiB0aGUgc2xp
ZGVzLg0KRGF2aWQgQmVuamFtaW4gcHJlc2VudGVkIG1lYXN1cmVtZW50IGluZm8gZnJvbSBDaHJv
bWUNCkhhbGYtY2xvc2UgZ2V0dGluZyBtZXJnZWQuDQpTTkkgYW5kIHJlc3VtcHRpb24g4oCTIHdh
aXRpbmcgZm9yIFBSIHRvIGRlc2NyaWJlIHNsaWRlIGNvbnRlbnQsIHRoZW4gdG8gYmUgbWVyZ2Vk
DQpEaXNjdXNzaW9uIG9mIG5leHQgc3RlcHMuICBDaGFpcnMgd2FudCB0byBzZWUgdGhlIE1vemls
bGEgYXBwcm94LiBjb25maXJtYXRpb24gb2YgR29vZ2xlIG51bWJlcnMNCkV4cGVjdCBkcmFmdC0y
MiB3aXRoIGNoYW5nZXMgZGlzY3Vzc2VkIGhlcmUsIHRoZW4gV0dMQyB0aGVuIG1vdmUgdG8gSUVU
RiBMQyBhbmQgdGhlbuKApiBwcm9maXQuDQoNCkRUTFMxLjMgKDMwbWluKQ0KRWtyIHByZXNlbnRp
bmc7IG1haW5seSBqb2ludCB3b3JrIHdpdGggSGFubmVzLg0KDQpDb25uZWN0aW9uIElEICgyNW1p
bikNCiAgICAgICAgICAgICAgICBFa3IgcHJlc2VudGluZy4gIFNlZSBzbGlkZXMuDQogICAgICAg
ICAgICAgICAgU3Ryb25nIGNvbnNlbnN1cyB2aWEgaHVtIHRvIGFkb3B0IHRoaXMuDQoNCkV4cG9y
dGVkIEF1dGhlbnRpY2F0b3JzIGluIFRMUyAoMTBtaW4pDQogICAgICAgICAgICAgICAgTmljayBT
dWxsaXZhbiBwcmVzZW50aW5nLg0KICAgICAgICAgICAgICAgIEhhdmUgYSBUYW1hcmluIChmb3Jt
YWwgYW5hbHlzaXMpIG1vZGVsLCBwcmVsaW1pbmFyeSByZXN1bHRzIHByb21pc2luZyBidXQgdGhl
cmUgaXMgc29tZSBkdXBsaWNhdGVkIGxvZ2ljIHNvIHRoZXJlIGlzIGEgcHJvcG9zZWQgY2hhbmdl
Lg0KICAgICAgICAgICAgICAgIEhUVFBXRyBpcyBsb29raW5nIGF0IOKAnGFkZGl0aW9uYWwgY2Vy
dHPigJ0gd2hpY2ggZG9lcyByZXF1aXJlIHRoaXMgZHJhZnQuDQoNCklBTkEgUmVnaXN0cnkgVXBk
YXRlcyBmb3IgVExTIGFuZCBEVExTICgxMG1pbikNCiAgICAgICAgICAgICAgICBTZWFuIHByZXNl
bnRpbmcuICBTdGVwaGVuIEZhcnJlbGwgdG8gc2hlcGhlcmQgYW5kIEFEIHJldmlldyBzdGFydGlu
Zy4NCg0KRXh0ZW5zaW9uIGZvciBwcm90ZWN0aW5nIChEKVRMUyBoYW5kc2hha2VzIGFnYWluc3Qg
RGVuaWFsIG9mIFNlcnZpY2UgKDEwbWluKQ0KICAgICAgICAgICAgICAgIE1hcmNvIFRpbG9jYSBw
cmVzZW50aW5nDQogICAgICAgICAgICAgICAgVHJ1c3QgYW5jaG9yICh0cnVzdGVkIGJ5IFRMUyBz
ZXJ2ZXIpIGdlbmVyYXRlcyBoYW5kc2hha2UgdG9rZW4gZm9yIGNsaWVudCB0byBwcmVzZW50IHdo
ZW4gaXQgdGFsa3MgdG8gdGhlIHNlcnZlciBhcyBhIGhhbmRzaGFrZSBleHRlbnNpb24uICBDcnlw
dG8gYWxsIGFyb3VuZC4NCg0KQXBwbGljYXRpb24tTGF5ZXIgVExTICgxMG1pbikNCiAgICAgICAg
ICAgICAgICBPd2VuIEZyaWVsIHByZXNlbnRpbmcuIERpc2N1c3Npb24gYWJvdXQgZ29hbHMgYW5k
IG1vdGl2YXRpb24uDQoNCg0K

--_000_3B3E645182A142CB9448DDE486B4C5C7akamaicom_
Content-Type: text/html; charset="utf-8"
Content-ID: <899145E9614DA44995EA1205D481F5FA@akamai.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1
bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl
cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29t
cG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0
ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1z
dHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9
DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh
bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4
LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk
U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxi
b2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5
NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UTFMgV0cgQCBJRVRGIDEwMDxicj4NCkNo
YWlyczogSm9lIFNhbG93ZXk8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU2VhbiBU
dXJuZXI8YnI+DQpNaW51dGVzIFJpY2ggU2FseiwgPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5KYWJiZXIg
PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0Ij5UaHVyc2RheSwgTm92ZW1iZXIgMTYsIDIwMTc8YnI+DQowOTMw
LTEyMDAgKFVUQyYjNDM7MDgpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxicj4NCkZvciBiYWNrZ3JvdW5k
LCBzZWUgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMC9z
ZXNzaW9uL3RscyI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTAwL3Nl
c3Npb24vdGxzPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48YnI+DQpBZG1pbmlzdHJpdmlhICgxMG1p
bik8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RG9jdW1lbnQgJm5ic3A7U3RhdHVzICg1
bWluKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0
ZXh0LWluZGVudDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UmVjb3JkIHNp
emUgSS1EIHRvIGdvIHRvIFdHTEM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQiPjxicj4NClRMUzEuMyAoNDBtaW4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0Ij5Fa3I6IEhvcGVmdWxseSB0aGUgcmVhbGx5IGxhc3QgdGltZSBJIGhhdmUg
dG8gc3RhbmQgdXAgYW5kIHRhbGsgYWJvdXQgVExTIDEuMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDouNWluIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdCI+RGlzY3Vzc2lvbiBvZiBjaGFuZ2VzIHJlcXVpcmVkLCBhbmQg
b3B0aW9uYWwsIHRvIHdvcmsgYXJvdW5kIG1pZGRsZWJveCBpbnRvbGVyYW5jZSAod2hpY2ggYWN0
dWFsbHkgbWVhbnMgYW55b25lIGNhbiBmb3JjZSBhIGRvd25ncmFkZSB0byBUTCAxLjIpIGFuZCBn
ZXQgdGhlIG9ic2VydmVkIFRMUyAxLjMgZmFpbHVyZQ0KIHJhdGVzIGRvd24gdG8gbGV2ZWxzIGNv
bXBhcmFibGUgdG8gcHJldmlvdXMgdmVyc2lvbnMuJm5ic3A7IFN0cm9uZyBjb25zZW5zdXMgKHZp
YSBodW0pIGluIHRoZSByb29tIHRvIG92ZXJhbGwgc3VwcG9ydCB0aGVzZSBjaGFuZ2VzLiBTdHJv
bmcgY29uc2Vuc3VzICh2aWEgaHVtKSB0byBub3QgcmVxdWlyZSDigJxjb21wYXRpYmlsaXR5IG1v
ZGXigJ0gYXMgZGVzY3JpYmVkIG9uIHRoZSBzbGlkZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi41aW4iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0Ij5EYXZpZCBCZW5qYW1pbiBwcmVzZW50ZWQgbWVhc3VyZW1lbnQg
aW5mbyBmcm9tIENocm9tZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJ0ZXh0LWluZGVudDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dCI+SGFsZi1jbG9zZSBnZXR0aW5nIG1lcmdlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQiPlNOSSBhbmQgcmVzdW1wdGlvbiDigJMgd2FpdGluZyBmb3IgUFIgdG8g
ZGVzY3JpYmUgc2xpZGUgY29udGVudCwgdGhlbiB0byBiZSBtZXJnZWQ8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LjVpbiI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkRpc2N1c3Npb24gb2YgbmV4dCBzdGVwcy4mbmJz
cDsgQ2hhaXJzIHdhbnQgdG8gc2VlIHRoZSBNb3ppbGxhIGFwcHJveC4gY29uZmlybWF0aW9uIG9m
IEdvb2dsZSBudW1iZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9InRleHQtaW5kZW50Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
Ij5FeHBlY3QgZHJhZnQtMjIgd2l0aCBjaGFuZ2VzIGRpc2N1c3NlZCBoZXJlLCB0aGVuIFdHTEMg
dGhlbiBtb3ZlIHRvIElFVEYgTEMgYW5kIHRoZW7igKYgcHJvZml0LjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
Ij48YnI+DQpEVExTMS4zICgzMG1pbikgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0Ij5Fa3IgcHJlc2VudGluZzsgbWFpbmx5IGpvaW50IHdvcmsgd2l0aCBIYW5uZXMu
PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkNvbm5lY3Rpb24gSUQgKDI1bWluKTxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRWtyIHByZXNl
bnRpbmcuJm5ic3A7IFNlZSBzbGlkZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyBTdHJvbmcgY29uc2Vuc3VzIHZpYSBodW0gdG8gYWRvcHQgdGhp
cy48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RXhwb3J0ZWQgQXV0aGVudGljYXRvcnMg
aW4gVExTICgxMG1pbik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IE5pY2sgU3VsbGl2YW4gcHJlc2VudGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhhdmUgYSBUYW1hcmluIChmb3JtYWwgYW5h
bHlzaXMpIG1vZGVsLCBwcmVsaW1pbmFyeSByZXN1bHRzIHByb21pc2luZyBidXQgdGhlcmUgaXMg
c29tZSBkdXBsaWNhdGVkIGxvZ2ljIHNvIHRoZXJlIGlzIGEgcHJvcG9zZWQgY2hhbmdlLjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSFRUUFdHIGlz
IGxvb2tpbmcgYXQg4oCcYWRkaXRpb25hbCBjZXJ0c+KAnSB3aGljaCBkb2VzIHJlcXVpcmUgdGhp
cyBkcmFmdC48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SUFOQSBSZWdpc3RyeSBVcGRh
dGVzIGZvciBUTFMgYW5kIERUTFMgKDEwbWluKTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyBTZWFuIHByZXNlbnRpbmcuJm5ic3A7IFN0ZXBoZW4gRmFycmVsbCB0byBzaGVw
aGVyZCBhbmQgQUQgcmV2aWV3IHN0YXJ0aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdCI+RXh0ZW5zaW9uIGZvciBwcm90ZWN0aW5nIChEKVRMUyBoYW5kc2hha2Vz
IGFnYWluc3QgRGVuaWFsIG9mIFNlcnZpY2UgKDEwbWluKTxicj4NCiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyBNYXJjbyBUaWxvY2EgcHJlc2VudGluZzxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVHJ1c3QgYW5jaG9yICh0cnVzdGVk
IGJ5IFRMUyBzZXJ2ZXIpIGdlbmVyYXRlcyBoYW5kc2hha2UgdG9rZW4gZm9yIGNsaWVudCB0byBw
cmVzZW50IHdoZW4gaXQgdGFsa3MgdG8gdGhlIHNlcnZlciBhcyBhIGhhbmRzaGFrZSBleHRlbnNp
b24uJm5ic3A7IENyeXB0byBhbGwgYXJvdW5kLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdCI+QXBwbGljYXRpb24tTGF5ZXIgVExTICgxMG1pbik8YnI+DQombmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT3dlbiBGcmllbCBwcmVzZW50aW5nLiBEaXNjdXNz
aW9uIGFib3V0IGdvYWxzIGFuZCBtb3RpdmF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
L2JvZHk+DQo8L2h0bWw+DQo=

--_000_3B3E645182A142CB9448DDE486B4C5C7akamaicom_--


From nobody Tue Nov 21 12:38:05 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38E3124B18 for ; Tue, 21 Nov 2017 12:38:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 3byME21SjPdP for ; Tue, 21 Nov 2017 12:38:02 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9929C1204DA for ; Tue, 21 Nov 2017 12:38:02 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 77346BE56 for ; Tue, 21 Nov 2017 20:38:00 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2rZfpGmzlqX for ; Tue, 21 Nov 2017 20:37:58 +0000 (GMT)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C6140BE53 for ; Tue, 21 Nov 2017 20:37:58 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1511296678; bh=Ap1TvdrDmAotZwipuunQOxCQKZzqujySt61EngwoG1I=; h=To:From:Subject:Date:From; b=RhgPJYqzIfSE3CuTDK7VvufPu7YMFb1KL8IjTiilzFzuZjBEhwtJrkZZIsrX60eQv /Oht4FtiQ8wVFZFbl9s3aoTYIp20+oKDImNt4Xa/NdWF3ytlSmlAthjdGVcnvBH5Dm aote1jbmlJqAra56fA50O6lN6L4dMNSgGsyMl/aw=
To: "tls@ietf.org" 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <0b536834-e49b-4c07-fc19-4d44c7e0ad99@cs.tcd.ie>
Date: Tue, 21 Nov 2017 20:37:58 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="24QlptuUESX9WTNf1SGm5cAvWFP6Hn7sm"
Archived-At: 
Subject: [TLS] question for the WG about draft-ietf-tls-iana-registry-updates
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 20:38:05 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--24QlptuUESX9WTNf1SGm5cAvWFP6Hn7sm
Content-Type: multipart/mixed; boundary="8H74E3cRju5QswcaoDB4jAgThOQE38pVb";
 protected-headers="v1"
From: Stephen Farrell 
To: "tls@ietf.org" 
Message-ID: <0b536834-e49b-4c07-fc19-4d44c7e0ad99@cs.tcd.ie>
Subject: question for the WG about draft-ietf-tls-iana-registry-updates

--8H74E3cRju5QswcaoDB4jAgThOQE38pVb
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable


Hiya,

I just posted a draft shepherd write-up for this [1]. (The
write-up text was mostly written by Sean as it happens - for
which he has my thanks as it's boring as hell to do that:-)

There are nits but only one substantive question that I don't
recall the WG discussing before (but maybe I'm forgetting).

What is needed to change from Recommended =3D=3D Yes down to
Recommended =3D=3D No? Does that need a standards action (e.g.
with an RFC) or just IETF review or even maybe just IESG
action?

In the current draft write-up I've put in the first as a
placeholder, as that's symmetric with the No->Yes change but
I think IESG action is probably ok if the WG wanted that as
the IESG probably won't go crazy and will likely do as the
WG want in such cases. If the WG do want to write a specific
foo-no-longer-recommended RFC it can do that in all cases,
and of course Yes->No transitions could be documented in an
RFC that documents a "replacement" Yes entry.

So, unless this was already discussed....answers on a postcard
please - which'd we like:

(1) say nothing (as in -02 draft)
(2) say standards action is required for a Yes->No transition
(3) say IETF review (i.e. an IETF last call) is required for a
    Yes->No transition
(4) say IESG action is required for a Yes->No transition
(5) something else

And as a reminder the Recommended column is not about crypto
quality but is about things for which we have consensus that
they ought be widely implemented and available at the current
point in time. Those are related things but Recommended =3D=3D No
does not imply crap-crypto even if crap-crypto will hopefully
imply Recommended =3D=3D No.

If nobody says anything I'll chat with Kathleen, Sean and Joe
and we'll pick a thing and that'll doubtless be quibbled about
during directorate reviews and IESG processing as these things
always are;-)

But since I'd hope implementers will care about keeping up to
date with the set of Recommended =3D=3D Yes things, I do hope that
folks are willing to express a preference here.

Cheers,
S.

[1]
https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/she=
pherdwriteup/


--8H74E3cRju5QswcaoDB4jAgThOQE38pVb--

--24QlptuUESX9WTNf1SGm5cAvWFP6Hn7sm
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJaFI6mAAoJEC88hzaAX42i+usIAJZquAGcqXR7H8ABVsAsTn7m
yvLdHyjfUmJV74KjtXyInL7/RQxHZSknSlELubzwjgBxZadIS9+JZ+T/SFxG+7qI
Z2fo7Asgtnd1JWCMsU2zLR0YnHTaPXflYVsR5p5J5Y7fqt20V7EvN695hoHMPj3f
qGlZ/u05p2hzEhPszgr28MijH58fxs0I4mE25HOeuLaXUti86fTOluU+vnH49JMB
VXkPfyLyH8Z3v6YHPjHctCX5uaK23ePuxIQyEOKt3OR1GsDFET7ozfZ8HvFIzFW3
av/j5w1TOyoEQq0UY8j+zmEvLrfb5CwZBBdBBYQ53mvLVILGYyAyncgGpGeVM1k=
=a8oV
-----END PGP SIGNATURE-----

--24QlptuUESX9WTNf1SGm5cAvWFP6Hn7sm--


From nobody Tue Nov 21 15:39:45 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A54129572 for ; Tue, 21 Nov 2017 15:39:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 If6gOrAKe64y for ; Tue, 21 Nov 2017 15:39:41 -0800 (PST)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 9CE2D12947B for ; Tue, 21 Nov 2017 15:39:41 -0800 (PST)
Received: by mail-oi0-x230.google.com with SMTP id d93so2066043oic.4 for ; Tue, 21 Nov 2017 15:39:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RQocx1CSZ1d4vEAvuK+1poBaa4DL2ur7XUxQ71N12Us=; b=YQBsDilw/oJweqjojPIAEEJyqY/ViaombZJQIASlGJraxKi20+QYJDameCM6mcpfYy Hwmam1IwLT4VQXE9yQFx2lA+nJMKUPRFp2kT1FulIH+lATPVzLHEvTZ27XfPHN1mZEA1 NlXQH+Xw3sqpDUSXsfWXVXhrlHFt6r5UsbptX9jGONQb6D6s9+VFA0X+A/Q8H62tSnaR ouAidu09yoqU7Ba4TU8j+S6r1wKlvtFfwhJ5tWnuubGd73ah4wbYGyEVSSAA94xSAccT IE9W9JRNhNXTOS7Lc+ZgivEhYjCm6OUYm3isDg6lfN8yIz8rt6KVbrMogCkIfPKp4Ija Dylg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RQocx1CSZ1d4vEAvuK+1poBaa4DL2ur7XUxQ71N12Us=; b=jOUA5VRe+IrEASvJvPb9j64CnAGJH2I1i/8Gbg2eFvAUdeSeSFeLDlWxTMWdZqZFc8 9/7epSEtvYfQ3kHFcB4LSikQxLKH9tGquEEpeU9SIIeMxuwjFo+umuzAQCDoSlaegR59 ALiD7lVAaY25n8z5PkkKHDcEeiC+lIsa207Hc7aa3Uksh+ci0xNe/nDi6dNwUzqAE1V+ rkxsn0L/k2IMbph/dATWH4NQ4KKrHaBY8NC1VNejRDmc2lQT0JgW19EYD90C78IDMjDG /HpWS73szCC54uNBVzeo/s0PseYcpVr8bobdBMxvG42Af2Giaf/BzB2Csv+UnMwlxAAB jKog==
X-Gm-Message-State: AJaThX7PrCE5flRq6OTLx7eIQ3/gGy5cCAPVJI6GiK8zFW1IWCcq5wJd f65NfPv20MK8A5+ANZd9RUl0UoqlrvFaLm4mHy0E7Q==
X-Google-Smtp-Source: AGs4zMYJAdcJ3Jzaa0f1TXLlvhlh3qmPdn0BGYrxlkannhx6hTSfxE3bmpQYHj4KVJMzNoU2Yxnf43z+7tBCyNzzpgw=
X-Received: by 10.202.48.8 with SMTP id w8mr10867840oiw.284.1511307580581; Tue, 21 Nov 2017 15:39:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.8.11 with HTTP; Tue, 21 Nov 2017 15:39:40 -0800 (PST)
In-Reply-To: <0b536834-e49b-4c07-fc19-4d44c7e0ad99@cs.tcd.ie>
References: <0b536834-e49b-4c07-fc19-4d44c7e0ad99@cs.tcd.ie>
From: Martin Thomson 
Date: Wed, 22 Nov 2017 10:39:40 +1100
Message-ID: 
To: Stephen Farrell 
Cc: "tls@ietf.org" 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [TLS] question for the WG about draft-ietf-tls-iana-registry-updates
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 23:39:43 -0000

IESG action seems appropriate for both.  If we could include guidance
around this (values with Yes should only include those for which the
community currently has consensus are worth having available at the
current time), tat would be awesome.

On Wed, Nov 22, 2017 at 7:37 AM, Stephen Farrell
 wrote:
>
> Hiya,
>
> I just posted a draft shepherd write-up for this [1]. (The
> write-up text was mostly written by Sean as it happens - for
> which he has my thanks as it's boring as hell to do that:-)
>
> There are nits but only one substantive question that I don't
> recall the WG discussing before (but maybe I'm forgetting).
>
> What is needed to change from Recommended == Yes down to
> Recommended == No? Does that need a standards action (e.g.
> with an RFC) or just IETF review or even maybe just IESG
> action?
>
> In the current draft write-up I've put in the first as a
> placeholder, as that's symmetric with the No->Yes change but
> I think IESG action is probably ok if the WG wanted that as
> the IESG probably won't go crazy and will likely do as the
> WG want in such cases. If the WG do want to write a specific
> foo-no-longer-recommended RFC it can do that in all cases,
> and of course Yes->No transitions could be documented in an
> RFC that documents a "replacement" Yes entry.
>
> So, unless this was already discussed....answers on a postcard
> please - which'd we like:
>
> (1) say nothing (as in -02 draft)
> (2) say standards action is required for a Yes->No transition
> (3) say IETF review (i.e. an IETF last call) is required for a
>     Yes->No transition
> (4) say IESG action is required for a Yes->No transition
> (5) something else
>
> And as a reminder the Recommended column is not about crypto
> quality but is about things for which we have consensus that
> they ought be widely implemented and available at the current
> point in time. Those are related things but Recommended == No
> does not imply crap-crypto even if crap-crypto will hopefully
> imply Recommended == No.
>
> If nobody says anything I'll chat with Kathleen, Sean and Joe
> and we'll pick a thing and that'll doubtless be quibbled about
> during directorate reviews and IESG processing as these things
> always are;-)
>
> But since I'd hope implementers will care about keeping up to
> date with the set of Recommended == Yes things, I do hope that
> folks are willing to express a preference here.
>
> Cheers,
> S.
>
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/shepherdwriteup/
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


From nobody Tue Nov 21 15:54:52 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3BB6129B79 for ; Tue, 21 Nov 2017 15:54:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 Lo6-QXn4HUUP for ; Tue, 21 Nov 2017 15:54:49 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087A7129451 for ; Tue, 21 Nov 2017 15:54:48 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 02D67BE56; Tue, 21 Nov 2017 23:54:46 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyVqvaizNvlj; Tue, 21 Nov 2017 23:54:43 +0000 (GMT)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 97F7EBE53; Tue, 21 Nov 2017 23:54:43 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1511308483; bh=0n5hAWDm1J37ijkMO1qNB0DT+FtfYc1ej/yRSL5MCCY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=SuFYE8F+5xJ9+54ei7lUI+aRTtfT8w08xWBxePfzOkG917sdDXk8F+xWFRoeRAR9t H5oCicalKcGJEiTuuszvn/IDv54+KN/VcSYN0ku+IiaAsoVaZ+T/soVSz08/VDkU5p zEGFoPHZe5k9yY3tOO5RscByizZS6fQ/IU2qtlCI=
To: Martin Thomson 
Cc: "tls@ietf.org" 
References: <0b536834-e49b-4c07-fc19-4d44c7e0ad99@cs.tcd.ie> 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <16bf6215-f8dd-5d9c-22c3-a8814da13693@cs.tcd.ie>
Date: Tue, 21 Nov 2017 23:54:42 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TnJh9QWo8eX7de6jLEnSVM3L8iOFeaXkt"
Archived-At: 
Subject: Re: [TLS] question for the WG about draft-ietf-tls-iana-registry-updates
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Nov 2017 23:54:51 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--TnJh9QWo8eX7de6jLEnSVM3L8iOFeaXkt
Content-Type: multipart/mixed; boundary="Ep2mFNP4oKLb8hut6M6BcKCSRA765W0BN";
 protected-headers="v1"
From: Stephen Farrell 
To: Martin Thomson 
Cc: "tls@ietf.org" 
Message-ID: <16bf6215-f8dd-5d9c-22c3-a8814da13693@cs.tcd.ie>
Subject: Re: [TLS] question for the WG about
 draft-ietf-tls-iana-registry-updates
References: <0b536834-e49b-4c07-fc19-4d44c7e0ad99@cs.tcd.ie>
 
In-Reply-To: 

--Ep2mFNP4oKLb8hut6M6BcKCSRA765W0BN
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable



On 21/11/17 23:39, Martin Thomson wrote:
> IESG action seems appropriate for both. =20

I'm fairly sure the WG discussed the No->Yes (or new Yes)
before and wanted standards action for that. I'd guess
that changing that might take some discussion. (FWIW, I'd
not support that change myself but maybe others would.)

If the No->Yes stuff doesn't change I'll take you as
arguing for a (4) below but correct me if that's wrong.

Cheers,
S.

> If we could include guidance
> around this (values with Yes should only include those for which the
> community currently has consensus are worth having available at the
> current time), tat would be awesom>
> On Wed, Nov 22, 2017 at 7:37 AM, Stephen Farrell
>  wrote:
>>
>> Hiya,
>>
>> I just posted a draft shepherd write-up for this [1]. (The
>> write-up text was mostly written by Sean as it happens - for
>> which he has my thanks as it's boring as hell to do that:-)
>>
>> There are nits but only one substantive question that I don't
>> recall the WG discussing before (but maybe I'm forgetting).
>>
>> What is needed to change from Recommended =3D=3D Yes down to
>> Recommended =3D=3D No? Does that need a standards action (e.g.
>> with an RFC) or just IETF review or even maybe just IESG
>> action?
>>
>> In the current draft write-up I've put in the first as a
>> placeholder, as that's symmetric with the No->Yes change but
>> I think IESG action is probably ok if the WG wanted that as
>> the IESG probably won't go crazy and will likely do as the
>> WG want in such cases. If the WG do want to write a specific
>> foo-no-longer-recommended RFC it can do that in all cases,
>> and of course Yes->No transitions could be documented in an
>> RFC that documents a "replacement" Yes entry.
>>
>> So, unless this was already discussed....answers on a postcard
>> please - which'd we like:
>>
>> (1) say nothing (as in -02 draft)
>> (2) say standards action is required for a Yes->No transition
>> (3) say IETF review (i.e. an IETF last call) is required for a
>>     Yes->No transition
>> (4) say IESG action is required for a Yes->No transition
>> (5) something else
>>
>> And as a reminder the Recommended column is not about crypto
>> quality but is about things for which we have consensus that
>> they ought be widely implemented and available at the current
>> point in time. Those are related things but Recommended =3D=3D No
>> does not imply crap-crypto even if crap-crypto will hopefully
>> imply Recommended =3D=3D No.
>>
>> If nobody says anything I'll chat with Kathleen, Sean and Joe
>> and we'll pick a thing and that'll doubtless be quibbled about
>> during directorate reviews and IESG processing as these things
>> always are;-)
>>
>> But since I'd hope implementers will care about keeping up to
>> date with the set of Recommended =3D=3D Yes things, I do hope that
>> folks are willing to express a preference here.
>>
>> Cheers,
>> S.
>>
>> [1]
>> https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/=
shepherdwriteup/
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>=20


--Ep2mFNP4oKLb8hut6M6BcKCSRA765W0BN--

--TnJh9QWo8eX7de6jLEnSVM3L8iOFeaXkt
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJaFLzDAAoJEC88hzaAX42iJGcH/3ObjNuSapyk8eDIExXvd991
ZUFIL7tDTorxLE7UFW3ysaqQJ+mrk03MpNz9YmEKpRo5CuDGzYchGx12Lx7yvNRE
YYVEG5KaDoqcx2gZo4JvJt0cFJNd02eI+l4GtEAkh6fNsc6ngDWj58RPVHsLS5Uh
zKT1fRArhAnM7cdQrEv1PZgCGPIw3VTa4HIhpJmRDgDA+Z5fe0/Q3qDGRyC5FqWK
xxWDRDND9+ZUGqdixUHVEXNE2MKUVPHG+GPkISe5SYqvE/EwLeoqxIbm2jCfEPKF
ueRB1QwT0iFXpQR2x5B8OX8lr7xiqu2pbjN5nF5HiOGbQQ29hskuFC31tiSk0Eo=
=xfrQ
-----END PGP SIGNATURE-----

--TnJh9QWo8eX7de6jLEnSVM3L8iOFeaXkt--


From nobody Tue Nov 21 18:40:59 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E12129477 for ; Tue, 21 Nov 2017 18:40:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.821
X-Spam-Level: 
X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=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 uvexhRnmGEvq for ; Tue, 21 Nov 2017 18:40:57 -0800 (PST)
Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0273120713 for ; Tue, 21 Nov 2017 18:40:56 -0800 (PST)
Received: from woodstock.owlhill.net (a88-112-88-23.elisa-laajakaista.fi [88.112.88.23]) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id D16DA40089 for ; Wed, 22 Nov 2017 04:40:53 +0200 (EET)
Received: from [192.168.0.158] (dhcp-158.owlhill [192.168.0.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by woodstock.owlhill.net (Postfix) with ESMTPSA id 65D2CC7CF65C0 for ; Wed, 22 Nov 2017 04:40:53 +0200 (EET)
To: tls@ietf.org
References: 
From: Tapio Sokura 
Message-ID: <389abe54-41d3-30e9-4cca-caa8b1469ae7@iki.fi>
Date: Wed, 22 Nov 2017 04:40:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 02:40:59 -0000

Hello,

On 6.11.2017 20:19, Eric Rescorla wrote:
> Once you do this, the middleboxes seem to mostly ignore everything
> after the CCS, so the rest of the handshake proceeds smoothly.
> 
> This is all a bit nasty, but none of it changes the cryptographic
> computations or the state machine (because you just ignore CCS).

The discussion in Singapore on middlebox issues during the WG session 
woke me up on this. I don't post much on this list, but here I have to 
say that this dance to work around middleboxes looks seriously like 
putting the cart before the horse.

I'm not arguing that the cryptographic properties/security of TLS 1.3 is 
affected by these changes. I'm saying that this messing around with 
making 1.3 look like 1.2 adds unnecessary complexity that will just hurt 
everyone in the long run. In the short term you get a few % more 
successful 1.3 handshakes, but once it's in the spec, it will bother 
implementers for years to come.

Sometimes you have to let some things break to be able to move forward. 
If over 90% (the figures presented in Singapore) of TLS 1.3 handshakes 
already go through without 1.2 emulation / middlebox compensation in the 
protocol, I find that a very good number for this point in time.

It's the middleboxes that should adapt to be 1.3 compatible, not the 
other way around. This is not sending a good signal to the industry.

Sorry if I'm beating a dead horse (behind the cart). But my 
interpretation of the comments made during the WG session indicate that 
if there's consensus on incorporating these middlebox compatibility 
changes, it's a very rough consensus.

   Tapio


From nobody Tue Nov 21 19:38:21 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0EE1205F0 for ; Tue, 21 Nov 2017 19:38:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=levangong-org.20150623.gappssmtp.com
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 tVhjT8wtQ6SG for ; Tue, 21 Nov 2017 19:38:18 -0800 (PST)
Received: from mail-pl0-x234.google.com (mail-pl0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) (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 D6E96124BE8 for ; Tue, 21 Nov 2017 19:38:18 -0800 (PST)
Received: by mail-pl0-x234.google.com with SMTP id v15so93715plk.11 for ; Tue, 21 Nov 2017 19:38:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=levangong-org.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=+vx7UKZjIz/ot74xCbd2V8mJNkyYnhIuPdTzGp4+oHY=; b=OVxMhodehmlHKEJaQss1npN1hHd1RztRuT1vg8n/NQWCAKBHWxuMQ4l759T7ejWEOn arnPwmQ1Nodg5GNBfLMsNzTPCSzsZ4q30FlbHdKrmp+9Pl6TzbNdLQbmDwx9zC04iNuO W6FFELidGRe29cTlez7wKWk76zBuwn0pMNKn0iHZMcIz0zVaK1YHkS+XmSvjzW00yZ9G gniU3VpQWHGbUL40MPtoXAvNEqvCrZJHNFW8WTiR4WtZsX+rdiVS3KoDIaKm2WBaXkrG RZf/Epv1iEOtCY+SLDAWk6CuFlR4LjQCukJ6dQx/U5G9mEMzL9ifHmyBAAYQPEzvH9Kw wjKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=+vx7UKZjIz/ot74xCbd2V8mJNkyYnhIuPdTzGp4+oHY=; b=hmtV0t9jOT0WzcoIdudXTi8eXNqKVwa+1aRUME2ZKqeIrQYXARJ3sarjego2/w1Hck UQL7arc7CHXKpkdILZIa6X4kHmD/6twr4dCiY30gdhwkV3Kym3QGhKtP83Ui7FP0Cv9E 6J0s18rIbF01w/ipaFnIO4bPUXXD25nY9xE0mlpG5JpK6ducIkH6cl/94pHvkWfhNdB2 DgxS3rpx62ARbFdA+43A2bTWe9NG6TTMRceJgZt2dF8EtXwkrOY5zYEc0jyIcIZmQA3L uWVPAfS3DnkFIMGmwA/K47sl0EEqnBhD+R+UTTXvESeBWGQwBd0nG0Am1q9zHI4lD9f4 bi+w==
X-Gm-Message-State: AJaThX6EuA5ZgE3flhmFRrqbyBvGhKz+Case9FJXXIPzGLhjR4JvRizG fm7sQoxwUeLEuxqAup4Q0m3akvy0
X-Google-Smtp-Source: AGs4zMZfujtHXr8p5XfnHtHQdWnj2K9QuzoXsyzj1/61YH0/jWkjAdkyqWWFini/Nbylnwqi2OQ1Cw==
X-Received: by 10.84.129.36 with SMTP id 33mr20295900plb.303.1511321898376; Tue, 21 Nov 2017 19:38:18 -0800 (PST)
Received: from [10.231.102.52] ([173.224.161.129]) by smtp.gmail.com with ESMTPSA id z2sm21473856pfh.39.2017.11.21.19.38.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Nov 2017 19:38:17 -0800 (PST)
To: tls@ietf.org
From: "Le Van Gong, Hubert" 
Message-ID: <94ced158-63b1-e7a3-024c-44d1149e7202@levangong.org>
Date: Tue, 21 Nov 2017 19:38:16 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: [TLS] Transcript-Hash during Handshake
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 03:38:20 -0000

Greetings,

Probably a trivial question but is the transcript hash (during 
handhsake) calculated over decrypted versions of messages like 
EncryptedExtensions or certificate or is it done over the raw/encrypted 
messages?
I could not find an exact confirmation in the spec.


Cheers,
Hubert


From nobody Tue Nov 21 19:54:13 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B52F1250B8 for ; Tue, 21 Nov 2017 19:54:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lekensteyn.nl
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 23PfZF9gUaoa for ; Tue, 21 Nov 2017 19:54:09 -0800 (PST)
Received: from mail.lekensteyn.nl (mail.lekensteyn.nl [IPv6:2a02:2308::360:1:25]) (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 3C23F129C20 for ; Tue, 21 Nov 2017 19:54:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lekensteyn.nl; s=s2048-2015-q1;  h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=bwsz74HxjJpSf3Pao2QOdZli7w8Gxsck0eb1Es8lZDg=;  b=ngMrcaRQNEOWu6YvDhqxcMf96/fGGfD5gNzb8Gl0DI0KvJ+I3eBr2sDvxXWwwYY3XetXm8f3BT6d9gG+0ntkMaWuILnT0ht+VVrWDw7RqpQgyuUIO0iyioj7GKRviabJEdu1+MVIsdr7GhPMoQ1K8+PW7H15mqXOHg55DzXrpVMCikiMw4NsVGzlUvXLi7683kyuWnvqeoUAYWrvWECZZ1R7JvswsD369ETqSgiJiQr5WYaFEFA+kJhS3WN9oYvfFQdz7msNKT64arugxWzHV86kTsLYo3QHWqv3JlYqhyHyqM13GRr2GhJodn2QYN+8Cxcee/jnnrpUVgkhB7tUhQ==;
Received: by lekensteyn.nl with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eHM6w-0004yj-B8 for tls@ietf.org; Wed, 22 Nov 2017 04:54:07 +0100
Date: Wed, 22 Nov 2017 03:54:04 +0000
From: Peter Wu 
To: tls@ietf.org
Message-ID: <20171122035404.GC18321@al>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.9.1 (2017-09-22)
Archived-At: 
Subject: [TLS] PR to clarify RSASSA-PSS requirements
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 03:54:12 -0000

Hi,

At the moment there is still ambiguity in the requirements for PSS with
relation to certificates. Proposal to clarify this:
https://github.com/tlswg/tls13-spec/pull/1098


This PR intends to clarify the requirements for PSS support.

The requirements are intentionally minimal to reduce implementation
efforts, but recognizes that some other implementations may be more
complete. Notes:

- "Supporting PSS signatures on certificates is a mandatory requirement
  and I think we should be very clear about the parameters we permit."
  https://www.ietf.org/mail-archive/web/tls/current/msg23007.html
- Martin Rex wishes to remove TLS requirements on signature algorithms
  for certificates, hence the "MAY" for other PSS parameters in this PR.
  https://www.ietf.org/mail-archive/web/tls/current/msg23021.html
- Regardless, rsa_pss_sha256 is currently MTI for CertificateVerify and
  certificates, hence the strong MUST wording in this PR.
- It does not say anything about non-end-entity certificates, that's up
  to the PKI verifier. Consider case "CA Key: rsa-pss; EE signature:
  rsa-pss; EE key: rsa" from
  https://www.ietf.org/mail-archive/web/tls/current/msg24453.html
- PSS params in certificates are explicitly not restricted, satisfying
  https://www.ietf.org/mail-archive/web/tls/current/msg24457.html

>From what I have heard, boringssl does not (or will not?) implement any
PSS support in the certificates (yet?). Don't know if anything should be
changed here to reflect that decision, but I thought it is worth
mentioning. It is possible that I'll follow boringssl's example in tris.

If a TLS extension is introduced later, hopefully that improves interop
with odd keys and signatures that are optional in this PR (PSS pubkey or
custom salt lengths).
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl


From nobody Tue Nov 21 19:59:22 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80376126557 for ; Tue, 21 Nov 2017 19:59:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lekensteyn.nl
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 SvbGctmZZhOf for ; Tue, 21 Nov 2017 19:59:19 -0800 (PST)
Received: from mail.lekensteyn.nl (mail.lekensteyn.nl [IPv6:2a02:2308::360:1:25]) (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 089481205F0 for ; Tue, 21 Nov 2017 19:59:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lekensteyn.nl; s=s2048-2015-q1;  h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=6KpwESxYTNG9P98euo4CDHHdI28S91Vkn7UmIOYKPys=;  b=GQVB63Ru2JBax8KI2dmRI5L+vK4I24MQgD5xulZVN3LhKpJtAIWa6opdzVgKK5lPeK/7UstcudeGkua3rxZfQzTi1AgwJJumyNrWAfreRaf4rD2hxkjt2qhEqPgaYj/b759AKvjmywsMsq3TwglxXiMOjifq/xdQL5smO+LDjJzZsceh1ZXe7Wl2OEtL2iaRk4rYwEcsGC156gIg8G4U8LQ60lLN/MNP0Q5lMGiTRJFwNrD1cb21nzOvBWBIahfFcGa70prNUuJGprDGzQzXhab7PXYIeeCjR/JvemT18DiQSB75mo9mRfhXmJ4HaZAF4LGPrP8WM3XthSVPWEw2LQ==;
Received: by lekensteyn.nl with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eHMBx-0004ze-BJ; Wed, 22 Nov 2017 04:59:17 +0100
Date: Wed, 22 Nov 2017 03:59:15 +0000
From: Peter Wu 
To: "Le Van Gong, Hubert" 
Cc: tls@ietf.org
Message-ID: <20171122035915.GD18321@al>
References: <94ced158-63b1-e7a3-024c-44d1149e7202@levangong.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <94ced158-63b1-e7a3-024c-44d1149e7202@levangong.org>
User-Agent: Mutt/1.9.1 (2017-09-22)
Archived-At: 
Subject: Re: [TLS] Transcript-Hash during Handshake
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 03:59:20 -0000

Hi Hubert,

On Tue, Nov 21, 2017 at 07:38:16PM -0800, Le Van Gong, Hubert wrote:
> Greetings,
> 
> Probably a trivial question but is the transcript hash (during handhsake)
> calculated over decrypted versions of messages like EncryptedExtensions or
> certificate or is it done over the raw/encrypted messages?
> I could not find an exact confirmation in the spec.

It covers the decrypted handshake messages, see
https://tools.ietf.org/html/draft-ietf-tls-tls13-21#section-4.4.1

    This value is computed by hashing the concatenation
    of each included handshake message, including the handshake message
    header carrying the handshake message type and length fields, but not
    including record layer headers

(The only way to know the message type is to have it in cleartext.)
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl


From nobody Tue Nov 21 20:36:49 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCA1129C36 for ; Tue, 21 Nov 2017 20:36:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level: 
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=levangong-org.20150623.gappssmtp.com
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 dHFtYmiKnsrb for ; Tue, 21 Nov 2017 20:36:47 -0800 (PST)
Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (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 34ECA129C2F for ; Tue, 21 Nov 2017 20:36:47 -0800 (PST)
Received: by mail-pg0-x233.google.com with SMTP id 4so11975934pge.1 for ; Tue, 21 Nov 2017 20:36:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=levangong-org.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=2GpdRFsdc1x+fi32KmDQj/SswwM9q85tyfc/mRL7n+E=; b=dJKF3YtErS+MfvmswAUoCZeYddqiFZHFwigqUMX/pd/5fc+JxwGcM/9vHBXwST9R+h M7pmb2VjbmZApA1y2KY+yguZvDMSqjWBaJ/yPkbstCV6RvuvY2IE3TsiZXybrOJyJB1r UIn4FLvWQRDZyOgnlr+hL+MBcWJD6BQ3rpTf7cJGTb4lgTga+Z7TAuw+AMFlh2W5OUC4 fNbDlXS0UPhxTkfjd/j4/NVobd7NK5EA1AOWSjeKqXxy+ICSEOBUaPZ+UxP5YRhlDA5L ee/W1H+1yICHUaU3yUrijCgD+jkJMe2zlZVrykJQzQcH+7DAh2tDFA0qfjTqMKU5nvq/ jwGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=2GpdRFsdc1x+fi32KmDQj/SswwM9q85tyfc/mRL7n+E=; b=g1ZxAaSt7nxLkvUr9lKKW9UhcEEfr+iX2TeEchuuVCkXKCYTkPhchCOpIVgScUODtq 0f6gr+B+E5fyXgKMHdPdBjeVxZufNashrHKXBfqEFJpMG2994LTj7jnWF18Rlxgl3swY iaGiywYeKn4n2owpja8GuB7ygUy/0atoZFQcVuV0cgusB43smGdNcL95U9mq2vkd7IZG hVrUVuTKVz00yoLwcOWXtBTQpg84zKwB/JodvdQHV2WShwMz9E/x6iZ6Kz3KizvcwULb gDom9quBljhdsIV9wWXQRNdGra9JOVA/99oRJn+sO3WcOH6u0jASCG4TfIn1W6A+rZ72 QR8Q==
X-Gm-Message-State: AJaThX7Kf/mWCjKKu+oThzznYqCrSW1eXPt+u83olRrFm9PyZuV1XAfi oT1/4lufgavodEMmR51MAE4Sqqhi
X-Google-Smtp-Source: AGs4zMZik9Ka9LnYTzPcHaxygvLlhCiZEiLpjmAcJUWNSxjXIS8rNTvezeGxXvA57S6wYw6iikgukA==
X-Received: by 10.98.21.17 with SMTP id 17mr17881501pfv.120.1511325406723; Tue, 21 Nov 2017 20:36:46 -0800 (PST)
Received: from [10.231.102.52] ([173.224.161.129]) by smtp.gmail.com with ESMTPSA id m8sm23952331pgc.64.2017.11.21.20.36.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Nov 2017 20:36:46 -0800 (PST)
To: Peter Wu 
Cc: tls@ietf.org
References: <94ced158-63b1-e7a3-024c-44d1149e7202@levangong.org> <20171122035915.GD18321@al>
From: "Le Van Gong, Hubert" 
Message-ID: 
Date: Tue, 21 Nov 2017 20:36:45 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171122035915.GD18321@al>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [TLS] Transcript-Hash during Handshake
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 04:36:48 -0000

Hi Peter,

Yes, that sentence is what made me think it must be over decrypted messages but I wanted to double check as it's not clearly stated.
Thanks for confirming!

Hubert

On 11/21/17 19:59, Peter Wu wrote:

> Hi Hubert,
>
> On Tue, Nov 21, 2017 at 07:38:16PM -0800, Le Van Gong, Hubert wrote:
>> Greetings,
>>
>> Probably a trivial question but is the transcript hash (during handhsake)
>> calculated over decrypted versions of messages like EncryptedExtensions or
>> certificate or is it done over the raw/encrypted messages?
>> I could not find an exact confirmation in the spec.
> It covers the decrypted handshake messages, see
> https://tools.ietf.org/html/draft-ietf-tls-tls13-21#section-4.4.1
>
>      This value is computed by hashing the concatenation
>      of each included handshake message, including the handshake message
>      header carrying the handshake message type and length fields, but not
>      including record layer headers
>
> (The only way to know the message type is to have it in cleartext.)
>


From nobody Tue Nov 21 20:38:31 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B23E129C30 for ; Tue, 21 Nov 2017 20:38:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 1PzIuxcXaIJQ for ; Tue, 21 Nov 2017 20:38:27 -0800 (PST)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 546D5129C2F for ; Tue, 21 Nov 2017 20:38:27 -0800 (PST)
Received: by mail-yw0-x22f.google.com with SMTP id c195so3816766ywh.10 for ; Tue, 21 Nov 2017 20:38:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MpdiR4z8iHRUEdf9gAWwLL634eUh9El518iO13VidII=; b=YjiCaSpgHyErCkiftLjMPToaLkYwaqki1NHkmBAMrW+Mo/oxVzigi/m9hP060QWjmt j9eLQa6KFvz+Y/K94EgyeAb6msMVfIL4NiYSani21UlZo3hSUlSqs6O0+BC+eM9Bi8kT HL5meYvW0BhWmCiMfyN40tmZ4NkUIp1rpMQyG/QX90OFTJXy5N+rniQh1WN2BwkpYCjG grAsjwzi1roN1bT8JSlF4YmxR9pitXU57H9gmJK5XWFO7AM6bhJOoCM7z3yC5KHFNFCg 7GgvppYoxhmbgR89wd4ov6NHzzVWRW6+y6Phfen7MRRWLvlKUG9UD+pek2wXQ/9WMwSH 9YxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MpdiR4z8iHRUEdf9gAWwLL634eUh9El518iO13VidII=; b=kLjGC6yhfeQfoAaskMI/rKqKxfgUMgidVHCUCjEDhtSsyGxfE0aEH8/BaGFPgoiJGT ghZxBTZo0AXaUp/SkGPa0eKT+hlZETG6+CAtg2ueOPoude+A01tvStKgzaN5fT3kRM6j p+s3UE2vSkwhrNwhzCV0DfjiOOekY5bhs8hrQ0O+Hi/x7n4jc4ODZB+BGd9NJcn4cljn GoPqjjGPb+WOr2u0tA3nHwNmi/DctlSyiOqi5HD9iFP1due1KOJO0+Ki8skzq4UzeaOI MXIBzpdtCSRsT5mwVRvZHcZXywy/BRx+TpRCp+gTGHLH88ORjyKG6uLcv/xXF/83ITEC 1TgQ==
X-Gm-Message-State: AJaThX7ymB5Q7JgCCF4tuPOFNh8N/a5cyGVd1FjKmNDVw3sSzMT4OytU be/C/98ecnKStAklCTGimXXcM7o6o52qdIBThRbqimhPNfc=
X-Google-Smtp-Source: AGs4zMa9bGIq+d0zgnXZsN5iIuaQlZXRa76ZbACV9SaBnEYCumNaQpDxTGNfAgo6eXnJGyyD83kd/orFaZcVUM4NTjk=
X-Received: by 10.129.154.22 with SMTP id r22mr12486182ywg.296.1511325506358;  Tue, 21 Nov 2017 20:38:26 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.123.132 with HTTP; Tue, 21 Nov 2017 20:37:45 -0800 (PST)
In-Reply-To: <20171122035404.GC18321@al>
References: <20171122035404.GC18321@al>
From: Eric Rescorla 
Date: Tue, 21 Nov 2017 20:37:45 -0800
Message-ID: 
To: Peter Wu 
Cc: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c0bb4e8f26512055e8ae32f"
Archived-At: 
Subject: Re: [TLS] PR to clarify RSASSA-PSS requirements
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 04:38:29 -0000

--94eb2c0bb4e8f26512055e8ae32f
Content-Type: text/plain; charset="UTF-8"

I don't think that this is the right answer.

Let's separate out the question of (a) what people need to support and (b)
what the code points mean. (b) needs to be unambigous, as that's the point
of the extension and this PR actually makes it explicitly unambigous.

With that said, there seem to be two points of contention:

- Whether the code point refers to signatures other than those in
CertificateVerify
- Whether the code point refers to SPKIs with OIDs other than rsaEncryption

For the first point, I recognize that there are those who believe that the
code point should refer only to CertificateVerify but that's not what it
meant in TLS 1.2 and I don't think there's consensus to make that change.
We could certainly introduce a new extension later which refers to just
chain certificates.

For the second point, I wouldn't be averse to having two code points, one
for PSS that means "must be rsaEncryption" and one for "PSS with funny
parameters" (with the hope we only ever needed the first). But that's not
this PR.

-Ekr


On Tue, Nov 21, 2017 at 7:54 PM, Peter Wu  wrote:

> Hi,
>
> At the moment there is still ambiguity in the requirements for PSS with
> relation to certificates. Proposal to clarify this:
> https://github.com/tlswg/tls13-spec/pull/1098
>
>
> This PR intends to clarify the requirements for PSS support.
>
> The requirements are intentionally minimal to reduce implementation
> efforts, but recognizes that some other implementations may be more
> complete. Notes:
>
> - "Supporting PSS signatures on certificates is a mandatory requirement
>   and I think we should be very clear about the parameters we permit."
>   https://www.ietf.org/mail-archive/web/tls/current/msg23007.html
> - Martin Rex wishes to remove TLS requirements on signature algorithms
>   for certificates, hence the "MAY" for other PSS parameters in this PR.
>   https://www.ietf.org/mail-archive/web/tls/current/msg23021.html
> - Regardless, rsa_pss_sha256 is currently MTI for CertificateVerify and
>   certificates, hence the strong MUST wording in this PR.
> - It does not say anything about non-end-entity certificates, that's up
>   to the PKI verifier. Consider case "CA Key: rsa-pss; EE signature:
>   rsa-pss; EE key: rsa" from
>   https://www.ietf.org/mail-archive/web/tls/current/msg24453.html
> - PSS params in certificates are explicitly not restricted, satisfying
>   https://www.ietf.org/mail-archive/web/tls/current/msg24457.html
>
> >From what I have heard, boringssl does not (or will not?) implement any
> PSS support in the certificates (yet?). Don't know if anything should be
> changed here to reflect that decision, but I thought it is worth
> mentioning. It is possible that I'll follow boringssl's example in tris.
>
> If a TLS extension is introduced later, hopefully that improves interop
> with odd keys and signatures that are optional in this PR (PSS pubkey or
> custom salt lengths).
> --
> Kind regards,
> Peter Wu
> https://lekensteyn.nl
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--94eb2c0bb4e8f26512055e8ae32f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I don't think that this is the right answer.

Let's separate out the question of (a) what people=
 need to support and (b) what the code points mean. (b) needs to be unambig=
ous, as that's the point of the extension and this PR actually makes it=
 explicitly unambigous.

With that said, there seem=
 to be two points of contention:

- Whether the cod=
e point refers to signatures other than those in CertificateVerify
- Whether the code point refers to SPKIs with OIDs other than rsaEncr=
yption

For the first point, I recognize that there=
 are those who believe that the code point should refer only to Certificate=
Verify but that's not what it meant in TLS 1.2 and I don't think th=
ere's consensus to make that change. We could certainly introduce a new=
 extension later which refers to just chain certificates.

For the second point, I wouldn't be averse to having two code p=
oints, one for PSS that means "must be rsaEncryption" and one for=
 "PSS with funny parameters" (with the hope we only ever needed t=
he first). But that's not this PR.

-Ekr
<=
div>

On Tue, N=
ov 21, 2017 at 7:54 PM, Peter Wu <peter@lekensteyn.nl> wro=
te:
Hi,



At the moment there is still ambiguity in the requirements for PSS with

relation to certificates. Proposal to clarify this:

https://github.com/tlswg/tls13-spec/pull/1098<=
br>




This PR intends to clarify the requirements for PSS support.



The requirements are intentionally minimal to reduce implementation

efforts, but recognizes that some other implementations may be more

complete. Notes:



- "Supporting PSS signatures on certificates is a mandatory requiremen=
t

=C2=A0 and I think we should be very clear about the parameters we permit.&=
quot;

=C2=A0 https://www.ietf.org/mail-archive/web/tls/current/msg23007.html

- Martin Rex wishes to remove TLS requirements on signature algorithms

=C2=A0 for certificates, hence the "MAY" for other PSS parameters=
 in this PR.

=C2=A0 https://www.ietf.org/mail-archive/web/tls/current/msg23021.html

- Regardless, rsa_pss_sha256 is currently MTI for CertificateVerify and

=C2=A0 certificates, hence the strong MUST wording in this PR.

- It does not say anything about non-end-entity certificates, that's up=


=C2=A0 to the PKI verifier. Consider case "CA Key: rsa-pss; EE signatu=
re:

=C2=A0 rsa-pss; EE key: rsa" from

=C2=A0 https://www.ietf.org/mail-archive/web/tls/current/msg24453.html

- PSS params in certificates are explicitly not restricted, satisfying

=C2=A0 https://www.ietf.org/mail-archive/web/tls/current/msg24457.html



>From what I have heard, boringssl does not (or will not?) implement any=


PSS support in the certificates (yet?). Don't know if anything should b=
e

changed here to reflect that decision, but I thought it is worth

mentioning. It is possible that I'll follow boringssl's example in =
tris.



If a TLS extension is introduced later, hopefully that improves interop

with odd keys and signatures that are optional in this PR (PSS pubkey or
custom salt lengths).

--

Kind regards,

Peter Wu

http=
s://lekensteyn.nl



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--94eb2c0bb4e8f26512055e8ae32f--


From nobody Wed Nov 22 00:42:13 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3598B128B44 for ; Wed, 22 Nov 2017 00:42:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 YMjo6Dn9tES0 for ; Wed, 22 Nov 2017 00:42:08 -0800 (PST)
Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41]) (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 14E9D1289C3 for ; Wed, 22 Nov 2017 00:42:07 -0800 (PST)
Received: by mail-wm0-f41.google.com with SMTP id r68so8485637wmr.1 for ; Wed, 22 Nov 2017 00:42:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=En/eCdQPCiv9N6is/nox2CmxdSnup6dzArXregQUbxQ=; b=l80iTiykOkK9ovXuIwdTmJn64ZPbh8n6vT9BdYzI1W5wwzB0BF/+7nvI+a0oGr87py C1tEJj1PUstsR8yQSi2SFPdkTqz+qgqWCI5htWpsHbHMQMxArZmM3ChHhdekb6E4m4yS /zuEqPCQ1htWakJvYwHTyeMi/Wo8JDXy9gSnemwPbeC1FmI5lIGhaEWzkXdjmTkw4Qk8 JYbPlkQ797DzQvz2gQnOAVAiXeQC5lJUzg1v9YoyakV6H99sMyCJJl+K56Tg/73pAeyt HvipYG29gDShRXwKMv6wJXPRDmYzowLL6IPXB7EBozs0YW6Urf/UmGcqAE+m7tX0Qt79 /qbA==
X-Gm-Message-State: AJaThX64KGNF4Oxs5yyjDWQ/9KjsjLtxRa0ecOyfMV0H+KZITnSvXAcs LvuTlBK12jYwS4xdqT0/QC9Mbg==
X-Google-Smtp-Source: AGs4zMYlZ0JJNWOi7MYq/iQMcHkCkBveaSqx5gJnYXDQBpp5Xv/Q0xfVwX+xKAx93DUDguV+WUwkjQ==
X-Received: by 10.80.201.77 with SMTP id p13mr1174658edh.33.1511340126045; Wed, 22 Nov 2017 00:42:06 -0800 (PST)
Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id z10sm200182edm.68.2017.11.22.00.42.05 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 22 Nov 2017 00:42:05 -0800 (PST)
Message-ID: <1511340124.22935.27.camel@redhat.com>
From: Nikos Mavrogiannopoulos 
To: Peter Wu , tls@ietf.org
Date: Wed, 22 Nov 2017 09:42:04 +0100
In-Reply-To: <20171122035404.GC18321@al>
References: <20171122035404.GC18321@al>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.24.6 (3.24.6-1.fc26) 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [TLS] PR to clarify RSASSA-PSS requirements
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 08:42:10 -0000

On Wed, 2017-11-22 at 03:54 +0000, Peter Wu wrote:
> Hi,
> 
> At the moment there is still ambiguity in the requirements for PSS
> with
> relation to certificates. Proposal to clarify this:
> https://github.com/tlswg/tls13-spec/pull/1098
> 
> 
> This PR intends to clarify the requirements for PSS support.

Hi,
 I commented on the PR, but to provide more context. I believe RSA-PSS
keys without parameters MUST be supported under TLS1.3. The reason is
that keys explicitly marked as RSA-PSS cannot be used for RSA PKCS#1
1.5 encryption, and thus they provide a way for the server to know that
it must protect that key against (cross-protocol) attacks which utilize
RSA ciphersuites under TLS1.2.

On why you don't want mixing keys for TLS1.3 and TLS1.2 RSA
ciphersuites, see all the bleichenbacher attack reiterations over the
years.

So what about distinguishing the RSA-PSS keys with and without
parameters:

"an RSASSA-PSS public key (OID id-RSASSA-PSS) without parameters MUST
be supported, while an RSASSA-PSS public key (OID id-RSASSA-PSS) with
parameters MAY be supported`."

regards,
Nikos


From nobody Wed Nov 22 04:10:52 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0A312940C for ; Wed, 22 Nov 2017 04:10:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lekensteyn.nl
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 lpG5hk3W6IHB for ; Wed, 22 Nov 2017 04:10:49 -0800 (PST)
Received: from mail.lekensteyn.nl (mail.lekensteyn.nl [IPv6:2a02:2308::360:1:25]) (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 1F1FA12940B for ; Wed, 22 Nov 2017 04:10:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lekensteyn.nl; s=s2048-2015-q1;  h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=AJ2n44xknqGG6jc6YR/BulWPktk8HtRY53alPKD1I/E=;  b=NLGmOkiCfO+G+20zHJEIxs7MJniK+iKgpSgs8GlO70DFE6q+PPhb239UolBEKnvnGvkyH1T/RRBAR1Uzwpv3X4JjEusZBE0uyLooi5IHABlZ1WoyL+Ro9NXoBw5p47BcUU5u8gou64EpEpFYVGRwUiNgHXTjom03F3lBYBYcrDq9YsIcPlUe9BwSVQQtqgmKKIboMqjPfSMSzbQ5AvJCFDoQYf7xbVAHG4F2IFDh+GWificscDWDBDcirIdA1oDoBz8BnXpmtnGa8ejbG5d6SjYmvPAcS05MWTsCf82ChLZzgO/2ypHyEsVHvnTk3u2K7BfcthLQKE/BHjiQgjIUQA==;
Received: by lekensteyn.nl with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eHTra-0006u9-QD; Wed, 22 Nov 2017 13:10:47 +0100
Date: Wed, 22 Nov 2017 12:10:44 +0000
From: Peter Wu 
To: Eric Rescorla 
Cc: "tls@ietf.org" 
Message-ID: <20171122121044.GE18321@al>
References: <20171122035404.GC18321@al> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.9.1 (2017-09-22)
Archived-At: 
Subject: Re: [TLS] PR to clarify RSASSA-PSS requirements
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 12:10:51 -0000

On Tue, Nov 21, 2017 at 08:37:45PM -0800, Eric Rescorla wrote:
> I don't think that this is the right answer.
> 
> Let's separate out the question of (a) what people need to support and (b)
> what the code points mean. (b) needs to be unambigous, as that's the point
> of the extension and this PR actually makes it explicitly unambigous.
> 
> With that said, there seem to be two points of contention:
> 
> - Whether the code point refers to signatures other than those in
> CertificateVerify
> - Whether the code point refers to SPKIs with OIDs other than rsaEncryption
> 
> For the first point, I recognize that there are those who believe that the
> code point should refer only to CertificateVerify but that's not what it
> meant in TLS 1.2 and I don't think there's consensus to make that change.

Yes, it is my understanding (now) that the code point covers both CV
(and SKE in TLS 1.2) and certificate signatures based on RFC 5246.

> We could certainly introduce a new extension later which refers to just
> chain certificates.
>
> For the second point, I wouldn't be averse to having two code points, one
> for PSS that means "must be rsaEncryption" and one for "PSS with funny
> parameters" (with the hope we only ever needed the first). But that's not
> this PR.

Limiting it to rsaEncryption sounds good to me, it removes some
complication. Since it is not clear to me which parameters MUST be
supported now, rather than defining three codepoints for PSS keys now,
what about deferring it to a future spec (possibly in combination with
the new extension for negotiating supported certificates)?

Alternatively something arbitrary can be done such as requiring the
parameters as used for TLS handshakes to be supported (as the PR
proposes) and allowing alternative configurations to be supported too.

Kind regards,
Peter

> -Ekr
> 
> 
> On Tue, Nov 21, 2017 at 7:54 PM, Peter Wu  wrote:
> 
> > Hi,
> >
> > At the moment there is still ambiguity in the requirements for PSS with
> > relation to certificates. Proposal to clarify this:
> > https://github.com/tlswg/tls13-spec/pull/1098
> >
> >
> > This PR intends to clarify the requirements for PSS support.
> >
> > The requirements are intentionally minimal to reduce implementation
> > efforts, but recognizes that some other implementations may be more
> > complete. Notes:
> >
> > - "Supporting PSS signatures on certificates is a mandatory requirement
> >   and I think we should be very clear about the parameters we permit."
> >   https://www.ietf.org/mail-archive/web/tls/current/msg23007.html
> > - Martin Rex wishes to remove TLS requirements on signature algorithms
> >   for certificates, hence the "MAY" for other PSS parameters in this PR.
> >   https://www.ietf.org/mail-archive/web/tls/current/msg23021.html
> > - Regardless, rsa_pss_sha256 is currently MTI for CertificateVerify and
> >   certificates, hence the strong MUST wording in this PR.
> > - It does not say anything about non-end-entity certificates, that's up
> >   to the PKI verifier. Consider case "CA Key: rsa-pss; EE signature:
> >   rsa-pss; EE key: rsa" from
> >   https://www.ietf.org/mail-archive/web/tls/current/msg24453.html
> > - PSS params in certificates are explicitly not restricted, satisfying
> >   https://www.ietf.org/mail-archive/web/tls/current/msg24457.html
> >
> > >From what I have heard, boringssl does not (or will not?) implement any
> > PSS support in the certificates (yet?). Don't know if anything should be
> > changed here to reflect that decision, but I thought it is worth
> > mentioning. It is possible that I'll follow boringssl's example in tris.
> >
> > If a TLS extension is introduced later, hopefully that improves interop
> > with odd keys and signatures that are optional in this PR (PSS pubkey or
> > custom salt lengths).
> > --
> > Kind regards,
> > Peter Wu
> > https://lekensteyn.nl


From nobody Wed Nov 22 04:16:06 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3355812941D for ; Wed, 22 Nov 2017 04:16:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lekensteyn.nl
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 ZS_myb-uOPAl for ; Wed, 22 Nov 2017 04:16:03 -0800 (PST)
Received: from mail.lekensteyn.nl (mail.lekensteyn.nl [IPv6:2a02:2308::360:1:25]) (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 6B700120046 for ; Wed, 22 Nov 2017 04:16:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lekensteyn.nl; s=s2048-2015-q1;  h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=XKY1GuK7bzLa7VNU0nt5kIrLiBIeIMXsJbzgi2Hul08=;  b=oofgO77QlT39w2w143gShei1acKBFvm9MCA89DvYTdIpnFeab1/OBkDP+m8gbvHyFbBRLwW7JQrlc0UWjD78g1oOrJA2ibv6U+j5Wny+1jGbF3wJ9GnoZtnG4wivGaH3sMO6nZnRdcrCUmG+jDnDQ5QD/8zgeDegE4njvia0JJW3cwnkQ8m3sy3LoJegHfues2UbXKCkqW5aDFxhvT6CjrZUAfynpsYINeMCyeDt/BC0pw/ow52n2/Y2pFDiGO6Y7lMkZRVJAH8feG302ESOBsxcBY54V5xccMm+A7yGdXDFHRkqwocV3HdhspEcsuxy03KZSuwCHBpmQdU2P0sYxg==;
Received: by lekensteyn.nl with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eHTwe-0006vb-CV; Wed, 22 Nov 2017 13:16:01 +0100
Date: Wed, 22 Nov 2017 12:15:58 +0000
From: Peter Wu 
To: Nikos Mavrogiannopoulos 
Cc: tls@ietf.org
Message-ID: <20171122121558.GF18321@al>
References: <20171122035404.GC18321@al> <1511340124.22935.27.camel@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1511340124.22935.27.camel@redhat.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
Archived-At: 
Subject: Re: [TLS] PR to clarify RSASSA-PSS requirements
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 12:16:05 -0000

Hi Nikos,

On Wed, Nov 22, 2017 at 09:42:04AM +0100, Nikos Mavrogiannopoulos wrote:
> On Wed, 2017-11-22 at 03:54 +0000, Peter Wu wrote:
> > Hi,
> > 
> > At the moment there is still ambiguity in the requirements for PSS
> > with
> > relation to certificates. Proposal to clarify this:
> > https://github.com/tlswg/tls13-spec/pull/1098
> > 
> > 
> > This PR intends to clarify the requirements for PSS support.
> 
> Hi,
>  I commented on the PR, but to provide more context. I believe RSA-PSS
> keys without parameters MUST be supported under TLS1.3. The reason is
> that keys explicitly marked as RSA-PSS cannot be used for RSA PKCS#1
> 1.5 encryption, and thus they provide a way for the server to know that
> it must protect that key against (cross-protocol) attacks which utilize
> RSA ciphersuites under TLS1.2.
> 
> On why you don't want mixing keys for TLS1.3 and TLS1.2 RSA
> ciphersuites, see all the bleichenbacher attack reiterations over the
> years.
> 
> So what about distinguishing the RSA-PSS keys with and without
> parameters:
> 
> "an RSASSA-PSS public key (OID id-RSASSA-PSS) without parameters MUST
> be supported, while an RSASSA-PSS public key (OID id-RSASSA-PSS) with
> parameters MAY be supported`."

In my understanding, the parameters are REQUIRED (cannot be NULL), but
an "empty" DER encoding means that the default parameters are used
(SHA-1, MFG1 with SHA-1, salt length equal to SHA-1 output (20), default
trailer) per https://tools.ietf.org/html/rfc8017#page-75

Is this restriction what you intended?
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl


From nobody Wed Nov 22 05:02:37 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223D5129439 for ; Wed, 22 Nov 2017 05:02:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 Yw3YUNC7nI6c for ; Wed, 22 Nov 2017 05:02:29 -0800 (PST)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 BB4B8129436 for ; Wed, 22 Nov 2017 05:02:28 -0800 (PST)
Received: by mail-qk0-x22b.google.com with SMTP id j202so16615307qke.10 for ; Wed, 22 Nov 2017 05:02:28 -0800 (PST)
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 :cc; bh=vDDWolFDEfZg4pDmfr5IYtjnGaRKzT09DndaLDG2afc=; b=gwLqByH+aCZCnObXNukDFi4ZurG2uUNvTzD2kXJn/n/P/7ok+CW/08NbS1NZZ/R49C o2hUv2WcEgaByqoz6fHHduDDzBBz5647YZ9gs5HHKpPY5LHQsVU9eRMhRE5EcBcE8WXH UNKMf61ReNgZsMVve1Hl9xDYMa0u7DHjHinIg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vDDWolFDEfZg4pDmfr5IYtjnGaRKzT09DndaLDG2afc=; b=oxdkpK0x1LG53eOZjFUxmiBwd6clPDkXzoSpYaY1CCym1clwadHcdIYol2l5Uw9SUW fSGPeYpfyshoR/sS7agkq6PprtJjtAEjpg6UG9M8Faw/fzWeXwfyTZ4m3stNNc8o0wgm AMJ1Wx2D7URsP6KXN974kyRTI0L8wslwT3dxiXBLBGp4wXiMjNVwvLBr8RCCRiuPYt6H wISzyroKm38rc82o+TqDBaPJlRPfkKx+LC6kbjE0BllmgQtQKlmjkUa/6vtBAkYgXC9s ryxEB+5uwh4YIUmUYNZL2jbxGgLGVFMBsHPiOAmjdNOI5SFgubk1aXRAIfsgMjQHmTSO cJMA==
X-Gm-Message-State: AJaThX7CIIqnbnIqvh1xJq9jmUE3JCSeVC1oKl7aqKEjsU8BWDczWxCF oc5VU7MkQ+2RF3CQVgmo99lu9gHIC6xg7t4SYZL5
X-Google-Smtp-Source: AGs4zMYXEzLthdYyAeN8IyvdfmZ+/KstCBNIq+iZmbgcOcuXZzrc/xoMr7mn3ZxVf/eScAhfawCGo7iL8UUJCuO+dWk=
X-Received: by 10.55.21.213 with SMTP id 82mr33762066qkv.110.1511355747353; Wed, 22 Nov 2017 05:02:27 -0800 (PST)
MIME-Version: 1.0
References:  <389abe54-41d3-30e9-4cca-caa8b1469ae7@iki.fi>
In-Reply-To: <389abe54-41d3-30e9-4cca-caa8b1469ae7@iki.fi>
From: David Benjamin 
Date: Wed, 22 Nov 2017 13:02:15 +0000
Message-ID: 
To: Tapio Sokura 
Cc: tls@ietf.org
Content-Type: multipart/alternative; boundary="001a1147b58474076e055e91eeb2"
Archived-At: 
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 13:02:36 -0000

--001a1147b58474076e055e91eeb2
Content-Type: text/plain; charset="UTF-8"

As a source of some of those numbers, someone interested in actually
deploying TLS 1.3, and, most importantly, someone who would have to deal
with the fallout of that deployment, I can unequivocally say those are not
"very good" figures. They are completely implausible by orders of
magnitude. TLS 1.3, the secure upgrade to TLS 1.2, is not even close to
being deployable today.

Unchanged, deployment would require a unsecured version fallback, the same
one that gave POODLE. An attacker could silently downgrade us to TLS 1.2.
That ServerHello.random anti-downgrade signal would have been purely
wishful thinking and never implemented. I think this would be a huge step
back. A de facto fallback would also send the same signal as tweaking the
protocol. There isn't enough incentive for middleboxes to ship updates or
for administrators to deploy those updates when doing nothing works just
fine. For 21 years, since SSL 3.0, we didn't really change TLS's handshake
and left it all unencrypted. In retrospect, it's probably to be expected
the network latched onto it. Ignoring the problem won't erase those 21
years.

These changes are certainly ugly, but they are only ugly. They have no
impact on security, unlike the fallback which does. There is a complexity
impact, but, having implemented it, the impact is actually quite small.
Making the first server message more uniform between versions and
HelloRetryRequest is even a small convenience.

This is indeed baggage, but that is not new. When I think of the
consequences of buggy middleboxes, I am actually less concerned that our
first roundtrip needs to look a little funny, and more that we are wasting
three bytes in front of *every* record (PR762). That we have entirely lost
TCP and my colleagues on QUIC needed to start over on UDP for improvements.
That even then QUIC ran into ossification later on. That every protocol
change is risky and requires endless experimentation. That the reality of
engineering on the Internet appears to be: if it was observable over time,
it has ossified.

I share the justified frustration with this picture, but it's reality.
There are two questions now:

1) What we do need to do to deploy a change today? (Our handshake
versioning joints have rusted shut, and we need to break them free.)
2) How do we avoid needing to do worse tomorrow? (We've got it moving
again, and we want to keep it that way.)

PR1091 seems to answer (1). (2) is harder. We need to think about how to
avoid ossification. Writing versioning invariants[*] clearly is an easy
step, but text alone isn't enough. Reducing unencrypted portions is also
obvious and valuable in itself, but TLS has a bootstrapping problem here.
We also need to think more in the direction of GREASE, but perhaps further
as GREASE itself only tried to prevent buggy endpoints.

This is a difficult question we won't fully explore immediately, and
solving it is not going to magic away (1) anyway. So I think our first step
is clear: get through the accumulated rust.

David

[*] TLS's versioning rules are quite restrictive. We promise you can parse
newer ClientHellos. Everything after that is fair game to change. If you
produced the ClientHello, you can reasonably assume the peer won't send you
anything that will confuse you. If you are forwarding a ClientHello you did
not produce, you MUST NOT process the response in any way. It will contain
incompatible messages in the future. Alas, reality shows that the network
did not observe these rules.

On Tue, Nov 21, 2017 at 9:41 PM Tapio Sokura  wrote:

> Hello,
>
> On 6.11.2017 20:19, Eric Rescorla wrote:
> > Once you do this, the middleboxes seem to mostly ignore everything
> > after the CCS, so the rest of the handshake proceeds smoothly.
> >
> > This is all a bit nasty, but none of it changes the cryptographic
> > computations or the state machine (because you just ignore CCS).
>
> The discussion in Singapore on middlebox issues during the WG session
> woke me up on this. I don't post much on this list, but here I have to
> say that this dance to work around middleboxes looks seriously like
> putting the cart before the horse.
>
> I'm not arguing that the cryptographic properties/security of TLS 1.3 is
> affected by these changes. I'm saying that this messing around with
> making 1.3 look like 1.2 adds unnecessary complexity that will just hurt
> everyone in the long run. In the short term you get a few % more
> successful 1.3 handshakes, but once it's in the spec, it will bother
> implementers for years to come.
>
> Sometimes you have to let some things break to be able to move forward.
> If over 90% (the figures presented in Singapore) of TLS 1.3 handshakes
> already go through without 1.2 emulation / middlebox compensation in the
> protocol, I find that a very good number for this point in time.
>
> It's the middleboxes that should adapt to be 1.3 compatible, not the
> other way around. This is not sending a good signal to the industry.
>
> Sorry if I'm beating a dead horse (behind the cart). But my
> interpretation of the comments made during the WG session indicate that
> if there's consensus on incorporating these middlebox compatibility
> changes, it's a very rough consensus.
>
>    Tapio
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--001a1147b58474076e055e91eeb2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


As a source of some of those numbers, someone interested i=
n actually deploying TLS 1.3, and, most importantly, someone who would have=
 to deal with the fallout of that deployment, I can=C2=A0unequivocally say =
those are not "very good" figures. They are completely implausibl=
e by orders of magnitude. TLS 1.3, the secure upgrade to TLS 1.2, is not ev=
en close to being deployable today.

Unchanged, deploymen=
t would require a unsecured version fallback, the same one that gave POODLE=
. An attacker could silently downgrade us to TLS 1.2. That ServerHello.rand=
om anti-downgrade signal would have been purely wishful thinking and never =
implemented. I think this would be a huge step back. A de facto fallback wo=
uld also send the same signal as tweaking the protocol. There isn't eno=
ugh incentive for middleboxes to ship updates or for administrators to depl=
oy those updates when doing nothing works just fine. For 21 years, since SS=
L 3.0, we didn't really change TLS's handshake and left it all unen=
crypted. In retrospect, it's probably to be expected the network latche=
d onto it. Ignoring the problem won't erase those 21 years.
These changes are certainly ugly, but they are only ugly. They=
 have no impact on security, unlike the fallback which does. There is a com=
plexity impact, but, having implemented it, the impact is actually quite sm=
all. Making the first server message more uniform between versions and Hell=
oRetryRequest is even a small convenience.

This is=
 indeed baggage, but that is not new. When I think of the consequences of b=
uggy middleboxes, I am actually less concerned that our first roundtrip nee=
ds to look a little funny, and more that we are wasting three bytes in fron=
t of *every* record (PR762). That we have entirely lost TCP and my colleagu=
es on QUIC needed to start over on UDP for improvements. That even then QUI=
C ran into ossification later on. That every protocol change is risky and r=
equires endless experimentation. That the reality of engineering on the Int=
ernet appears to be: if it was observable over time, it has ossified.
=


I share the justified frustration with this picture, bu=
t it's reality. There are two questions now:

1=
) What we do need to do to deploy a change today? (Our handshake versioning=
 joints have rusted shut, and we need to break them free.)
2)=
 How do we avoid needing to do worse tomorrow? (We've got it moving aga=
in, and we want to keep it that way.)

PR1091 seems=
 to answer (1). (2) is harder. We need to think about how to avoid ossifica=
tion. Writing versioning invariants[*] clearly is an easy step, but text al=
one isn't enough. Reducing unencrypted portions is also obvious and val=
uable in itself, but TLS has a bootstrapping problem here. We also need to =
think more in the direction of GREASE, but perhaps further as GREASE itself=
 only tried to prevent buggy endpoints.

This is a =
difficult question we won't fully explore immediately, and solving it i=
s not going to magic away (1) anyway. So I think our first step is clear: g=
et through the accumulated rust.

David

[*] TLS's versioning rules are quite restrictive. We =
promise you can parse newer ClientHellos. Everything after that is fair gam=
e to change. If you produced the ClientHello, you can reasonably assume the=
 peer won't send you anything that will confuse you. If you are forward=
ing a ClientHello you did not produce, you MUST NOT process the response in=
 any way. It will contain incompatible messages in the future. Alas, realit=
y shows that the network did not observe these rules.

<=
div>
On Tue,=
 Nov 21, 2017 at 9:41 PM Tapio Sokura <tapio.sokura@iki.fi> wrote:
Hello,



On 6.11.2017 20:19, Eric Rescorla wrote:

> Once you do this, the middleboxes seem to mostly ignore everything

> after the CCS, so the rest of the handshake proceeds smoothly.

>

> This is all a bit nasty, but none of it changes the cryptographic

> computations or the state machine (because you just ignore CCS).



The discussion in Singapore on middlebox issues during the WG session

woke me up on this. I don't post much on this list, but here I have to<=
br>
say that this dance to work around middleboxes looks seriously like

putting the cart before the horse.



I'm not arguing that the cryptographic properties/security of TLS 1.3 i=
s

affected by these changes. I'm saying that this messing around with

making 1.3 look like 1.2 adds unnecessary complexity that will just hurt
everyone in the long run. In the short term you get a few % more

successful 1.3 handshakes, but once it's in the spec, it will bother
implementers for years to come.



Sometimes you have to let some things break to be able to move forward.

If over 90% (the figures presented in Singapore) of TLS 1.3 handshakes

already go through without 1.2 emulation / middlebox compensation in the
protocol, I find that a very good number for this point in time.



It's the middleboxes that should adapt to be 1.3 compatible, not the
other way around. This is not sending a good signal to the industry.



Sorry if I'm beating a dead horse (behind the cart). But my

interpretation of the comments made during the WG session indicate that

if there's consensus on incorporating these middlebox compatibility

changes, it's a very rough consensus.



=C2=A0 =C2=A0Tapio



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--001a1147b58474076e055e91eeb2--


From nobody Wed Nov 22 05:33:37 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 166EF129440 for ; Wed, 22 Nov 2017 05:33:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 jQ4GQySgsqcf for ; Wed, 22 Nov 2017 05:33:32 -0800 (PST)
Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) (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 8ED181200FC for ; Wed, 22 Nov 2017 05:33:32 -0800 (PST)
Received: by mail-wm0-f45.google.com with SMTP id r68so10307511wmr.1 for ; Wed, 22 Nov 2017 05:33:32 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=js+j9kk9Up8QgA3KORyXvig20TQ6D33KD1h0kKuBDRc=; b=tD7vaojLtA2vMHqeTirhsBdLL+Ftk3QpMfgKZ+Ojh+VWHEgCeHrNHs3IRMpzxEvA5T 207deijjjtoM3spT9vAxgDzptwyH/AHzTnkS+y9YcDm5VQkSN0Z6GWra8d9uxTmRgT8T mPqjI3UmCh3BtoR8f54dDn61ekTqer+bJzNHNaxDCYiceb6SMKZuyRWupPCKdIMcg77T Vuwh8yh0YPbMZ8qK5uL70RYwfID7YtaqNSa8UJbDapVQoYBVocFNvDtTNA280FHw4bX2 MDjpoVkeOWvCeh/yx9pAGoaRq615XsGe1EnVqAr90j5uBi1iCa2Zu+Uh0eY8LPNmGGuh lK4A==
X-Gm-Message-State: AJaThX6V7oD3J4kqjnjylkVU7dk1733bjyn4LB5xA1QH8A00dYvjBWN0 BoRxF0egSbFq5SDNmksM0YLSVgE67uw=
X-Google-Smtp-Source: AGs4zMajLftDTI3lah2VfxXXqSldXj/syePskbTgLrz51dTFldEw1edG2QQhT2xFoGVBiXOVQsAatw==
X-Received: by 10.28.139.144 with SMTP id n138mr4292641wmd.78.1511357610940; Wed, 22 Nov 2017 05:33:30 -0800 (PST)
Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id m189sm2596546wmb.38.2017.11.22.05.33.30 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 22 Nov 2017 05:33:30 -0800 (PST)
Message-ID: <1511357609.22935.47.camel@redhat.com>
From: Nikos Mavrogiannopoulos 
To: Peter Wu 
Cc: tls@ietf.org
Date: Wed, 22 Nov 2017 14:33:29 +0100
In-Reply-To: <20171122121558.GF18321@al>
References: <20171122035404.GC18321@al> <1511340124.22935.27.camel@redhat.com> <20171122121558.GF18321@al>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.24.6 (3.24.6-1.fc26) 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [TLS] PR to clarify RSASSA-PSS requirements
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 13:33:35 -0000

On Wed, 2017-11-22 at 12:15 +0000, Peter Wu wrote:
> Hi Nikos,
> 
> On Wed, Nov 22, 2017 at 09:42:04AM +0100, Nikos Mavrogiannopoulos
> wrote:
> > On Wed, 2017-11-22 at 03:54 +0000, Peter Wu wrote:
> > > Hi,
> > > 
> > > At the moment there is still ambiguity in the requirements for
> > > PSS
> > > with
> > > relation to certificates. Proposal to clarify this:
> > > https://github.com/tlswg/tls13-spec/pull/1098
> > > 
> > > 
> > > This PR intends to clarify the requirements for PSS support.
> > 
> > Hi,
> >  I commented on the PR, but to provide more context. I believe RSA-
> > PSS
> > keys without parameters MUST be supported under TLS1.3. The reason
> > is
> > that keys explicitly marked as RSA-PSS cannot be used for RSA
> > PKCS#1
> > 1.5 encryption, and thus they provide a way for the server to know
> > that
> > it must protect that key against (cross-protocol) attacks which
> > utilize
> > RSA ciphersuites under TLS1.2.
> > 
> > On why you don't want mixing keys for TLS1.3 and TLS1.2 RSA
> > ciphersuites, see all the bleichenbacher attack reiterations over
> > the
> > years.
> > 
> > So what about distinguishing the RSA-PSS keys with and without
> > parameters:
> > 
> > "an RSASSA-PSS public key (OID id-RSASSA-PSS) without parameters
> > MUST
> > be supported, while an RSASSA-PSS public key (OID id-RSASSA-PSS)
> > with
> > parameters MAY be supported`."
> 
> In my understanding, the parameters are REQUIRED (cannot be NULL),
> but
> an "empty" DER encoding means that the default parameters are used
> (SHA-1, MFG1 with SHA-1, salt length equal to SHA-1 output (20),
> default
> trailer) per https://tools.ietf.org/html/rfc8017#page-75

That's not what the DEFAULT keyword means in ASN.1. My understanding is
that the default value applies when there is a sequence without that
value present, not when the sequence is not there at all.

Nevertheless, irrespective of that interpreation, for TLS1.3 an empty
DER encoding means nothing of that as these parameters are negotiated
over TLS (e.g, rsa_pss_sha256). See:
https://tools.ietf.org/html/draft-ietf-tls-tls13-21#section-4.2.3

On whether empty parameters are allowed on RSA-PSS certificates,
RFC4055 is clear on that:
"CAs MAY require that the parameters be present in the
publicKeyAlgorithms field for end-entity certificates."

https://tools.ietf.org/html/rfc4055#section-3

regards,
Nikos


From nobody Wed Nov 22 05:45:33 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43751129447 for ; Wed, 22 Nov 2017 05:45:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 ckq-ikuLBl8c for ; Wed, 22 Nov 2017 05:45:27 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84A2E1200FC for ; Wed, 22 Nov 2017 05:45:27 -0800 (PST)
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1D4B7883BE; Wed, 22 Nov 2017 13:45:27 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (unknown [10.43.21.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DC3695EE1E; Wed, 22 Nov 2017 13:45:24 +0000 (UTC)
From: Hubert Kario 
To: tls@ietf.org
Date: Wed, 22 Nov 2017 14:45:17 +0100
Message-ID: <2262437.LnmhgzYEf9@pintsize.usersys.redhat.com>
In-Reply-To: <20171122121558.GF18321@al>
References: <20171122035404.GC18321@al> <1511340124.22935.27.camel@redhat.com> <20171122121558.GF18321@al>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2415715.2mRxGMS3kh"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 22 Nov 2017 13:45:27 +0000 (UTC)
Archived-At: 
Subject: Re: [TLS] PR to clarify RSASSA-PSS requirements
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 13:45:30 -0000

--nextPart2415715.2mRxGMS3kh
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Wednesday, 22 November 2017 13:15:58 CET Peter Wu wrote:
> Hi Nikos,
>=20
> On Wed, Nov 22, 2017 at 09:42:04AM +0100, Nikos Mavrogiannopoulos wrote:
> > On Wed, 2017-11-22 at 03:54 +0000, Peter Wu wrote:
> > > Hi,
> > >=20
> > > At the moment there is still ambiguity in the requirements for PSS
> > > with
> > > relation to certificates. Proposal to clarify this:
> > > https://github.com/tlswg/tls13-spec/pull/1098
> > >=20
> > >=20
> > > This PR intends to clarify the requirements for PSS support.
> >=20
> > Hi,
> >=20
> >  I commented on the PR, but to provide more context. I believe RSA-PSS
> >=20
> > keys without parameters MUST be supported under TLS1.3. The reason is
> > that keys explicitly marked as RSA-PSS cannot be used for RSA PKCS#1
> > 1.5 encryption, and thus they provide a way for the server to know that
> > it must protect that key against (cross-protocol) attacks which utilize
> > RSA ciphersuites under TLS1.2.
> >=20
> > On why you don't want mixing keys for TLS1.3 and TLS1.2 RSA
> > ciphersuites, see all the bleichenbacher attack reiterations over the
> > years.
> >=20
> > So what about distinguishing the RSA-PSS keys with and without
> > parameters:
> >=20
> > "an RSASSA-PSS public key (OID id-RSASSA-PSS) without parameters MUST
> > be supported, while an RSASSA-PSS public key (OID id-RSASSA-PSS) with
> > parameters MAY be supported`."
>=20
> In my understanding, the parameters are REQUIRED (cannot be NULL), but
> an "empty" DER encoding means that the default parameters are used
> (SHA-1, MFG1 with SHA-1, salt length equal to SHA-1 output (20), default
> trailer) per https://tools.ietf.org/html/rfc8017#page-75

No, when the parameters are completely omitted (the=20
AlgorithmIdentifier.parameters is completely omitted in the SEQUENCE of=20
AlgorithmIdentifier), that means that the key is unrestricted and can be us=
ed=20
with arbitrary hashes and salt lengths (just like a rsaEncryption key).
If the AlgorithmIdentifier.parameters is present but empty (empty SEQUENCE =
in=20
DER), that means that all parameters are restricted and have default=20
parameters (sha1, 20 byte salt).

RFC 5756 is a bit more explicit on requirements for EE and CA certificates:
   When the id-RSASSA-PSS object identifier appears in the
   TBSCertificate subjectPublicKeyInfo algorithm field of CA
   certificates, then the parameters field SHOULD include the RSASSA-
   PSS-params structure.  When the id-RSASSA-PSS object identifier
   appears in the TBSCertificate subjectPublicKeyInfo algorithm field of
   EE certificates, then the parameters field MAY include the RSASSA-
   PSS-params structure.

The unrestricted EE keys should be supported, and I would even go as far as=
=20
specifying that in TLS1.3 RSA-PSS EE certs MUST be unrestricted.
=2D-=20
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00  Brno, Czech Republic
--nextPart2415715.2mRxGMS3kh
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAABCgAGBQJaFX9tAAoJEJKo0bgB0vX1b70P/irAaNilP0HAhH23MerAWLZT
6RUZf50hvhsoWN4sCNZh7YgqTRynFBZ3TPi1GOu4PYP7f6Un0shLexXwGorOpTtQ
X33jGH8PXTZKNcEJxDPIxKUAvyL8xtfnOv2dXomHCUOLf7kjsuLmQiU8wYlhA4OA
7kaR9oHVwF01a8amgMo67ehPhLMwkcyCz78XpfPzSnv0SrqTc8PqRokh4/kkyWhQ
tmJwU0E4bXdF6a05zpB5e/wRGbmCTLsBuI+Y8MBptgkByxoumPu+OEwuQzN60duO
E6aCRydzuvGksuUopW6UWOxK1dgAAm7FkHxD9euJV3XzchtcPtRGh6tNk3Cxvvai
Q6cMmdA80ZlaxtwO4CpIpQQHGYHEMFwQNyvSlQvCcD/73J0WAX1qnbKW4eypsa4p
74LncjLTeTGo36hCtW+lOlHGR/oFhd+Vm5MlGwUniaOjYjqADzHiaQsuVuZbPnAp
7Q7SaIvgN+Anmx51zHG0sj7Cuea4XryoIMgcSV3WCsPVrAnA2BFiivnh7PAM6PLm
S08secfkDkZMqJkpauw06+Mi153QT3wdH7ycdkx37pQqSxwHANqwYtn+N2OAvAoG
RvpEUpS82w1CcPYu2eStTXoF3qw4uqrn6qZzx6MLabBD2LuBmxvUpzDtOPeD9WY/
G5YJlzdmEr2DOryjN08s
=cZL8
-----END PGP SIGNATURE-----

--nextPart2415715.2mRxGMS3kh--


From nobody Wed Nov 22 09:13:29 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A01129466 for ; Wed, 22 Nov 2017 09:13:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
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 sD557EBfL_kg for ; Wed, 22 Nov 2017 09:13:26 -0800 (PST)
Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 7D8DE1201F8 for ; Wed, 22 Nov 2017 09:13:26 -0800 (PST)
Received: by mail-qt0-x22c.google.com with SMTP id n32so24705597qtb.2 for ; Wed, 22 Nov 2017 09:13:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CBi+79xllhlzftk7SZU+NaxBZSMa4D4CLHbroQveR0w=; b=TFoFuijKZTuOyU1L1Z7iVkegxYaqzmPYzgDjxxWJp6SZ10E1ZMJbPFokUKI5vuyM5k T7pSGZAwBEztQ7++ZgkWrPf0dGOcn+2jNcZ72wbnbnb48JxxaEAPZFfLDIi5ztZynYrD IyuwaO9inucXaVhPSzyVcw8rPlWLFkO2PtDSQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CBi+79xllhlzftk7SZU+NaxBZSMa4D4CLHbroQveR0w=; b=gGjuMppP0TmjwaFpXebjttg1zTzS5F1nP7OqPB1a/HcYu0NZBZHXYEMPNJlnPiTr8L 4bQAy8wxyGYtr5287AFLrZO7x7l6xzIoLyLdEH9mnI+L8K8XUKbW2GKSKvUfGNCt+GLs 7EHLhicY8QLCxKpt6yEmP5vmjXHrCSxfon1H7xHyiSGAV7C2ihkqxJivLOQRIAkugst9 b8FEkYViN8WcaklsqdnCEO1Bj1mppzsxjTTEFftioiJznzJzu42ZfzyyrSRJCoD9y5PZ H/b7aMnVzYGjg120isq/84UBBZhns9RidG8UBap7mPPQ5TX6cg6mwk7g1r78BH61aro3 lpZA==
X-Gm-Message-State: AJaThX5R2XC5DS217OmBx7rIVKuuXqN+zp0hhUaejGposV0VhCOALaT/ Kv24ezew6t2Zsmqrq04leQOpmqMslNY=
X-Google-Smtp-Source: AGs4zMb5EAw5m4n0YnlI7lCVFSaxGojNJyuj0/3SkC2D+sMxNF8oCwfI98MkRs42uLhKmd5gfYFDrA==
X-Received: by 10.237.56.226 with SMTP id k89mr31971742qte.320.1511370805484;  Wed, 22 Nov 2017 09:13:25 -0800 (PST)
Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id 50sm7671956qtn.48.2017.11.22.09.13.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Nov 2017 09:13:24 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Sean Turner 
In-Reply-To: <16bf6215-f8dd-5d9c-22c3-a8814da13693@cs.tcd.ie>
Date: Wed, 22 Nov 2017 12:13:23 -0500
Cc: "tls@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <0b536834-e49b-4c07-fc19-4d44c7e0ad99@cs.tcd.ie>  <16bf6215-f8dd-5d9c-22c3-a8814da13693@cs.tcd.ie>
To: Stephen Farrell 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [TLS] question for the WG about draft-ietf-tls-iana-registry-updates
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 17:13:28 -0000

Funny I never thought about going down, but I guess we should ;) I think =
the premise we want here is hard to get a Yes (whether new or upgrade) =
and somewhat easier than that to go down but it can=E2=80=99t be done in =
the dark so 4 would work. This kind of works out because people are =
motivated to get ciphers specified, but very much less so to de-specify =
them.

spt
> On Nov 21, 2017, at 18:54, Stephen Farrell  =
wrote:
>=20
>=20
>=20
> On 21/11/17 23:39, Martin Thomson wrote:
>> IESG action seems appropriate for both. =20
>=20
> I'm fairly sure the WG discussed the No->Yes (or new Yes)
> before and wanted standards action for that. I'd guess
> that changing that might take some discussion. (FWIW, I'd
> not support that change myself but maybe others would.)
>=20
> If the No->Yes stuff doesn't change I'll take you as
> arguing for a (4) below but correct me if that's wrong.
>=20
> Cheers,
> S.
>=20
>> If we could include guidance
>> around this (values with Yes should only include those for which the
>> community currently has consensus are worth having available at the
>> current time), tat would be awesom>
>> On Wed, Nov 22, 2017 at 7:37 AM, Stephen Farrell
>>  wrote:
>>>=20
>>> Hiya,
>>>=20
>>> I just posted a draft shepherd write-up for this [1]. (The
>>> write-up text was mostly written by Sean as it happens - for
>>> which he has my thanks as it's boring as hell to do that:-)
>>>=20
>>> There are nits but only one substantive question that I don't
>>> recall the WG discussing before (but maybe I'm forgetting).
>>>=20
>>> What is needed to change from Recommended =3D=3D Yes down to
>>> Recommended =3D=3D No? Does that need a standards action (e.g.
>>> with an RFC) or just IETF review or even maybe just IESG
>>> action?
>>>=20
>>> In the current draft write-up I've put in the first as a
>>> placeholder, as that's symmetric with the No->Yes change but
>>> I think IESG action is probably ok if the WG wanted that as
>>> the IESG probably won't go crazy and will likely do as the
>>> WG want in such cases. If the WG do want to write a specific
>>> foo-no-longer-recommended RFC it can do that in all cases,
>>> and of course Yes->No transitions could be documented in an
>>> RFC that documents a "replacement" Yes entry.
>>>=20
>>> So, unless this was already discussed....answers on a postcard
>>> please - which'd we like:
>>>=20
>>> (1) say nothing (as in -02 draft)
>>> (2) say standards action is required for a Yes->No transition
>>> (3) say IETF review (i.e. an IETF last call) is required for a
>>>    Yes->No transition
>>> (4) say IESG action is required for a Yes->No transition
>>> (5) something else
>>>=20
>>> And as a reminder the Recommended column is not about crypto
>>> quality but is about things for which we have consensus that
>>> they ought be widely implemented and available at the current
>>> point in time. Those are related things but Recommended =3D=3D No
>>> does not imply crap-crypto even if crap-crypto will hopefully
>>> imply Recommended =3D=3D No.
>>>=20
>>> If nobody says anything I'll chat with Kathleen, Sean and Joe
>>> and we'll pick a thing and that'll doubtless be quibbled about
>>> during directorate reviews and IESG processing as these things
>>> always are;-)
>>>=20
>>> But since I'd hope implementers will care about keeping up to
>>> date with the set of Recommended =3D=3D Yes things, I do hope that
>>> folks are willing to express a preference here.
>>>=20
>>> Cheers,
>>> S.
>>>=20
>>> [1]
>>> =
https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/shep=
herdwriteup/
>>>=20
>>>=20
>>> _______________________________________________
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>=20
>>=20
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From nobody Wed Nov 22 09:52:53 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCB3129503 for ; Wed, 22 Nov 2017 09:52:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.875
X-Spam-Level: 
X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com
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 zaG8V5qhvAwg for ; Wed, 22 Nov 2017 09:52:50 -0800 (PST)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-oln040092007108.outbound.protection.outlook.com [40.92.7.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DD241294DF for ; Wed, 22 Nov 2017 09:52:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9lVEppWIk6I43N9alZgDbLqlp1VM2P1xu8zKH3cVnzI=; b=hM/VDb4rrPMDQw7y1rzimLPFQvL2nnybCX5Dw2QbAzh3MIak1gFBp6Q2QTLEvxaMg/HVlf1l+YOGnsQn0rb/wMhL7qT0ZWbW7ILQRDUPFPhmJj1erWi48PQwrKOj2VtCRg10ykyS7v2kOKy3F0cqPbRXp1BhpVVZQ4emXtdOox1CgaOgocKotNoZP/jK2L4f9pX6jZJ6jS7EJQ1uQbNriDq4bYDrddJmR9kMSyOWIORQlTk++1cisRZMVg9Gtvx/wfXjcOlX9ODl56NHAHYxcaY3G1TkLTtVF7phfQ9bPc+8ccE6qUY3QPTnIkaKQcYPcstwA0dhjJPF10sjvFU11g==
Received: from DM3NAM03FT035.eop-NAM03.prod.protection.outlook.com (10.152.82.56) by DM3NAM03HT185.eop-NAM03.prod.protection.outlook.com (10.152.83.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Wed, 22 Nov 2017 17:52:49 +0000
Received: from MWHPR1801MB2061.namprd18.prod.outlook.com (10.152.82.59) by DM3NAM03FT035.mail.protection.outlook.com (10.152.82.188) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.239.4 via Frontend Transport; Wed, 22 Nov 2017 17:52:48 +0000
Received: from MWHPR1801MB2061.namprd18.prod.outlook.com ([10.164.205.38]) by MWHPR1801MB2061.namprd18.prod.outlook.com ([10.164.205.38]) with mapi id 15.20.0239.009; Wed, 22 Nov 2017 17:52:48 +0000
From: Yuhong Bao 
To: David Benjamin , Tapio Sokura 
CC: "tls@ietf.org" 
Thread-Topic: [TLS] PR#1091: Changes to provide middlebox robustness
Thread-Index: AQHTVyvb2MH+ZKktR0KvrQ+TnVw5FaMfyD2AgACtqICAAFERWw==
Date: Wed, 22 Nov 2017 17:52:48 +0000
Message-ID: 
References:  <389abe54-41d3-30e9-4cca-caa8b1469ae7@iki.fi>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-incomingtopheadermarker: OriginalChecksum:0ADDB0F0F550F00E0357164ED63149A82AD75B9D012D0BFDB3F666584252CD82; UpperCasedChecksum:E953DBFDB7A8997FC6DAEEECA2AB3786274834B79B8FB3E3EB880D8B29591CCB; SizeAsReceived:7390; Count:47
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [XTMq0STemv02kEtzpBwwZtXq720eSlySBzC4y6I3zFpqBMlkIqC1H5rZFYfoqmIr]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM3NAM03HT185; 6:CMgdgotXwuDtqgqXuAkEqsHlweGGW3ROOpSxS7MJAnUz0w5N2y3H9D/oYyhyIYXFwV2ORGAKztDAZt2g/6TkfE0+Q5nmzNT74nQdZlIi9NI71KoxOpCnk4hiqjpd6538mzov5FVjg12xTuTy7eZ8z3Ums1dhYUlLUW/lKlQdA/yKImiUs4r16t8q2GydMmyEcX+efRnYxUvrNETNHUVu7iWC1ooyqMPRfY3/M/aBrBjzWWpyk2FjG2hpxQCS2EWXQjxSFGeVgq8v5IDEAOvUiOY7RIvz/L+I3zCvyyflauEYcL7TnNAr8U0zwb3xFE748+1p4WfprFlPNRxfVXiuK5EACsGZr8G6y0ckLwXNz8U=; 5:8lg8QM6jnbcoy6Ktntxm164aymzSeu15ndTRAHtoyPi6DnMLLub0Xb0QlBF/5poNcf2ZdZlX5D/dSa6nqtCUhY1lE1qh1bFH232iqGNUWLt45eQ1cWbIsooHlU+P0m1NPC6BiB0GIC1ZVnBPcmPi0yE9F6OLg95ZFAtR1FCHs0E=; 24:9pTQPvL2zlWAj8YgJrM/3VacdBkeTX8/3tlvYn/G6WKFhdYh/2xlDvybhNxw+8rGbGndz8hc276XEAgi8T/KyW7eD57ZeYzCJyLieuqnByU=; 7:rla2vEU97FRGt0QAQjMC7VZ0x/QwftUzhtkUszAqPLvLc0+KHoCxtHh14sc88cfVptKNjqainsKh4Y9jVfIxDqKwYsChzEQ4ZIWb34Mly4QczLVlDPKPi+IU9oWYMY/Tw3vg05wlAwu7dfMx2wC/q7IG3+JGIvdHP6wv4IS7qETdzCnDkATRhkbZREeaU8tgSqB27NxwyPISAB3wsxuu29tyw2XgEJ2ApYTIb6H09DXUt3z9gDBASGEwew11gR+h
x-incomingheadercount: 47
x-eopattributedmessage: 0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:DM3NAM03HT185; 
x-ms-traffictypediagnostic: DM3NAM03HT185:
x-ms-office365-filtering-correlation-id: 4b4c1889-7c46-4db4-56e7-08d531d1d842
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:DM3NAM03HT185; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM3NAM03HT185; 
x-forefront-prvs: 0499DAF22A
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:DM3NAM03HT185; H:MWHPR1801MB2061.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4b4c1889-7c46-4db4-56e7-08d531d1d842
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2017 17:52:48.8320 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3NAM03HT185
Archived-At: 
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 17:52:52 -0000

The real question is if getting into an arms race with middleboxes is even =
a good idea IMO.

________________________________________
From: TLS  on behalf of David Benjamin 
Sent: Wednesday, November 22, 2017 5:02:15 AM
To: Tapio Sokura
Cc: tls@ietf.org
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness

As a source of some of those numbers, someone interested in actually deploy=
ing TLS 1.3, and, most importantly, someone who would have to deal with the=
 fallout of that deployment, I can unequivocally say those are not "very go=
od" figures. They are completely implausible by orders of magnitude. TLS 1.=
3, the secure upgrade to TLS 1.2, is not even close to being deployable tod=
ay.

Unchanged, deployment would require a unsecured version fallback, the same =
one that gave POODLE. An attacker could silently downgrade us to TLS 1.2. T=
hat ServerHello.random anti-downgrade signal would have been purely wishful=
 thinking and never implemented. I think this would be a huge step back. A =
de facto fallback would also send the same signal as tweaking the protocol.=
 There isn't enough incentive for middleboxes to ship updates or for admini=
strators to deploy those updates when doing nothing works just fine. For 21=
 years, since SSL 3.0, we didn't really change TLS's handshake and left it =
all unencrypted. In retrospect, it's probably to be expected the network la=
tched onto it. Ignoring the problem won't erase those 21 years.

These changes are certainly ugly, but they are only ugly. They have no impa=
ct on security, unlike the fallback which does. There is a complexity impac=
t, but, having implemented it, the impact is actually quite small. Making t=
he first server message more uniform between versions and HelloRetryRequest=
 is even a small convenience.

This is indeed baggage, but that is not new. When I think of the consequenc=
es of buggy middleboxes, I am actually less concerned that our first roundt=
rip needs to look a little funny, and more that we are wasting three bytes =
in front of *every* record (PR762). That we have entirely lost TCP and my c=
olleagues on QUIC needed to start over on UDP for improvements. That even t=
hen QUIC ran into ossification later on. That every protocol change is risk=
y and requires endless experimentation. That the reality of engineering on =
the Internet appears to be: if it was observable over time, it has ossified=
.

I share the justified frustration with this picture, but it's reality. Ther=
e are two questions now:

1) What we do need to do to deploy a change today? (Our handshake versionin=
g joints have rusted shut, and we need to break them free.)
2) How do we avoid needing to do worse tomorrow? (We've got it moving again=
, and we want to keep it that way.)

PR1091 seems to answer (1). (2) is harder. We need to think about how to av=
oid ossification. Writing versioning invariants[*] clearly is an easy step,=
 but text alone isn't enough. Reducing unencrypted portions is also obvious=
 and valuable in itself, but TLS has a bootstrapping problem here. We also =
need to think more in the direction of GREASE, but perhaps further as GREAS=
E itself only tried to prevent buggy endpoints.

This is a difficult question we won't fully explore immediately, and solvin=
g it is not going to magic away (1) anyway. So I think our first step is cl=
ear: get through the accumulated rust.

David

[*] TLS's versioning rules are quite restrictive. We promise you can parse =
newer ClientHellos. Everything after that is fair game to change. If you pr=
oduced the ClientHello, you can reasonably assume the peer won't send you a=
nything that will confuse you. If you are forwarding a ClientHello you did =
not produce, you MUST NOT process the response in any way. It will contain =
incompatible messages in the future. Alas, reality shows that the network d=
id not observe these rules.

On Tue, Nov 21, 2017 at 9:41 PM Tapio Sokura > wrote:
Hello,

On 6.11.2017 20:19, Eric Rescorla wrote:
> Once you do this, the middleboxes seem to mostly ignore everything
> after the CCS, so the rest of the handshake proceeds smoothly.
>
> This is all a bit nasty, but none of it changes the cryptographic
> computations or the state machine (because you just ignore CCS).

The discussion in Singapore on middlebox issues during the WG session
woke me up on this. I don't post much on this list, but here I have to
say that this dance to work around middleboxes looks seriously like
putting the cart before the horse.

I'm not arguing that the cryptographic properties/security of TLS 1.3 is
affected by these changes. I'm saying that this messing around with
making 1.3 look like 1.2 adds unnecessary complexity that will just hurt
everyone in the long run. In the short term you get a few % more
successful 1.3 handshakes, but once it's in the spec, it will bother
implementers for years to come.

Sometimes you have to let some things break to be able to move forward.
If over 90% (the figures presented in Singapore) of TLS 1.3 handshakes
already go through without 1.2 emulation / middlebox compensation in the
protocol, I find that a very good number for this point in time.

It's the middleboxes that should adapt to be 1.3 compatible, not the
other way around. This is not sending a good signal to the industry.

Sorry if I'm beating a dead horse (behind the cart). But my
interpretation of the comments made during the WG session indicate that
if there's consensus on incorporating these middlebox compatibility
changes, it's a very rough consensus.

   Tapio

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


From nobody Wed Nov 22 10:15:36 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C95129AB2 for ; Wed, 22 Nov 2017 10:15:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 6qvBZQlkF9jc for ; Wed, 22 Nov 2017 10:15:32 -0800 (PST)
Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 511EA126E3A for ; Wed, 22 Nov 2017 10:15:32 -0800 (PST)
Received: by mail-yw0-x234.google.com with SMTP id q37so7505127ywa.12 for ; Wed, 22 Nov 2017 10:15:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fCEOzRixk8UIGzSLT8RlfaY6/Ervgy8TpuB00e0LIFw=; b=kBx9MdKpL8WOQL9BLdH1Mg2E5pexreXmcAAlc2hnDE7L2kYohSG4qFFV+KEuYvaXWB WpzCKwE0VC5yRSiTa0+AFssMYQA7gddnLnyXIw7PBhqOQR4qz4Ig2Q9s2enB2BdZssi6 hTFXojYaNX8x5FT5v/tsYDeUEzFTKCuYtwRG0HTAM0OfG6zOCgYJOpRqKrAEuSfb0RqP KSu0WB67tHTR6BQDLcrEipp+WAzMw8sgkj74H9EeclWjUM0MD7hZBT/4dcBLww2QtZF8 hbDJAqPwYUuzE/Ym7bAMjpvNkK4mDE9es57bm+H63v9s7G+vb6xPgbr3qvyWmWHXqRVw NsSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fCEOzRixk8UIGzSLT8RlfaY6/Ervgy8TpuB00e0LIFw=; b=kbZBtsaKNARWotpQbTHSSwQ9LwtQfEgXj7/Yrw7Wlpp8VFHBm1JmQHPt/CXuGndNF/ 7UnwqFyDQetkAWwr85qNh9p3hL3C/H7cFtI/7FaBRyDWe6sJhAmcjqVwuLcZzyAemaDu i9UEfaZ+TcRZAES236IDL2k0IvxzDeir/Fp9+97vwSbTsJh5MF0f0crnUkfNpp0wtBDF 0/LFvM8mGXgdC/B4aTeq39DDFhktzeuXTaGhfXh1GPRNg81/uLXu8JG7pvf2FDHiqp8M cTR5ncD3josWqSdyZQGcWNiRdQjbQxnr02h7/WCcWoDeVW/dwPvJGobzwCtbgRoC1Ety DSiQ==
X-Gm-Message-State: AJaThX5HoFrMPIypau+VWHi6KsGwknwx7dybDx4WudDxDoQ3Hm2HMoTS QignTkt8uefgnYMpzYNC+VNBUhm+KyTpUl5saB/bZA==
X-Google-Smtp-Source: AGs4zMaew/KxhHh29dUwKd3Svf3khG+QyviCKctyntqxMGo3IRS95VMWSCTuyQMYM5jV5/lczWxLQN60wXVSJS/Q/o4=
X-Received: by 10.129.154.22 with SMTP id r22mr13859228ywg.296.1511374531258;  Wed, 22 Nov 2017 10:15:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.123.132 with HTTP; Wed, 22 Nov 2017 10:14:50 -0800 (PST)
In-Reply-To: 
References:  <389abe54-41d3-30e9-4cca-caa8b1469ae7@iki.fi>  
From: Eric Rescorla 
Date: Wed, 22 Nov 2017 10:14:50 -0800
Message-ID: 
To: Yuhong Bao 
Cc: David Benjamin , Tapio Sokura , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c0bb4e80f0502055e964eb9"
Archived-At: 
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 18:15:35 -0000

--94eb2c0bb4e80f0502055e964eb9
Content-Type: text/plain; charset="UTF-8"

On Wed, Nov 22, 2017 at 9:52 AM, Yuhong Bao 
wrote:

> The real question is if getting into an arms race with middleboxes is even
> a good idea IMO.
>

I don't think of it this way. As David says, the problem here is that
middleboxes are misbehaving (i.e., not conforming to the TLS version
semantics) and aren't upgrading fast enough. If they actually were
upgrading quickly (what you would have to do to get in an arms race) then
they could also handle TLS 1.3 properly and we would be in far better shape.

-Ekr




>
> ________________________________________
> From: TLS  on behalf of David Benjamin <
> davidben@chromium.org>
> Sent: Wednesday, November 22, 2017 5:02:15 AM
> To: Tapio Sokura
> Cc: tls@ietf.org
> Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness
>
> As a source of some of those numbers, someone interested in actually
> deploying TLS 1.3, and, most importantly, someone who would have to deal
> with the fallout of that deployment, I can unequivocally say those are not
> "very good" figures. They are completely implausible by orders of
> magnitude. TLS 1.3, the secure upgrade to TLS 1.2, is not even close to
> being deployable today.
>
> Unchanged, deployment would require a unsecured version fallback, the same
> one that gave POODLE. An attacker could silently downgrade us to TLS 1.2.
> That ServerHello.random anti-downgrade signal would have been purely
> wishful thinking and never implemented. I think this would be a huge step
> back. A de facto fallback would also send the same signal as tweaking the
> protocol. There isn't enough incentive for middleboxes to ship updates or
> for administrators to deploy those updates when doing nothing works just
> fine. For 21 years, since SSL 3.0, we didn't really change TLS's handshake
> and left it all unencrypted. In retrospect, it's probably to be expected
> the network latched onto it. Ignoring the problem won't erase those 21
> years.
>
> These changes are certainly ugly, but they are only ugly. They have no
> impact on security, unlike the fallback which does. There is a complexity
> impact, but, having implemented it, the impact is actually quite small.
> Making the first server message more uniform between versions and
> HelloRetryRequest is even a small convenience.
>
> This is indeed baggage, but that is not new. When I think of the
> consequences of buggy middleboxes, I am actually less concerned that our
> first roundtrip needs to look a little funny, and more that we are wasting
> three bytes in front of *every* record (PR762). That we have entirely lost
> TCP and my colleagues on QUIC needed to start over on UDP for improvements.
> That even then QUIC ran into ossification later on. That every protocol
> change is risky and requires endless experimentation. That the reality of
> engineering on the Internet appears to be: if it was observable over time,
> it has ossified.
>
> I share the justified frustration with this picture, but it's reality.
> There are two questions now:
>
> 1) What we do need to do to deploy a change today? (Our handshake
> versioning joints have rusted shut, and we need to break them free.)
> 2) How do we avoid needing to do worse tomorrow? (We've got it moving
> again, and we want to keep it that way.)
>
> PR1091 seems to answer (1). (2) is harder. We need to think about how to
> avoid ossification. Writing versioning invariants[*] clearly is an easy
> step, but text alone isn't enough. Reducing unencrypted portions is also
> obvious and valuable in itself, but TLS has a bootstrapping problem here.
> We also need to think more in the direction of GREASE, but perhaps further
> as GREASE itself only tried to prevent buggy endpoints.
>
> This is a difficult question we won't fully explore immediately, and
> solving it is not going to magic away (1) anyway. So I think our first step
> is clear: get through the accumulated rust.
>
> David
>
> [*] TLS's versioning rules are quite restrictive. We promise you can parse
> newer ClientHellos. Everything after that is fair game to change. If you
> produced the ClientHello, you can reasonably assume the peer won't send you
> anything that will confuse you. If you are forwarding a ClientHello you did
> not produce, you MUST NOT process the response in any way. It will contain
> incompatible messages in the future. Alas, reality shows that the network
> did not observe these rules.
>
> On Tue, Nov 21, 2017 at 9:41 PM Tapio Sokura  tapio.sokura@iki.fi>> wrote:
> Hello,
>
> On 6.11.2017 20:19, Eric Rescorla wrote:
> > Once you do this, the middleboxes seem to mostly ignore everything
> > after the CCS, so the rest of the handshake proceeds smoothly.
> >
> > This is all a bit nasty, but none of it changes the cryptographic
> > computations or the state machine (because you just ignore CCS).
>
> The discussion in Singapore on middlebox issues during the WG session
> woke me up on this. I don't post much on this list, but here I have to
> say that this dance to work around middleboxes looks seriously like
> putting the cart before the horse.
>
> I'm not arguing that the cryptographic properties/security of TLS 1.3 is
> affected by these changes. I'm saying that this messing around with
> making 1.3 look like 1.2 adds unnecessary complexity that will just hurt
> everyone in the long run. In the short term you get a few % more
> successful 1.3 handshakes, but once it's in the spec, it will bother
> implementers for years to come.
>
> Sometimes you have to let some things break to be able to move forward.
> If over 90% (the figures presented in Singapore) of TLS 1.3 handshakes
> already go through without 1.2 emulation / middlebox compensation in the
> protocol, I find that a very good number for this point in time.
>
> It's the middleboxes that should adapt to be 1.3 compatible, not the
> other way around. This is not sending a good signal to the industry.
>
> Sorry if I'm beating a dead horse (behind the cart). But my
> interpretation of the comments made during the WG session indicate that
> if there's consensus on incorporating these middlebox compatibility
> changes, it's a very rough consensus.
>
>    Tapio
>
> _______________________________________________
> 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
>

--94eb2c0bb4e80f0502055e964eb9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, Nov 22, 2017 at 9:52 AM, Yuhong Bao <yuhongbao_386@hot=
mail.com> wrote:
The real=
 question is if getting into an arms race with middleboxes is even a good i=
dea IMO.

I don't think of it this w=
ay. As David says, the problem here is that middleboxes are misbehaving (i.=
e., not conforming to the TLS version semantics) and aren't upgrading f=
ast enough. If they actually were upgrading quickly (what you would have to=
 do to get in an arms race) then they could also handle TLS 1.3 properly an=
d we would be in far better shape.

-Ekr
=


=C2=A0



________________________________________

From: TLS <tls-bounces@ietf.org<=
/a>> on behalf of David Benjamin <davidben@chromium.org>

Sent: Wednesday, November 22, 2017 5:02:15 AM

To: Tapio Sokura

Cc: tls@ietf.org

Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness



As a source of some of those numbers, someone inter=
ested in actually deploying TLS 1.3, and, most importantly, someone who wou=
ld have to deal with the fallout of that deployment, I can unequivocally sa=
y those are not "very good" figures. They are completely implausi=
ble by orders of magnitude. TLS 1.3, the secure upgrade to TLS 1.2, is not =
even close to being deployable today.



Unchanged, deployment would require a unsecured version fallback, the same =
one that gave POODLE. An attacker could silently downgrade us to TLS 1.2. T=
hat ServerHello.random anti-downgrade signal would have been purely wishful=
 thinking and never implemented. I think this would be a huge step back. A =
de facto fallback would also send the same signal as tweaking the protocol.=
 There isn't enough incentive for middleboxes to ship updates or for ad=
ministrators to deploy those updates when doing nothing works just fine. Fo=
r 21 years, since SSL 3.0, we didn't really change TLS's handshake =
and left it all unencrypted. In retrospect, it's probably to be expecte=
d the network latched onto it. Ignoring the problem won't erase those 2=
1 years.



These changes are certainly ugly, but they are only ugly. They have no impa=
ct on security, unlike the fallback which does. There is a complexity impac=
t, but, having implemented it, the impact is actually quite small. Making t=
he first server message more uniform between versions and HelloRetryRequest=
 is even a small convenience.



This is indeed baggage, but that is not new. When I think of the consequenc=
es of buggy middleboxes, I am actually less concerned that our first roundt=
rip needs to look a little funny, and more that we are wasting three bytes =
in front of *every* record (PR762). That we have entirely lost TCP and my c=
olleagues on QUIC needed to start over on UDP for improvements. That even t=
hen QUIC ran into ossification later on. That every protocol change is risk=
y and requires endless experimentation. That the reality of engineering on =
the Internet appears to be: if it was observable over time, it has ossified=
.



I share the justified frustration with this picture, but it's reality. =
There are two questions now:



1) What we do need to do to deploy a change today? (Our handshake versionin=
g joints have rusted shut, and we need to break them free.)

2) How do we avoid needing to do worse tomorrow? (We've got it moving a=
gain, and we want to keep it that way.)



PR1091 seems to answer (1). (2) is harder. We need to think about how to av=
oid ossification. Writing versioning invariants[*] clearly is an easy step,=
 but text alone isn't enough. Reducing unencrypted portions is also obv=
ious and valuable in itself, but TLS has a bootstrapping problem here. We a=
lso need to think more in the direction of GREASE, but perhaps further as G=
REASE itself only tried to prevent buggy endpoints.



This is a difficult question we won't fully explore immediately, and so=
lving it is not going to magic away (1) anyway. So I think our first step i=
s clear: get through the accumulated rust.



David



[*] TLS's versioning rules are quite restrictive. We promise you can pa=
rse newer ClientHellos. Everything after that is fair game to change. If yo=
u produced the ClientHello, you can reasonably assume the peer won't se=
nd you anything that will confuse you. If you are forwarding a ClientHello =
you did not produce, you MUST NOT process the response in any way. It will =
contain incompatible messages in the future. Alas, reality shows that the n=
etwork did not observe these rules.




On Tue, Nov 21, 2017 at 9:41 PM Tapio Sokura =
<tapio.sokura@iki.fi<mailt=
o:tapio.sokura@iki.fi>&g=
t; wrote:

Hello,



On 6.11.2017 20:19, Eric Rescorla wrote:

> Once you do this, the middleboxes seem to mostly ignore everything

> after the CCS, so the rest of the handshake proceeds smoothly.

>

> This is all a bit nasty, but none of it changes the cryptographic

> computations or the state machine (because you just ignore CCS).



The discussion in Singapore on middlebox issues during the WG session

woke me up on this. I don't post much on this list, but here I have to<=
br>
say that this dance to work around middleboxes looks seriously like

putting the cart before the horse.



I'm not arguing that the cryptographic properties/security of TLS 1.3 i=
s

affected by these changes. I'm saying that this messing around with

making 1.3 look like 1.2 adds unnecessary complexity that will just hurt
everyone in the long run. In the short term you get a few % more

successful 1.3 handshakes, but once it's in the spec, it will bother
implementers for years to come.



Sometimes you have to let some things break to be able to move forward.

If over 90% (the figures presented in Singapore) of TLS 1.3 handshakes

already go through without 1.2 emulation / middlebox compensation in the
protocol, I find that a very good number for this point in time.



It's the middleboxes that should adapt to be 1.3 compatible, not the
other way around. This is not sending a good signal to the industry.



Sorry if I'm beating a dead horse (behind the cart). But my

interpretation of the comments made during the WG session indicate that

if there's consensus on incorporating these middlebox compatibility

changes, it's a very rough consensus.



=C2=A0 =C2=A0Tapio



_______________________________________________

TLS mailing list


TLS@ietf.org<mailto:TLS@ietf.org>

https://www.ietf.org/mailman/listinfo/tls




_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--94eb2c0bb4e80f0502055e964eb9--


From nobody Wed Nov 22 10:16:36 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322FE129AF3 for ; Wed, 22 Nov 2017 10:16:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.875
X-Spam-Level: 
X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com
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 SEWNnghQHdgz for ; Wed, 22 Nov 2017 10:16:33 -0800 (PST)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-oln040092001019.outbound.protection.outlook.com [40.92.1.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4098129ADF for ; Wed, 22 Nov 2017 10:16:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XJREvaZrRiF+LU+/jgPwdnOUzGHPSnpvqrg4YglpGqE=; b=Pym9g3PcOgrtBaOcVm+m32NCkxVLPWLMgMQm1YjYkgLPpH9t820DQTWJTSXus6IBIpAogNQPvrKY19SAPZXhd92WzC2TJD7JzFN1KrmuqNyU1w971xCAdlY1mbCHZH3IK6hDtHAIaYq9aSmxL65PRRiQUHvF5ekv8zZjS7V4ckBJBO4zP7N48RJtB0YVJzCAEeat1yStfn5vkSzaQWXiZ34I+GvlFLlWoZ/vHU7BuonGOHmBLyV0jufELD9exFNwgTbC2WvDpVJ9nGrTz8qLBpY0D1M7017h5YVCDPzZ37Cc76yjf6qSO/4q1Q/yMfc8GwSfsukDG4HD+Sd+b+cEGQ==
Received: from BN3NAM01FT028.eop-nam01.prod.protection.outlook.com (10.152.66.56) by BN3NAM01HT194.eop-nam01.prod.protection.outlook.com (10.152.67.241) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.218.12; Wed, 22 Nov 2017 18:16:30 +0000
Received: from MWHPR1801MB2061.namprd18.prod.outlook.com (10.152.66.57) by BN3NAM01FT028.mail.protection.outlook.com (10.152.67.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.239.4 via Frontend Transport; Wed, 22 Nov 2017 18:16:29 +0000
Received: from MWHPR1801MB2061.namprd18.prod.outlook.com ([10.164.205.38]) by MWHPR1801MB2061.namprd18.prod.outlook.com ([10.164.205.38]) with mapi id 15.20.0239.009; Wed, 22 Nov 2017 18:16:29 +0000
From: Yuhong Bao 
To: Eric Rescorla 
CC: David Benjamin , Tapio Sokura , "tls@ietf.org" 
Thread-Topic: [TLS] PR#1091: Changes to provide middlebox robustness
Thread-Index: AQHTVyvb2MH+ZKktR0KvrQ+TnVw5FaMfyD2AgACtqICAAFERW4AABkQAgAAAXoE=
Date: Wed, 22 Nov 2017 18:16:29 +0000
Message-ID: 
References:  <389abe54-41d3-30e9-4cca-caa8b1469ae7@iki.fi>  , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: rtfm.com; dkim=none (message not signed) header.d=none;rtfm.com; dmarc=none action=none header.from=hotmail.com;
x-incomingtopheadermarker: OriginalChecksum:43D266580A3544A2D73607813E879EBAFECACF905AE9A6DCF1359DAE039C7747; UpperCasedChecksum:BB2E7DD516EC0C6EFF074BD7612D142DCBD69593F8EA7C6ADB34E6363AED6541; SizeAsReceived:7608; Count:47
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [JVbpzL+xAbDFjDU0djdXNj9BYd0yavbotHIeWEJFHEzF65kZrdqTOm/HOTA6ypkg]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3NAM01HT194; 6:mqO+jWw6htH6wo/jUUCToJELUTZF5Xl2s0/QidtD6GBV1P32vhcMq8mXbCFrMu1cNYh+pZ/6Ic4fA+QLWLCpj4bBtjuwVLvmlLSBS8iPZxjzmuuoTLsRff4DxxlR9eOh2dMoQVRzva6O7YEhN71Q8M7ix4hf5tXQxDGBJjvIEuwDce9wQ32mhIzeb0YTL3MUWFU6sS22Wd0C1jzsdHllPzvmqxZ6vv/8kvllBdvMagxUAPk1+zV3CkD08crM14ZPJooU9nm6J1G+9ME8D7NcQezizZ+N2mpez2QW+zt/NOgEwDnCJJZOv1y8V1nDFJjg6vuWSR22uClLsY8ujAiVH14aTB4kEomGJL7M5T+fHcU=; 5:mn6fYkSu32XfIKx61lkQzAWX/myd64wnXH1/VPQ9M5iwDinYSkH3B6pesHc66VojeylkB7KCAGAcQeVh627Wmv/FdY7e+Hmw9Nyp9HfIJxuucssqbTHbOG1Ot0wX62KoPT9sBUmpSm1fpiuZv6eY3xt//t0YfPncI1pgStNzI80=; 24:wEdOyPBUDDsVtKQH/RP6NM4ONu7Eo8mGGhU3emfShfLRtMgsE0Mu8ItQ0ojdAY0fXFw/gz0aYzer1DG1VaZjApZPPEDgv5vJviLDI4gKu4w=; 7:iulEwYxAc+3PZkg7HjYscBvvoAJbbghMxpQeDjglsCInX9dLxI1uk8ByedBjnJ/Iqjgna8oyD1vJZE9UVZc5Os4/EDwI1aRutal3VpFXrRof3H1JoUfJDS1U/6iHhCJZ4yPjVWU9X7RqkxBP80oAGMgLvWHc9r13QCjXg7jrHHThpI70IYRV2f/OHLoFxkj2xvqZkq6qCB2/yI6gpvOUOi4Gf1707dK8OZy+ei5Xwybhjith6TEaInHNWTr8/kf3
x-incomingheadercount: 47
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: dd80201f-61fe-4456-76ea-08d531d5272d
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:BN3NAM01HT194; 
x-ms-traffictypediagnostic: BN3NAM01HT194:
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:BN3NAM01HT194; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3NAM01HT194; 
x-forefront-prvs: 0499DAF22A
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:BN3NAM01HT194; H:MWHPR1801MB2061.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dd80201f-61fe-4456-76ea-08d531d5272d
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2017 18:16:29.7098 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM01HT194
Archived-At: 
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 18:16:35 -0000

The problem is not TLS 1.3, the problem is future versions of TLS.

________________________________________
From: Eric Rescorla 
Sent: Wednesday, November 22, 2017 10:14:50 AM
To: Yuhong Bao
Cc: David Benjamin; Tapio Sokura; tls@ietf.org
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness



On Wed, Nov 22, 2017 at 9:52 AM, Yuhong Bao > wrote:
The real question is if getting into an arms race with middleboxes is even =
a good idea IMO.

I don't think of it this way. As David says, the problem here is that middl=
eboxes are misbehaving (i.e., not conforming to the TLS version semantics) =
and aren't upgrading fast enough. If they actually were upgrading quickly (=
what you would have to do to get in an arms race) then they could also hand=
le TLS 1.3 properly and we would be in far better shape.

-Ekr




________________________________________
From: TLS > on behalf of =
David Benjamin >
Sent: Wednesday, November 22, 2017 5:02:15 AM
To: Tapio Sokura
Cc: tls@ietf.org
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness

As a source of some of those numbers, someone interested in actually deploy=
ing TLS 1.3, and, most importantly, someone who would have to deal with the=
 fallout of that deployment, I can unequivocally say those are not "very go=
od" figures. They are completely implausible by orders of magnitude. TLS 1.=
3, the secure upgrade to TLS 1.2, is not even close to being deployable tod=
ay.

Unchanged, deployment would require a unsecured version fallback, the same =
one that gave POODLE. An attacker could silently downgrade us to TLS 1.2. T=
hat ServerHello.random anti-downgrade signal would have been purely wishful=
 thinking and never implemented. I think this would be a huge step back. A =
de facto fallback would also send the same signal as tweaking the protocol.=
 There isn't enough incentive for middleboxes to ship updates or for admini=
strators to deploy those updates when doing nothing works just fine. For 21=
 years, since SSL 3.0, we didn't really change TLS's handshake and left it =
all unencrypted. In retrospect, it's probably to be expected the network la=
tched onto it. Ignoring the problem won't erase those 21 years.

These changes are certainly ugly, but they are only ugly. They have no impa=
ct on security, unlike the fallback which does. There is a complexity impac=
t, but, having implemented it, the impact is actually quite small. Making t=
he first server message more uniform between versions and HelloRetryRequest=
 is even a small convenience.

This is indeed baggage, but that is not new. When I think of the consequenc=
es of buggy middleboxes, I am actually less concerned that our first roundt=
rip needs to look a little funny, and more that we are wasting three bytes =
in front of *every* record (PR762). That we have entirely lost TCP and my c=
olleagues on QUIC needed to start over on UDP for improvements. That even t=
hen QUIC ran into ossification later on. That every protocol change is risk=
y and requires endless experimentation. That the reality of engineering on =
the Internet appears to be: if it was observable over time, it has ossified=
.

I share the justified frustration with this picture, but it's reality. Ther=
e are two questions now:

1) What we do need to do to deploy a change today? (Our handshake versionin=
g joints have rusted shut, and we need to break them free.)
2) How do we avoid needing to do worse tomorrow? (We've got it moving again=
, and we want to keep it that way.)

PR1091 seems to answer (1). (2) is harder. We need to think about how to av=
oid ossification. Writing versioning invariants[*] clearly is an easy step,=
 but text alone isn't enough. Reducing unencrypted portions is also obvious=
 and valuable in itself, but TLS has a bootstrapping problem here. We also =
need to think more in the direction of GREASE, but perhaps further as GREAS=
E itself only tried to prevent buggy endpoints.

This is a difficult question we won't fully explore immediately, and solvin=
g it is not going to magic away (1) anyway. So I think our first step is cl=
ear: get through the accumulated rust.

David

[*] TLS's versioning rules are quite restrictive. We promise you can parse =
newer ClientHellos. Everything after that is fair game to change. If you pr=
oduced the ClientHello, you can reasonably assume the peer won't send you a=
nything that will confuse you. If you are forwarding a ClientHello you did =
not produce, you MUST NOT process the response in any way. It will contain =
incompatible messages in the future. Alas, reality shows that the network d=
id not observe these rules.

On Tue, Nov 21, 2017 at 9:41 PM Tapio Sokura >>=
 wrote:
Hello,

On 6.11.2017 20:19, Eric Rescorla wrote:
> Once you do this, the middleboxes seem to mostly ignore everything
> after the CCS, so the rest of the handshake proceeds smoothly.
>
> This is all a bit nasty, but none of it changes the cryptographic
> computations or the state machine (because you just ignore CCS).

The discussion in Singapore on middlebox issues during the WG session
woke me up on this. I don't post much on this list, but here I have to
say that this dance to work around middleboxes looks seriously like
putting the cart before the horse.

I'm not arguing that the cryptographic properties/security of TLS 1.3 is
affected by these changes. I'm saying that this messing around with
making 1.3 look like 1.2 adds unnecessary complexity that will just hurt
everyone in the long run. In the short term you get a few % more
successful 1.3 handshakes, but once it's in the spec, it will bother
implementers for years to come.

Sometimes you have to let some things break to be able to move forward.
If over 90% (the figures presented in Singapore) of TLS 1.3 handshakes
already go through without 1.2 emulation / middlebox compensation in the
protocol, I find that a very good number for this point in time.

It's the middleboxes that should adapt to be 1.3 compatible, not the
other way around. This is not sending a good signal to the industry.

Sorry if I'm beating a dead horse (behind the cart). But my
interpretation of the comments made during the WG session indicate that
if there's consensus on incorporating these middlebox compatibility
changes, it's a very rough consensus.

   Tapio

_______________________________________________
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


From nobody Wed Nov 22 11:02:46 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80CA12957B for ; Wed, 22 Nov 2017 11:02:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level: 
X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=Wm3fl1Kx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=l3RttYGT
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 ZLKb43RVkFY7 for ; Wed, 22 Nov 2017 11:02:42 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55442129601 for ; Wed, 22 Nov 2017 11:02:42 -0800 (PST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id BADF820BC1; Wed, 22 Nov 2017 14:02:41 -0500 (EST)
Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 22 Nov 2017 14:02:41 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=0nOaEjWuEiFpknVVapA2IC7uaphL7vDPKXmjB1/vfC8=; b=Wm3fl1Kx K7PAqHhuYFBiz4kFK1dHWkf49XL5223IymlB0iAfnmVuqWL0vRBCWoa1pzXPmTAY YUVxEzjiQT0t3szijJ+pB3BE/5PpD8OmY5F79ufu/34NH7b3hq1LyDBp5GCEyoCp jgmg73KRumemRn6yFzEACIjvy7+BtaH4L1QvhIihmpdF+zfP91Zb5tNGApQNKEkD QSIkr+lJLcJshoNiYSudMp1LY0JTNciIAmxx+02HpjYqXiljYrrVrXICV03oi7iP iqohXPJfDIcYyXMrMxyNxq0nJN0modRYBLf1APRxwQx/lWZw5a69+35/YJPlNbJ5 OZEtPpy8ON2EOQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=0nOaEjWuEiFpknVVapA2IC7uaphL7 vDPKXmjB1/vfC8=; b=l3RttYGTvudjuq0yKf6a7sPOcORafFzo6Cr594YdLk3Zx P1K/T7QfuVq0tOKXRYITXtwWF2kF8lmpD2AF6Az2EacLLsJ/zxY++3d+2nWQ4YG8 Af+qPEScHaaDPULFCOuSBZMx+rc3pckpilj6hzucnLGzOh1vo6V0IdW/w58jLEK6 ef6k7wzWctK3Rogr58G3kdLxnUMpfVe9cprAinbphYjsI1yzXMLdDy1aNbGRtupW aJYtUwk1afaBoLebi9ULPcxzonYej8/EaT5o4QC054Pb1fqoCQCk3Onu9CAAH+QY 3gbCna6wUdKYUA576f01rx7dJJZ9PGpHriV0s4vxA==
X-ME-Sender: 
Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id 13696247A5; Wed, 22 Nov 2017 14:02:41 -0500 (EST)
To: Yuhong Bao , Eric Rescorla 
Cc: "tls@ietf.org" , Tapio Sokura 
References:  <389abe54-41d3-30e9-4cca-caa8b1469ae7@iki.fi>    
From: Peter Saint-Andre 
Message-ID: 
Date: Wed, 22 Nov 2017 12:02:39 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CuBFje5ELrMG2QmOnCfp6XcFiOfGmF3PG"
Archived-At: 
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 19:02:45 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--CuBFje5ELrMG2QmOnCfp6XcFiOfGmF3PG
Content-Type: multipart/mixed; boundary="NmHMAfVCN5c1WdHuHOFAonOHROlCq2NWd";
 protected-headers="v1"
From: Peter Saint-Andre 
To: Yuhong Bao , Eric Rescorla 
Cc: "tls@ietf.org" , Tapio Sokura 
Message-ID: 
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness
References: 
 <389abe54-41d3-30e9-4cca-caa8b1469ae7@iki.fi>
 
 
 
 
In-Reply-To: 

--NmHMAfVCN5c1WdHuHOFAonOHROlCq2NWd
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 11/22/17 11:16 AM, Yuhong Bao wrote:
> The problem is not TLS 1.3, the problem is future versions of TLS.

Would you mind explaining that in more detail?

Peter


--NmHMAfVCN5c1WdHuHOFAonOHROlCq2NWd--

--CuBFje5ELrMG2QmOnCfp6XcFiOfGmF3PG
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIzBAEBCAAdFiEEO1gGYnPG8aeH+JR96gakkSvFrakFAloVyc8ACgkQ6gakkSvF
ramUuxAAoUgqvRgmNdqRvBgE9ogNdUYy1ky2wTyLdOVdSLroOA7S7vwNcDIh7Xew
YTq4uTqnQVZ7WWIO2cUR5dIyZro5vWVIiTliiOw726wHimRkABYtedB8pC7YlzJf
BhS79QZI3UDy5HsC4uAtu8WdOg40QZU/+XTS3m568AFHnuY1QQm5qyS1UM52pm5O
DEu8YNF5tOSuIu09fqcAIVCJx7O38QSFTGagphYusZKgtTw6/nuOpqNDrt5epZOr
hI/QOCRFzu973sjG35OFI5z9Ri8ayIWczf6iZFmAQY6URaEqAhu7f+hQBHpPGY79
1Lf6zmxNH2Bg9wU7t4uN77ZHTQqYFUfrhKbFvadMTPcJJelUr+rAKMpdzeTSQFCz
Nq/b3HIzZG/xn9JfdFAfkmdDYqYXL8A5/QUUL8JTHYaFGEERiJkzHBO7BQDV7OA6
yekXbcDAywIrqJQEpEb1hXHpONPLhYuvVmeBgbr2T+S0lNnQ89Pt42bg5EpQ6GjF
oy7g+bm9Nbe90qlaJtwU3nimLMMbVbaErJN9ce+geF0Xv3NwPQUxsgCWW6y1YOJS
QJjih5oW/EnDx/em7LnzNXh5tXMdhTi6X8Gc3EcM+MRD2/7PK6739S7MPE/TEMXb
zq5d0XBkvtTOS5yRmyh1zNt55w/L+0m4+cE/VJ7W88jkEOJSB/Y=
=NmYD
-----END PGP SIGNATURE-----

--CuBFje5ELrMG2QmOnCfp6XcFiOfGmF3PG--


From nobody Wed Nov 22 11:04:24 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4335A129B89 for ; Wed, 22 Nov 2017 11:04:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.875
X-Spam-Level: 
X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com
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 vjeW3OfwXaZi for ; Wed, 22 Nov 2017 11:04:22 -0800 (PST)
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-oln040092010066.outbound.protection.outlook.com [40.92.10.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A623129B51 for ; Wed, 22 Nov 2017 11:04:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=q/vGV5rBCPodmRwko1WujpncEnYg8ygtcX82dUuCdpA=; b=rNrd2iLi0S2F0JKuYE0pGZET2bYArhgaPTJfEPSGjQgWfuHbiPv2OmK6/KTqwWsL+skCoyZUtga+hgZAVkCje35yuzUL2o6SfTUejjlZ6Fq+Vj+lS3U7ooHH7QpVpEuvHW2jlQq0k+ppX0bUW0TRZEo6MXN+9jch8oYStz8TB+rwk+LzA326vjWM8FCOwhDYVTq/mDeEVs0uo1HFIsbvJovWxrI/cZHQ0nVGBonCu1EJhysCTLZFDs305EgLNZIzxcK8UvdTyQdCxhOe0ww5J1QkZzW52HV99jZ5uBYCJQw21YJdd9v7tw7rMq0h+AqyIdYA15jZ6N6A/9oXWlrMag==
Received: from CO1NAM04FT007.eop-NAM04.prod.protection.outlook.com (10.152.90.59) by CO1NAM04HT076.eop-NAM04.prod.protection.outlook.com (10.152.91.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Wed, 22 Nov 2017 19:04:19 +0000
Received: from MWHPR1801MB2061.namprd18.prod.outlook.com (10.152.90.51) by CO1NAM04FT007.mail.protection.outlook.com (10.152.90.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.239.4 via Frontend Transport; Wed, 22 Nov 2017 19:04:19 +0000
Received: from MWHPR1801MB2061.namprd18.prod.outlook.com ([10.164.205.38]) by MWHPR1801MB2061.namprd18.prod.outlook.com ([10.164.205.38]) with mapi id 15.20.0239.009; Wed, 22 Nov 2017 19:04:19 +0000
From: Yuhong Bao 
To: Peter Saint-Andre , Eric Rescorla 
CC: "tls@ietf.org" , Tapio Sokura 
Thread-Topic: [TLS] PR#1091: Changes to provide middlebox robustness
Thread-Index: AQHTVyvb2MH+ZKktR0KvrQ+TnVw5FaMfyD2AgACtqICAAFERW4AABkQAgAAAXoGAAAz+gIAAADWv
Date: Wed, 22 Nov 2017 19:04:19 +0000
Message-ID: 
References:  <389abe54-41d3-30e9-4cca-caa8b1469ae7@iki.fi>    , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-incomingtopheadermarker: OriginalChecksum:E9F9038DEC28ACCFE7DFD3E86A7BF96DE2192B994EC4830D92190F6499C16DC4; UpperCasedChecksum:6A5583E06F8D453D5665625E3D24A2B79385AD0F91A28C82DA01A1E9A15BA1AB; SizeAsReceived:7724; Count:47
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [/RntlG4kAjLx4AHdS1Vwdk1FDUPmVbJpW5av0jxN0oANjz2sm6CrHQMD8t5fv/Wc]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CO1NAM04HT076; 6:pY6O2lPLarLUMUS0hDsWcj9hN/g+wADQkcsmfG58EzmQ48mv+vmUx0W1PA89MLcPq8Mbw5oLZb8vNEPyzr/Zz0v9U71BCRVbGBB3VG2sb+XyyfNPuW5fHhlef0BXNmmcUCXtkq8r9THQel4+lOcp24ffVB5JYoyGym/6FNCJvpOGVQ9XcSaJqdudSxQLIQ5aTS6oQ3OFUcDtzaSo6UjK9s0uj2PsVyh7UjCgW9CkY46Ng/F//bKRzgA7ORFrDwNnGPai42Gv7RnPq33Z/wg2zq841NpYE1TyQd//iArYw6QJCF6aQ9cuMJs3RD/B5muV/XXPVku97ALea8N64vRg0N7+07DlXqJZih8Ld7w7gkU=; 5:/7Zekj2UYiJmYzu2SuuGqMQ0MudUKGnbxy6t4Y23h9GV8L6E44ZIcq6upHrL2UpA7tMSkD/bAFjy2b5CKi99uXOFDY+mEZ48O/1wAYyV75Wf20Sa+Sm3kugmiWkzl0fyYFvDn5t+WIfdeTDK4xiTt8MtfUJP3Fl+3lA7nMKNAgk=; 24:lQ++wbS6EGeoXZhBo/4oYfqO/rTOrBm4jI4PajE4r/hMvoUUu/RInwmxmQI1wM1GkUhUNgRrXOhAlqQBTO7VtOjmpTVQJCaJCApue2XjTps=; 7:tDfAyzwpymi9GHA5VSdFvHKiQKlrfTcmGOVYrSzKXPbcmwVCDd2Z+S46hKEUEB5a6psk1SqvF1o4YO2NzVKZAeEFot1XU3X0TFlKqDhSv3a7puFBUE2mks3tUr6ckIS4k+O/raHYSRwf+fLy7gYvxPc72Xa7Z+3DzguqfLizBaS8gc55vhB7ka1OtxuHiyJdvBOGsQTMr/N+/yRnEAiQFUgTEgD77qxIa7lX3eIqsg0Nz7AhOnuRwo2r0PscES+t
x-incomingheadercount: 47
x-eopattributedmessage: 0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:CO1NAM04HT076; 
x-ms-traffictypediagnostic: CO1NAM04HT076:
x-ms-office365-filtering-correlation-id: ee48b293-42af-4e21-eb6f-08d531dbd5c4
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:CO1NAM04HT076; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CO1NAM04HT076; 
x-forefront-prvs: 0499DAF22A
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:CO1NAM04HT076; H:MWHPR1801MB2061.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ee48b293-42af-4e21-eb6f-08d531dbd5c4
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2017 19:04:19.6063 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM04HT076
Archived-At: 
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 19:04:23 -0000

They are basically doing a supported_versions extension with only one entry=
 in the ServerHello.
The problem with future middleboxes should be obvious.

________________________________________
From: Peter Saint-Andre 
Sent: Wednesday, November 22, 2017 11:02:39 AM
To: Yuhong Bao; Eric Rescorla
Cc: tls@ietf.org; Tapio Sokura
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness

On 11/22/17 11:16 AM, Yuhong Bao wrote:
> The problem is not TLS 1.3, the problem is future versions of TLS.

Would you mind explaining that in more detail?

Peter


From nobody Wed Nov 22 11:08:46 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079A0129B5C for ; Wed, 22 Nov 2017 11:08:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level: 
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 BLQHYmdrps-C for ; Wed, 22 Nov 2017 11:08:43 -0800 (PST)
Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 8F6531298A1 for ; Wed, 22 Nov 2017 11:08:42 -0800 (PST)
Received: by mail-lf0-x233.google.com with SMTP id i14so19444984lfc.1 for ; Wed, 22 Nov 2017 11:08:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=zXGJtj4rogm9POJw670o+osbR4r/fBKSwHoA+TULBZk=; b=VsP0I2z7QZcZ56k9fWY7nIP11fq0J9ZxZuqwlgD2ivplz1cNUaYhRavh24L8u4uCVR QaaO4zVWZKUdXSYVpKWN0KCgWwGXU6VSQX9KioZod6Ab/k4J+WlGqB+TCMYPPpW/g2+c gme2J4KKf+ntKdeDwtDO4cfRDlVPjuVSOARGbPZyyUUxjx9+dfMWuugxpnngO0f4E/OT zKn41ZMP3lZ7/vbBxGNMZfAt6jZ5ueldinTwf3by9iORAtH8kvKwpQiSSk6w6l6xKFnH Lg0W8zEZ9V6DJgdfjpQ2FXYsKwT2CN6jWKK3WTfsCj4OxyEIp+DhTCv5xl8d1iMkkmPD VPbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=zXGJtj4rogm9POJw670o+osbR4r/fBKSwHoA+TULBZk=; b=ROR5IFBbToNXGLAZFrrPq6jXrw8YvrBkdLbklM4CbYDGSgyUaroRKUnOAyL2zQ1rqw 7C0j+2lSOsaGh9BUaQ7LOncU77uQJEkFz7zrJFoDAgGlqMPRMqS9z9UhImZQTZYvXVRp xymBLsK5oPlf5yac7M7OBjMe4VM3myh6bqASk4jkDXFFtHhAUveGUc3tVCrVKKcedSMm AO+OS59QfMwsPsXmdjnag/RxYRNFoxCa95ntvIrOs77huyGoNNr3l2z3NHwsV2e/4Vpq zKzerLxzkVwRzMMaU70TqM/HY6GQk7PBJsBY+64V6qs6WHDtbMyeCPmf2Lb04a1KMM6O 1gyA==
X-Gm-Message-State: AJaThX7fWtrDrgpc2FW/ztTZlkckdNx1dUyoXFSbOAfMrX6Z3nFwTO8x zQH8hxLNHzdem5xkHTNw03JZ9MO08zIXW8fwsDM=
X-Google-Smtp-Source: AGs4zMZ09i76IwwWfUO6nrKh9X3Y+ettgHwsfB90btQJfN8Hu+0gizI4nEAQY/t4v6qrfnPZH1QkueeT1TWecBWBMaU=
X-Received: by 10.46.34.134 with SMTP id i128mr1168495lji.11.1511377720738; Wed, 22 Nov 2017 11:08:40 -0800 (PST)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 10.46.70.2 with HTTP; Wed, 22 Nov 2017 11:08:39 -0800 (PST)
In-Reply-To: 
References: <0b536834-e49b-4c07-fc19-4d44c7e0ad99@cs.tcd.ie>  <16bf6215-f8dd-5d9c-22c3-a8814da13693@cs.tcd.ie> 
From: Daniel Migault 
Date: Wed, 22 Nov 2017 14:08:39 -0500
X-Google-Sender-Auth: XzXYs2oOxiiHhGlccr2mP450AkY
Message-ID: 
To: Sean Turner 
Cc: Stephen Farrell , "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="f4030439dfa42a88c3055e970ca1"
Archived-At: 
Subject: Re: [TLS] question for the WG about draft-ietf-tls-iana-registry-updates
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 19:08:45 -0000

--f4030439dfa42a88c3055e970ca1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

IESG approval seems also fine to me. Hopefully ciphers may not be used at
the time they are deprecated.

Yours,
Daniel

On Wed, Nov 22, 2017 at 12:13 PM, Sean Turner  wrote:

> Funny I never thought about going down, but I guess we should ;) I think
> the premise we want here is hard to get a Yes (whether new or upgrade) an=
d
> somewhat easier than that to go down but it can=E2=80=99t be done in the =
dark so 4
> would work. This kind of works out because people are motivated to get
> ciphers specified, but very much less so to de-specify them.
>
> spt
> > On Nov 21, 2017, at 18:54, Stephen Farrell 
> wrote:
> >
> >
> >
> > On 21/11/17 23:39, Martin Thomson wrote:
> >> IESG action seems appropriate for both.
> >
> > I'm fairly sure the WG discussed the No->Yes (or new Yes)
> > before and wanted standards action for that. I'd guess
> > that changing that might take some discussion. (FWIW, I'd
> > not support that change myself but maybe others would.)
> >
> > If the No->Yes stuff doesn't change I'll take you as
> > arguing for a (4) below but correct me if that's wrong.
> >
> > Cheers,
> > S.
> >
> >> If we could include guidance
> >> around this (values with Yes should only include those for which the
> >> community currently has consensus are worth having available at the
> >> current time), tat would be awesom>
> >> On Wed, Nov 22, 2017 at 7:37 AM, Stephen Farrell
> >>  wrote:
> >>>
> >>> Hiya,
> >>>
> >>> I just posted a draft shepherd write-up for this [1]. (The
> >>> write-up text was mostly written by Sean as it happens - for
> >>> which he has my thanks as it's boring as hell to do that:-)
> >>>
> >>> There are nits but only one substantive question that I don't
> >>> recall the WG discussing before (but maybe I'm forgetting).
> >>>
> >>> What is needed to change from Recommended =3D=3D Yes down to
> >>> Recommended =3D=3D No? Does that need a standards action (e.g.
> >>> with an RFC) or just IETF review or even maybe just IESG
> >>> action?
> >>>
> >>> In the current draft write-up I've put in the first as a
> >>> placeholder, as that's symmetric with the No->Yes change but
> >>> I think IESG action is probably ok if the WG wanted that as
> >>> the IESG probably won't go crazy and will likely do as the
> >>> WG want in such cases. If the WG do want to write a specific
> >>> foo-no-longer-recommended RFC it can do that in all cases,
> >>> and of course Yes->No transitions could be documented in an
> >>> RFC that documents a "replacement" Yes entry.
> >>>
> >>> So, unless this was already discussed....answers on a postcard
> >>> please - which'd we like:
> >>>
> >>> (1) say nothing (as in -02 draft)
> >>> (2) say standards action is required for a Yes->No transition
> >>> (3) say IETF review (i.e. an IETF last call) is required for a
> >>>    Yes->No transition
> >>> (4) say IESG action is required for a Yes->No transition
> >>> (5) something else
> >>>
> >>> And as a reminder the Recommended column is not about crypto
> >>> quality but is about things for which we have consensus that
> >>> they ought be widely implemented and available at the current
> >>> point in time. Those are related things but Recommended =3D=3D No
> >>> does not imply crap-crypto even if crap-crypto will hopefully
> >>> imply Recommended =3D=3D No.
> >>>
> >>> If nobody says anything I'll chat with Kathleen, Sean and Joe
> >>> and we'll pick a thing and that'll doubtless be quibbled about
> >>> during directorate reviews and IESG processing as these things
> >>> always are;-)
> >>>
> >>> But since I'd hope implementers will care about keeping up to
> >>> date with the set of Recommended =3D=3D Yes things, I do hope that
> >>> folks are willing to express a preference here.
> >>>
> >>> Cheers,
> >>> S.
> >>>
> >>> [1]
> >>> https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates=
/
> shepherdwriteup/
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--f4030439dfa42a88c3055e970ca1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


IESG approval seems also fine to me. Hopefully ciphers may=
 not be used at the time they are deprecated. 

Yours, 
Daniel

On Wed, Nov 22, 2017 at 12:13 PM, Sean =
Turner <sean@sn3rd.com> wrote:
> On Nov 21, 2017, at 18:54, Ste=
phen Farrell <stephen.farre=
ll@cs.tcd.ie> wrote:

>

>

>

> On 21/11/17 23:39, Martin Thomson wrote:

>> IESG action seems appropriate for both.

>

> I'm fairly sure the WG discussed the No->Yes (or new Yes)

> before and wanted standards action for that. I'd guess

> that changing that might take some discussion. (FWIW, I'd

> not support that change myself but maybe others would.)

>

> If the No->Yes stuff doesn't change I'll take you as

> arguing for a (4) below but correct me if that's wrong.

>

> Cheers,

> S.

>

>> If we could include guidance

>> around this (values with Yes should only include those for which t=
he

>> community currently has consensus are worth having available at th=
e

>> current time), tat would be awesom>

>> On Wed, Nov 22, 2017 at 7:37 AM, Stephen Farrell

>> <stephen.farrell@c=
s.tcd.ie> wrote:

>>>

>>> Hiya,

>>>

>>> I just posted a draft shepherd write-up for this [1]. (The

>>> write-up text was mostly written by Sean as it happens - for
>>> which he has my thanks as it's boring as hell to do that:-=
)

>>>

>>> There are nits but only one substantive question that I don=
9;t

>>> recall the WG discussing before (but maybe I'm forgetting)=
.

>>>

>>> What is needed to change from Recommended =3D=3D Yes down to
>>> Recommended =3D=3D No? Does that need a standards action (e.g.=


>>> with an RFC) or just IETF review or even maybe just IESG

>>> action?

>>>

>>> In the current draft write-up I've put in the first as a
>>> placeholder, as that's symmetric with the No->Yes chang=
e but

>>> I think IESG action is probably ok if the WG wanted that as
>>> the IESG probably won't go crazy and will likely do as the=


>>> WG want in such cases. If the WG do want to write a specific
>>> foo-no-longer-recommended RFC it can do that in all cases,

>>> and of course Yes->No transitions could be documented in an=


>>> RFC that documents a "replacement" Yes entry.

>>>

>>> So, unless this was already discussed....answers on a postcard=


>>> please - which'd we like:

>>>

>>> (1) say nothing (as in -02 draft)

>>> (2) say standards action is required for a Yes->No transiti=
on

>>> (3) say IETF review (i.e. an IETF last call) is required for a=


>>>=C2=A0 =C2=A0 Yes->No transition

>>> (4) say IESG action is required for a Yes->No transition
>>> (5) something else

>>>

>>> And as a reminder the Recommended column is not about crypto
>>> quality but is about things for which we have consensus that
>>> they ought be widely implemented and available at the current<=
br>
>>> point in time. Those are related things but Recommended =3D=3D=
 No

>>> does not imply crap-crypto even if crap-crypto will hopefully<=
br>
>>> imply Recommended =3D=3D No.

>>>

>>> If nobody says anything I'll chat with Kathleen, Sean and =
Joe

>>> and we'll pick a thing and that'll doubtless be quibbl=
ed about

>>> during directorate reviews and IESG processing as these things=


>>> always are;-)

>>>

>>> But since I'd hope implementers will care about keeping up=
 to

>>> date with the set of Recommended =3D=3D Yes things, I do hope =
that

>>> folks are willing to express a preference here.

>>>

>>> Cheers,

>>> S.

>>>

>>> [1]

>>> h=
ttps://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-upda=
tes/shepherdwriteup/

>>>

>>>

>>> _______________________________________________

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



_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--f4030439dfa42a88c3055e970ca1--


From nobody Wed Nov 22 11:22:29 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B84129B77 for ; Wed, 22 Nov 2017 11:22:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level: 
X-Spam-Status: No, score=-2.02 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_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
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 sVqUUFS47ZQh for ; Wed, 22 Nov 2017 11:22:26 -0800 (PST)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0108.outbound.protection.outlook.com [104.47.34.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF8591296C9 for ; Wed, 22 Nov 2017 11:22:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YZssHoEZ9D/GLDVW+Hnm+qnDL2Rd4JO5XN4rwGR2SlY=; b=GAaIOtWpwJQ9xIB01u0lvtll0HFg4YujFlA3lKeeyFJ+apFK2Y+al60WRs1h0EEGeKgfcH5FZ8AOQ8PhmAaRDsaEeF3rUef8wiwpDadOtQs/PrMpCI0+XNCec6yQcwDkwYahFBnVnC7SXrSsy1kkuif6u9KJJSIa0l3VB6hBavQ=
Received: from CY4PR21MB0120.namprd21.prod.outlook.com (10.173.189.14) by CY4PR21MB0469.namprd21.prod.outlook.com (10.172.121.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Wed, 22 Nov 2017 19:22:24 +0000
Received: from CY4PR21MB0120.namprd21.prod.outlook.com ([10.173.189.14]) by CY4PR21MB0120.namprd21.prod.outlook.com ([10.173.189.14]) with mapi id 15.20.0260.003; Wed, 22 Nov 2017 19:22:24 +0000
From: Andrei Popov 
To: Yuhong Bao , Peter Saint-Andre , Eric Rescorla 
CC: "tls@ietf.org" , Tapio Sokura 
Thread-Topic: [TLS] PR#1091: Changes to provide middlebox robustness
Thread-Index: AQHTVyvnGkBu16gvEUib9Q78H5YjdqMfyD2AgACtp4CAAFEuAIAABigAgAAAdoCAAAzmgIAAAHeAgAAAU5A=
Date: Wed, 22 Nov 2017 19:22:23 +0000
Message-ID: 
References:  <389abe54-41d3-30e9-4cca-caa8b1469ae7@iki.fi>    ,  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:3::4ca]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0469; 6:5zohZ+rB/PhRXLWF2tKcVlY4k1u8FLd0EvCUaC2BJR1J/h1g3pcEHZ8fNxYdiQky4Zt1o5LM+RVcJacGzooWKVLEJJtbVKn/X35nwVc69jHXrouyEXiXVLxXZNUl9t8HPNHOV1DKtC8wNbs4Xjz5Tl/rkaQxys/P0LmKJUTFBS5smR6TpIQSQHo9jpB8ATvsWEH3rTNGze5e84WE8u+1RaLvL7OJRo3S6Q0XfD6Eai0u4/5a9H3uVuacg0wg19xs/2z5TPLsSvUPgXvmNbuOxWrWhRn0j1W2Q42LMsCd9oElx802ZV6gHWyxlQxRSmUfRJtF/mm+Aj/o4elx1kDYbcN9zNbzViWWjtab9Oujvew=; 5:X1/zN5uanZa1C1r4g1wiNDs+316GvmajFHms3+fDknFB/iLfgAi0sfp2dnzFleHrSeguEWMP7KdsV3dTZyIdDZtbWh7EM1EULrEf0Ak1mTcOrxQ45Z0EfUEWMeFuIqDXzreOR+lBW2OiWntK5D0GLeNSCvLdfQ05PlbCAkGrXpo=; 24:QPb3fO7sclKdFiooEACTaz0zrh4WENt3lTUAxVd6jI26Ev8bRorAnJWUjnZnHdQrOsQv0kV+zarQRJqXAm35z4SKK2Y8Qjl97eRkaBZyq2U=; 7:tIu92IQaeMTYRTXidGJneMXVwKgzM6E2nB4WrtP4TWtOh6kW7H0WebaQKpI3HQOlumCm4Hq8TDKifCsnzsbM9A1hMaVsPCUsLP0imgL9FAVyFh0O/5vlI2jkOMswxrmvONNvOW5wDnnVGiDtppi1VAM997l7Pi0NwWfeNEz84c1XqTduRWMnV83ssHdbquPtEqzVAAzdFrxWBFe7NsdTFC7HifaqcXJFJ6GMLl4mntWWKepEqCCQxjcs1z6AzXIm
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 189892c3-69f6-484f-5c27-08d531de5c2b
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600022)(4604075)(2017052603258); SRVR:CY4PR21MB0469; 
x-ms-traffictypediagnostic: CY4PR21MB0469:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(189930954265078)(219752817060721);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3231022)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0469; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0469; 
x-forefront-prvs: 0499DAF22A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(47760400005)(13464003)(24454002)(199003)(189002)(3280700002)(76176999)(54356999)(22452003)(6116002)(7696004)(4326008)(102836003)(8936002)(33656002)(39060400002)(5660300001)(101416001)(106356001)(966005)(105586002)(25786009)(6246003)(110136005)(97736004)(316002)(2950100002)(478600001)(14454004)(229853002)(2906002)(53936002)(54906003)(3660700001)(50986999)(72206003)(77096006)(8676002)(6306002)(9686003)(6436002)(8990500004)(55016002)(10090500001)(6506006)(10290500003)(93886005)(7736002)(81156014)(575784001)(68736007)(86362001)(305945005)(189998001)(53546010)(74316002)(2900100001)(86612001)(81166006)(99286004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0469; H:CY4PR21MB0120.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 189892c3-69f6-484f-5c27-08d531de5c2b
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2017 19:22:23.9608 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0469
Archived-At: 
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 19:22:28 -0000

The idea was for the client to randomly add non-existent TLS versions to su=
pported_versions.
Presumably, this will exercise the extensibility joint and prevent it from =
becoming unusable.

I'm not convinced this new approach will help, but we know the old one requ=
ired fallbacks every time a new protocol version was introduced.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Yuhong Bao
Sent: Wednesday, November 22, 2017 11:04 AM
To: Peter Saint-Andre ; Eric Rescorla 
Cc: tls@ietf.org; Tapio Sokura 
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness

They are basically doing a supported_versions extension with only one entry=
 in the ServerHello.
The problem with future middleboxes should be obvious.

________________________________________
From: Peter Saint-Andre 
Sent: Wednesday, November 22, 2017 11:02:39 AM
To: Yuhong Bao; Eric Rescorla
Cc: tls@ietf.org; Tapio Sokura
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness

On 11/22/17 11:16 AM, Yuhong Bao wrote:
> The problem is not TLS 1.3, the problem is future versions of TLS.

Would you mind explaining that in more detail?

Peter

_______________________________________________
TLS mailing list
TLS@ietf.org
https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf=
.org%2Fmailman%2Flistinfo%2Ftls&data=3D02%7C01%7CAndrei.Popov%40microsoft.c=
om%7C71d594d28d4241b8757f08d531dbdbb2%7C72f988bf86f141af91ab2d7cd011db47%7C=
1%7C0%7C636469742719473989&sdata=3DfCAZVB8XHK3IJQAoSf%2FUwSDlHYiy2tm0WBktCG=
S%2BPW8%3D&reserved=3D0


From nobody Wed Nov 22 11:30:50 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F21B129C35 for ; Wed, 22 Nov 2017 11:30:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 LhwWR2Y-8IRX for ; Wed, 22 Nov 2017 11:30:45 -0800 (PST)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC92F1296C9 for ; Wed, 22 Nov 2017 11:30:45 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id A162B5DE3E; Wed, 22 Nov 2017 21:30:43 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id znykbiTWkPED; Wed, 22 Nov 2017 21:30:43 +0200 (EET)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 4924627B; Wed, 22 Nov 2017 21:30:41 +0200 (EET)
Date: Wed, 22 Nov 2017 21:30:40 +0200
From: Ilari Liusvaara 
To: Peter Wu , tls@ietf.org
Message-ID: <20171122193040.GA22445@LK-Perkele-VII>
References: <20171122035404.GC18321@al> <1511340124.22935.27.camel@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <1511340124.22935.27.camel@redhat.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] PR to clarify RSASSA-PSS requirements
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Nov 2017 19:30:48 -0000

On Wed, Nov 22, 2017 at 09:42:04AM +0100, Nikos Mavrogiannopoulos wrote:
> On Wed, 2017-11-22 at 03:54 +0000, Peter Wu wrote:
> > Hi,
> > 
> > At the moment there is still ambiguity in the requirements for PSS
> > with
> > relation to certificates. Proposal to clarify this:
> > https://github.com/tlswg/tls13-spec/pull/1098
> > 
> > 
> > This PR intends to clarify the requirements for PSS support.
> 
> Hi,
>  I commented on the PR, but to provide more context. I believe RSA-PSS
> keys without parameters MUST be supported under TLS1.3. The reason is
> that keys explicitly marked as RSA-PSS cannot be used for RSA PKCS#1
> 1.5 encryption, and thus they provide a way for the server to know that
> it must protect that key against (cross-protocol) attacks which utilize
> RSA ciphersuites under TLS1.2.

Furthermore, this would also let the client know that the key itself is
not likely to be subject to DROWN-type issues.

This becomes extremely significant when considering things like
Delegated Credentials (WG document now). E.g., I consider it
unacceptable risk to accept DCs signed with RsaEncryption keys.
_Even_ if the certificate has an additional extension.

> On why you don't want mixing keys for TLS1.3 and TLS1.2 RSA
> ciphersuites, see all the bleichenbacher attack reiterations over the
> years.

There was a rather nasty one just very recently.

> So what about distinguishing the RSA-PSS keys with and without
> parameters:
> 
> "an RSASSA-PSS public key (OID id-RSASSA-PSS) without parameters MUST
> be supported, while an RSASSA-PSS public key (OID id-RSASSA-PSS) with
> parameters MAY be supported`."

+1


-Ilari


From nobody Thu Nov 23 11:42:17 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17AE6126DFE for ; Thu, 23 Nov 2017 11:42:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
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 fHWUMswVV4Lf for ; Thu, 23 Nov 2017 11:42:13 -0800 (PST)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0099.outbound.protection.outlook.com [104.47.34.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C67DA120724 for ; Thu, 23 Nov 2017 11:42:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=58YHeyFZNwTtN+Gd4SxmVr4OkTb2W2oRpfHJKLEnXig=; b=DIptIrP7Htxf5m+kveBL2el8y1wh1/03y6lrd9t9VsLLaPoggkihk2uSL+/ZeCXH+AT/7LPqh8EYxdzNotzP4w0C1TP0OoZoNJQdJ9jPwS3R3ZfGb11ywDwpYT5GY05GL3lC5iHC7J34DmLP1Eckr5JgB3ktCfx0L3uqbjiCbxg=
Received: from CY4PR21MB0120.namprd21.prod.outlook.com (10.173.189.14) by CY4PR21MB0166.namprd21.prod.outlook.com (10.173.192.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Thu, 23 Nov 2017 19:42:12 +0000
Received: from CY4PR21MB0120.namprd21.prod.outlook.com ([10.173.189.14]) by CY4PR21MB0120.namprd21.prod.outlook.com ([10.173.189.14]) with mapi id 15.20.0260.003; Thu, 23 Nov 2017 19:42:12 +0000
From: Andrei Popov 
To: Peter Wu , "Le Van Gong, Hubert" 
CC: "tls@ietf.org" 
Thread-Topic: [TLS] Transcript-Hash during Handshake
Thread-Index: AQHTY0NdZhue01kvP0GuzyEZJSYmNaMfxf+AgAKUW4A=
Date: Thu, 23 Nov 2017 19:42:12 +0000
Message-ID: 
References: <94ced158-63b1-e7a3-024c-44d1149e7202@levangong.org> <20171122035915.GD18321@al>
In-Reply-To: <20171122035915.GD18321@al>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:3::4ca]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0166; 6:dRgKSFU5sIz91yrA8lxI1zLdR+L2pd1bUjWzbeFKriXihZnU78n4/KPzL2XFs74RdJK1MZfw8NN3H6ncpB+qkKtsy3uh199EOBfpJ4grKJFztGkzmc8VjAkEq5zNFkL1HBwueoYtPiyafbRsZmcLKFoLQJ/FA1ia4gs4kKVK7RqG26lulYZ3v5m2cfFw/MWo4L7weAB9qfBZy7RIqGn3n9yjomvzPwNVVNu3GMETXVnlc5DHZ7sdPBBuLYPafqGOADEH76UIhwsPaRKWeW5q8jHS6Edf2m5+wDFRqvWqPHAFLNjElykfzG8W9vE6ePNYEygWOflD/wtoKIV+w6U0BCnMBsSwB05ZDRinVyuN4D4=; 5:mzZeHvqV2t9cswzkklER/g0Hvlk6wCUNPnPtjqBPMZoCrhfkQ/GU5XSSjo7B6xjSwMN0HYXWGQ/5OpVQJDWD/nQOj1pO5jxk3H00n+rl/Ut+U4tKd+FnZGWUBdhP0uiYB2xvaprsFcIPUlzuvN7ZV4TPZuOm7SAU0VpNillYMw0=; 24:KcUfZOfcI/D+vQRn2EgSlVW3OBWHCaQtrp9NQXUcn85FnEParEgVYcHFNMavh80XhakcpCWdgKpiiyE/sKQtqJmmhaYwkAY8Z9L9WIXvgrQ=; 7:b6J1N3J4MDA2FAh4/4x7KM9xd97uDdgiKDnYt9MO+DAudb/07u+2ErbT+i6xZsHV/wR2rS7OQlCmPd6Ah0VX6nNwFHMKsTWMAjmYZ7HC/j+T/H3Qdexs9K/4BkynaZmwe1Dbq9lQBK0zMv+GTlhxRHKedKOezEJXlRMQyNYrmtWeAyWdY1PSwXIl6P/zdsG7KqfsY/ObO7lSDvsz+dtKhaz5SuYfmDe/dnxxYagjll8E+lgQ9t9Th+AvM1HmQVA6
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 8202de05-ce35-4ebf-d630-08d532aa4b00
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(5600025)(4604075)(2017052603258); SRVR:CY4PR21MB0166; 
x-ms-traffictypediagnostic: CY4PR21MB0166:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(189930954265078)(219752817060721);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(93006095)(93001095)(3231022)(10201501046)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0166; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0166; 
x-forefront-prvs: 05009853EF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(366004)(346002)(376002)(39860400002)(47760400005)(199003)(13464003)(24454002)(189002)(81156014)(8676002)(2906002)(81166006)(99286004)(2900100001)(53936002)(6246003)(105586002)(22452003)(102836003)(316002)(101416001)(7696005)(3660700001)(110136005)(97736004)(3280700002)(305945005)(86362001)(575784001)(189998001)(7736002)(6116002)(10090500001)(74316002)(86612001)(478600001)(966005)(72206003)(55016002)(53546010)(25786009)(4326008)(8990500004)(6436002)(10290500003)(14454004)(229853002)(76176999)(33656002)(68736007)(6306002)(9686003)(106356001)(50986999)(54356999)(6506006)(8936002)(77096006)(2950100002)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0166; H:CY4PR21MB0120.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8202de05-ce35-4ebf-d630-08d532aa4b00
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2017 19:42:12.5405 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0166
Archived-At: 
Subject: Re: [TLS] Transcript-Hash during Handshake
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Nov 2017 19:42:16 -0000

To confirm, TLSInnerPlaintext.type and TLSInnerPlaintext.zeros are not part=
 of the handshake messages, and therefore are not included in the transcrip=
t hash?

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Peter Wu
Sent: Tuesday, November 21, 2017 7:59 PM
To: Le Van Gong, Hubert 
Cc: tls@ietf.org
Subject: Re: [TLS] Transcript-Hash during Handshake

Hi Hubert,

On Tue, Nov 21, 2017 at 07:38:16PM -0800, Le Van Gong, Hubert wrote:
> Greetings,
>=20
> Probably a trivial question but is the transcript hash (during=20
> handhsake) calculated over decrypted versions of messages like=20
> EncryptedExtensions or certificate or is it done over the raw/encrypted m=
essages?
> I could not find an exact confirmation in the spec.

It covers the decrypted handshake messages, see
https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ie=
tf.org%2Fhtml%2Fdraft-ietf-tls-tls13-21%23section-4.4.1&data=3D02%7C01%7CAn=
drei.Popov%40microsoft.com%7C5f27ddaec3b4434c6d8c08d5315d6d6b%7C72f988bf86f=
141af91ab2d7cd011db47%7C1%7C0%7C636469199703666199&sdata=3DKKJRCPF%2BNTbh0L=
GMZG2zRZQW9NK8tgeP1Ws07n4Wanc%3D&reserved=3D0

    This value is computed by hashing the concatenation
    of each included handshake message, including the handshake message
    header carrying the handshake message type and length fields, but not
    including record layer headers

(The only way to know the message type is to have it in cleartext.)
--
Kind regards,
Peter Wu
https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Flekenste=
yn.nl&data=3D02%7C01%7CAndrei.Popov%40microsoft.com%7C5f27ddaec3b4434c6d8c0=
8d5315d6d6b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636469199703666199=
&sdata=3DaRZZ0GYkqQEaHN1lsEXjAjetzsXgfnRiITpqulNoFYk%3D&reserved=3D0

_______________________________________________
TLS mailing list
TLS@ietf.org
https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf=
.org%2Fmailman%2Flistinfo%2Ftls&data=3D02%7C01%7CAndrei.Popov%40microsoft.c=
om%7C5f27ddaec3b4434c6d8c08d5315d6d6b%7C72f988bf86f141af91ab2d7cd011db47%7C=
1%7C0%7C636469199703666199&sdata=3DIDfdpwgg1JsBr%2BijxbZvRRzVVb5i5D3aIuEtti=
R0eDk%3D&reserved=3D0


From nobody Thu Nov 23 11:52:06 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0980C127005 for ; Thu, 23 Nov 2017 11:52:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 yj1Her5vBawX for ; Thu, 23 Nov 2017 11:52:03 -0800 (PST)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75E1E120724 for ; Thu, 23 Nov 2017 11:52:03 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id D32965DE4A; Thu, 23 Nov 2017 21:52:01 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id Zz56rfDZ8K3E; Thu, 23 Nov 2017 21:52:01 +0200 (EET)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 82870C4; Thu, 23 Nov 2017 21:51:57 +0200 (EET)
Date: Thu, 23 Nov 2017 21:51:57 +0200
From: Ilari Liusvaara 
To: Andrei Popov 
Cc: Peter Wu , "Le Van Gong, Hubert" , "tls@ietf.org" 
Message-ID: <20171123195157.GB28646@LK-Perkele-VII>
References: <94ced158-63b1-e7a3-024c-44d1149e7202@levangong.org> <20171122035915.GD18321@al> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.9.1 (2017-09-22)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] Transcript-Hash during Handshake
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Nov 2017 19:52:05 -0000

On Thu, Nov 23, 2017 at 07:42:12PM +0000, Andrei Popov wrote:
> To confirm, TLSInnerPlaintext.type and TLSInnerPlaintext.zeros are
> not part of the handshake messages, and therefore are not included
> in the transcript hash?

Correct. The transcript hash is also not affected by fragmentation.

E.g. in TLS 1.3, the raw finished messag fed to SHA-256 is always
14 00 00 20 <32 bytes payload>. Regardless of padding and
fragmnentation (for SHA-384, that would be 14 00 00 30 <48 bytes
payload>).

(In DTLS, the header would be different and larger, but also
not affected by padding and fragmentation).


-Ilari


From nobody Thu Nov 23 11:59:02 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C083120727 for ; Thu, 23 Nov 2017 11:59:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
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 0Ri_eY9KuaBa for ; Thu, 23 Nov 2017 11:59:01 -0800 (PST)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0095.outbound.protection.outlook.com [104.47.32.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8C2A120724 for ; Thu, 23 Nov 2017 11:59:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=U+wqws17vInuxDnz/BFHX1jPYf3zVDpEmJCrihH+9CE=; b=LUKTlauUYLuEi3jCgvfcS9gABeQN+8DsCP+pGcnunqE2e3RjPSa09FAjsHNsIXK4zqqBY5RBxGQIfNEyw72Wh2fUUmbduCM5NUJA8IBzBd2Gx5HcMu7z3Qh2qMIUesB9jkX8IqYpePiHRYVzap320UPpYUVRdO+3Rya2O5o9AEA=
Received: from CY4PR21MB0120.namprd21.prod.outlook.com (10.173.189.14) by CY4PR21MB0277.namprd21.prod.outlook.com (10.173.193.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Thu, 23 Nov 2017 19:58:57 +0000
Received: from CY4PR21MB0120.namprd21.prod.outlook.com ([10.173.189.14]) by CY4PR21MB0120.namprd21.prod.outlook.com ([10.173.189.14]) with mapi id 15.20.0260.003; Thu, 23 Nov 2017 19:58:56 +0000
From: Andrei Popov 
To: "ilariliusvaara@welho.com" 
CC: Peter Wu , "Le Van Gong, Hubert" , "tls@ietf.org" 
Thread-Topic: [TLS] Transcript-Hash during Handshake
Thread-Index: AQHTY0NdZhue01kvP0GuzyEZJSYmNaMfxf+AgAKUW4CAAAgogIAAAWxw
Date: Thu, 23 Nov 2017 19:58:56 +0000
Message-ID: 
References: <94ced158-63b1-e7a3-024c-44d1149e7202@levangong.org> <20171122035915.GD18321@al>  <20171123195157.GB28646@LK-Perkele-VII>
In-Reply-To: <20171123195157.GB28646@LK-Perkele-VII>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:3::4ca]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0277; 6:bTM+m7v05rtqlRP1a8QJvZLMWSl4iq4eMjAaoux/iHlMO8wr1efyfCx+7MgXJm57A/zEhDI6PkF139B6zFlmlIa/9YSNBtnKERkQzU3jTclTdLEfmTC3YDt7eB69LTeXgx4ipYNm4RlywZfCXcbJmUdMbkVaSsBxnWs0MfYebo7UgA8Vt+VZnZk3/H1EGXpOzGsMNCuIhMMwwkNjKD20mZxPlNwTyD6nWqaq/aa18ik3JlLWE3aaK+nx1HgZ7RsX+xQ5rLzkF/PJYs2GuZRDEFwi4U5IegLSAnKPDWg+zkjw+oaHPExIexl3fAmKUdmqktx3txkBy0jHwBZvQpo7eW/Uzo1GCwW5smLUDbEIWGg=; 5:ndEwUZFtTyqXyeQh9EFhqff/3acNlLyFNfHWMTwIsNL1umCgo9t9JLN/IO1kGClZnUVNPVDiC7bz4sJ/QhLsXsRbf202ZaCOG7SuX7vNil8dMvMSfivRtrKcKE2smDriZT/E6fqIH9iSYE4gKliAka3ajSGXp0o+pk72644pqMw=; 24:0qg9cqmCtgSExXK2Ud1AxV4BHBU412/bOHTWhCZIUgC0M39kDHlj+Z1Vx+32JDSJEBPL36whhqv/UcBc8DaOqelEAOLwXM+Rxnxnf1sL3RE=; 7:ETPokg+sAvpYBYUWXIPglrlSw3FwarWCzJrvlYzQDfsw1jFjEoV6CRfzLcbpD8vdMifizGKFJm7/A20Fa2OaxaoYYA8LBTO/vtmzRBKG6fCVdrx8bAM0CYPoyug5D/6x/q5ipSlm0Po+Mdf1AOqLGzNRkMtpjKBufGngSY1mT1eM6EkHrpVUUVrSk1FgvxmA4mFukUDMouFiPzD80zvL7CE6vonkthGFcw/earr8aDp8LBACP4meFfpEl5lCk3i7
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 1f69d41b-5dba-4b92-ffaa-08d532aca198
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(5600025)(4604075)(2017052603258); SRVR:CY4PR21MB0277; 
x-ms-traffictypediagnostic: CY4PR21MB0277:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(89211679590171);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3231022)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0277; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0277; 
x-forefront-prvs: 05009853EF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(366004)(346002)(376002)(47760400005)(189002)(199003)(24454002)(13464003)(53936002)(229853002)(7736002)(81156014)(1730700003)(8676002)(305945005)(74316002)(25786009)(99286004)(97736004)(22452003)(316002)(93886005)(10090500001)(101416001)(86612001)(76176999)(50986999)(86362001)(6916009)(54356999)(81166006)(77096006)(55016002)(5640700003)(6506006)(6436002)(6246003)(4326008)(5660300001)(9686003)(2950100002)(2900100001)(33656002)(106356001)(189998001)(105586002)(2351001)(72206003)(478600001)(53546010)(2501003)(54906003)(10290500003)(14454004)(8936002)(6116002)(102836003)(8990500004)(3280700002)(68736007)(3660700001)(2906002)(7696005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0277; H:CY4PR21MB0120.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1f69d41b-5dba-4b92-ffaa-08d532aca198
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2017 19:58:56.8309 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0277
Archived-At: 
Subject: Re: [TLS] Transcript-Hash during Handshake
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Nov 2017 19:59:02 -0000

VGhhbmtzLCBJbGFyaSENCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlsYXJp
bGl1c3ZhYXJhQHdlbGhvLmNvbSBbbWFpbHRvOmlsYXJpbGl1c3ZhYXJhQHdlbGhvLmNvbV0gDQpT
ZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMjMsIDIwMTcgMTE6NTIgQU0NClRvOiBBbmRyZWkgUG9w
b3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPg0KQ2M6IFBldGVyIFd1IDxwZXRlckBsZWtl
bnN0ZXluLm5sPjsgTGUgVmFuIEdvbmcsIEh1YmVydCA8aHViZXJ0QGxldmFuZ29uZy5vcmc+OyB0
bHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVExTXSBUcmFuc2NyaXB0LUhhc2ggZHVyaW5nIEhh
bmRzaGFrZQ0KDQpPbiBUaHUsIE5vdiAyMywgMjAxNyBhdCAwNzo0MjoxMlBNICswMDAwLCBBbmRy
ZWkgUG9wb3Ygd3JvdGU6DQo+IFRvIGNvbmZpcm0sIFRMU0lubmVyUGxhaW50ZXh0LnR5cGUgYW5k
IFRMU0lubmVyUGxhaW50ZXh0Lnplcm9zIGFyZSBub3QgDQo+IHBhcnQgb2YgdGhlIGhhbmRzaGFr
ZSBtZXNzYWdlcywgYW5kIHRoZXJlZm9yZSBhcmUgbm90IGluY2x1ZGVkIGluIHRoZSANCj4gdHJh
bnNjcmlwdCBoYXNoPw0KDQpDb3JyZWN0LiBUaGUgdHJhbnNjcmlwdCBoYXNoIGlzIGFsc28gbm90
IGFmZmVjdGVkIGJ5IGZyYWdtZW50YXRpb24uDQoNCkUuZy4gaW4gVExTIDEuMywgdGhlIHJhdyBm
aW5pc2hlZCBtZXNzYWcgZmVkIHRvIFNIQS0yNTYgaXMgYWx3YXlzDQoxNCAwMCAwMCAyMCA8MzIg
Ynl0ZXMgcGF5bG9hZD4uIFJlZ2FyZGxlc3Mgb2YgcGFkZGluZyBhbmQgZnJhZ21uZW50YXRpb24g
KGZvciBTSEEtMzg0LCB0aGF0IHdvdWxkIGJlIDE0IDAwIDAwIDMwIDw0OCBieXRlcw0KcGF5bG9h
ZD4pLg0KDQooSW4gRFRMUywgdGhlIGhlYWRlciB3b3VsZCBiZSBkaWZmZXJlbnQgYW5kIGxhcmdl
ciwgYnV0IGFsc28gbm90IGFmZmVjdGVkIGJ5IHBhZGRpbmcgYW5kIGZyYWdtZW50YXRpb24pLg0K
DQoNCi1JbGFyaQ0K


From nobody Thu Nov 23 13:18:26 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11D1127275 for ; Thu, 23 Nov 2017 13:18:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 WsRCE67P2hQ6 for ; Thu, 23 Nov 2017 13:18:22 -0800 (PST)
Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 B6A501243F6 for ; Thu, 23 Nov 2017 13:18:15 -0800 (PST)
Received: by mail-wr0-x232.google.com with SMTP id w95so18679512wrc.2 for ; Thu, 23 Nov 2017 13:18:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=xKzWRKHb+0VsUQzPlbSo6KdxSUvJ1OG/Kr56a+uZPNc=; b=VMJY96nHNWvDapiaDirOZi4a+7v+JirgGZlnY/oeo4wCIfuu8zc2t1hQLfBRSEgr+3 U9ufnTPeG5rsR4rPGl9lKNmoEfbKwenVG8t5MVU98emPMhZNuCzbEZ7G5JLEwmoz9mrO ljuT/8yQIcqwaOg4BOglLan5tAfrKCQ6a0xQ0I0odoU/Al1JqLv72zvfDSjJWHMBHz2b AoBEROzF6onENLB7HlyEglGsuJ6Mb3gm/kcr56x1vdNBalKZz6k1gIi65xGSCTZEjlVX oc3540h9J174OaHJxT46rt4X2QF2VaoYLbsf1vsJquY/R69EC45GtWGTy14S5Mxb/fD5 z6Wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xKzWRKHb+0VsUQzPlbSo6KdxSUvJ1OG/Kr56a+uZPNc=; b=DNTlcwHN3nCTp3Z4pVeeO7FnovLEFUR6uWE1h1LWaNoKCLCeedp0e7JOWDX7yFhGW2 RywH5kHpUVk7AaIY9wVU1mIgzdTApvRseFEWBKv9PKcq6Zxc2e+Y7mZpj0b0B2lzitsg /HQ9N8wg9uj8Fur4PNY4z6hC8EsqmZRYSokz1Hj3A/FAorHE5FRK4sTdKGlFNZPkEPTa bgOEivvjotfqNT0lsm12juC2WT2ZrIa0s6Y122w0a/kG02iwFXJQlqb1xyOGEv3ZGB3k HtAVDTofBbpGMfSetr9thRX1OGg3ZBjfDbLJ2zRVOSJEM9NV94etHACoLwgiIVoc3bFC c4OA==
X-Gm-Message-State: AJaThX6MRGapTen1JJQStVbd8063UmBVZ4IvWf3NXK8KYKVCJ835RXnA ACzBZqckWfPqvYl+oXnOThxFGa+qsPysGpSfDL8=
X-Google-Smtp-Source: AGs4zMYUT4uSOGNp/R8QnKprCa2SW3rGAz0x1PyLncMV0fUHGm9+9LjNMlng2cL5PtPdETM4nUApPA4aORSCD12hk3Q=
X-Received: by 10.223.135.3 with SMTP id a3mr21385846wra.109.1511471894081; Thu, 23 Nov 2017 13:18:14 -0800 (PST)
MIME-Version: 1.0
From: Nick Sullivan 
Date: Thu, 23 Nov 2017 21:18:03 +0000
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11491a5e55b83e055eacf9bc"
Archived-At: 
Subject: [TLS] Exported Authenticators proposed change to incorporate authenticator request
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Nov 2017 21:18:24 -0000

--001a11491a5e55b83e055eacf9bc
Content-Type: text/plain; charset="UTF-8"

Martin Thomson raised an issue Github (Issue #5
) suggesting
that we modify the exported authenticators draft to include the ability to
incorporate a CertificateRequest into an authenticator. I have put together
a set of changes to the draft to incorporate this suggestion:
https://github.com/tlswg/tls-exported-authenticator/pull/9

The advantage of this change is that it provides a more explicit binding
between a request for an authenticator (which includes TLS extensions) and
the authenticator itself. This change also significantly simplifies the HTTP/2
Additional Certificates draft

that depends on exported authenticators. I presented this change at IETF
100 and there were no objections.

Comments welcome,
Nick

--001a11491a5e55b83e055eacf9bc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Martin Thomson raised an issue Github (Issue #5) suggesting that we modify the exported authenticators draft to i=
nclude the ability to incorporate a CertificateRequest into an authenticato=
r. I have put together a set of changes to the draft to incorporate this su=
ggestion:
https://github.com/tlswg/tls-exported-authenticator/pull/9

The advantage of this change is that it provides a mor=
e explicit binding between a request for an authenticator (which includes T=
LS extensions) and the authenticator itself. This change also significantly=
 simplifies the HTTP/2 Additional Certificates draft that d=
epends on exported authenticators. I presented this change at IETF 100 and =
there were no objections.

Comments welcome,
<=
div>Nick

=C2=A0


=




--001a11491a5e55b83e055eacf9bc--


From nobody Fri Nov 24 11:21:55 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66964126FB3 for ; Fri, 24 Nov 2017 11:21:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.875
X-Spam-Level: 
X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com
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 FZInVaZSlCaz for ; Fri, 24 Nov 2017 11:21:51 -0800 (PST)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-oln040092004064.outbound.protection.outlook.com [40.92.4.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BC141200C5 for ; Fri, 24 Nov 2017 11:21:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Gzs9v948gfF7mFMTN6UbAo5SRt0ClWvl+rlvkRXSPEc=; b=M9dRNiCpwvNasmfZnRWspYGmmDJ+Ulbtno7EVGppPtzbdwIDE3lLzUDU9dgF2bmM55EDflVOUEumc35bpS/PSdEZdKm/jz4mJ6IyxlhZ+aKqBj4mqwc81OJG0FT2QUeqrj8GVfJIul3TqyVuGM8wzf3+vxoVAcN8UNdP3E9yBsLL/StKnlcRF/CH45mL1s9HsizjGwpROpnGV4DnDcjQAaS18LVP5hHh9yboKj3sr3zs6OjkQ26CfTcikTDQmv5TFWCQAmbp592ykyeDmTSgTA33EYT+EMLgTrXzJ8ZcN0Xi9an6dfnVZTDt4+BQzy0SN9Vi1gBIGWw2ZbkU78gEfA==
Received: from BL2NAM02FT037.eop-nam02.prod.protection.outlook.com (10.152.76.60) by BL2NAM02HT182.eop-nam02.prod.protection.outlook.com (10.152.77.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Fri, 24 Nov 2017 19:21:49 +0000
Received: from MWHPR1801MB2061.namprd18.prod.outlook.com (10.152.76.53) by BL2NAM02FT037.mail.protection.outlook.com (10.152.77.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.239.4 via Frontend Transport; Fri, 24 Nov 2017 19:21:49 +0000
Received: from MWHPR1801MB2061.namprd18.prod.outlook.com ([10.164.205.38]) by MWHPR1801MB2061.namprd18.prod.outlook.com ([10.164.205.38]) with mapi id 15.20.0239.009; Fri, 24 Nov 2017 19:21:49 +0000
From: Yuhong Bao 
To: Andrei Popov , Peter Saint-Andre , Eric Rescorla 
CC: "tls@ietf.org" , Tapio Sokura 
Thread-Topic: [TLS] PR#1091: Changes to provide middlebox robustness
Thread-Index: AQHTVyvb2MH+ZKktR0KvrQ+TnVw5FaMfyD2AgACtqICAAFERW4AABkQAgAAAXoGAAAz+gIAAADWvgAAFT4CAAyRyIg==
Date: Fri, 24 Nov 2017 19:21:49 +0000
Message-ID: 
References:  <389abe54-41d3-30e9-4cca-caa8b1469ae7@iki.fi>    ,  , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-incomingtopheadermarker: OriginalChecksum:0242788D961FB0C3FD410C29E13DA9519170AAA497870702460C42E165C87277; UpperCasedChecksum:C76A54C556BA1C0059BD0129EE965F02F2EA634E18F9FDA478E74D2ECCCA7616; SizeAsReceived:7990; Count:47
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [YhoYSOVQp9zSsyLx8rEwif+QY8Z78R6NYwwjQfO4Aj7VQ9LHYgo2ppFM4954ed0F]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BL2NAM02HT182; 6:M/zaSXBbRE29CjUx5L2Xrh9izJjY3HupHod4lO7UU9RaN09mI1+etBe1N1ACvfqnwmwbOz3l/9l8M3qUEZC8zaoX2HeZjrwwKNjc5VcReH24YjSsITtXEA+kKid1WJ7NFPhGfi6aeprITa1/J/ePPJN37VBlIPm5GdyMh4tsrl3VO80xsy84DnH60NnXhx3269NWNZX5QZGDkRLQwgXWzEF9TnnphzjWWCuKVKioM5YCdbFDTL/Uiq5s+U8G+XtrNr4PT2k6TsK6Wrk7W7OBsW9IUiQMnrc+AhDQX7QGzQ8vjXZ8no5rwR4Y+SlJWbzKYw+ryL63QPnR5Wvlta9lMJct6Jv63XtFbMtLtaIOEz4=; 5:RbpZ7j/otgBmrhTjldpPYBe28a9Cmp7Fdj0Rxi1GSPw0KEwTQSZxUiIEEwhJk759LHPJ+nwzyf4zuzBREMfZhkp9/3TFie7qlgz8VP0jJUpOcx14Buef+bpYM8IsVtjb+uutT2jgi73UYxvEfuGtFjOdoqexTnQcDsMLoYIC/VA=; 24:hW+NuF7v/CCJxcC82qxRYYF1zAvNc6ebSA3jL11tA0jMjfoD+L7Sv/e/3cTjdrqe4BHsFVUmOJKJfy6uQXnjMYPzYkaPh1dDsiZtRm+S5Wo=; 7:C7shq4skaHb9Ej142g/aJDNGNXIBDcFkwJBhi57iubcGItojwg5h4I+hq2yZB5cKDQjJosRKWLBk04m1tGEHDW8H7QJKGH6az1uqEVRmmBdtDabhbEsmsevlkRIHTiv+ELieL4OXy+OwhvIf/mahIx8p3yUsW4d99wuADCFo3ko52sXIe6SqKnZeV67BCwA9+skWdjh/ORhxq+q19ykQlpmfuXggg4tOEAGdv3sZ83GBiGsVrjJBKcVjSz7Hhqrm
x-incomingheadercount: 47
x-eopattributedmessage: 0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:BL2NAM02HT182; 
x-ms-traffictypediagnostic: BL2NAM02HT182:
x-ms-office365-filtering-correlation-id: f0911c84-3f74-4bdf-cbdd-08d533709c8b
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031); SRVR:BL2NAM02HT182; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BL2NAM02HT182; 
x-forefront-prvs: 05015EB482
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:BL2NAM02HT182; H:MWHPR1801MB2061.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f0911c84-3f74-4bdf-cbdd-08d533709c8b
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Nov 2017 19:21:49.8085 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2NAM02HT182
Archived-At: 
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Nov 2017 19:21:53 -0000

That only applies to the ClientHello.

________________________________________
From: Andrei Popov 
Sent: Wednesday, November 22, 2017 11:22:23 AM
To: Yuhong Bao; Peter Saint-Andre; Eric Rescorla
Cc: tls@ietf.org; Tapio Sokura
Subject: RE: [TLS] PR#1091: Changes to provide middlebox robustness

The idea was for the client to randomly add non-existent TLS versions to su=
pported_versions.
Presumably, this will exercise the extensibility joint and prevent it from =
becoming unusable.

I'm not convinced this new approach will help, but we know the old one requ=
ired fallbacks every time a new protocol version was introduced.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Yuhong Bao
Sent: Wednesday, November 22, 2017 11:04 AM
To: Peter Saint-Andre ; Eric Rescorla 
Cc: tls@ietf.org; Tapio Sokura 
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness

They are basically doing a supported_versions extension with only one entry=
 in the ServerHello.
The problem with future middleboxes should be obvious.

________________________________________
From: Peter Saint-Andre 
Sent: Wednesday, November 22, 2017 11:02:39 AM
To: Yuhong Bao; Eric Rescorla
Cc: tls@ietf.org; Tapio Sokura
Subject: Re: [TLS] PR#1091: Changes to provide middlebox robustness

On 11/22/17 11:16 AM, Yuhong Bao wrote:
> The problem is not TLS 1.3, the problem is future versions of TLS.

Would you mind explaining that in more detail?

Peter

_______________________________________________
TLS mailing list
TLS@ietf.org
https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf=
.org%2Fmailman%2Flistinfo%2Ftls&data=3D02%7C01%7CAndrei.Popov%40microsoft.c=
om%7C71d594d28d4241b8757f08d531dbdbb2%7C72f988bf86f141af91ab2d7cd011db47%7C=
1%7C0%7C636469742719473989&sdata=3DfCAZVB8XHK3IJQAoSf%2FUwSDlHYiy2tm0WBktCG=
S%2BPW8%3D&reserved=3D0


From nobody Fri Nov 24 12:32:59 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D74A127B31 for ; Fri, 24 Nov 2017 12:32:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 eQdH1tImcGuE for ; Fri, 24 Nov 2017 12:32:57 -0800 (PST)
Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (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 270C6127ABE for ; Fri, 24 Nov 2017 12:32:57 -0800 (PST)
Received: by mail-yw0-x232.google.com with SMTP id j198so9918733ywg.9 for ; Fri, 24 Nov 2017 12:32:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=0Nfc2zHn9MS9hWUjcVGJ+YU8n/dNl0WY9l5yukl4Td8=; b=jl7rtrzaHMmKhx1naHlAhn+0nPkYl22aVmADRk63cETJhkpS2WORXZKGenPqp2LOuX pEwB5gS9f70CzKU/PaRDceLujD7cmODhbyxT65Cb39nUNgCXvzUBRtKFrER+YravwKgN KoH4LV2Z8vazWb2j5yQy4HgZcHJbK1dW3vsJbV034FzABRrfezib0XUgIHmZ/4Is65MP McmelTfyt6Y5p6CRefkb6mXtXHZbxXFUMlz2EQQsCdhqcx2vSujhqWW1GfRV6GZVce8D qVNNb5TEm2maW5ZqEsUNTxob/gW/n5IdGZss4cUg4PSmyT2XJieY1biZAZBoDGfJEtw+ IU0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0Nfc2zHn9MS9hWUjcVGJ+YU8n/dNl0WY9l5yukl4Td8=; b=Hus1Vl9Mtd7SS8fyEAdqrgxgPiI8HON/17gUhEGl78FmITHWLp+pDMSy2yagYSsjCd ktTtSpZwB53R1L/ZQwWBuRKuJ76k6wJWvscZizqb/wLHOUU/WuJ0MOlJkbrw2pDkQwox FRmXshmjDo22uAyINkA4N3g9ulk4imeVa0Sc8EpvVb5ChKpQkHI2dmOFBv07lAH4InoX 8VvTVcV2Yq29sdIlOzT8epZQvNU40ljlZAiuPJhK4cg76DHVVeiJ18HZBfd9ogQMSn44 3mMxBPBRDH+ysw9vhzkT3zhAq1HlQkUMrg9uEVjU/yf+KN3NBzOCZFXwXMrRU82MG2g+ ti4g==
X-Gm-Message-State: AJaThX4ADwV6FM6TuRcV5XYa7cWaUP4ciQi53thWqC9q57QovHDXt69e kXDOKv1xRAlMz+I+8O4zJLseThM2OP08YAnetvnx7v0Faj0=
X-Google-Smtp-Source: AGs4zMZbm2SOZ98UDJO2H8iTYNbiAomu4aeqdqukAj36w32CY7aT6q8VL3+0NAQzr2R5hmAfhHI8bmv22mFymd16n1Y=
X-Received: by 10.129.85.198 with SMTP id j189mr19182335ywb.504.1511555576096;  Fri, 24 Nov 2017 12:32:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.123.132 with HTTP; Fri, 24 Nov 2017 12:32:15 -0800 (PST)
From: Eric Rescorla 
Date: Fri, 24 Nov 2017 12:32:15 -0800
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a113f169e2bfe44055ec075d8"
Archived-At: 
Subject: [TLS] Update on middlebox measurements in Firefox
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Nov 2017 20:32:58 -0000

--001a113f169e2bfe44055ec075d8
Content-Type: text/plain; charset="UTF-8"

Hi folks,

As I mentioned last week, we will be testing the changes in PR#1091 in
Firefox. Here's an update on that. We are doing two tests:

- The original Google test ("7e02") which is (mostly) PR#1091 applied
  to draft-18, using Firefox Beta.

- draft-22 (as soon to be published) using Firefox Nightly.

The first of these tests will go out today or Monday and will run for
a week or so while we collect the data. For the second, we're landing
the draft-22 code in Nightly early next week, and plan to start the
tests mid next week.

I will provide further updates next week when we should have more data.

-Ekr

--001a113f169e2bfe44055ec075d8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi folks,

As I mentioned las=
t week, we will be testing the changes in PR#1091 in
Firefox. Her=
e's an update on that. We are doing two tests:

- The original Google test ("7e02") which is (mostly) PR#1091 ap=
plied
=C2=A0 to draft-18, using Firefox Beta.
=C2=A0=C2=
=A0
- draft-22 (as soon to be published) using Firefox Nightly.

The first of these tests will go out today or Monda=
y and will run for
a week or so while we collect the data. For th=
e second, we're landing
the draft-22 code in Nightly early ne=
xt week, and plan to start the
tests mid next week.
I will provide further updates next week when we should have mo=
re data.

-Ekr


<=
div>



=C2=A0=C2=
=A0


--001a113f169e2bfe44055ec075d8--


From nobody Mon Nov 27 19:44:08 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB20129353 for ; Mon, 27 Nov 2017 19:44:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 xScQo0A0t_qV for ; Mon, 27 Nov 2017 19:44:05 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD5911201F2 for ; Mon, 27 Nov 2017 19:44:05 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id CCDBCB80D43; Mon, 27 Nov 2017 19:43:55 -0800 (PST)
To: ekr@rtfm.com, nagendra@cs.stanford.edu, Kathleen.Moriarty.ietf@gmail.com,  ekr@rtfm.com, joe@salowey.net, sean+ietf@sn3rd.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: chenwumao@hisilicon.com, tls@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20171128034355.CCDBCB80D43@rfc-editor.org>
Date: Mon, 27 Nov 2017 19:43:55 -0800 (PST)
Archived-At: 
Subject: [TLS] [Technical Errata Reported] RFC6347 (5186)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 03:44:07 -0000

The following errata report has been submitted for RFC6347,
"Datagram Transport Layer Security Version 1.2".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5186

--------------------------------------
Type: Technical
Reported by: Chen Wumao 

Section: 4.2.4

Original Text
-------------
[p17]                                                 In order to avoid
   sequence number duplication in case of multiple HelloVerifyRequests,
   the server MUST use the record sequence number in the ClientHello as
   the record sequence number in the HelloVerifyRequest.

[p17]                  In order to avoid sequence number duplication in
   case of multiple cookie exchanges, the server MUST use the record
   sequence number in the ClientHello as the record sequence number in
   its initial ServerHello. 

Corrected Text
--------------
[p17]                                                 In order to avoid
   sequence number duplication in case of multiple HelloVerifyRequests,
   the server MUST use the message_seq in the ClientHello as
   the message_seq in the HelloVerifyRequest.

[p17]                  In order to avoid sequence number duplication in
   case of multiple cookie exchanges, the server MUST use the 
   message_seq in the ClientHello as the message_seq in
   its initial ServerHello. 

Notes
-----
the "record sequence number" here should be message_seq.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6347 (draft-ietf-tls-rfc4347-bis-06)
--------------------------------------
Title               : Datagram Transport Layer Security Version 1.2
Publication Date    : January 2012
Author(s)           : E. Rescorla, N. Modadugu
Category            : PROPOSED STANDARD
Source              : Transport Layer Security
Area                : Security
Stream              : IETF
Verifying Party     : IESG


From nobody Mon Nov 27 20:01:03 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD19129426 for ; Mon, 27 Nov 2017 20:01:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 tnrmKPAtXe8s for ; Mon, 27 Nov 2017 20:00:59 -0800 (PST)
Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (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 28A081200F1 for ; Mon, 27 Nov 2017 20:00:59 -0800 (PST)
Received: by mail-yb0-x22a.google.com with SMTP id q84so8332689ybc.10 for ; Mon, 27 Nov 2017 20:00:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a6lsDWaclYfLfJ69cyPWv+vYOigz4Vff36Pqygiz24M=; b=ZUDU6gz/4a3eqYN525Lz6rXr3xGJbcEzJJPVM3cYUrejd+hlyUscHoptMT8aCy7yOU BPPdEyS4dKBhw0zcXsmuodQwSNY5qAYsPY1XSzMuvfIQY2sOScnNkLogjATZOl7CQlO5 XL+Qx0q5Lm74P2gA3Pt0fMwziAYoX0OAzDVkOupU4opUYmSJwKF7FvO98cFL/9JIa7u7 0fIX4FYPBGpyEqrr3vsvkiPjFn7LFcknFuHsE+DbldUK1oQr5Zs2CC01IaAZecMAwlMW USQIFIPseaKfq+5O9KGo9/4QWRRqL/AG4hze1ZhcABQAUpGsHChGnI15CcX7smzKyhMg /KOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=a6lsDWaclYfLfJ69cyPWv+vYOigz4Vff36Pqygiz24M=; b=XywvYRCqhtgZ4bczYx9FY3J6O7m9g+zlNGr9o/S43uOyaLpfp2+oad/rBX4EfJlef9 QlXzTGxpYBbGcmvyOzPBgIW8AhKXcHLMLT6pzvikuSDNgnq1CpR0MZSBXIpWfKfDlgpw EX6TXYnstvWKUpqGwoW/8t1b9mr9C163pKaH5+d7OZetBqj/zLtMifyPtrkLE4i8i1ma cs3asnNc0jEFEvY9f0caaQFSxeOZuQT3MrBECWPDnl+JsYjn4MZ6RHyP77CZQyf5gB6b rbgO/zjHXWfHBUbxGFlTZCWR2leNg478WOdjE3KOmAfnZ9991pAMenh5hVHn5zkng3T+ N9jw==
X-Gm-Message-State: AJaThX7SALTq73lro+ixxFXN4Hiq+DUf0BSlWRiZkoCo9vfmMSTsyDC0 ywo+OC9ea87JBe4KPiFRtjWkPNYRrp7q942LO+Utnw==
X-Google-Smtp-Source: AGs4zMZntBLjdCLxEwGQ07d74muRLFChkehNtouASQE7o5G9J/+F5Snz3nfWG5YT+GtBYh7po4Y5bDRviQs53Hi1kLw=
X-Received: by 10.37.187.73 with SMTP id b9mr9642982ybk.208.1511841658264; Mon, 27 Nov 2017 20:00:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.123.132 with HTTP; Mon, 27 Nov 2017 20:00:17 -0800 (PST)
In-Reply-To: <20171128034355.CCDBCB80D43@rfc-editor.org>
References: <20171128034355.CCDBCB80D43@rfc-editor.org>
From: Eric Rescorla 
Date: Mon, 27 Nov 2017 20:00:17 -0800
Message-ID: 
To: RFC Errata System 
Cc: Nagendra Modadugu ,  Kathleen Moriarty , Joseph Salowey , sean+ietf@sn3rd.com,  chenwumao@hisilicon.com, "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="f403043d7d60ff8c6b055f031040"
Archived-At: 
Subject: Re: [TLS] [Technical Errata Reported] RFC6347 (5186)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 04:01:01 -0000

--f403043d7d60ff8c6b055f031040
Content-Type: text/plain; charset="UTF-8"

I'm pretty sure record_sequence_number is correct. The MSN is always 0 for
HVR and 1 for SH,

-Ekr


On Mon, Nov 27, 2017 at 7:43 PM, RFC Errata System <
rfc-editor@rfc-editor.org> wrote:

> The following errata report has been submitted for RFC6347,
> "Datagram Transport Layer Security Version 1.2".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5186
>
> --------------------------------------
> Type: Technical
> Reported by: Chen Wumao 
>
> Section: 4.2.4
>
> Original Text
> -------------
> [p17]                                                 In order to avoid
>    sequence number duplication in case of multiple HelloVerifyRequests,
>    the server MUST use the record sequence number in the ClientHello as
>    the record sequence number in the HelloVerifyRequest.
>
> [p17]                  In order to avoid sequence number duplication in
>    case of multiple cookie exchanges, the server MUST use the record
>    sequence number in the ClientHello as the record sequence number in
>    its initial ServerHello.
>
> Corrected Text
> --------------
> [p17]                                                 In order to avoid
>    sequence number duplication in case of multiple HelloVerifyRequests,
>    the server MUST use the message_seq in the ClientHello as
>    the message_seq in the HelloVerifyRequest.
>
> [p17]                  In order to avoid sequence number duplication in
>    case of multiple cookie exchanges, the server MUST use the
>    message_seq in the ClientHello as the message_seq in
>    its initial ServerHello.
>
> Notes
> -----
> the "record sequence number" here should be message_seq.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC6347 (draft-ietf-tls-rfc4347-bis-06)
> --------------------------------------
> Title               : Datagram Transport Layer Security Version 1.2
> Publication Date    : January 2012
> Author(s)           : E. Rescorla, N. Modadugu
> Category            : PROPOSED STANDARD
> Source              : Transport Layer Security
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG
>

--f403043d7d60ff8c6b055f031040
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I'm pretty sure record_sequence_number is correct=
. The MSN is always 0 for HVR and 1 for SH,

-Ekr


On Mon, Nov 27, 2017 at 7:43 PM, RFC Errata System <rfc-ed=
itor@rfc-editor.org> wrote:
The following errata report has been submitted for RFC6347,

"Datagram Transport Layer Security Version 1.2".



--------------------------------------

You may review the report below and at:

http://www.rfc-editor.org/errata/eid5186



--------------------------------------

Type: Technical

Reported by: Chen Wumao <chen=
wumao@hisilicon.com>



Section: 4.2.4



Original Text

-------------

[p17]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In order to avoid

=C2=A0 =C2=A0sequence number duplication in case of multiple HelloVerifyReq=
uests,

=C2=A0 =C2=A0the server MUST use the record sequence number in the ClientHe=
llo as

=C2=A0 =C2=A0the record sequence number in the HelloVerifyRequest.



[p17]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 In orde=
r to avoid sequence number duplication in

=C2=A0 =C2=A0case of multiple cookie exchanges, the server MUST use the rec=
ord

=C2=A0 =C2=A0sequence number in the ClientHello as the record sequence numb=
er in

=C2=A0 =C2=A0its initial ServerHello.



Corrected Text

--------------

[p17]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In order to avoid

=C2=A0 =C2=A0sequence number duplication in case of multiple HelloVerifyReq=
uests,

=C2=A0 =C2=A0the server MUST use the message_seq in the ClientHello as

=C2=A0 =C2=A0the message_seq in the HelloVerifyRequest.



[p17]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 In orde=
r to avoid sequence number duplication in

=C2=A0 =C2=A0case of multiple cookie exchanges, the server MUST use the

=C2=A0 =C2=A0message_seq in the ClientHello as the message_seq in

=C2=A0 =C2=A0its initial ServerHello.



Notes

-----

the "record sequence number" here should be message_seq.



Instructions:

-------------

This erratum is currently posted as "Reported". If necessary, ple=
ase

use "Reply All" to discuss whether it should be verified or

rejected. When a decision is reached, the verifying party

can log in to change the status and edit the report, if necessary.



--------------------------------------

RFC6347 (draft-ietf-tls-rfc4347-bis-06)

--------------------------------------

Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Datagram Tran=
sport Layer Security Version 1.2

Publication Date=C2=A0 =C2=A0 : January 2012

Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: E. Rescorla, N. Modadug=
u

Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD

Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Transport Layer Se=
curity

Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security

Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF

Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG





--f403043d7d60ff8c6b055f031040--


From nobody Tue Nov 28 12:17:09 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C1725129413; Tue, 28 Nov 2017 12:17:07 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Secretariat 
To: , , 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151190022778.12413.2586756020553488436.idtracker@ietfa.amsl.com>
Date: Tue, 28 Nov 2017 12:17:07 -0800
Archived-At: 
Subject: [TLS] The TLS WG has placed draft-rescorla-tls-dtls-connection-id in state "Candidate for WG Adoption"
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 20:17:08 -0000

The TLS WG has placed draft-rescorla-tls-dtls-connection-id in state
Candidate for WG Adoption (entered by Sean Turner)

The document is available at
https://datatracker.ietf.org/doc/draft-rescorla-tls-dtls-connection-id/


From nobody Tue Nov 28 12:17:20 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED365128DE7 for ; Tue, 28 Nov 2017 12:17:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
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 IcWaav4tFE31 for ; Tue, 28 Nov 2017 12:17:14 -0800 (PST)
Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 76222128D2E for ; Tue, 28 Nov 2017 12:17:14 -0800 (PST)
Received: by mail-qt0-x22c.google.com with SMTP id i40so1518225qti.8 for ; Tue, 28 Nov 2017 12:17:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=jo5ZFN7SQ1SYKWivk5qKbVGtDKm0RzRa4Y5wAtLD0H8=; b=R4o1IBtQ0pgfdi0l/0MRpsXPxnpT8y1Q0VHHlqZbTOTG/KPeWoQzJ7Gu/bkBL02uTh HrBlICNUq6rwPF9FMrZjoABgRE32CQ2N83vpUz+Z3rvyBQIqrkzH347sY4Ri396wWhgG YIrZylgBa7rlvudpTRoo4F7xvx/C+yBYAMDNw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=jo5ZFN7SQ1SYKWivk5qKbVGtDKm0RzRa4Y5wAtLD0H8=; b=bFeE/BRjP/k7QAuv66XFo3ACLJiqjA+2KOq0s2EVM80oymwmXo+Im/738bOgp9JCkg DBM/w4qpjp2VJDcTp470CzYfQB6W0QAiiNoruk9BcAM841aoTujol7PHmA9KStJpm99c BQcXaY3YGHNPsKeoRGz/hSVZr9sQMZPOGrgRPXqkT+VIUtCmKCkGmNWjE7tn3rHPbJjT WP20TJx3GaOBJ7IDpeyF9WBIhqKmGqaKMvwHTzy/0iKXXUxrWXQp+HPQxLQw6kF5pawh 43W/+eF9GlJSC44bzTQ+yV97GaRbKs0aLdVOkYfrGfq+UnNOyDJJrhl6SsmmAwyi+VrV NIDg==
X-Gm-Message-State: AJaThX7PfkkmfiluZW7nlgDrj1/qUqxCABSK3JSPvInzHES84unGtLUM bHW3z92FrtGu86xgxvL09YeGxjBWEsM=
X-Google-Smtp-Source: AGs4zMaOVjZN2R/cVwYTLBblWmmUtXMXyDSqpB8uoxNmyrLNTTWzmayDSDtMPalS7aXIzHnOahFCOw==
X-Received: by 10.237.60.206 with SMTP id e14mr688137qtf.157.1511900233495; Tue, 28 Nov 2017 12:17:13 -0800 (PST)
Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id s189sm22019955qke.68.2017.11.28.12.17.12 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Nov 2017 12:17:12 -0800 (PST)
From: Sean Turner 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Message-Id: <6C12EF11-D3CE-41B4-B3AE-B46607E901AA@sn3rd.com>
Date: Tue, 28 Nov 2017 15:17:12 -0500
To: "" 
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
Subject: [TLS] WG call for adoption of draft-rescorla-tls-dtls-connection-id
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 20:17:16 -0000

All,

In Singapore @ IETF100, there was strong WG consensus to adopt =
draft-rescorla-tls-dtls-connection-id, but we need to confirm this on =
the list.  Please let us know by X December 2017 whether you oppose =
adopting this draft and why.

Your chairs: J&S=


From nobody Tue Nov 28 12:19:32 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E848128D2E for ; Tue, 28 Nov 2017 12:19:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
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 XW3HTkm5GzPt for ; Tue, 28 Nov 2017 12:19:29 -0800 (PST)
Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 64AC41204DA for ; Tue, 28 Nov 2017 12:19:29 -0800 (PST)
Received: by mail-qt0-x234.google.com with SMTP id i40so1526677qti.8 for ; Tue, 28 Nov 2017 12:19:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=pZ64Uhi3316TPwha2IlAWSBFFFASJkjmQu2p3nGs2Zw=; b=KD2ICDw1VhZJYFyhuvh+ujERCUEhTynctTcLQdQZuNYUeGVXBGHbD1/ta1nH3pwEW7 NMs2birtPUNxZWecSYLxIbLFVzrNB8ZKVuxWjbV89ahEa2a1u1lAdy1QVT2YXwqnzQ8q ad5d6NEoONaLNLhCHLVl+m2Soo4U2jSGvMf2I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=pZ64Uhi3316TPwha2IlAWSBFFFASJkjmQu2p3nGs2Zw=; b=KXv0FtZWzocY+5k3qZUonE7D3HbYo1yE+eVOSHqKQQ0YVOW4C01cBYn4tLghUs8nBX dCfr+VUVRf94DA+zraU5A7UtiDBkgqtAGze8IXihT93w2XNMqFfcw2VJNEpjMXT3RO7i GL3ZxuxUOAyTZheS0jy5ZJUCsi95nZUBhvUuhOAVJQJqKHKbEVzjwjzQEHdzWoQFnYyY SJEDEcWavHnCdAWfR+EhI0a5Oxq17xyEJTFKuJVkddM1FC8vylk4Zwjz878lvt6zfQj9 rTWQUrohrkRh2Q3SeP0t1KMZ8sVpUsQn/HcaQoZaUlhuWOvRBj12Uusmnvt2TMwp+6K+ wM2w==
X-Gm-Message-State: AJaThX5mkVJG5WfIQgEwpwHYRfTjF0D1eTHJCGlgK+f/V9GM23gnGjgg w7kvByBevoXLvI4PU//tE4Co6+UbauI=
X-Google-Smtp-Source: AGs4zMaoHTh0YuIIh8TP90Wcs2fFhhL7OiVc28Qa8doo7RDm6YCVa0Q/7MC8zmRcz19+e9waGEZNhQ==
X-Received: by 10.200.4.44 with SMTP id v44mr757629qtg.80.1511900368353; Tue, 28 Nov 2017 12:19:28 -0800 (PST)
Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id a195sm8205qkb.23.2017.11.28.12.19.27 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Nov 2017 12:19:27 -0800 (PST)
From: Sean Turner 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Date: Tue, 28 Nov 2017 15:19:26 -0500
References: <6C12EF11-D3CE-41B4-B3AE-B46607E901AA@sn3rd.com>
To: "" 
In-Reply-To: <6C12EF11-D3CE-41B4-B3AE-B46607E901AA@sn3rd.com>
Message-Id: <46E879AF-5F68-48E5-908A-CD1660EB9D1F@sn3rd.com>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: 
Subject: Re: [TLS] WG call for adoption of draft-rescorla-tls-dtls-connection-id
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 20:19:30 -0000

Should have included a date: 13 December 2017.

> On Nov 28, 2017, at 15:17, Sean Turner  wrote:
>=20
> All,
>=20
> In Singapore @ IETF100, there was strong WG consensus to adopt =
draft-rescorla-tls-dtls-connection-id, but we need to confirm this on =
the list.  Please let us know by X December 2017 whether you oppose =
adopting this draft and why.
>=20
> Your chairs: J&S


From nobody Tue Nov 28 12:46:04 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96C41205D3 for ; Tue, 28 Nov 2017 12:46:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=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 X8hqJ-FVMzSf for ; Tue, 28 Nov 2017 12:46:01 -0800 (PST)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB72C124239 for ; Tue, 28 Nov 2017 12:46:00 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 1FEA497981; Tue, 28 Nov 2017 22:45:58 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 0qdbeNTb7LlT; Tue, 28 Nov 2017 22:45:57 +0200 (EET)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id BDEF727F; Tue, 28 Nov 2017 22:45:55 +0200 (EET)
Date: Tue, 28 Nov 2017 22:45:55 +0200
From: Ilari Liusvaara 
To: Eric Rescorla 
Cc: "tls@ietf.org" 
Message-ID: <20171128204555.GA7166@LK-Perkele-VII>
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.9.1 (2017-09-22)
Sender: ilariliusvaara@welho.com
Archived-At: 
Subject: Re: [TLS] Update on middlebox measurements in Firefox
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 20:46:03 -0000

On Fri, Nov 24, 2017 at 12:32:15PM -0800, Eric Rescorla wrote:
> Hi folks,
> 
> - draft-22 (as soon to be published) using Firefox Nightly.
> 
> The first of these tests will go out today or Monday and will run for
> a week or so while we collect the data. For the second, we're landing
> the draft-22 code in Nightly early next week, and plan to start the
> tests mid next week.

Err... Where is the draft-22 I-D? Datatracker shows -21 as latest
version for me.

(Nevertheless, spotted the Mozilla test server and did some interop
testing with version=0x7f16).


-Ilari


From nobody Tue Nov 28 12:53:56 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D991205D3 for ; Tue, 28 Nov 2017 12:53:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 vKZ9BhBRQIHi for ; Tue, 28 Nov 2017 12:53:51 -0800 (PST)
Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (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 99AD7126CD6 for ; Tue, 28 Nov 2017 12:53:51 -0800 (PST)
Received: by mail-yb0-x233.google.com with SMTP id g187so502511yba.13 for ; Tue, 28 Nov 2017 12:53:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OUQ4cAYXJac89TtA8djme0jfTXexb1LOsRLOOeM+XGM=; b=g1W0LgGcPkKXwrxnk+GBFdn2c8S8nJzxXuvr+5D9wj9Ze+AReTmVljapF+sBSetCDv VBa+hgACDgwF+ZGQVOuzLyV4XgIqv8v7ulOPPn/B3VxH2QDrZL9WHkTNDZjwiAQKSGDf YLZN74GRkaDEHghmlujInPt9WLU74NbHtCnE6HqEXRNdl/QILg405AKq8ae82yqCXISd gFV9e5g7ln9lg1v+zhhY7BoISR0eIE9TQsf/btgSg+p5J7V4zo4liPlc8d6id+EP0ivD 815vs/I8+BglJVov2AJW6AvZe96Isj8RijsOZ8w2XH4U4DL9rUWs8k5G6WWNK55oVYGT R3yQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OUQ4cAYXJac89TtA8djme0jfTXexb1LOsRLOOeM+XGM=; b=kqaqSBY/ySsLBn6PVggo22j/qyfSX9lusH3SHbO1qwm+FvCuGc1onUsxLi5MZI4qpu KmE0yU8yMAUYqwp+keuRSDppWY7mBvHNLi9lGTtGQoxEBKNsTx/cQ1haWL2yD6Xygw6U Mz5mAumsPaJySoGkI/G4B+vXsVFSmpTHir3QEXSgB60Ghf7a64eRJ0gXlr1t8sBaMe7H LKeqwa7/MliAkZSgt8h1cp/jPqpLXJmQFDaf6lR0z/B153sO4YfSSOOkSCFlI1Q6/Dum RBg2lYmaP/THxb14UbzbxNnatsTz9BX4tWurj75rlQ4qcX3i1+qVxsbpnyax6Ekg4XBp BEIQ==
X-Gm-Message-State: AJaThX4lMHniAyKl9Jd6EvbzTGSR1JfIh/YE/TqaEcfI6a7lsnamj3wL 6iU/+JXRi8G9rRWQRF9/nPu3+AO5BCBgUjV5BVoVKgvh
X-Google-Smtp-Source: AGs4zMZ07lnLZOkBXDkJSeNTQGuE83OUkpYuGdeXZsYtGwFPbBseE7VCCqmSTYnYI+Yuo6zHtRB9Of2GaBKjj6RXjVQ=
X-Received: by 10.37.16.134 with SMTP id 128mr330972ybq.474.1511902430687; Tue, 28 Nov 2017 12:53:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.123.132 with HTTP; Tue, 28 Nov 2017 12:53:10 -0800 (PST)
In-Reply-To: <20171128204555.GA7166@LK-Perkele-VII>
References:  <20171128204555.GA7166@LK-Perkele-VII>
From: Eric Rescorla 
Date: Tue, 28 Nov 2017 12:53:10 -0800
Message-ID: 
To: Ilari Liusvaara 
Cc: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11c0125a511153055f1137e5"
Archived-At: 
Subject: Re: [TLS] Update on middlebox measurements in Firefox
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Nov 2017 20:53:54 -0000

--001a11c0125a511153055f1137e5
Content-Type: text/plain; charset="UTF-8"

22 will be out in the next day or two. Just cleaning up the last few PRs.

-Ekr


On Tue, Nov 28, 2017 at 12:45 PM, Ilari Liusvaara 
wrote:

> On Fri, Nov 24, 2017 at 12:32:15PM -0800, Eric Rescorla wrote:
> > Hi folks,
> >
> > - draft-22 (as soon to be published) using Firefox Nightly.
> >
> > The first of these tests will go out today or Monday and will run for
> > a week or so while we collect the data. For the second, we're landing
> > the draft-22 code in Nightly early next week, and plan to start the
> > tests mid next week.
>
> Err... Where is the draft-22 I-D? Datatracker shows -21 as latest
> version for me.
>
> (Nevertheless, spotted the Mozilla test server and did some interop
> testing with version=0x7f16).
>
>
> -Ilari
>

--001a11c0125a511153055f1137e5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


22 will be out in the next day or two. Just cleaning =
up the last few PRs.

-Ekr


On Tue, Nov 28, 2017 =
at 12:45 PM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Fri, Nov 24, 2017 at 12:32:1=
5PM -0800, Eric Rescorla wrote:

> Hi folks,

>

> - draft-22 (as soon to be published) using Firefox Nightly.

>

> The first of these tests will go out today or Monday and will run for<=
br>
> a week or so while we collect the data. For the second, we're land=
ing

> the draft-22 code in Nightly early next week, and plan to start the
> tests mid next week.



Err... Where is the draft-22 I-D? Datatracker shows -21 as latest
version for me.



(Nevertheless, spotted the Mozilla test server and did some interop

testing with version=3D0x7f16).





-Ilari





--001a11c0125a511153055f1137e5--


From nobody Tue Nov 28 16:06:49 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE32127735 for ; Tue, 28 Nov 2017 16:06:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lekensteyn.nl
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 QW_7xS0GfWFq for ; Tue, 28 Nov 2017 16:06:43 -0800 (PST)
Received: from mail.lekensteyn.nl (mail.lekensteyn.nl [IPv6:2a02:2308::360:1:25]) (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 652911205F0 for ; Tue, 28 Nov 2017 16:06:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lekensteyn.nl; s=s2048-2015-q1;  h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=dk+vd45rPmw+C+o6Pvgn7SgcB0CJj2D31ih7dVoOWZg=;  b=Y3hibj86YWorE8SAtJpraOFDIN2IxA8cKOaJDeki7a3cO9bpcxBSXQIqxsrks6zave4ebjUlaZwJf9TP0qTShd2QYQsBhggzp0vVnKK5jAAt7iBMOg5mmqswmcU2copmOOwiAV6wRtNRNPfMmLbjqtYZJGIDDSs4S2xDVwj3ziF68BzHwuNhoCV0wngoCUttsK8O/PyDI/SIBiygESk0bXKXETIlRLJHe6uz0oKV+mixmfFvxpYYYUq4hPrk0FPEK2M710qyx/iXeBQnfyuGjebUucLR0QjQ2t/rzUbL3MS2Fyk8AUfb9jC0zsA6xD2RatPXpljftFffw1gcMKJK1A==;
Received: by lekensteyn.nl with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eJptg-0003Bk-H5; Wed, 29 Nov 2017 01:06:40 +0100
Date: Wed, 29 Nov 2017 00:06:37 +0000
From: Peter Wu 
To: Eric Rescorla 
Cc: "tls@ietf.org" 
Message-ID: <20171129000637.GA3051@al>
References: <20171122035404.GC18321@al> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.9.1 (2017-09-22)
Archived-At: 
Subject: Re: [TLS] PR to clarify RSASSA-PSS requirements
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 00:06:47 -0000

Hi Eric and list,

I have updated the PR https://github.com/tlswg/tls13-spec/pull/1098 last
week based on received feedback. Two issues are however still open:

 - Should a different codepoint be used for SPKIs other than
   rsaEncryption (i.e. id-RSASSA-PSS)? If so, what codepoints?

 - Should certificates with SPKI id-RSASSA-PSS be required to have no
   parameters (i.e. not restrict the hash algorithm chosen in TLS)?

Ideally it would already be sorted out before draft 22 is released. If
nothing is changed, then the specification remains ambiguous and
interoperability issues may occur.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl


From nobody Wed Nov 29 07:54:19 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3598A127B57; Wed, 29 Nov 2017 07:54:12 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151197085214.7952.17207235386981526626@ietfa.amsl.com>
Date: Wed, 29 Nov 2017 07:54:12 -0800
Archived-At: 
Subject: [TLS] I-D Action: draft-ietf-tls-tls13-22.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 15:54:12 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : The Transport Layer Security (TLS) Protocol Version 1.3
        Author          : Eric Rescorla
	Filename        : draft-ietf-tls-tls13-22.txt
	Pages           : 150
	Date            : 2017-11-29

Abstract:
   This document specifies version 1.3 of the Transport Layer Security
   (TLS) protocol.  TLS allows client/server applications to communicate
   over the Internet in a way that is designed to prevent eavesdropping,
   tampering, and message forgery.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-tls13-22
https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-22

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-22


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Nov 29 07:54:56 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCC81275C5 for ; Wed, 29 Nov 2017 07:54:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 Th9-MqYxfcnL for ; Wed, 29 Nov 2017 07:54:54 -0800 (PST)
Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 CB0A11200B9 for ; Wed, 29 Nov 2017 07:54:53 -0800 (PST)
Received: by mail-yw0-x22f.google.com with SMTP id x199so1517953ywg.5 for ; Wed, 29 Nov 2017 07:54:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Hm2XHVz9/72Hdx2kon2SXewh7iDq0E2t1vZjq50mOEE=; b=UiqGPohCa/iAWWRTyCtkKnsICY5tesmcLdeF9JznaP/Z3GTTHGyMmoRN1A8hbdYdV0 iOaaXKNGb/UavCVP+7PtSQx+CbVW413Wi7xANQgtdEQzIJpIXdgznUoRxBiFeCRKeuIo /nx9pS6aqXZFlazfoYrYeaYlIs4KHpq9shSubQrC2/PNdMsA+hkvAv25LLpV1yZ8UeCf uQ3ti60Hno6fu+BsYJUoTer6N17xI3d9cGtrVLKQJp1M8R2QURzHDXcdvDrioBFglbgB PdyPUDaZjY3nfQLOJ/VI+I3pZXLI4xRBrCNQ+MGc1pBo0krsp/37OoaLaBHmCEsRIyb5 /nmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Hm2XHVz9/72Hdx2kon2SXewh7iDq0E2t1vZjq50mOEE=; b=glWXAWTLvxjBw13FT4giFL7Qaq1QlDWcHLs8CqYrVSAtScVJQIHJKhwZiuJeuhQy6K G4F6FXvoCvcnTUE21/aSWxsfdJH1ImFPXKIwCWxaQCzFvcxBON8of6gEy4yPVQL9s/Wy XJcgYKJcSLSP+3CWz4tAndmL0Oso7KfIYu0CAQtlHBtmmnSf/ofYgllNFMpoDSftTRJB 5Eg7Q+oiKOWtLzVDe3WqJ1/JjDhPbthyXtR9bIR3oEe6V06xehcgXnXIib4Rx/IGBRkw /l6kknuHY4I8k1ynSRCmLFp2wCtxWOUh3eT60SLY11FA3kMHXqEvFodghD909h6CLtB9 0l2Q==
X-Gm-Message-State: AJaThX5LnG22YBQWCK4momj5ux9wuDeHTcpMEFQdlBkJPRfD/ETalVBw mV9yEu/1f+pWYUcowgjUZIW9QKGhPRk4AIm5VpkJ12vB8FM=
X-Google-Smtp-Source: AGs4zMZksP3nOQW4SUE6M0yPsnkED1TmhEaTE7pdRF9DF0YAEhZYaAiYdDVe6betyo4c4xeSsqXlPUW2Wm8YfsLvef8=
X-Received: by 10.129.87.210 with SMTP id l201mr2155480ywb.2.1511970892753; Wed, 29 Nov 2017 07:54:52 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.123.132 with HTTP; Wed, 29 Nov 2017 07:54:12 -0800 (PST)
From: Eric Rescorla 
Date: Wed, 29 Nov 2017 07:54:12 -0800
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11457576f9449a055f212764"
Archived-At: 
Subject: [TLS] Draft-22 submitted.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 15:54:55 -0000

--001a11457576f9449a055f212764
Content-Type: text/plain; charset="UTF-8"

Hi folks,

I have just submitted draft-22. This includes all the changes we discussed
in Singapore. For convenience, the change log is attached at the end of this
message.

I elected not to merge either of the PSS PRs. I'll be sending a proposal
to the list for how to resolve this in the next day or two, but I didn't
want to delay people's ability to deploy and test -22

-Ekr



- Implement changes for improved middlebox penetration (*)

- Move server_certificate_type to encrypted extensions (*)

- Allow resumption with a different SNI (*)

- Padding extension can change on HRR (*)

- Allow an empty ticket_nonce (*)

- Remove requirement to immediately respond to close_notify with
  close_notify (allowing half-close)

--001a11457576f9449a055f212764
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi folks,

I have just submit=
ted draft-22. This includes all the changes we discussed
in Singa=
pore. For convenience, the change log is attached at the end of this
<=
div>message.

I elected not to merge either of the =
PSS PRs. I'll be sending a proposal
to the list for how to re=
solve this in the next day or two, but I didn't
want to delay=
 people's ability to deploy and test -22

-Ekr<=
/div>



- Implement changes =
for improved middlebox penetration (*)

- Move serv=
er_certificate_type to encrypted extensions (*)

- =
Allow resumption with a different SNI (*)

- Paddin=
g extension can change on HRR (*)

- Allow an empty=
 ticket_nonce (*)

- Remove requirement to immediat=
ely respond to close_notify with
=C2=A0 close_notify (allowing ha=
lf-close)




=



--001a11457576f9449a055f212764--


From nobody Wed Nov 29 07:59:31 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00F61271DF for ; Wed, 29 Nov 2017 07:59:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 T7zsjIXQsCzn for ; Wed, 29 Nov 2017 07:59:29 -0800 (PST)
Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (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 EA91E1200B9 for ; Wed, 29 Nov 2017 07:59:28 -0800 (PST)
Received: by mail-yb0-x230.google.com with SMTP id t127so1516550ybf.9 for ; Wed, 29 Nov 2017 07:59:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=0NZeI9HFPUWep8ZeP6moBpKhwAmi46m9ia12wlqJPvg=; b=CPCl86czcZzOgxCket+zfONvsEQw9KuBkXqcygOjFRmJM3ZxVcihUNPTQT26+BvHpn IIo8WuuvKbum1syW+JZWhiOd/BkZaD8WlYYzsVQoqug0GxaGvhJVzQTvPw0+emJtKnn3 6J+Gt6hsVoV/zrE7N73kiQj3Uw7gcQlCTn3NNIr3EziYI13ZD6u9YDvyAPuRPbaNXhve U9iZ/lGsb6qcOI0KCNa1lmJb+NpZAvhmBZwYvBecOsWdT3B3qftjeMQM8y3PrzjnzLdu mGKQmrL4FYxXYAxg+PTaB++vBii8u/t+VO6sEejt2Bi3D/0ownqPVigCCFguF9LYPOrI Vjog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0NZeI9HFPUWep8ZeP6moBpKhwAmi46m9ia12wlqJPvg=; b=Yz6fAXp7/FZjAFil9zpHqCxXtf052mneGy3Icn5ib5L53WbihG3SV5CKvlAZ2mPvIg 7iKUhuPsUjJX6Ok+VJ9EFttosIpdViD3QET0X5UYbGxILVtnQxfKEgwxltyo9dS9hFgA uP0vWB7Jd6UG06IhorX0QqQp2F+TVjyTPv14f4RYF1N/HER7IDFC5gIbZHoQKXR3XesM np67A6uQDrXqCaTWeWs05YASVS8I0+ynuIQ+I/z2L1iVKdbhO5PnV/mSrQwuBGMVu4Vo b5sna2wLr+oFGewgCmHK7Ny18g8POpWt3Estv2Feni40lf3nZdkZzlk66UheNCxGX3tE d63w==
X-Gm-Message-State: AJaThX6mC8rngCdePYnNlMTHsNaIu0KPEKrhF+3am9rY1PolPU2Elqdd hemkrenTOV5I4ZSxcwC2RjfAYz+ElzennzxR+DagSLHl
X-Google-Smtp-Source: AGs4zMbGMJTGPr+t1TgxKs56jgjGnlMgXxhXTmEr2kT8XTtRo8g/aDxZ+rYBL346/wVgjiQTWPY3gX1qVnhaUF/70Rc=
X-Received: by 10.37.187.73 with SMTP id b9mr1999235ybk.208.1511971167943; Wed, 29 Nov 2017 07:59:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.123.132 with HTTP; Wed, 29 Nov 2017 07:58:47 -0800 (PST)
From: Eric Rescorla 
Date: Wed, 29 Nov 2017 07:58:47 -0800
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="f403043d7d60605144055f213876"
Archived-At: 
Subject: [TLS] PSA: Ignore DTLS notifications for -03 to -21
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 15:59:30 -0000

--f403043d7d60605144055f213876
Content-Type: text/plain; charset="UTF-8"

I'm going to make the DTLS draft numbers aiign with the TLS draft numbers,
so you're going to receive a bunch of bogus notifications, terminating in a
real DTLS 1.3-22.

Apologies for the inconvenience.

-Ekr

--f403043d7d60605144055f213876
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I'm going to make the DTLS draft numbers aiign with th=
e TLS draft numbers, so you're going to receive a bunch of bogus notifi=
cations, terminating in a real DTLS 1.3-22.=C2=A0

Apolog=
ies for the inconvenience.

-Ekr



--f403043d7d60605144055f213876--


From nobody Wed Nov 29 08:05:15 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 74ACC1271DF; Wed, 29 Nov 2017 08:05:09 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151197150944.8049.13780096347533652449@ietfa.amsl.com>
Date: Wed, 29 Nov 2017 08:05:09 -0800
Archived-At: 
Subject: [TLS] I-D Action: draft-ietf-tls-dtls13-03.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 16:05:10 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
        Authors         : Eric Rescorla
                          Hannes Tschofenig
                          Nagendra Modadugu
	Filename        : draft-ietf-tls-dtls13-03.txt
	Pages           : 41
	Date            : 2017-11-29

Abstract:
   This document specifies Version 1.3 of the Datagram Transport Layer
   Security (DTLS) protocol.  DTLS 1.3 allows client/server applications
   to communicate over the Internet in a way that is designed to prevent
   eavesdropping, tampering, and message forgery.

   The DTLS 1.3 protocol is intentionally based on the Transport Layer
   Security (TLS) 1.3 protocol and provides equivalent security
   guarantees.  Datagram semantics of the underlying transport are
   preserved by the DTLS protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-dtls13-03
https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Nov 29 08:06:38 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 14CAD1271DF; Wed, 29 Nov 2017 08:06:37 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151197159703.7968.7172689642934023293@ietfa.amsl.com>
Date: Wed, 29 Nov 2017 08:06:37 -0800
Archived-At: 
Subject: [TLS] I-D Action: draft-ietf-tls-dtls13-04.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 16:06:37 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
        Authors         : Eric Rescorla
                          Hannes Tschofenig
                          Nagendra Modadugu
	Filename        : draft-ietf-tls-dtls13-04.txt
	Pages           : 41
	Date            : 2017-11-29

Abstract:
   This document specifies Version 1.3 of the Datagram Transport Layer
   Security (DTLS) protocol.  DTLS 1.3 allows client/server applications
   to communicate over the Internet in a way that is designed to prevent
   eavesdropping, tampering, and message forgery.

   The DTLS 1.3 protocol is intentionally based on the Transport Layer
   Security (TLS) 1.3 protocol and provides equivalent security
   guarantees.  Datagram semantics of the underlying transport are
   preserved by the DTLS protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-dtls13-04
https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Nov 29 08:10:28 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7479120727; Wed, 29 Nov 2017 08:10:26 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151197182691.8049.10825539219140976586@ietfa.amsl.com>
Date: Wed, 29 Nov 2017 08:10:26 -0800
Archived-At: 
Subject: [TLS] I-D Action: draft-ietf-tls-dtls13-05.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 16:10:27 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
        Authors         : Eric Rescorla
                          Hannes Tschofenig
                          Nagendra Modadugu
	Filename        : draft-ietf-tls-dtls13-05.txt
	Pages           : 41
	Date            : 2017-11-29

Abstract:
   This document specifies Version 1.3 of the Datagram Transport Layer
   Security (DTLS) protocol.  DTLS 1.3 allows client/server applications
   to communicate over the Internet in a way that is designed to prevent
   eavesdropping, tampering, and message forgery.

   The DTLS 1.3 protocol is intentionally based on the Transport Layer
   Security (TLS) 1.3 protocol and provides equivalent security
   guarantees.  Datagram semantics of the underlying transport are
   preserved by the DTLS protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-dtls13-05
https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Nov 29 08:12:46 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF97A1271DF; Wed, 29 Nov 2017 08:12:38 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151197195896.8070.8288665695412121561@ietfa.amsl.com>
Date: Wed, 29 Nov 2017 08:12:38 -0800
Archived-At: 
Subject: [TLS] I-D Action: draft-ietf-tls-dtls13-06.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 16:12:39 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
        Authors         : Eric Rescorla
                          Hannes Tschofenig
                          Nagendra Modadugu
	Filename        : draft-ietf-tls-dtls13-06.txt
	Pages           : 41
	Date            : 2017-11-29

Abstract:
   This document specifies Version 1.3 of the Datagram Transport Layer
   Security (DTLS) protocol.  DTLS 1.3 allows client/server applications
   to communicate over the Internet in a way that is designed to prevent
   eavesdropping, tampering, and message forgery.

   The DTLS 1.3 protocol is intentionally based on the Transport Layer
   Security (TLS) 1.3 protocol and provides equivalent security
   guarantees.  Datagram semantics of the underlying transport are
   preserved by the DTLS protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-dtls13-06
https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Nov 29 08:14:11 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B08128CFF; Wed, 29 Nov 2017 08:14:03 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151197204349.8057.4135237758988453001@ietfa.amsl.com>
Date: Wed, 29 Nov 2017 08:14:03 -0800
Archived-At: 
Subject: [TLS] I-D Action: draft-ietf-tls-dtls13-07.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 16:14:04 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
        Authors         : Eric Rescorla
                          Hannes Tschofenig
                          Nagendra Modadugu
	Filename        : draft-ietf-tls-dtls13-07.txt
	Pages           : 41
	Date            : 2017-11-29

Abstract:
   This document specifies Version 1.3 of the Datagram Transport Layer
   Security (DTLS) protocol.  DTLS 1.3 allows client/server applications
   to communicate over the Internet in a way that is designed to prevent
   eavesdropping, tampering, and message forgery.

   The DTLS 1.3 protocol is intentionally based on the Transport Layer
   Security (TLS) 1.3 protocol and provides equivalent security
   guarantees.  Datagram semantics of the underlying transport are
   preserved by the DTLS protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-dtls13-07
https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Nov 29 08:16:09 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B5E1275C5; Wed, 29 Nov 2017 08:16:02 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151197216256.8061.11165915305086186352@ietfa.amsl.com>
Date: Wed, 29 Nov 2017 08:16:02 -0800
Archived-At: 
Subject: [TLS] I-D Action: draft-ietf-tls-dtls13-08.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 16:16:03 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
        Authors         : Eric Rescorla
                          Hannes Tschofenig
                          Nagendra Modadugu
	Filename        : draft-ietf-tls-dtls13-08.txt
	Pages           : 41
	Date            : 2017-11-29

Abstract:
   This document specifies Version 1.3 of the Datagram Transport Layer
   Security (DTLS) protocol.  DTLS 1.3 allows client/server applications
   to communicate over the Internet in a way that is designed to prevent
   eavesdropping, tampering, and message forgery.

   The DTLS 1.3 protocol is intentionally based on the Transport Layer
   Security (TLS) 1.3 protocol and provides equivalent security
   guarantees.  Datagram semantics of the underlying transport are
   preserved by the DTLS protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-dtls13-08
https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-08


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Nov 29 08:17:06 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0FF128C81; Wed, 29 Nov 2017 08:17:00 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151197222015.8025.14164658294112823663@ietfa.amsl.com>
Date: Wed, 29 Nov 2017 08:17:00 -0800
Archived-At: 
Subject: [TLS] I-D Action: draft-ietf-tls-dtls13-09.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 16:17:00 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
        Authors         : Eric Rescorla
                          Hannes Tschofenig
                          Nagendra Modadugu
	Filename        : draft-ietf-tls-dtls13-09.txt
	Pages           : 41
	Date            : 2017-11-29

Abstract:
   This document specifies Version 1.3 of the Datagram Transport Layer
   Security (DTLS) protocol.  DTLS 1.3 allows client/server applications
   to communicate over the Internet in a way that is designed to prevent
   eavesdropping, tampering, and message forgery.

   The DTLS 1.3 protocol is intentionally based on the Transport Layer
   Security (TLS) 1.3 protocol and provides equivalent security
   guarantees.  Datagram semantics of the underlying transport are
   preserved by the DTLS protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-dtls13-09
https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-09


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Nov 29 08:18:26 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE471275C5; Wed, 29 Nov 2017 08:18:24 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151197230473.8005.3457667653165695980@ietfa.amsl.com>
Date: Wed, 29 Nov 2017 08:18:24 -0800
Archived-At: 
Subject: [TLS] I-D Action: draft-ietf-tls-dtls13-10.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 16:18:25 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
        Authors         : Eric Rescorla
                          Hannes Tschofenig
                          Nagendra Modadugu
	Filename        : draft-ietf-tls-dtls13-10.txt
	Pages           : 41
	Date            : 2017-11-29

Abstract:
   This document specifies Version 1.3 of the Datagram Transport Layer
   Security (DTLS) protocol.  DTLS 1.3 allows client/server applications
   to communicate over the Internet in a way that is designed to prevent
   eavesdropping, tampering, and message forgery.

   The DTLS 1.3 protocol is intentionally based on the Transport Layer
   Security (TLS) 1.3 protocol and provides equivalent security
   guarantees.  Datagram semantics of the underlying transport are
   preserved by the DTLS protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-dtls13-10
https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Nov 29 08:20:41 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 434BF127871; Wed, 29 Nov 2017 08:20:34 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151197243423.8045.16740837131155004025@ietfa.amsl.com>
Date: Wed, 29 Nov 2017 08:20:34 -0800
Archived-At: 
Subject: [TLS] I-D Action: draft-ietf-tls-dtls13-11.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 16:20:34 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
        Authors         : Eric Rescorla
                          Hannes Tschofenig
                          Nagendra Modadugu
	Filename        : draft-ietf-tls-dtls13-11.txt
	Pages           : 41
	Date            : 2017-11-29

Abstract:
   This document specifies Version 1.3 of the Datagram Transport Layer
   Security (DTLS) protocol.  DTLS 1.3 allows client/server applications
   to communicate over the Internet in a way that is designed to prevent
   eavesdropping, tampering, and message forgery.

   The DTLS 1.3 protocol is intentionally based on the Transport Layer
   Security (TLS) 1.3 protocol and provides equivalent security
   guarantees.  Datagram semantics of the underlying transport are
   preserved by the DTLS protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-dtls13-11
https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-11


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Nov 29 08:23:31 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F2C128896; Wed, 29 Nov 2017 08:23:29 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151197260925.7984.13298865630703523389@ietfa.amsl.com>
Date: Wed, 29 Nov 2017 08:23:29 -0800
Archived-At: 
Subject: [TLS] I-D Action: draft-ietf-tls-dtls13-12.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 16:23:29 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
        Authors         : Eric Rescorla
                          Hannes Tschofenig
                          Nagendra Modadugu
	Filename        : draft-ietf-tls-dtls13-12.txt
	Pages           : 41
	Date            : 2017-11-29

Abstract:
   This document specifies Version 1.3 of the Datagram Transport Layer
   Security (DTLS) protocol.  DTLS 1.3 allows client/server applications
   to communicate over the Internet in a way that is designed to prevent
   eavesdropping, tampering, and message forgery.

   The DTLS 1.3 protocol is intentionally based on the Transport Layer
   Security (TLS) 1.3 protocol and provides equivalent security
   guarantees.  Datagram semantics of the underlying transport are
   preserved by the DTLS protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-dtls13-12
https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-12


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Nov 29 08:24:30 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B486129418; Wed, 29 Nov 2017 08:24:24 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151197266441.8017.4742978101317164860@ietfa.amsl.com>
Date: Wed, 29 Nov 2017 08:24:24 -0800
Archived-At: 
Subject: [TLS] I-D Action: draft-ietf-tls-dtls13-13.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 16:24:24 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
        Authors         : Eric Rescorla
                          Hannes Tschofenig
                          Nagendra Modadugu
	Filename        : draft-ietf-tls-dtls13-13.txt
	Pages           : 41
	Date            : 2017-11-29

Abstract:
   This document specifies Version 1.3 of the Datagram Transport Layer
   Security (DTLS) protocol.  DTLS 1.3 allows client/server applications
   to communicate over the Internet in a way that is designed to prevent
   eavesdropping, tampering, and message forgery.

   The DTLS 1.3 protocol is intentionally based on the Transport Layer
   Security (TLS) 1.3 protocol and provides equivalent security
   guarantees.  Datagram semantics of the underlying transport are
   preserved by the DTLS protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-dtls13-13
https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-13


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Nov 29 08:25:25 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC36612871F; Wed, 29 Nov 2017 08:25:17 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151197271794.8061.15300889353429234097@ietfa.amsl.com>
Date: Wed, 29 Nov 2017 08:25:17 -0800
Archived-At: 
Subject: [TLS] I-D Action: draft-ietf-tls-dtls13-14.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 16:25:18 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
        Authors         : Eric Rescorla
                          Hannes Tschofenig
                          Nagendra Modadugu
	Filename        : draft-ietf-tls-dtls13-14.txt
	Pages           : 41
	Date            : 2017-11-29

Abstract:
   This document specifies Version 1.3 of the Datagram Transport Layer
   Security (DTLS) protocol.  DTLS 1.3 allows client/server applications
   to communicate over the Internet in a way that is designed to prevent
   eavesdropping, tampering, and message forgery.

   The DTLS 1.3 protocol is intentionally based on the Transport Layer
   Security (TLS) 1.3 protocol and provides equivalent security
   guarantees.  Datagram semantics of the underlying transport are
   preserved by the DTLS protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-dtls13-14
https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-14


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Nov 29 08:26:41 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA37128616; Wed, 29 Nov 2017 08:26:39 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151197279995.8000.5849631035711039892@ietfa.amsl.com>
Date: Wed, 29 Nov 2017 08:26:39 -0800
Archived-At: 
Subject: [TLS] I-D Action: draft-ietf-tls-dtls13-15.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 16:26:40 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
        Authors         : Eric Rescorla
                          Hannes Tschofenig
                          Nagendra Modadugu
	Filename        : draft-ietf-tls-dtls13-15.txt
	Pages           : 41
	Date            : 2017-11-29

Abstract:
   This document specifies Version 1.3 of the Datagram Transport Layer
   Security (DTLS) protocol.  DTLS 1.3 allows client/server applications
   to communicate over the Internet in a way that is designed to prevent
   eavesdropping, tampering, and message forgery.

   The DTLS 1.3 protocol is intentionally based on the Transport Layer
   Security (TLS) 1.3 protocol and provides equivalent security
   guarantees.  Datagram semantics of the underlying transport are
   preserved by the DTLS protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-dtls13-15
https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-15


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Nov 29 08:27:46 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED41B1271DF; Wed, 29 Nov 2017 08:27:35 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151197285591.7956.4271018616397410590@ietfa.amsl.com>
Date: Wed, 29 Nov 2017 08:27:35 -0800
Archived-At: 
Subject: [TLS] I-D Action: draft-ietf-tls-dtls13-16.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 16:27:36 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
        Authors         : Eric Rescorla
                          Hannes Tschofenig
                          Nagendra Modadugu
	Filename        : draft-ietf-tls-dtls13-16.txt
	Pages           : 41
	Date            : 2017-11-29

Abstract:
   This document specifies Version 1.3 of the Datagram Transport Layer
   Security (DTLS) protocol.  DTLS 1.3 allows client/server applications
   to communicate over the Internet in a way that is designed to prevent
   eavesdropping, tampering, and message forgery.

   The DTLS 1.3 protocol is intentionally based on the Transport Layer
   Security (TLS) 1.3 protocol and provides equivalent security
   guarantees.  Datagram semantics of the underlying transport are
   preserved by the DTLS protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-dtls13-16
https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-16


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Nov 29 08:28:46 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 529981271DF; Wed, 29 Nov 2017 08:28:40 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151197292030.7984.6104434539260296497@ietfa.amsl.com>
Date: Wed, 29 Nov 2017 08:28:40 -0800
Archived-At: 
Subject: [TLS] I-D Action: draft-ietf-tls-dtls13-17.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 16:28:40 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
        Authors         : Eric Rescorla
                          Hannes Tschofenig
                          Nagendra Modadugu
	Filename        : draft-ietf-tls-dtls13-17.txt
	Pages           : 41
	Date            : 2017-11-29

Abstract:
   This document specifies Version 1.3 of the Datagram Transport Layer
   Security (DTLS) protocol.  DTLS 1.3 allows client/server applications
   to communicate over the Internet in a way that is designed to prevent
   eavesdropping, tampering, and message forgery.

   The DTLS 1.3 protocol is intentionally based on the Transport Layer
   Security (TLS) 1.3 protocol and provides equivalent security
   guarantees.  Datagram semantics of the underlying transport are
   preserved by the DTLS protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-dtls13-17
https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-17


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Nov 29 08:29:55 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A82512940F; Wed, 29 Nov 2017 08:29:48 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151197298853.7996.17626624150856934907@ietfa.amsl.com>
Date: Wed, 29 Nov 2017 08:29:48 -0800
Archived-At: 
Subject: [TLS] I-D Action: draft-ietf-tls-dtls13-18.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 16:29:48 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
        Authors         : Eric Rescorla
                          Hannes Tschofenig
                          Nagendra Modadugu
	Filename        : draft-ietf-tls-dtls13-18.txt
	Pages           : 41
	Date            : 2017-11-29

Abstract:
   This document specifies Version 1.3 of the Datagram Transport Layer
   Security (DTLS) protocol.  DTLS 1.3 allows client/server applications
   to communicate over the Internet in a way that is designed to prevent
   eavesdropping, tampering, and message forgery.

   The DTLS 1.3 protocol is intentionally based on the Transport Layer
   Security (TLS) 1.3 protocol and provides equivalent security
   guarantees.  Datagram semantics of the underlying transport are
   preserved by the DTLS protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-dtls13-18
https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-18

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-18


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Nov 29 08:30:56 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5175B1293DF; Wed, 29 Nov 2017 08:30:50 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151197305031.8098.13075654123832922797@ietfa.amsl.com>
Date: Wed, 29 Nov 2017 08:30:50 -0800
Archived-At: 
Subject: [TLS] I-D Action: draft-ietf-tls-dtls13-19.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 16:30:50 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
        Authors         : Eric Rescorla
                          Hannes Tschofenig
                          Nagendra Modadugu
	Filename        : draft-ietf-tls-dtls13-19.txt
	Pages           : 41
	Date            : 2017-11-29

Abstract:
   This document specifies Version 1.3 of the Datagram Transport Layer
   Security (DTLS) protocol.  DTLS 1.3 allows client/server applications
   to communicate over the Internet in a way that is designed to prevent
   eavesdropping, tampering, and message forgery.

   The DTLS 1.3 protocol is intentionally based on the Transport Layer
   Security (TLS) 1.3 protocol and provides equivalent security
   guarantees.  Datagram semantics of the underlying transport are
   preserved by the DTLS protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-dtls13-19
https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-19

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-19


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Nov 29 08:31:40 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C264A1242EA; Wed, 29 Nov 2017 08:31:33 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151197309376.8074.3880533122271270818@ietfa.amsl.com>
Date: Wed, 29 Nov 2017 08:31:33 -0800
Archived-At: 
Subject: [TLS] I-D Action: draft-ietf-tls-dtls13-20.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 16:31:34 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
        Authors         : Eric Rescorla
                          Hannes Tschofenig
                          Nagendra Modadugu
	Filename        : draft-ietf-tls-dtls13-20.txt
	Pages           : 41
	Date            : 2017-11-29

Abstract:
   This document specifies Version 1.3 of the Datagram Transport Layer
   Security (DTLS) protocol.  DTLS 1.3 allows client/server applications
   to communicate over the Internet in a way that is designed to prevent
   eavesdropping, tampering, and message forgery.

   The DTLS 1.3 protocol is intentionally based on the Transport Layer
   Security (TLS) 1.3 protocol and provides equivalent security
   guarantees.  Datagram semantics of the underlying transport are
   preserved by the DTLS protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-dtls13-20
https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-20

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-20


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Nov 29 08:32:24 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8F01293EE; Wed, 29 Nov 2017 08:32:22 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151197314248.7944.18412704683678728265@ietfa.amsl.com>
Date: Wed, 29 Nov 2017 08:32:22 -0800
Archived-At: 
Subject: [TLS] I-D Action: draft-ietf-tls-dtls13-21.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 16:32:22 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
        Authors         : Eric Rescorla
                          Hannes Tschofenig
                          Nagendra Modadugu
	Filename        : draft-ietf-tls-dtls13-21.txt
	Pages           : 41
	Date            : 2017-11-29

Abstract:
   This document specifies Version 1.3 of the Datagram Transport Layer
   Security (DTLS) protocol.  DTLS 1.3 allows client/server applications
   to communicate over the Internet in a way that is designed to prevent
   eavesdropping, tampering, and message forgery.

   The DTLS 1.3 protocol is intentionally based on the Transport Layer
   Security (TLS) 1.3 protocol and provides equivalent security
   guarantees.  Datagram semantics of the underlying transport are
   preserved by the DTLS protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-dtls13-21
https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-21

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-21


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Nov 29 08:36:04 2017
Return-Path: 
X-Original-To: tls@ietf.org
Delivered-To: tls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C02F7124F57; Wed, 29 Nov 2017 08:36:01 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151197336175.7988.7196299144054638671@ietfa.amsl.com>
Date: Wed, 29 Nov 2017 08:36:01 -0800
Archived-At: 
Subject: [TLS] I-D Action: draft-ietf-tls-dtls13-22.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 16:36:02 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
        Authors         : Eric Rescorla
                          Hannes Tschofenig
                          Nagendra Modadugu
	Filename        : draft-ietf-tls-dtls13-22.txt
	Pages           : 41
	Date            : 2017-11-29

Abstract:
   This document specifies Version 1.3 of the Datagram Transport Layer
   Security (DTLS) protocol.  DTLS 1.3 allows client/server applications
   to communicate over the Internet in a way that is designed to prevent
   eavesdropping, tampering, and message forgery.

   The DTLS 1.3 protocol is intentionally based on the Transport Layer
   Security (TLS) 1.3 protocol and provides equivalent security
   guarantees.  Datagram semantics of the underlying transport are
   preserved by the DTLS protocol.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-dtls13-22
https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-22

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-22


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Nov 29 10:30:28 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6706B128B8E for ; Wed, 29 Nov 2017 10:30:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
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 UdaBVY-4tW5f for ; Wed, 29 Nov 2017 10:30:25 -0800 (PST)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B593F12896F for ; Wed, 29 Nov 2017 10:30:25 -0800 (PST)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vATIR2KU013374 for ; Wed, 29 Nov 2017 18:30:22 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=zk1pVLiB881Cfy0nutRpXpBR18p+L4TdWOcf1E+UeVQ=; b=fMGXlhwSZGbYsBbGxHVlyc04D2io5fbB4X/oWCh5KYG2bS23VGhV1DEgWEoJiz40A+ph rxZSiFFtlfhnbfAmFAyCXRnTrYTP6xJhGX3iCwBFqUOAnm8Gqbnr0Ns2P0cQGI+MrcMJ xV2RS022f9kWxeXf3FTFCQGv7E+hTHTE0HuOic5hQGbc520iioJHeDJ8PqXLlE5wMzo5 rP7XWEkpXri1YPIqrfKbVXjWu//PJkA7K793M6V7//AoZvTiRKFtRrP/n59HkoWdA9t/ ZCDJjM4ggERd4eyTN+U6ISLTkaYHy6gXBT7H6rurzmF2ZZbHnoB5d6hnkMRncE8iFELQ zg== 
Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050095.ppops.net-00190b01. with ESMTP id 2ehpp7sv6k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 29 Nov 2017 18:30:22 +0000
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vATIQFrh026002 for ; Wed, 29 Nov 2017 13:30:21 -0500
Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint4.akamai.com with ESMTP id 2ef4r0ku05-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 29 Nov 2017 13:30:21 -0500
Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 29 Nov 2017 13:30:19 -0500
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 29 Nov 2017 13:30:19 -0500
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 29 Nov 2017 13:30:19 -0500
From: "Salz, Rich" 
To: "tls@ietf.org" 
Thread-Topic: Editorial comments on -22
Thread-Index: AQHTaUAbnaRRU+T5RkyWt9VJzT68Yg==
Date: Wed, 29 Nov 2017 18:30:18 +0000
Message-ID: <141C1E5B-0A3C-4923-B5E4-6BFC4F44A9CD@akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.27.0.171010
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.34.97]
Content-Type: multipart/alternative; boundary="_000_141C1E5B0A3C4923B5E46BFC4F44A9CDakamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-29_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711290238
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-29_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711290238
Archived-At: 
Subject: [TLS] Editorial comments on -22
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Nov 2017 18:30:27 -0000

--_000_141C1E5B0A3C4923B5E46BFC4F44A9CDakamaicom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

PiBUaGUgaGFuZHNoYWtlIHN0YXRlIG1hY2hpbmUgaGFzIGJlZW4gc2lnbmlmaWNhbnRseSByZXN0
cnVjdHVyZWQgdG8NCiAgICAgIGJlIG1vcmUgY29uc2lzdGVudCBhbmQgdG8gcmVtb3ZlIHN1cGVy
Zmx1b3VzIG1lc3NhZ2VzIHN1Y2ggYXMNCiAgICAgIENoYW5nZUNpcGhlclNwZWMuDQoNCk5vIGxv
bmdlciB0cnVlLCBhdCBsZWFzdCBmb3IgQ0NTLg0KDQo+ICAgICAgY29ubmVjdGlvbi4gIFVuZm9y
dHVuYXRlbHksIHNvbWUgbWlkZGxlYm94ZXMgZmFpbCB3aGVuIHByZXNlbnRlZA0KICAgICAgd2l0
aCBuZXcgdmFsdWVzLiAgSW4gVExTIDEuMywgdGhlIFRMUyBzZXJ2ZXIgaW5kaWNhdGVzIGl0cyB2
ZXJzaW9uDQoNCkkgc3VnZ2VzdCByZXBsYWNpbmcg4oCcbWlkZGxlYm94ZXMgZmFpbOKAnSB3aXRo
IOKAnGludGVybWVkaWFyaWVzIGJsb2NrIHRoZSBjb25uZWN0aW9u4oCdDQoNCj4gICBGb3IgYmFj
a3dhcmQgY29tcGF0aWJpbGl0eSByZWFzb25zIHdpdGggbWlkZGxlYm94ZXMgKHNlZQ0KDQpSZXBs
YWNlIOKAnG1pZGRsZWJveOKAnSB3aXRoIOKAnGludGVybWVkaWFyeeKAnS4gIFRoaXMgYXBwZWFy
cyBhIGNvdXBsZSBvZiBvdGhlciB0aW1lcywgYW5kIEkgc3VnZ2VzdCBkb2luZyB0aGF0IHJlcGxh
Y2VtZW50IGV2ZXJ5d2hlcmUgZXhjZXB0IGluIEFwcGVuZGl4IEQgd2hlcmUgd2Ugc2F5IHNvbWV0
aGluZyBsaWtlDQoNCuKAnE5ldHdvcmsgaW50ZXJtZWRpYXJpZXMsIGFsb25nIHRoZSBwYXRoIGJl
dHdlZW4gdGhlIHR3byBjb21tdW5pY2F0aW5nIGVuZHBvaW50cywgdHlwaWNhbGx5IGNhbGxlZCBp
bnRlcm1lZGlhcmllcywgaGF2ZSBiZWVuIHNob3duIHRvIGludGVyZmVyZSDigKbigJ0NCg0KSSBh
bHNvIHRoaW5rIHRoYXQgYWxsIG9mIHRoZSBjaGFuZ2VzIGRlc2NyaWJlZCBlYXJsaWVyIChzdWNo
IGFzIHRoZSBvbmVzIHF1b3RlZCBhYm92ZSwgYnV0IHRoZXJlIGFyZSBvdGhlcnMpIHNob3VsZCBi
ZSBzdW1tYXJpemVkIGluIEFwcGVuZGl4IEQuDQoNCkkgYW0gd2lsbGluZyB0byBkbyBhIFBSIGZv
ciB0aGlzLCBidXQgbm90IHN1cmUgd2hhdCB0byBkbyBhYm91dCB0aGUgZmlyc3QgcG9pbnQgSSBy
YWlzZWQgYWJvdmUuDQoNCg==

--_000_141C1E5B0A3C4923B5E46BFC4F44A9CDakamaicom_
Content-Type: text/html; charset="utf-8"
Content-ID: <2E034E69A7A8F545AA1D5AAE1E9BEEBD@akamai.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg
MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0
aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt
ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5
bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt
YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy
LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4u
TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0K
CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu
a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRl
eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN
Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls
eToiQ291cmllciIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6
cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj
b2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxl
LW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN
Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3Vy
aWVyIixzZXJpZjt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN
Cgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9y
OnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ
Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ
e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk
aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hl
YWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZs
aW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jmd0Ozwvc3Bhbj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90
OyxzZXJpZiI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoZSBoYW5k
c2hha2Ugc3RhdGUgbWFjaGluZSBoYXMgYmVlbiBzaWduaWZpY2FudGx5IHJlc3RydWN0dXJlZCB0
bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYmUgbW9y
ZSBjb25zaXN0ZW50IGFuZCB0byByZW1vdmUgc3VwZXJmbHVvdXMgbWVzc2FnZXMgc3VjaCBhczxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2hhbmdlQ2lw
aGVyU3BlYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk5vIGxv
bmdlciB0cnVlLCBhdCBsZWFzdCBmb3IgQ0NTLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdCI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb25uZWN0
aW9uLiZuYnNwOyBVbmZvcnR1bmF0ZWx5LCBzb21lIG1pZGRsZWJveGVzIGZhaWwgd2hlbiBwcmVz
ZW50ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdp
dGggbmV3IHZhbHVlcy4mbmJzcDsgSW4gVExTIDEuMywgdGhlIFRMUyBzZXJ2ZXIgaW5kaWNhdGVz
IGl0cyB2ZXJzaW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5J
IHN1Z2dlc3QgcmVwbGFjaW5nIOKAnG1pZGRsZWJveGVzIGZhaWzigJ0gd2l0aCDigJxpbnRlcm1l
ZGlhcmllcyBibG9jayB0aGUgY29ubmVjdGlvbuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdCI+Jmd0OyAmbmJzcDsmbmJzcDtGb3IgYmFja3dhcmQgY29tcGF0aWJp
bGl0eSByZWFzb25zIHdpdGggbWlkZGxlYm94ZXMgKHNlZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdCI+UmVwbGFjZSDigJxtaWRkbGVib3jigJ0gd2l0aCDigJxpbnRl
cm1lZGlhcnnigJ0uJm5ic3A7IFRoaXMgYXBwZWFycyBhIGNvdXBsZSBvZiBvdGhlciB0aW1lcywg
YW5kIEkgc3VnZ2VzdCBkb2luZyB0aGF0IHJlcGxhY2VtZW50IGV2ZXJ5d2hlcmUgZXhjZXB0IGlu
IEFwcGVuZGl4IEQgd2hlcmUgd2Ugc2F5IHNvbWV0aGluZyBsaWtlPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij7igJxOZXR3b3JrIGludGVybWVkaWFyaWVzLCBhbG9u
ZyB0aGUgcGF0aCBiZXR3ZWVuIHRoZSB0d28gY29tbXVuaWNhdGluZyBlbmRwb2ludHMsIHR5cGlj
YWxseSBjYWxsZWQgaW50ZXJtZWRpYXJpZXMsIGhhdmUgYmVlbiBzaG93biB0byBpbnRlcmZlcmUg
4oCm4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIGFsc28g
dGhpbmsgdGhhdCBhbGwgb2YgdGhlIGNoYW5nZXMgZGVzY3JpYmVkIGVhcmxpZXIgKHN1Y2ggYXMg
dGhlIG9uZXMgcXVvdGVkIGFib3ZlLCBidXQgdGhlcmUgYXJlIG90aGVycykgc2hvdWxkIGJlIHN1
bW1hcml6ZWQgaW4gQXBwZW5kaXggRC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQiPkkgYW0gd2lsbGluZyB0byBkbyBhIFBSIGZvciB0aGlzLCBidXQgbm90IHN1cmUg
d2hhdCB0byBkbyBhYm91dCB0aGUgZmlyc3QgcG9pbnQgSSByYWlzZWQgYWJvdmUuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0K
PC9odG1sPg0K

--_000_141C1E5B0A3C4923B5E46BFC4F44A9CDakamaicom_--


From nobody Wed Nov 29 16:26:15 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F595126E3A for ; Wed, 29 Nov 2017 16:26:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 9IBdQQGr9Nyy for ; Wed, 29 Nov 2017 16:26:13 -0800 (PST)
Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 EF7641241FC for ; Wed, 29 Nov 2017 16:26:12 -0800 (PST)
Received: by mail-oi0-x22c.google.com with SMTP id w125so3706253oie.7 for ; Wed, 29 Nov 2017 16:26:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=Jf4DKkfqoiK2D2I2fbfiEndTJTIFs7vQwXIkVE3HgWE=; b=fWIoPtbpK5vOqu+FO5l5ELNksLmk7OuDCiOTOlpn1tmSlNLOwVw/qOqWhEdm3YR5pq 4r9bb3rAtE4A20exP30CvwNhxF4OCOWlZ35Dk0VsWezetFl6jVgKfN6m/ZV54AFU3JOZ Wm4SGe68qEl2FTpbom5iWuLImgBxgTgpeDdgAGwDtPDnzMAvhOlmHjTzGY3kQk+G8gNh YCxfDTin00Z/c6DFQezieXW5ue+MncWXIlZ0qMnUBrFV5cBFvdsHR/E+INPq6tor/dhN YAmQdbk8KB4YbcqdzK/E3SjFPT68xTZi2vM0tCri/BBf+PzopdFW1hFAqJoVWwHpz2Xq RJbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Jf4DKkfqoiK2D2I2fbfiEndTJTIFs7vQwXIkVE3HgWE=; b=nXP3s7D/IfRCwjB/kz4OHUfdjgdeQNFH4Xl5IxYf7Uq4lDHDRWl4zrQFhh7E8NowiV hJxHPNo0sBHhS9kjv/u0zOfVvIjeaQsqtWUh3QsZWIkYDanFPOlE4FwZbYh7ksrb98KF 4+cMF3LnHc18cN+ipCihY2UHAeL/kYMb7ZvFeOI+RpzT2fpyEX8LHjcduGAzc1QhxXmX oVvDCRWQW9YdhStpal/xvqW2IFdZ9FIozYIWtZXziMfuqKvpDAW8YiJkIVA4n+bLZakb m4udqair7hHkJmjaDm5WNLzlbXLH2meh4HtEkIG7vauunVcZtkZQ6KKUxFzYwIiMeZR4 LYjA==
X-Gm-Message-State: AJaThX5fGSwW2ckJZCGu7k5Aca1TemN8VScbND1zgDoPPtBe+ohTPvsV jdyzKX8zWqN8/Av0jftOxXPlCn7JySnYOScMZ0X4Cg==
X-Google-Smtp-Source: AGs4zMYPojZJeLDvguxFVF7rCGTfRAU3JpNQW4+PJf3B2k9jOVtENPlkB/b3//p2EVCCFXaYFOvJO4XkahAF0+GJeEc=
X-Received: by 10.202.48.8 with SMTP id w8mr3208658oiw.284.1512001572011; Wed, 29 Nov 2017 16:26:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.8.11 with HTTP; Wed, 29 Nov 2017 16:26:11 -0800 (PST)
From: Martin Thomson 
Date: Thu, 30 Nov 2017 11:26:11 +1100
Message-ID: 
To: "tls@ietf.org" , Sean Turner , Joseph Salowey 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: [TLS] Codepoint assignment for record limit
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 00:26:14 -0000

I am looking at landing code for this draft, which is easier with an
assigned code point.  Can I request a codepoint for this?


From nobody Thu Nov 30 09:43:25 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5327D126D85 for ; Thu, 30 Nov 2017 09:43:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 3gjPZwEyvxWH for ; Thu, 30 Nov 2017 09:43:21 -0800 (PST)
Received: from esa4.dyson.c3s2.iphmx.com (esa4.dyson.c3s2.iphmx.com [68.232.139.183]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04C2F126BF3 for ; Thu, 30 Nov 2017 09:43:20 -0800 (PST)
X-IronPort-SPF: SKIP
X-IronPort-AV: E=McAfee;i="5900,7806,8730"; a="26127773"
X-IronPort-AV: E=Sophos;i="5.45,341,1508799600"; d="scan'208";a="26127773"
Received: from unknown (HELO uk-dlp-smtp-01.dyson.global.corp) ([62.189.202.16]) by esa4.dyson.c3s2.iphmx.com with ESMTP; 30 Nov 2017 17:43:18 +0000
Received: from uk-dlp-smtp-01.dyson.global.corp (uk-dlp-smtp-01.dyson.global.corp [127.0.0.1]) by uk-dlp-smtp-01.dyson.global.corp (Service) with ESMTP id BB176FA10 for ; Thu, 30 Nov 2017 16:26:43 +0000 (GMT)
Received: from UK-MAL-CAS-02.dyson.global.corp (unknown [10.1.108.3]) by uk-dlp-smtp-01.dyson.global.corp (Service) with ESMTP id A3A7CFA02 for ; Thu, 30 Nov 2017 16:26:43 +0000 (GMT)
Received: from UK-MAL-MBOX-02.dyson.global.corp ([fe80::d06f:fa07:f6dd:5a9c]) by UK-MAL-CAS-02.dyson.global.corp ([fe80::d0fe:1c2d:58fc:2dbb%17]) with mapi id 14.03.0319.002; Thu, 30 Nov 2017 17:43:18 +0000
From: Tony Putman 
To: "tls@ietf.org" 
Thread-Topic: New Version Notification for draft-putman-tls-preshared-ecdh-00.txt
Thread-Index: AQHTafzmFrjATNGI7ku1Z80A/CPnz6MtLWfw
Date: Thu, 30 Nov 2017 17:43:18 +0000
Message-ID: <140080C241BAA1419B58F093108F9EDC0B0363F0@UK-MAL-MBOX-02.dyson.global.corp>
References: <151206123390.4809.15953787972366154379.idtracker@ietfa.amsl.com>
In-Reply-To: <151206123390.4809.15953787972366154379.idtracker@ietfa.amsl.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.1.108.27]
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Archived-At: 
Subject: [TLS] New Version Notification for draft-putman-tls-preshared-ecdh-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 17:43:23 -0000

SGksDQoNCkkndmUgZmxlc2hlZCBvdXQgbXkgaWRlYXMgb24gdGhlIHVzZSBvZiB0cmlwbGUtRUNE
SCBhdXRoZW50aWNhdGlvbiBmb3IgVExTIDEuMiBpbnRvIHRoZSBJLUQgcmVmZXJlbmNlZCBiZWxv
dy4gV2hpbGUgd29ya2luZyBvbiB0aGlzIEkgY2FtZSB0byBzb21lIG5ldyBjb25jbHVzaW9uczog
DQogLSBQRlMgbWF5IG5vdCBiZSBpbXBvcnRhbnQgZm9yIElvVCwgc28gSSBpbmNsdWRlZCBjaXBo
ZXIgc3VpdGVzIHVzaW5nIERvdWJsZS1FQ0RIIGFzIHdlbGwNCiAtIFByb3RlY3RpbmcgdGhlIFBT
SyBJZGVudGl0eSBpcyByZWFsbHkgZWFzeSwgc28gSSBhZGRlZCB0aGF0IGFzIHdlbGwNCiAtIEkg
YWRkZWQgdGhlIHN0YXRpYyBwdWJsaWMga2V5cyBpbnRvIHRoZSBwcmVtYXN0ZXIgY2FsY3VsYXRp
b24gdG8gbWF0Y2ggdGhlIHNlY3VyaXR5IHByb29mOyBJIGRvbid0IGtub3cgaWYgdGhpcyBpcyBu
ZWNlc3NhcnkNCg0KSSBzdXBwb3NlIHRoYXQgdGhlIG5leHQgc3RlcCBpcyB0byBmaW5kIG91dCBp
ZiBhbnlvbmUgZWxzZSBpcyBpbnRlcmVzdGVkIGluIHRoaXMgYXBwcm9hY2guIEknZCBhcHByZWNp
YXRlIGl0IGlmIHBlb3BsZSBjb3VsZCBzdWdnZXN0IG90aGVyIG1haWxpbmcgbGlzdHMgd2hvIG1p
Z2h0IHNob3cgYW4gaW50ZXJlc3QgKEFDRT8pLiBPdGhlciBxdWVzdGlvbnMgYW5kIHN1Z2dlc3Rp
b25zIGFyZSB3ZWxjb21lLiANCi0tIA0KVG9ueQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRz
QGlldGYub3JnXSANClNlbnQ6IDMwIE5vdmVtYmVyIDIwMTcgMTc6MDENClRvOiBUb255IFB1dG1h
bg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1wdXRtYW4tdGxz
LXByZXNoYXJlZC1lY2RoLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1w
dXRtYW4tdGxzLXByZXNoYXJlZC1lY2RoLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1
Ym1pdHRlZCBieSBUb255IFB1dG1hbiBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5
Lg0KDQpOYW1lOgkJZHJhZnQtcHV0bWFuLXRscy1wcmVzaGFyZWQtZWNkaA0KUmV2aXNpb246CTAw
DQpUaXRsZToJCUVDREgtYmFzZWQgQXV0aGVudGljYXRpb24gdXNpbmcgUHJlLVNoYXJlZCBBc3lt
bWV0cmljIEtleXBhaXJzIGZvciAoRGF0YWdyYW0pIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAo
KEQpVExTKSBQcm90b2NvbCB2ZXJzaW9uIDEuMg0KRG9jdW1lbnQgZGF0ZToJMjAxNy0xMS0zMA0K
R3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTcNClVSTDogICAgICAgICAg
ICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcHV0bWFuLXRscy1w
cmVzaGFyZWQtZWNkaC0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2Vy
LmlldGYub3JnL2RvYy9kcmFmdC1wdXRtYW4tdGxzLXByZXNoYXJlZC1lY2RoLw0KSHRtbGl6ZWQ6
ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wdXRtYW4tdGxzLXByZXNo
YXJlZC1lY2RoLTAwDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y
Zy9kb2MvaHRtbC9kcmFmdC1wdXRtYW4tdGxzLXByZXNoYXJlZC1lY2RoLTAwDQoNCg0KQWJzdHJh
Y3Q6DQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBuZXcgbXV0dWFsIGF1dGhlbnRpY2F0aW9u
IG1ldGhvZCBmb3IgdGhlDQogICBUcmFuc3BvcnQgTGF5ZXIgU2VjdXJpdHkgKFRMUykgcHJvdG9j
b2wgdmVyc2lvbiAxLjIuICBUaGUNCiAgIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCByZXF1aXJlcyB0
aGF0IHRoZSBjbGllbnQgYW5kIHNlcnZlciBhcmUgZWFjaA0KICAgcHJlLXByb3Zpc2lvbmVkIHdp
dGggYSB1bmlxdWUgYXN5bW1ldHJpYyBFbGxpcHRpYyBDdXJ2ZSBEaWZmaWUtDQogICBIZWxsbWFu
IChFQ0RIKSBrZXlwYWlyIGFuZCB3aXRoIHRoZSBwdWJsaWMgRUNESCBrZXkgb2YgdGhlIHBlZXIu
ICBUaGUNCiAgIGhhbmRzaGFrZSBwcm92aWRlcyBlcGhlbWVyYWwgRUNESCBrZXlzLCBhbmQgYSBw
cmVtYXN0ZXIga2V5IGlzIGFncmVlZA0KICAgdXNpbmcgRG91YmxlLSBvciBUcmlwbGUtRUNESDsg
Y29uZmlybWF0aW9uIG9mIHBvc3Nlc3Npb24gb2YgdGhpcyBrZXkNCiAgIHByb3ZpZGVzIG11dHVh
bCBhdXRoZW50aWNhdGlvbi4gIE11bHRpcGxlIG5ldyBjaXBoZXIgc3VpdGVzIHdoaWNoIHVzZQ0K
ICAgdGhpcyBhdXRoZW50aWNhdGlvbiBtZXRob2QgYXJlIHNwZWNpZmllZC4NCg0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw
bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1s
aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoN
ClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCgpEeXNvbiBUZWNobm9sb2d5IExpbWl0ZWQsIGNvbXBh
bnkgbnVtYmVyIDAxOTU5MDkwLCBUZXRidXJ5IEhpbGwsIE1hbG1lc2J1cnksIFNOMTYgMFJQLCBV
Sy4KVGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZSBhbmQg
bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLiBJZiB5b3UgaGF2ZSByZWNlaXZl
ZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50
bHkgZGVsZXRlIGl0LCBhbmQgZG8gbm90IHVzZSwgY29weSBvciBkaXNjbG9zZSB0aGUgaW5mb3Jt
YXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBvciBpbiBhbnkgYXR0YWNobWVudC4KRHlz
b24gbWF5IG1vbml0b3IgZW1haWwgdHJhZmZpYyBkYXRhIGFuZCBjb250ZW50IGZvciBzZWN1cml0
eSAmIHRyYWluaW5nLgo=


From nobody Thu Nov 30 10:31:29 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9112128959 for ; Thu, 30 Nov 2017 10:31:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level: 
X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=katriel.co.uk header.b=PuYQoreW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dq++dJoG
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 tJeKCATWYiob for ; Thu, 30 Nov 2017 10:31:24 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 982821286B1 for ; Thu, 30 Nov 2017 10:31:24 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D224920CC9; Thu, 30 Nov 2017 13:31:23 -0500 (EST)
Received: from web6 ([10.202.2.216]) by compute6.internal (MEProxy); Thu, 30 Nov 2017 13:31:23 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=katriel.co.uk; h=content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=yWmu6JbwdCg3VbIRego+aMqlNY DShrNougKOr7QF8ag=; b=PuYQoreWIdRWhvj30/7yU4O04tji8o0EzvHhmZdyHk NaOea5Fs+k9TwZ396TXDktiGoXulblqJACOhyyuuKgfWRcdEdPGdlWpPnq69ylEH tL9g8advdKlNk+A+Y86kc5e9tNwNIhlaNolI742xrV+eqLSGrOKWmgcuGQt9rHIn k=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=yWmu6J bwdCg3VbIRego+aMqlNYDShrNougKOr7QF8ag=; b=dq++dJoG/VJRNdmpeMpog8 8DSts4xhalkHcgFkAb4GF3SHS+4s7ufuE+7MOxiU2oMcM63rX6KCZ7FkM+ID7CEp WQ3H+PJWFaiM+Z+zqyEw1BIj4rBH7q0oozn6ZWK8Xtkva0OtzCd4Zp5fSdWxxM3i jrWBMa4hBUj3t5XrjUGy0ZxEmCOAO9qo/K8A+VhlwBocj5ow/ihT5O1LUOr7JY2+ gmWxsoJYaKIjPgjHcUvkGyQUeFisyBVGcBXzRJtfBTJF6eZhF82x8NvCjWkfIxp+ a3I9q1fvJLWUP5tNsLAbrR1IYv+AK4jdp+fAj0p87yMSkeEO73mV6SDpa11JvO2Q ==
X-ME-Sender: 
Received: by mailuser.nyi.internal (Postfix, from userid 99) id AA8ED411D; Thu, 30 Nov 2017 13:31:23 -0500 (EST)
Message-Id: <1512066683.2703229.1189737376.36787A76@webmail.messagingengine.com>
From: "Katriel Cohn-Gordon" 
To: Tony Putman , tls@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-a169161c
References: <151206123390.4809.15953787972366154379.idtracker@ietfa.amsl.com> <140080C241BAA1419B58F093108F9EDC0B0363F0@UK-MAL-MBOX-02.dyson.global.corp>
Date: Thu, 30 Nov 2017 18:31:23 +0000
In-Reply-To: <140080C241BAA1419B58F093108F9EDC0B0363F0@UK-MAL-MBOX-02.dyson.global.corp>
Archived-At: 
Subject: Re: [TLS] New Version Notification for draft-putman-tls-preshared-ecdh-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 30 Nov 2017 18:31:27 -0000

If you add the fourth (static-static) DH, you should be protected
against poor generation of ephemeral keys.

(For example, IoT devices might have a long-term DH key provisioned in
the factory, but broken RNGs. If two of them talk to each other using
triple DH no security is achieved, but if the static-static is included
then the connection will still be secure)

Katriel

On Thu, 30 Nov 2017, at 05:43 PM, Tony Putman wrote:
> Hi,
> 
> I've fleshed out my ideas on the use of triple-ECDH authentication for
> TLS 1.2 into the I-D referenced below. While working on this I came to
> some new conclusions: 
>  - PFS may not be important for IoT, so I included cipher suites using
>  Double-ECDH as well
>  - Protecting the PSK Identity is really easy, so I added that as well
>  - I added the static public keys into the premaster calculation to match
>  the security proof; I don't know if this is necessary
> 
> I suppose that the next step is to find out if anyone else is interested
> in this approach. I'd appreciate it if people could suggest other mailing
> lists who might show an interest (ACE?). Other questions and suggestions
> are welcome. 
> -- 
> Tony
> 
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
> Sent: 30 November 2017 17:01
> To: Tony Putman
> Subject: New Version Notification for
> draft-putman-tls-preshared-ecdh-00.txt
> 
> 
> A new version of I-D, draft-putman-tls-preshared-ecdh-00.txt
> has been successfully submitted by Tony Putman and posted to the
> IETF repository.
> 
> Name:           draft-putman-tls-preshared-ecdh
> Revision:       00
> Title:          ECDH-based Authentication using Pre-Shared Asymmetric
> Keypairs for (Datagram) Transport Layer Security ((D)TLS) Protocol
> version 1.2
> Document date:  2017-11-30
> Group:          Individual Submission
> Pages:          17
> URL:           
> https://www.ietf.org/internet-drafts/draft-putman-tls-preshared-ecdh-00.txt
> Status:        
> https://datatracker.ietf.org/doc/draft-putman-tls-preshared-ecdh/
> Htmlized:      
> https://tools.ietf.org/html/draft-putman-tls-preshared-ecdh-00
> Htmlized:      
> https://datatracker.ietf.org/doc/html/draft-putman-tls-preshared-ecdh-00
> 
> 
> Abstract:
>    This document defines a new mutual authentication method for the
>    Transport Layer Security (TLS) protocol version 1.2.  The
>    authentication method requires that the client and server are each
>    pre-provisioned with a unique asymmetric Elliptic Curve Diffie-
>    Hellman (ECDH) keypair and with the public ECDH key of the peer.  The
>    handshake provides ephemeral ECDH keys, and a premaster key is agreed
>    using Double- or Triple-ECDH; confirmation of possession of this key
>    provides mutual authentication.  Multiple new cipher suites which use
>    this authentication method are specified.
> 
>                                                                                   
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> Dyson Technology Limited, company number 01959090, Tetbury Hill,
> Malmesbury, SN16 0RP, UK.
> This message is intended solely for the addressee and may contain
> confidential information. If you have received this message in error,
> please immediately and permanently delete it, and do not use, copy or
> disclose the information contained in this message or in any attachment.
> Dyson may monitor email traffic data and content for security & training.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


I took a look at this.

Witho=
ut getting into the question of whether the types of middleboxes
=
you describe here provide a security benefit, there are several points
in the document that are either wrong or at least misleading/confusin=
g.

- Key Synchronization
This document n=
otes that in TLS 1.2, it is possible for a middlebox
that traffic=
 keys match on both sides of the connection it is proxying,
but i=
n TLS 1.3 it is not:

=C2=A0 =C2=A0There are severa=
l techniques that can be utilized.=C2=A0 Those techniques
=C2=A0 =
=C2=A0function with TLS 1.2 and earlier versions but not with TLS 1.3.

=C2=A0 =C2=A0One technique is for the middlebox to neg=
otiate the same master
=C2=A0 =C2=A0secret with the original TLS =
client and server, as if the two
=C2=A0 =C2=A0endpoints handshake=
 directly.=C2=A0 This is also known as "Triple
=C2=A0 =C2=A0=
Handshake" used by legitimate middleboxes.=C2=A0 [BreakTLS] describes =
the
=C2=A0 =C2=A0methods with RSA and DH key exchanges.=C2=A0 Whe=
n the proxy session keys
=C2=A0 =C2=A0are the same as for a direc=
t handshake, the middlebox is able to
=C2=A0 =C2=A0"cut-thro=
ugh" the two TLS proxy sessions when it finishes the
=C2=A0 =
=C2=A0security inspection.

=C2=A0 =C2=A0This techn=
ique is not functional with TLS 1.3 since the transcript
=C2=A0 =
=C2=A0hash over the handshake messages is part of the key derivation
<=
div>=C2=A0 =C2=A0procedure.

First, I would note th=
at this property of TLS 1.2 is bad, as it leads
to Unknown Key Sh=
are (UKS) attacks, which can be the basis of real
attacks on TLS =
1.2 as fielded. It is for this reason that the TLS
WG published R=
FC 7627.

Second, this property is really only avai=
lable with RSA. Although
it is possible for an attacker to synchr=
onize DH keys by generating
bogus DH parameters, the technique de=
scribed by Bhargavan et al
results in an insecure MS (i.e., the s=
erver's public DH share).
Any middlebox doing this, therefore, has comp=
letely broken TLS
for the endpoints on both sides of it. Your doc=
ument suggests
that people do use this technique: I sincerely hop=
e not.

In short, this property of TLS 1.3 is reall=
y a property of the use
of (EC)DHE [0], the use of which is impor=
tant for security even in TLS 1.2
(hence the rapid increase in th=
e use of ECDHE and the corresponding
decline in static RSA). Even=
 if TLS 1.3 were never deployed, the
continued use of static RSA =
is going to be come increasingly
nonviable.

<=
div>Finally, you note several times in the document (e.g., S 4.5), that
with key synchronization, the middlebox can perform the handshake an=
d
then disengage from the connection. However, the cases you ment=
ion
(e.g.., detecting exploit attempts) ultimately require examin=
ing
all traffic in the connection.


<=
/div>
- PSK and resumption
You write:

=C2=A0 =C2=A0In TLS 1.3, the above mechanism is replaced by Pre-Shared Ke=
ys (PSK),
=C2=A0 =C2=A0which can be negotiated as part of an init=
ial handshake and then used
=C2=A0 =C2=A0in a subsequent handshak=
e to perform resumption using the PSK.=C2=A0 TLS
=C2=A0 =C2=A01.3=
 states that the client SHOULD include a "key_share" extension to=

=C2=A0 =C2=A0enable the server to decline resumption and fall ba=
ck to a full
=C2=A0 =C2=A0handshake, however it is not an absolut=
e requirement.

=C2=A0 =C2=A0Example scenarios that=
 are impacted by this are middleboxes that were
=C2=A0 =C2=A0not =
part of the initial handshake, and hence do not know the PSK.=C2=A0 If
=C2=A0 =C2=A0the client does not include the "key_share" ex=
tension, the middlebox
=C2=A0 =C2=A0cannot force a fallback to th=
e full handshake.=C2=A0 If the middlebox
=C2=A0 =C2=A0policy requ=
ires it to inspect the session, it will have to fail the
=C2=A0 =
=C2=A0connection instead.

In TLS 1.3, PSKs and ses=
sion resumption are basically the same and
have the same properti=
es. While I concede that the document does
not require the client=
 to offer key_shares, as a practical matter
it is very unlikely t=
hat a client will act in such a way that
failure to retain the PS=
K causes a hard failure, for two reasons:

(a) In e=
very version of TLS, the ticket lifetime is just a hint, and
=C2=
=A0 =C2=A0 the server can forget it at any time
=C2=A0 =C2=A0 (https://tlswg.github.io/tls13-spec/draft-ietf=
-tls-tls13.html#NSTMessage). Thus,
=C2=A0 =C2=A0 a clien=
t which does not allow a full handshake will often
=C2=A0 =C2=A0 =
find itself unable to connect.

(b) The relevant qu=
estion is not whether the client offers a key share
=C2=A0 =C2=A0=
 extension but whether it advertises any DH groups. If the client sends
=C2=A0 =C2=A0 a group but not a key share, the server can send Hello=
RetryRequest
=C2=A0 =C2=A0 to force the client to send a key shar=
e.

For these reasons, as far as I know, every clie=
nt (and at least every
browser client) should allow a full handsh=
ake even when trying to resume.


- S=
erver Certificate Concealment
You note that in TLS 1.2 the middle=
box can examine both the SNI and the
server's certificate in =
order to decide whether to MITM the connection,
but that in TLS 1=
.3, the middlebox cannot guarantee that the SNI in
uses is correc=
t:

=C2=A0 =C2=A0In TLS 1.2, the ClientHello, Serve=
rHello and Certificate messages are
=C2=A0 =C2=A0all sent in clea=
r-text, however in TLS 1.3, the Certificate message
=C2=A0 =C2=A0=
is encrypted thereby hiding the server identity from any
=C2=A0 =
=C2=A0intermediary.=C2=A0 Note that even _if_ the SNI is provided (in clear=
text)
=C2=A0 =C2=A0by the client, there is no guarantee that the =
actual server
=C2=A0 =C2=A0responding is the one indicated in the=
 SNI from the client.

In this case, it's impor=
tant to distinguish between conformant and
nonconformant clients.=
 In the former case -- as when the user is
not attempting to evad=
e inspection -- the SNI will reflect the
identity that the client=
 expects and therefore will compare the
certificate against.

Of course, in the case where the client is attempting =
to evade
inspection, the certificate might not match. However, in=
 this
scenario, the client and server are colluding and so there =
are
a variety of ways to avoid inspection, even when doing TLS 1.=
2.

For example:

1. The cl=
ient and server can share a prearranged public key and then
negot=
iate static RSA. The client sends an innocuous SNI and the server
can simply send the certificate of the corresponding server, captured
by connecting to that server. The client then enciphers the PMS
=

under the server's prearranged key and continues with TLS as usual=
.
This cannot be detected by the middlebox without decrypting the=
 EPMS.

2. If an (EC)DHE cipher suite must be negot=
iated, then the attack
described above does not work directly bec=
ause the server's signature
over the ServerKeyExchange can be=
 validated, and of course the
attacker server does not have the l=
egitimate server's key. However,
the server can forward the C=
lientHello to the legitimate server,
capture the Certificate and =
ServerKeyExchange and the proxy those to
the client. This looks l=
egitimate to the inspection device and then
the client can simply=
 send the Encrypted PMS in the first chunk of
data that is appare=
ntly encrypted under the server's key.

For the=
se reasons, being able to see the server's certificate provides
a false sense of security, as this check is easily bypassed.
<=
br>
-Ekr


[0] Note: the us=
e of static DH is very rare.


On Fri, Nov 3, 2017 at 6:49 PM, Nancy=
 Cam-Winget (ncamwing) <ncamwing@cisco.com> wrote:













All, 


=
=C2=A0


@IETF99=
, awareness was raised to some of the security WGs (thanks Kathleen
=E2=98=BA) t=
hat TLS 1.3 will obscure visibility currently afforded in TLS 1.2 and asked=
 what the implications would be for the security solutions
 today.=C2=A0=C2=A0=
https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00=C2=A0is
 an initial draft to describe some of the impacts relating to current netwo=
rk security solutions.=C2=A0=C2=A0The goal of the draft is NOT to propose a=
ny solution as a few have been proposed, but rather to raise awareness to h=
ow current network-based security solutions
 work today and their impact on them based on the current TLS 1.3 specifica=
tion.


=C2=A0


Regards, Nancy, Fle=
mming and Eric







_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls





--001a11431c64da123f055d5401e6--


From nobody Mon Nov  6 10:19:46 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84F213FC5E for ; Mon,  6 Nov 2017 10:19:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 rJ65_csmH6Ys for ; Mon,  6 Nov 2017 10:19:43 -0800 (PST)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 69F1813FB8E for ; Mon,  6 Nov 2017 10:19:43 -0800 (PST)
Received: by mail-yw0-x22d.google.com with SMTP id k11so8641208ywh.1 for ; Mon, 06 Nov 2017 10:19:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=6Qcc8GEY4rFzaDKxwlryb1dILLqxGqhguGrcBbzT/cU=; b=mUwxjejxeH5U7kDZl84YvIwSbov8DJBWo141wSYNKJEqFQjSLm3xKGXJ/iVM0ngmXH avNvikW9k6FyRs62uW9DMZWaZWG6aLZj0koMPvc1iDqnUS2OmR8h4AUz/gMpc717crrj KtIyyn1sKjR3XP+KNsLN20FI7W0biaEx6QasNUvQa5LxTO068ShroqwT2d1dYhjI8apZ q8TPF0NoOSD8PVzRvkEIc8rsWN+LnSt8MTMQoutdrS7JSjSQlQ+aatWBG/YaS24RTjol EMRRuh6Qz0Ul7MeELyWMZZdiz+rKhBBS2Nnzat8j6CVI4h2/qAqZXsL0LwnBE+3dVu4X IX5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6Qcc8GEY4rFzaDKxwlryb1dILLqxGqhguGrcBbzT/cU=; b=CtPb31eAtxS8I9zFmjqWteDKzZUYkwb1MBSLrms5ZbpKDOtReHA7/JZAs8HhIrT29h 7zbfM2a3HBU155AUY7qHO54Qmm7NkpquR6oUqaGQfVRWd9Ad6opPqGylP1yQyVYe8ZoJ LgCzxz0Xn7Wesz0XDwtDvrgPt7n3VNiT5O2cEzYats488WM8NnSNLZ5H/Wt0ID+nJWe3 cErAJDxmZ8HIHrvop7QKGU1jjLz/b7xQvG+FXAKXtMnFM9SHnHpwjpPoj4Qe0xIMTB++ Y9gVO8vLHU225Oyo0GpJSvovACSMEWvyFTD9JWyeIIrIMrCImCRkLzKEJm97J5OJQUjl GXWw==
X-Gm-Message-State: AMCzsaU8jBOi/tPM8A4lnupAaSEl8Hdb8kKiOTaP11fkDPKD1h8o+56c 95KS19S680DC2ocbVr6SGXc7yxOuysNUkFGSu5DfsNHum14=
X-Google-Smtp-Source: ABhQp+RNpbHDm/zTkzA5EiVLJqfAaJcrtLjXbRE/Feu96SHpL2CkeBkLj7meWceuIG0LVaaCEK8gAXvuNTfJwlgzeAE=
X-Received: by 10.37.195.65 with SMTP id t62mr10037301ybf.71.1509992382288; Mon, 06 Nov 2017 10:19:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.61.12 with HTTP; Mon, 6 Nov 2017 10:19:01 -0800 (PST)
From: Eric Rescorla 
Date: Mon, 6 Nov 2017 10:19:01 -0800
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114d7db28f671b055d547f8e"
Archived-At: 
Subject: [TLS] PR#1091: Changes to provide middlebox robustness
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Nov 2017 18:19:45 -0000

--001a114d7db28f671b055d547f8e
Content-Type: text/plain; charset="UTF-8"

https://github.com/tlswg/tls13-spec/pull/1091

As I mentioned a while back, we've been seeing evidence of middlebox
intolerance. I just posted PR 1091, which is based on a bunch of work
by the BoringSSL team and an original suggestion by Kyle Nekritz that
should significantly decrease the rate of these errors.

The general idea here is to make TLS 1.3 look more like TLS 1.2
resumption. The major changes are:

- Move version negotiation entirely into "supported_versions", and hence
  ServerHello.version == 0x0303 (TLS 1.2)
- Restore the missing session_id and compression fields in ServerHello
- The client sends a fake session_id and the server echoes it
- The server sends ChangeCipherSpec messages after
ServerHello/HelloRetryRequest
  (so that the middlebox ignores any "encrypted" data afterwards),
  and the client sends ChangeCipherSpec after ClientHello. Either
  side has to ignore ChangeCipherSpec during the handshake.
- Merge HRR and ServerHello into a single message with the semantics
  distinguished by a special ServerHello.Random value.
- Switch the record layer version to 0x0303 for post-ClientHello
  messages to match ServerHello.

Once you do this, the middleboxes seem to mostly ignore everything
after the CCS, so the rest of the handshake proceeds smoothly.

This is all a bit nasty, but none of it changes the cryptographic
computations or the state machine (because you just ignore CCS).
Several of the most unpleasant changes (sending fake session id and
sending ChangeCipherSpec), are only needed in compatibility mode,
and if you don't have to worry about middleboxes, you can just
omit them.

There are implementations of these changes (except for HRR) in both
BoringSSL and NSS, and Google has preliminary measurements with these
changes that show comparable error rates to TLS 1.2 (I expect them to
publish those shortly). We expect to have further measurements from
Chrome as well as from Firefox by the WG meeting.

Please take a look and hopefully we can close on this in Singapore.

-Ekr

--001a114d7db28f671b055d547f8e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



=

As I mentioned a while back, we've been seeing evidence of middleb=
ox
intolerance. I just posted PR 1091, which is based on a bunch =
of work
by the BoringSSL team and an original suggestion by Kyle =
Nekritz that
should significantly decrease the rate of these erro=
rs.

The general idea here is to make TLS 1.3 look =
more like TLS 1.2
resumption. The major changes are:
- Move version negotiation entirely into "supported_versi=
ons", and hence
=C2=A0 ServerHello.version =3D=3D 0x0303 (TL=
S 1.2)
- Restore the missing session_id and compression fields in=
 ServerHello
- The client sends a fake session_id and the server =
echoes it
- The server sends ChangeCipherSpec messages after Serv=
erHello/HelloRetryRequest
=C2=A0 (so that the middlebox ignores a=
ny "encrypted" data afterwards),
=C2=A0 and the client =
sends ChangeCipherSpec after ClientHello. Either
=C2=A0 side has =
to ignore ChangeCipherSpec during the handshake.
- Merge HRR and =
ServerHello into a single message with the semantics
=C2=A0 disti=
nguished by a special ServerHello.Random value.
- Switch the reco=
rd layer version to 0x0303 for post-ClientHello
=C2=A0 messages t=
o match ServerHello.
=C2=A0=C2=A0
Once you do this, the=
 middleboxes seem to mostly ignore everything
after the CCS, so t=
he rest of the handshake proceeds smoothly.

This i=
s all a bit nasty, but none of it changes the cryptographic
compu=
tations or the state machine (because you just ignore CCS).
Sever=
al of the most unpleasant changes (sending fake session id and
se=
nding ChangeCipherSpec), are only needed in compatibility mode,
a=
nd if you don't have to worry about middleboxes, you can just
omit them.

There are implementations of these cha=
nges (except for HRR) in both
BoringSSL and NSS, and Google has p=
reliminary measurements with these
changes that show comparable e=
rror rates to TLS 1.2 (I expect them to
publish those shortly). W=
e expect to have further measurements from
Chrome as well as from=
 Firefox by the WG meeting.

Please take a look and=
 hopefully we can close on this in Singapore.

-Ekr=

=C2=A0


--001a114d7db28f671b055d547f8e--


From nobody Mon Nov  6 17:15:30 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA6813FB49 for ; Mon,  6 Nov 2017 17:15:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level: 
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 8GgFSgEP6GNx for ; Mon,  6 Nov 2017 17:15:25 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5F9213FADA for ; Mon,  6 Nov 2017 17:15:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=63256; q=dns/txt; s=iport; t=1510017325; x=1511226925; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XICffXAmP5FjAZOo4ewL+5icBhTRUkSI+qG5BJ0oI2o=; b=TAPzBnhbslnId+YHwtySylVm8QWi9HULitN2yQwY3wL4V20tkHmXPShR 3PLgRjYSgsri1/gXANFpNyw4aTGZSZlF7KbzziklcLpZBQ1rCeRjT/SLU nk4w11ExFEq+97TrDaMzWtBiLy5E1k/WL8vc0b0xrgZk3tuc3sfirpIm5 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CWAQCeCAFa/4ENJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgkRCLmRuJweDdplAgXx9ggCTSYEyA1wKGAEKgV6DOgIahE9BFgE?= =?us-ascii?q?BAQEBAQEBAWsohR4BAQEEAQEYCQQGQQkCEAIBCA4DBAEBIQEGAwICAiULFAkIA?= =?us-ascii?q?gQKBAUIE4kkZBCpdYFtOosUAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYMugQ4nUoF?= =?us-ascii?q?TgWmCHVg1hHtMCIJXgmIFii6HMJAwAodkjQ2CHl+FJIscjGGJCAIRGQGBOAEPF?= =?us-ascii?q?wIvT4EdehUfKoJkCYRWdwGKECyBBYERAQEB?=
X-IronPort-AV: E=Sophos; i="5.44,355,1505779200"; d="scan'208,217"; a="27169046"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Nov 2017 01:15:24 +0000
Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vA71FOSq024791 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Nov 2017 01:15:24 GMT
Received: from xch-rcd-012.cisco.com (173.37.102.22) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 6 Nov 2017 19:15:23 -0600
Received: from xch-rcd-012.cisco.com ([173.37.102.22]) by XCH-RCD-012.cisco.com ([173.37.102.22]) with mapi id 15.00.1320.000; Mon, 6 Nov 2017 19:15:23 -0600
From: "Owen Friel (ofriel)" 
To: Ben Schwartz 
CC: Richard Barnes , "" 
Thread-Topic: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt
Thread-Index: AQHTUbfdWlszSrswCU+9CVrREn/H1KL9SjIAgAACWICAAAM5gIAAACMAgAABfwCAAAVAgIAAKr4AgADoaBCAAGG6gIAJTdmw
Date: Tue, 7 Nov 2017 01:15:23 +0000
Message-ID: <9668bf1b98474e50a46347d9199ffd8c@XCH-RCD-012.cisco.com>
References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com>         
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.55.8.30]
Content-Type: multipart/alternative; boundary="_000_9668bf1b98474e50a46347d9199ffd8cXCHRCD012ciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Nov 2017 01:15:29 -0000

--_000_9668bf1b98474e50a46347d9199ffd8cXCHRCD012ciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQoNCkZyb206IEJlbiBTY2h3YXJ0eiBbbWFpbHRvOmJlbWFzY0Bnb29nbGUuY29tXQ0KU2VudDog
VHVlc2RheSAzMSBPY3RvYmVyIDIwMTcgMjE6MTcNClRvOiBPd2VuIEZyaWVsIChvZnJpZWwpIDxv
ZnJpZWxAY2lzY28uY29tPg0KQ2M6IFJpY2hhcmQgQmFybmVzIDxybGJAaXB2LnN4PjsgPHRsc0Bp
ZXRmLm9yZz4gPHRsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVExTXSBOZXcgVmVyc2lvbiBO
b3RpZmljYXRpb24gZm9yIGRyYWZ0LWZyaWVsLXRscy1vdmVyLWh0dHAtMDAudHh0DQoNCg0KDQpP
biBUdWUsIE9jdCAzMSwgMjAxNyBhdCA1OjAzIFBNLCBPd2VuIEZyaWVsIChvZnJpZWwpIDxvZnJp
ZWxAY2lzY28uY29tPG1haWx0bzpvZnJpZWxAY2lzY28uY29tPj4gd3JvdGU6DQoNCg0KRnJvbTog
VExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnRscy1ib3VuY2VzQGlldGYu
b3JnPl0gT24gQmVoYWxmIE9mIEJlbiBTY2h3YXJ0eg0KU2VudDogMzEgT2N0b2JlciAyMDE3IDAx
OjM1DQpUbzogUmljaGFyZCBCYXJuZXMgPHJsYkBpcHYuc3g8bWFpbHRvOnJsYkBpcHYuc3g+Pg0K
Q2M6IDx0bHNAaWV0Zi5vcmc8bWFpbHRvOnRsc0BpZXRmLm9yZz4+IDx0bHNAaWV0Zi5vcmc8bWFp
bHRvOnRsc0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW1RMU10gTmV3IFZlcnNpb24gTm90aWZp
Y2F0aW9uIGZvciBkcmFmdC1mcmllbC10bHMtb3Zlci1odHRwLTAwLnR4dA0KDQpPbiBNb24sIE9j
dCAzMCwgMjAxNyBhdCA3OjAyIFBNLCBSaWNoYXJkIEJhcm5lcyA8cmxiQGlwdi5zeDxtYWlsdG86
cmxiQGlwdi5zeD4+IHdyb3RlOg0KSXQgcmVxdWlyZXMgYXdhcmVuZXNzIGluIHRoZSBmb2xsb3dp
bmcgc2Vuc2U6IElmIGJ5IGNoYW5jZSB0aGUgY2xpZW50IGlzIGluIGEgbmljZSwgb3BlbiBuZXR3
b3JrIGFuZCB0aGUgYmFzZSBUTFMgY29ubmVjdGlvbiBnb2VzIGRpcmVjdGx5IHRvIHRoZSBzZXJ2
ZXIsIENPTk5FQ1QgaXMga2luZCBvZiB1bm5hdHVyYWw7IHlvdSB3b3VsZCB3YW50IHRoZSBjbGll
bnQgdG8gZG8gc29tZXRoaW5nIGRpZmZlcmVudCBpbiB0aGF0IGNhc2UuDQoNClN1cmVseSB0aGlz
IGlzIGVxdWFsbHkgdHJ1ZS91bnRydWUgb2YgQVRMUy4gIFdoeSBkbyBkb3VibGUtVExTIGlmIGl0
IGNhbiBiZSBhdm9pZGVkPyAgQnV0IHRoZW4sIGhvdyBkb2VzIHRoZSBhcHBsaWNhdGlvbiBrbm93
IHdoZXRoZXIgdG8gZG8gQVRMUyBlbmNhcHN1bGF0aW9uPyAgSXQncyB0aGUgc2FtZSBxdWVzdGlv
biBpbiBib3RoIGNhc2VzLg0KDQpbb2ZyaWVsXSBUaGUgZHJhZnQgZG9lcyBzdGF0ZSDigJxBcyBh
biBvcHRpbWlzYXRpb24sIGNsaWVudHMgbWF5IGNob29zZSB0byBvbmx5IHVzZSBBVExTIGFzIGEg
ZmFsbGJhY2sNCiAgIG1lY2hhbmlzbSBpZiBjZXJ0aWZpY2F0ZSB2YWxpZGF0aW9uIGZhaWxzIG9u
IHRoZSB0cmFuc3BvcnQgbGF5ZXIgVExTDQogICBjb25uZWN0aW9uIHRvIHRoZSBzZXJ2aWNlDQri
gJ0NCkl0IHNob3VsZCBiZSBlYXN5IGZvciBhIGRldmljZSB0byBkZXRlY3QgdGhlIHByZXNlbmNl
IG9mIGEgbWlkZGxlYm94IGlmIHRoZSBuZXR3b3JrIGxheWVyIFRMUyBjb25uZWN0aW9uIHByZXNl
bnRzIGEgc2VydmljZSBjZXJ0aWZpY2F0ZSB0aGF0IGhhcyB0aGUgZXhwZWN0ZWQgU0FOL0NOLCBi
dXQgaXMgc2lnbmVkIGJ5IGFuIHVuZXhwZWN0ZWQvdW50cnVzdGVkIENBIChpLmUuIG9uZSBub3Qg
YmFrZWQgaW50by9leHBsaWNpdGx5IGNvbmZpZ3VyZWQgb24gdGhlIGRldmljZSkuDQoNClllcywg
YnV0IHRoZSBjbGllbnQgY291bGQgZXF1YWxseSB3ZWxsIGZhbGwgYmFjayB0byBIVFRQIENPTk5F
Q1QgaW4gdGhpcyBjYXNlLiAgTXkgY29tbWVudHMgYXJlIGFsbCBkaXJlY3RlZCB0byB0aGUgcXVl
c3Rpb24gb2Ygd2h5IHRvIHVzZSBBVExTIGluc3RlYWQgb2YgYW4gZXhpc3Rpbmcgc29sdXRpb24s
IHN1Y2ggYXMgIlRMUyBvdmVyIEhUVFAgQ09OTkVDVCIuDQoNCltvZnJpZWxdIEkgZnVsbHkgYWdy
ZWUgdGhhdCBpZiBhIFRMUyB0dW5uZWwgb3BlbmVkIHZpYSBIVFRQIENPTk5FQ1QgaXMgcG9zc2li
bGUsIHRoZW4gQVRMUyBpcyBub3QgbmVlZGVkIGFzIHRoZSBUTFMgY29ubmVjdGlvbiBpcyBlMmUg
YmV0d2VlbiBDLT5TIGFuZCB0aGUgbWlkZGxlYm94IGlzIG5vdCBpbnNwZWN0aW5nIHRyYWZmaWMu
IEhvd2V2ZXIsIGlmIHRoZSBtaWRkbGVib3ggcHJveHkgZW5mb3JjZXMgVExTIGluc3BlY3Rpb24g
YW5kIGRvZXMgbm90IGFsbG93IG9wZW5pbmcgYSBUTFMgdHVubmVsIHZpYSBIVFRQIENPTk5FQ1Qs
IHRoZW4gdGhlIGR1bWIgSW9UIGRldmljZSB3aWxsIGZhaWwgY2VydCB2YWxpZGF0ZSBvbiB0aGUg
VExTIGNvbm5lY3Rpb24gdGVybWluYXRlZCBvbiB0aGUgbWlkZGxlYm94Lg0KDQogIFlvdSdyZSBj
b3JyZWN0IHRoYXQgeW91ICpjb3VsZCogY29uZmlndXJlIHRoZSBzZXJ2ZXIgdG8gaGFuZGxlIGNv
bm5lY3QgcHJvcGVybHksIGJ1dCBhbGwgb2YgdGhlIG9wdGlvbnMgZm9yIGRvaW5nIHRoaXMgYXJl
IGtpbmQgb2YgY3VtYmVyc29tZSAtLSBlaXRoZXIgeW91IGhhdmUgdG8gc3RpY2sgYSBwb3NzaWJs
eS11bm5lY2Vzc2FyeSBwcm94eSBpbiBmcm9udCBvZiB0aGUgc2VydmVyLCBvciBoYW5kbGUgQ09O
TkVDVCBvbiB0aGUgc2VydmVyLCB3aGljaCBpcyBub3QgcmVhbGx5IHdlbGwtc3VwcG9ydGVkIGJ5
IHdlYiBhcHBsaWNhdGlvbiBmcmFtZXdvcmtzLiAgQnkgY29udHJhc3QsIHJ1bm5pbmcgZGF0YSBv
dmVyIFBPU1QgaXMgdWJpcXVpdG91cy4NCg0KVGhpcyBtYWtlcyBhIGNlcnRhaW4gYW1vdW50IG9m
IHNlbnNlIHRvIG1lLiAgSWYgaXQgd2VyZSB1cCB0byBtZSwgcmF0aGVyIHRoYW4gZGVzaWduIGEg
VExTLXNwZWNpZmljIHRyYW5zcG9ydCwgSSdkIGJlIG1vcmUgaW5jbGluZWQgdG8gcHJvcG9zZSBh
IHN0YW5kYXJkaXplZCB2ZXJzaW9uIG9mIHNvbWV0aGluZyBsaWtlIENyb3diYXI8aHR0cHM6Ly9n
aXRodWIuY29tL3Ezay9jcm93YmFyPi4NCltvZnJpZWxdIC9tZSByZWFkcy4g4oCYbGlrZeKAmSBh
cHBlYXJzIHRvIGJlIHRoZSBvcGVyYXRpdmUgd29yZCBoZXJlIGJhc2VkIG9uIGF1dGhvciBjb21t
ZW50cyBvbiBodHRwczovL2dpdGh1Yi5jb20vcTNrL2Nyb3diYXI6IOKAnENyb3diYXIgRE9FUyBO
T1QgUFJPVklERSBBTlkgREFUQSBDT05GSURFTlRJQUxJVFnigJ0NCg0KWWVzLCBidXQgIlRMUyBv
dmVyIENyb3diYXIiIGRvZXMgcHJvdmlkZSBjb25maWRlbnRpYWxpdHksIGFuZCB0aGF0IGlzIHRo
ZSBhbHRlcm5hdGl2ZSB0byBBVExTIHRoYXQgSSBhbSBwcm9wb3NpbmcgaW4gdGhpcyBzZW50ZW5j
ZS4NCg0KW29mcmllbF0gT24gYnJvd3Npbmcgd2hhdCBjcm93YmFyIGNvZGUgYWN0dWFsbHkgZG9l
cywgdGhpcyBtYWtlcyBzZW5zZS4gVGhlIGNyb3diYXIgc29sdXRpb24gaW5jbHVkZXMgYSBjcm93
YmFyLWZvcndhcmQgYWdlbnQgdGhhdCBjbGllbnQgYXBwcyB0YWxrIHRvLCBhbmQgdGhpcyBzZW5k
cyB0aGUgcGFja2V0cyByZWNlaXZlZCBvdmVyIFRDUCBmcm9tIHRoZSBjbGllbnQgYXBwIGluc2lk
ZSBIVFRQIGJvZGllcyB0byBhIGNyb3diYXJkIHNlcnZlciwgd2hpY2ggaW4gdHVybiBmb3J3YXJk
cyB0aGVtIHRvIHRoZSB0YXJnZXQgc2VydmVyIGhvc3Q6cG9ydC4gSXQgYWxzbyBpbmNsdWRlcyBz
b21lIGZ1bmt5IFVSSSBhbmQgbWVzc2FnZSBib2R5IHByZWZpeGVzIGluIGh0dHBzOi8vZ2l0aHVi
LmNvbS9xM2svY3Jvd2Jhci9ibG9iL21hc3Rlci9wcm90by5nbyBhbmQgc29tZSBydWRpbWVudGFy
eSBITUFDKHB3ZCkgYmFzZWQgYXV0aGVudGljYXRpb24uDQoNCldoaWxlIGNyb3diYXIgZG9lcyBz
dXBwb3J0IGxpc3RlbmluZyBmb3IgYW55IFRDUCBwYWNrZXQgc3RyZWFtICh3aGljaCBjb3VsZCBi
ZSBhIFRMUyBzdHJlYW0pIGFuZCBmb3J3YXJkaW5nIHRoZW0gaW5zaWRlIEhUVFAgYm9kaWVzICh2
aWEgY3Jvd2Jhci1mb3J3YXJkIGFuZCBjcm93YmFyZCBzZXJ2ZXIpIHRvIGEgdGFyZ2V0IGhvc3Q6
cG9ydDsgd2UgYXJlIGdldHRpbmcgaW50byB0aGUgcmVhbG1zIG9mIHJlcXVpcmVtZW50cyBoZXJl
LiBXaGF0IHdlIGhhZCBzZXQgb3V0IHRvIGFjaGlldmUgd2FzIGUyZSBlbmNyeXB0aW9uIGJldHdl
ZW4gYSBjbGllbnQgYW5kIGEgc2VydmljZSBhY3Jvc3MgYSBUTFMgaW50ZXJjZXB0aW5nIG1pZGRs
ZWJveCwgYnkgc2ltcGxlIHJldXNlIG9mIHRoZSBzdGFuZGFyZCBUTFMgc3RhY2ssIHdpdGhvdXQg
cmVxdWlyaW5nIGFueSBleHRyYSBzZXJ2aWNlcy4gTW9yZSBvbiB0aGlzIGJlbG93Li4NCg0KKE9y
IGp1c3QgZG9jdW1lbnQgdGhhdCByZXZlcnNlIHByb3hpZXMgYW5kIGZyYW1ld29ya3Mgb3VnaHQg
dG8gZG8gc29tZXRoaW5nIHJlYXNvbmFibGUgd2l0aCBDT05ORUNULg0KW29mcmllbF0gQ09OTkVD
VCB3b3VsZCBqdXN0IG9wZW4gYSB0dW5uZWwgdG8gZ2V0IHBhY2tldHMgdGhyb3VnaCB0aGUgcHJv
eHkgdG8gdGhlIHNlcnZpY2UsIGJ1dCB3b3VsZCByZXF1aXJlIHRoZSBwcm94eSB0byAqbm90KiBh
dHRlbXB0IHRvIGRvIFRMUyBpbnRlcmNlcHRpb24sIHdoaWNoIGlzIGV4YWN0bHkgd2hhdCB3ZSBh
cmUgdHJ5aW5nIHRvIGFsbG93LiBJZiBwb2xpY3kgZGljdGF0ZXMgdGhhdCBldmVyeXRoaW5nIG11
c3QgYmUgaW50ZXJjZXB0ZWQsIHRoaXMgbWVjaGFuaXNtIGVuYWJsZXMgdGhhdC4NCg0KSSBkb24n
dCB1bmRlcnN0YW5kIHdoaWNoIHByb3h5IHlvdSdyZSByZWZlcnJpbmcgdG8sIG9yIGhvdyB0aGlz
IGRpc3Rpbmd1aXNoZXMgQVRMUyBmcm9tICJUTFMgb3ZlciBIVFRQIENPTk5FQ1QiLg0KDQpbb2Zy
aWVsXSBJIGhvcGUgSSBjbGFyaWZpZWQgdGhpcyBhYm92ZS4gVExTIG92ZXIgSFRUUCBDT05ORUNU
IGlzIGUyZSBuZXR3b3JrIGxheWVyIFRMUyBmcm9tIEMtPlMsIHRoZSBtaWRkbGVib3ggaXMgbm90
IGluc3BlY3RpbmcgY29udGVudCwgYW5kIEFUTFMgaXNu4oCZdCBuZWVkZWQgaWYgdGhlIG1pZGRs
ZWJveCBhbGxvd3MgdGhpcy4NCg0KKSAgT3RoZXJ3aXNlIHRoaXMgc2VlbXMgdG8gYmUgb3NzaWZ5
aW5nIHRoZSBwcm94eSwgcHJpdmlsZWdpbmcgVExTIGFuZCBwcmV2ZW50aW5nIGRlcGxveW1lbnQg
b2YgTm9pc2UgcHJvdG9jb2w8aHR0cDovL25vaXNlcHJvdG9jb2wub3JnLz4gb3Igd2hhdGV2ZXIg
dGhlIGZ1dHVyZSBtYXkgaG9sZC4NCltvZnJpZWxdIE9uZSBvZiB0aGUgcmVhc29uIGZvciBibGlu
ZGx5IHRyYW5zcG9ydGluZyBUTFMgYW5kIG5vdCBpbiBhbnkgd2F5IHJlc3RyaWN0aW5nIG9yIGN1
c3RvbWlzaW5nIHRoZSBUTFMgcmVjb3JkcyB0cmFuc2ZlcnJlZCB3YXMgdG8gYmUgZnV0dXJlIGNv
bXBhdGlibGUgd2l0aCBhbGwgZnV0dXJlIHZlcnNpb25zIG9mIFRMUzsgYW5kIGFsc28gdG8gYWxs
b3cgYW4gYXBwbGljYXRpb24gdG8gbGV2ZXJhZ2UgYSBzaW5nbGUgc29mdHdhcmUgbGlicmFyeSBm
b3IgYm90aCBuZXR3b3JrIHRyYW5zcG9ydCBhbmQgYXBwbGljYXRpb24gY3J5cHRvIGV4Y2hhbmdl
cy4NCg0KT0ssIGJ1dCB5b3UgY2FuIGJlIGV2ZW4gbW9yZSBhYnN0cmFjdGVkIGJ5IHNpbXBseSB0
cmFuc3BvcnRpbmcgYSBieXRlLXN0cmVhbSwgYW5kIGxldHRpbmcgdGhlIGFwcGxpY2F0aW9uIGRl
dmVsb3BlciBjaG9vc2Ugd2hhdCBwcm90b2NvbCB0byBzcGVhayBpbiB0aGF0IHN0cmVhbS4gIFRo
aXMgc2hhcmVzIGV2ZW4gbW9yZSBjb2RlIGJldHdlZW4gdGhlICJuZXR3b3JrIiBhbmQgImFwcGxp
Y2F0aW9uIiB1c2FnZSBvZiBUTFMsIHNpbmNlIHRoZXkgYm90aCBmbG93IG92ZXIgYnl0ZXN0cmVh
bSBhYnN0cmFjdGlvbnMgKG5vIG5lZWQgdG8gZXhwb3NlIHRoZSBUTFMgcmVjb3JkIGxheWVyKS4N
Cg0KW29mcmllbF0gQW5vdGhlciBwYWNrYWdpbmcgb2YgY29udGVudCB3ZSBoYWQgY29uc2lkZXJl
ZCwgYW5kIHdoaWNoIGlzIGVxdWFsbHkgdmFsaWQsIGlzIHRvIGp1c3Qgc2VuZCB0aGUgcmF3IFRM
UyBSZWNvcmRzIGluIHRoZSBib2R5IGFuZCBzcGVjaWZ5IENvbnRlbnQtVHlwZSBhcyBzb21ldGhp
bmcgbGlrZSBhcHBsaWNhdGlvbi9hdGxzK29jdGV0LXN0cmVhbSwgbm90IGV4cGxpY2l0bHkgaW5j
bHVkZSB0aGUgVExTIOKAnHNlc3Npb27igJ0gaWRlbnRpZmllciBpbiB0aGUgbWVzc2FnZSBib2R5
IGFuZCBoYXZlIGl0IHNldCBieSB0aGUgc2VydmljZSBpbiBhIHN1aXRhYmxlIFNldC1Db29raWUu
DQoNCk5vdGUgdGhhdCB0aGUgVExTIHJlY29yZCBsYXllciBpc27igJl0IHJlYWxseSBleHBvc2Vk
IHBlci1zZSB0byB0aGUgYXBwbGljYXRpb24gaW4gZWl0aGVyIGNhc2UuIFRoZSBUTFMgc3RhY2tz
IChPcGVuU1NMIGFuZCBKU1NFIGF0IGxlYXN0KSBwcm9kdWNlIHJhdyBieXRlIHN0cmVhbXMgdGhh
dCBoYXBwZW4gdG8gYmUgVExTIHJlY29yZHMsIGJ1dCB0aGUgYXBwbGljYXRpb24gaGFzIG5vIGlk
ZWEgdGhhdCB0aGV5IGFjdHVhbGx5IGFyZSBUTFMgcmVjb3Jkcy4gSW4gZmFjdCwgdGhlIHN0YWNr
cyBkb27igJl0IGV2ZW4gZXhwb3NlIEFQSXMgZGlyZWN0bHkgdG8gY29uc3VtZXJzIGZvciBwYXJz
aW5nIHRoZSBieXRlIHN0cmVhbXMgcHJvZHVjZWQgZXZlbiBpZiB0aGUgYXBwIHdhbnRlZCB0byBn
cm9rIHRoZSBUTFMgcmVjb3Jkcy4NCg0KT25lIG9wdGlvbiBmb3IgbWFraW5nIHRoZSB0cmFuc3Bv
cnQgbW9yZSBnZW5lcmljIGlzIHRvIHNpbXBseSBpbmNsdWRlIHJhdyBieXRlc3RyZWFtcyAoU1NI
LCBUTFMsIHdoYXRldmVyKSBpbiBIVFRQIGJvZGllcyBhbmQgZGVmaW5lIHN1aXRhYmxlIGFwcGxp
Y2F0aW9uL3h4eHgrb2N0ZXQtc3RyZWFtLg0KSXQgd2FzIGFsc28gcG9pbnRlZCB0byBtZSBvZmYt
bGlzdCB0aGF0IHlvdSBjYW4gZ2VuZXJhdGUgUE9TVCByZXF1ZXN0cyBmcm9tIEphdmFzY3JpcHQg
aW4gWEhSLCBidXQgbm90IENPTk5FQ1QgcmVxdWVzdHMuICBTbyBkb2luZyB0aGlzIG92ZXIgUE9T
VHMgYWxzbyBtYWtlcyBpdCBhY2Nlc3NpYmxlIHRvIHdlYiBhcHBzLiAgKGBlbXNjcmlwdGVuIGxp
YnNzbC5hYCBsZWZ0IGFzIGFuIGV4ZXJjaXNlIHRvIHRoZSByZWFkZXIuKQ0KDQpJdCBzZWVtcyB5
b3VyIHRocmVhdCBtb2RlbCBhc3N1bWVzIGFuIGFkdmVyc2FyeSB3aG8gaXMgYW4gYWN0aXZlIGlu
dGVybWVkaWFyeSBpbiB5b3VyIEhUVFAgc2Vzc2lvbi4gIElmIHNvLCB0aGVuIHRoaXMgd291bGRu
J3Qgc2VlbSB0byBwcm90ZWN0IHRoZSB1c2VyIGFnYWluc3QgdGhlIHRocmVhdC4NCltvZnJpZWxd
IENhbiB5b3UgY2xhcmlmeSB3aHkgdGhpcyBkb2VzbuKAmXQgcHJvdGVjdCBhZ2FpbnN0IGFuIGFj
dGl2ZSBpbnRlcm1lZGlhcnkgaW4gdGhlIEhUVFAgc2Vzc2lvbj8gVHJhbnNmZXJyaW5nIHRoZSBU
TFMgcmVjb3JkcyBwYXlsb2FkcyBpbiBIVFRQIGJvZGllcyBpcyBkaXJlY3RseSBhbmFsb2dvdXMg
dG8gIHRyYW5zZmVycmluZyBUTFMgcmVjb3JkcyBvdmVyIHVudHJ1c3RlZCBUQ1AgbmV0d29yayB0
cmFuc3BvcnQuDQoNCkluIGEgIndlYiBhcHAiLCB0aGUgZW1zY3JpcHRlbi1jb21waWxlZCBjb3B5
IG9mIGxpYnNzbCB3b3VsZCBuZWNlc3NhcmlseSBiZSB0cmFuc21pdHRlZCBvdmVyIHRoZSBpbnNl
Y3VyZSBIVFRQIGNvbm5lY3Rpb24gdGhhdCBhbHNvIGNvbnRhaW5zIEFUTFMuICBBbiBhY3RpdmUg
aW50ZXJtZWRpYXJ5IHRoZXJlZm9yZSBjb3VsZCwgZm9yIGV4YW1wbGUsIHJlcGxhY2UgdGhlIGxp
YnJhcnkgd2l0aCBhIG1vZGlmaWVkIHZlcnNpb24gdGhhdCB1c2VzIGEgYnJva2VuIFBSTkcuDQoN
CltvZnJpZWxdIE9rLiBUaGF04oCZcyB0cnVlIGZvciB3ZWJhcHBzIGRvd25sb2FkaW5nIEphdmFT
Y3JpcHQgb3ZlciB0aGUgSFRUUCBjb25uZWN0aW9uLiBCdXQgbm90IHRydWUgZm9yIGRldmljZXMg
dGhhdCB3b3VsZCBiZSB1c2luZyB0aGUgVExTIHN0YWNrIGJha2VkIGludG8gdGhlaXIgZmlybXdh
cmUuIEFuIGFjdGl2ZSBpbnRlcm1lZGlhcnkgY291bGRu4oCZdCBtZXNzIHdpdGggdGhlIEFUTFMg
c3RhY2sgaW4gdGhhdCBpbnN0YW5jZS4NCg0KDQoNCi0tUmljaGFyZA0KDQoNCk9uIE1vbiwgT2N0
IDMwLCAyMDE3IGF0IDY6NDMgUE0sIEJlbiBTY2h3YXJ0eiA8YmVtYXNjQGdvb2dsZS5jb208bWFp
bHRvOmJlbWFzY0Bnb29nbGUuY29tPj4gd3JvdGU6DQpJIGRvbid0IHVuZGVyc3RhbmQgd2h5IEFU
TFMgYWxsb3dzIHRoZSBhcHAgdG8gYmUgbGVzcyAiYXdhcmUiIHRoYW4gSFRUUCBDT05ORUNULiAg
SSBhbHNvIGRvbid0IHVuZGVyc3RhbmQgaG93IGFuIEFUTFMgY2xpZW50IGlzIGNsb3NlciB0byAi
b25lIGNvZGUgcGF0aCIgdGhhbiBIVFRQIENPTk5FQ1QuICBJdCBzZWVtcyB0byBtZSB0aGF0IHlv
dXIgZGVzY3JpcHRpb24gb2YgY2xpZW50IGJlaGF2aW9yIGFwcGxpZXMgZXF1YWxseSB0byBBVExT
IGFuZCBIVFRQIENPTk5FQ1QuDQoNCk9uIE1vbiwgT2N0IDMwLCAyMDE3IGF0IDY6MzggUE0sIFJp
Y2hhcmQgQmFybmVzIDxybGJAaXB2LnN4PG1haWx0bzpybGJAaXB2LnN4Pj4gd3JvdGU6DQpCdXQg
SSBhZ3JlZSwgaXQgd291bGQgYmUgZ29vZCB0byBoYXZlIHNvbWUgbW9yZSBjbGFyaXR5IGFyb3Vu
ZCB1c2UgY2FzZXMgYW5kIHdoeSBub3Qgb3RoZXIgc29sdXRpb25zLg0KDQpPbiBNb24sIE9jdCAz
MCwgMjAxNyBhdCA2OjM3IFBNLCBSaWNoYXJkIEJhcm5lcyA8cmxiQGlwdi5zeDxtYWlsdG86cmxi
QGlwdi5zeD4+IHdyb3RlOg0KSFRUUCBDT05ORUNUIGlzIG5vdCBncmVhdCBmb3Igc29tZSB1c2Ug
Y2FzZXMgYmVjYXVzZSBpdCByZXF1aXJlcyB0aGUgYXBwIHRvIGJlIGF3YXJlIHRoYXQgaXQncyBk
ZWFsaW5nIHdpdGggYSBwcm94eS4gIEl0J3Mgc2ltcGxlciBpZiB5b3UgY2FuIGp1c3QgaGF2ZSBv
bmUgY29kZSBwYXRoIHRoYXQgd29ya3Mgd2hldGhlciB5b3VyIFRMUyBpcyBpbnRlcm1lZGlhdGVk
IG9yIG5vdC4gIFdpdGggdGhlIHNvbHV0aW9uIG91dGxpbmVkIGluIHRoZSBkcmFmdCwgeW91IGNh
biBqdXN0IGFsd2F5cyBpZ25vcmUgdGhlIGNlcnRpZmljYXRlIHRoZSBzZXJ2ZXIgc2VuZHMgaW4g
dGhlIGZpcnN0IFRMUyBjb25uZWN0aW9uIChiZWNhdXNlIGl0IG1pZ2h0IGJlIGZyb20gYSBNaXRN
KSwgYW5kIHRoZW4gZG8gYWxsIHlvdXIgY2VydCB2YWxpZGF0aW9uLCBwaW4gY2hlY2tzLCBldGMu
IGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllci4NCg0KT24gTW9uLCBPY3QgMzAsIDIwMTcgYXQgNjoy
NiBQTSwgQmVuIFNjaHdhcnR6IDxiZW1hc2NAZ29vZ2xlLmNvbTxtYWlsdG86YmVtYXNjQGdvb2ds
ZS5jb20+PiB3cm90ZToNCldoeSBub3QgdXNlIEhUVFAgQ09OTkVDVD8gIE9yIHJhdGhlciwgaXQg
d291bGQgYmUgaGVscGZ1bCB0byBoYXZlIGEgc2VjdGlvbiBvbiB3aGVuL3doeSBvbmUgd291bGQg
ZG8gdGhpcyB2cy4gQ09OTkVDVC4NCg0KT24gTW9uLCBPY3QgMzAsIDIwMTcgYXQgNjoxNyBQTSwg
UmljaGFyZCBCYXJuZXMgPHJsYkBpcHYuc3g8bWFpbHRvOnJsYkBpcHYuc3g+PiB3cm90ZToNCkhl
eSBUTFMgZm9sa3MsDQoNCk93ZW4sIE1heCwgYW5kIEkgaGF2ZSBiZWVuIGtpY2tpbmcgYXJvdW5k
IHNvbWUgaWRlYXMgZm9yIGhvdyB0byBtYWtlIHNlY3VyZSBjb25uZWN0aW9ucyBpbiBlbnZpcm9u
bWVudHMgd2hlcmUgSFRUUFMgaXMgc3ViamVjdCB0byBNaXRNIC8gcHJveHlpbmcuDQoNClRoZSBi
ZWxvdyBkcmFmdCBsYXlzIG91dCBhIHdheSB0byB0dW5uZWwgVExTIG92ZXIgSFRUUFMsIGluIGhv
cGVzIG9mIGNyZWF0aW5nIGEgY2hhbm5lbCB5b3UgY291bGQgdXNlIHdoZW4geW91IHJlYWxseSBu
ZWVkIHRoaW5ncyB0byBiZSBwcml2YXRlLCBldmVuIGZyb20gdGhlIGxvY2FsIE1pdE0uDQoNCkZl
ZWRiYWNrIG9idmlvdXNseSB2ZXJ5IHdlbGNvbWUuICBJbnRlcmVzdGVkIGluIHdoZXRoZXIgZm9s
a3MgdGhpbmsgdGhpcyBpcyBhIHVzZWZ1bCBhcmVhIGluIHdoaWNoIHRvIGRldmVsb3AgYW4gUkZD
LCBhbmQgYW55IHRob3VnaHRzIG9uIGhvdyB0byBkbyB0aGlzIGJldHRlci4NCg0KVGhhbmtzLA0K
LS1SaWNoYXJkDQoNCg0KT24gTW9uLCBPY3QgMzAsIDIwMTcgYXQgMzo0NyBQTSwgPGludGVybmV0
LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPj4gd3JvdGU6
DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1mcmllbC10bHMtb3Zlci1odHRwLTAwLnR4
dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBPd2VuIEZyaWVsIGFuZCBwb3N0
ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICAgICBkcmFmdC1mcmll
bC10bHMtb3Zlci1odHRwDQpSZXZpc2lvbjogICAgICAgMDANClRpdGxlOiAgICAgICAgICBBcHBs
aWNhdGlvbi1MYXllciBUTFMNCkRvY3VtZW50IGRhdGU6ICAyMDE3LTEwLTMwDQpHcm91cDogICAg
ICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgICAgMjANClVSTDogICAg
ICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZnJpZWwt
dGxzLW92ZXItaHR0cC0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2Vy
LmlldGYub3JnL2RvYy9kcmFmdC1mcmllbC10bHMtb3Zlci1odHRwLw0KSHRtbGl6ZWQ6ICAgICAg
IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mcmllbC10bHMtb3Zlci1odHRwLTAw
DQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9k
cmFmdC1mcmllbC10bHMtb3Zlci1odHRwLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBNYW55IGNsaWVu
dHMgbmVlZCB0byBlc3RhYmxpc2ggc2VjdXJlIGNvbm5lY3Rpb25zIHRvIGFwcGxpY2F0aW9uDQog
ICBzZXJ2aWNlcyBidXQgZmFjZSBjaGFsbGVuZ2VzIGVzdGFibGlzaGluZyB0aGVzZSBjb25uZWN0
aW9ucyBkdWUgdG8NCiAgIHRoZSBwcmVzZW5jZSBvZiBtaWRkbGVib3hlcyB0aGF0IHRlcm1pbmF0
ZSBUTFMgY29ubmVjdGlvbnMgZnJvbSB0aGUNCiAgIGNsaWVudCBhbmQgcmVzdGFibGlzaCBuZXcg
VExTIGNvbm5lY3Rpb25zIHRvIHRoZSBzZXJ2aWNlLiAgVGhpcw0KICAgZG9jdW1lbnQgZGVmaW5l
cyBhIG1lY2hhbmlzbSBmb3IgdHJhbnNwb3J0aW5nIFRMUyByZWNvcmRzIGluIEhUVFANCiAgIG1l
c3NhZ2UgYm9kaWVzIGJldHdlZW4gY2xpZW50cyBhbmQgc2VydmljZXMuICBUaGlzIGVuYWJsZXMg
Y2xpZW50cw0KICAgYW5kIHNlcnZpY2VzIHRvIGVzdGFibGlzaCBzZWN1cmUgY29ubmVjdGlvbnMg
dXNpbmcgVExTIGF0IHRoZQ0KICAgYXBwbGljYXRpb24gbGF5ZXIsIGFuZCB0cmVhdCBhbnkgbWlk
ZGxlYm94ZXMgdGhhdCBhcmUgaW50ZXJjZXB0aW5nDQogICB0cmFmZmljIGF0IHRoZSBuZXR3b3Jr
IGxheWVyIGFzIHVudHJ1c3RlZCB0cmFuc3BvcnQuICBJbiBzaG9ydCwgdGhpcw0KICAgbWVjaGFu
aXNtIG1vdmVzIHRoZSBUTFMgaGFuZHNoYWtlIHVwIHRoZSBPU0kgc3RhY2sgdG8gdGhlIGFwcGxp
Y2F0aW9uDQogICBsYXllci4NCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBh
IGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhl
IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9y
ZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGlu
ZyBsaXN0DQpUTFNAaWV0Zi5vcmc8bWFpbHRvOlRMU0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQoNCg0KDQoNCg0KDQoNCg==

--_000_9668bf1b98474e50a46347d9199ffd8cXCHRCD012ciscocom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlNlZ29lIFVJIjsNCglwYW5vc2UtMToyIDExIDUg
MiA0IDIgNCAyIDIgMzt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp
Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206
LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t
YW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp
c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5
Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk
IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6
ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxp
Lm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsN
Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0
Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uZ21haWwtDQoJ
e21zby1zdHlsZS1uYW1lOmdtYWlsLTt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21z
by1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWls
eTpDb25zb2xhczsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1JRTt9DQpzcGFuLkVtYWlsU3R5
bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs
aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1h
bDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw
ZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28t
ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu
MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu
V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn
dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx
MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz
aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg
Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh
bmc9IkVOLUlFIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT
ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVh
c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWYiPiBCZW4gU2Nod2FydHogW21haWx0bzpiZW1hc2NAZ29vZ2xlLmNvbV0N
Cjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5IDMxIE9jdG9iZXIgMjAxNyAyMToxNzxicj4NCjxi
PlRvOjwvYj4gT3dlbiBGcmllbCAob2ZyaWVsKSAmbHQ7b2ZyaWVsQGNpc2NvLmNvbSZndDs8YnI+
DQo8Yj5DYzo8L2I+IFJpY2hhcmQgQmFybmVzICZsdDtybGJAaXB2LnN4Jmd0OzsgJmx0O3Rsc0Bp
ZXRmLm9yZyZndDsgJmx0O3Rsc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6
IFtUTFNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZnJpZWwtdGxzLW92ZXIt
aHR0cC0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE9jdCAzMSwgMjAx
NyBhdCA1OjAzIFBNLCBPd2VuIEZyaWVsIChvZnJpZWwpICZsdDs8YSBocmVmPSJtYWlsdG86b2Zy
aWVsQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm9mcmllbEBjaXNjby5jb208L2E+Jmd0OyB3
cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy
Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDBCMDUw
Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMDBCMDUwIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg
MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y
ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt
IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIg
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+
IFRMUw0KIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnIiB0YXJn
ZXQ9Il9ibGFuayI+dGxzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwv
Yj5CZW4gU2Nod2FydHo8YnI+DQo8Yj5TZW50OjwvYj4gMzEgT2N0b2JlciAyMDE3IDAxOjM1PGJy
Pg0KPGI+VG86PC9iPiBSaWNoYXJkIEJhcm5lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJsYkBpcHYu
c3giPnJsYkBpcHYuc3g8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gJmx0OzxhIGhyZWY9Im1haWx0
bzp0bHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50bHNAaWV0Zi5vcmc8L2E+Jmd0OyAmbHQ7
PGEgaHJlZj0ibWFpbHRvOnRsc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRsc0BpZXRmLm9y
ZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVExTXSBOZXcgVmVyc2lvbiBOb3Rp
ZmljYXRpb24gZm9yIGRyYWZ0LWZyaWVsLXRscy1vdmVyLWh0dHAtMDAudHh0PC9zcGFuPjxzcGFu
IGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48
L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBsYW5nPSJFTi1HQiI+T24gTW9uLCBPY3QgMzAsIDIwMTcgYXQgNzowMiBQTSwgUmljaGFy
ZCBCYXJuZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpybGJAaXB2LnN4IiB0YXJnZXQ9Il9ibGFuayI+
cmxiQGlwdi5zeDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1
b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh
ZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw
dDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5JdCByZXF1aXJlcyBhd2Fy
ZW5lc3MgaW4gdGhlIGZvbGxvd2luZyBzZW5zZTogSWYgYnkgY2hhbmNlIHRoZSBjbGllbnQgaXMg
aW4gYSBuaWNlLCBvcGVuIG5ldHdvcmsgYW5kIHRoZSBiYXNlIFRMUyBjb25uZWN0aW9uIGdvZXMg
ZGlyZWN0bHkgdG8gdGhlIHNlcnZlciwgQ09OTkVDVA0KIGlzIGtpbmQgb2YgdW5uYXR1cmFsOyB5
b3Ugd291bGQgd2FudCB0aGUgY2xpZW50IHRvIGRvIHNvbWV0aGluZyBkaWZmZXJlbnQgaW4gdGhh
dCBjYXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv
dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5i
c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+U3VyZWx5IHRoaXMgaXMgZXF1YWxseSB0cnVlL3Vu
dHJ1ZSBvZiBBVExTLiZuYnNwOyBXaHkgZG8gZG91YmxlLVRMUyBpZiBpdCBjYW4gYmUgYXZvaWRl
ZD8mbmJzcDsgQnV0IHRoZW4sIGhvdyBkb2VzIHRoZSBhcHBsaWNhdGlvbiBrbm93IHdoZXRoZXIg
dG8gZG8gQVRMUyBlbmNhcHN1bGF0aW9uPyZuYnNwOw0KIEl0J3MgdGhlIHNhbWUgcXVlc3Rpb24g
aW4gYm90aCBjYXNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlPjxiPjxpPjxzcGFuIGxh
bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwQjA1MCI+W29mcmllbF0gVGhlIGRyYWZ0IGRv
ZXMgc3RhdGUg4oCcPC9zcGFuPjwvaT48L2I+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xv
cjpibGFjayI+QXMgYW4gb3B0aW1pc2F0aW9uLCBjbGllbnRzIG1heSBjaG9vc2UgdG8gb25seSB1
c2UgQVRMUyBhcyBhIGZhbGxiYWNrPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpw
Pjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0Ii
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1
b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgbWVjaGFuaXNtIGlmIGNlcnRpZmljYXRlIHZh
bGlkYXRpb24gZmFpbHMgb24gdGhlIHRyYW5zcG9ydCBsYXllciBUTFM8L3NwYW4+PHNwYW4gbGFu
Zz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgY29ubmVjdGlv
biB0byB0aGUgc2VydmljZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBsYW5nPSJFTi1HQiIg
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMwMEIwNTAiPuKAnTwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVO
LUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxp
PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwQjA1MCI+SXQgc2hvdWxkIGJl
IGVhc3kgZm9yIGEgZGV2aWNlIHRvIGRldGVjdCB0aGUgcHJlc2VuY2Ugb2YgYSBtaWRkbGVib3gg
aWYgdGhlIG5ldHdvcmsNCiBsYXllciBUTFMgY29ubmVjdGlvbiBwcmVzZW50cyBhIHNlcnZpY2Ug
Y2VydGlmaWNhdGUgdGhhdCBoYXMgdGhlIGV4cGVjdGVkIFNBTi9DTiwgYnV0IGlzIHNpZ25lZCBi
eSBhbiB1bmV4cGVjdGVkL3VudHJ1c3RlZCBDQSAoaS5lLiBvbmUgbm90IGJha2VkIGludG8vZXhw
bGljaXRseSBjb25maWd1cmVkIG9uIHRoZSBkZXZpY2UpLjwvc3Bhbj48L2k+PC9iPjxzcGFuIGxh
bmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgYnV0IHRoZSBjbGllbnQgY291bGQgZXF1YWxseSB3
ZWxsIGZhbGwgYmFjayB0byBIVFRQIENPTk5FQ1QgaW4gdGhpcyBjYXNlLiZuYnNwOyBNeSBjb21t
ZW50cyBhcmUgYWxsIGRpcmVjdGVkIHRvIHRoZSBxdWVzdGlvbiBvZiB3aHkgdG8gdXNlIEFUTFMg
aW5zdGVhZCBvZiBhbiBleGlzdGluZyBzb2x1dGlvbiwgc3VjaCBhcyAmcXVvdDtUTFMgb3ZlciBI
VFRQIENPTk5FQ1QmcXVvdDsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZiI+W29mcmllbF0gSSBmdWxseSBhZ3JlZSB0aGF0IGlmIGEgVExTIHR1
bm5lbCBvcGVuZWQgdmlhIEhUVFAgQ09OTkVDVCBpcyBwb3NzaWJsZSwgdGhlbiBBVExTIGlzIG5v
dCBuZWVkZWQgYXMgdGhlIFRMUyBjb25uZWN0aW9uIGlzIGUyZSBiZXR3ZWVuIEMtJmd0O1MgYW5k
IHRoZSBtaWRkbGVib3ggaXMgbm90DQogaW5zcGVjdGluZyB0cmFmZmljLiBIb3dldmVyLCBpZiB0
aGUgbWlkZGxlYm94IHByb3h5IGVuZm9yY2VzIFRMUyBpbnNwZWN0aW9uIGFuZCBkb2VzIG5vdCBh
bGxvdyBvcGVuaW5nIGEgVExTIHR1bm5lbCB2aWEgSFRUUCBDT05ORUNULCB0aGVuIHRoZSBkdW1i
IElvVCBkZXZpY2Ugd2lsbCBmYWlsIGNlcnQgdmFsaWRhdGUgb24gdGhlIFRMUyBjb25uZWN0aW9u
IHRlcm1pbmF0ZWQgb24gdGhlIG1pZGRsZWJveC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND
Q0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy
Z2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs
YW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2tx
dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw
YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w
cHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7IFlvdSdyZSBj
b3JyZWN0IHRoYXQgeW91ICpjb3VsZCogY29uZmlndXJlIHRoZSBzZXJ2ZXIgdG8gaGFuZGxlIGNv
bm5lY3QgcHJvcGVybHksIGJ1dCBhbGwgb2YgdGhlIG9wdGlvbnMgZm9yIGRvaW5nIHRoaXMgYXJl
IGtpbmQgb2YgY3VtYmVyc29tZSAtLSBlaXRoZXIgeW91DQogaGF2ZSB0byBzdGljayBhIHBvc3Np
Ymx5LXVubmVjZXNzYXJ5IHByb3h5IGluIGZyb250IG9mIHRoZSBzZXJ2ZXIsIG9yIGhhbmRsZSBD
T05ORUNUIG9uIHRoZSBzZXJ2ZXIsIHdoaWNoIGlzIG5vdCByZWFsbHkgd2VsbC1zdXBwb3J0ZWQg
Ynkgd2ViIGFwcGxpY2F0aW9uIGZyYW1ld29ya3MuJm5ic3A7IEJ5IGNvbnRyYXN0LCBydW5uaW5n
IGRhdGEgb3ZlciBQT1NUIGlzIHViaXF1aXRvdXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5UaGlzIG1h
a2VzIGEgY2VydGFpbiBhbW91bnQgb2Ygc2Vuc2UgdG8gbWUuJm5ic3A7IElmIGl0IHdlcmUgdXAg
dG8gbWUsIHJhdGhlciB0aGFuIGRlc2lnbiBhIFRMUy1zcGVjaWZpYyB0cmFuc3BvcnQsIEknZCBi
ZSBtb3JlIGluY2xpbmVkIHRvIHByb3Bvc2UgYSBzdGFuZGFyZGl6ZWQNCiB2ZXJzaW9uIG9mIHNv
bWV0aGluZyBsaWtlIDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9xM2svY3Jvd2JhciIgdGFy
Z2V0PSJfYmxhbmsiPg0KQ3Jvd2JhcjwvYT4uJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48aT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMwMEIwNTAiPltvZnJpZWxdIC9tZSByZWFkcy4g4oCYbGlrZeKAmSBhcHBlYXJzIHRv
IGJlIHRoZSBvcGVyYXRpdmUgd29yZCBoZXJlIGJhc2VkIG9uIGF1dGhvcg0KIGNvbW1lbnRzIG9u
IDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9xM2svY3Jvd2JhciIgdGFyZ2V0PSJfYmxhbmsi
Pmh0dHBzOi8vZ2l0aHViLmNvbS9xM2svY3Jvd2JhcjwvYT46IOKAnDwvc3Bhbj48L2k+PC9iPjxz
cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMjQyOTJFO2JhY2tncm91bmQ6d2hpdGUiPkNyb3diYXImbmJzcDs8
c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5z
LXNlcmlmIj5ET0VTDQogTk9UIFBST1ZJREUgQU5ZIERBVEEgQ09ORklERU5USUFMSVRZPC9zcGFu
Pjwvc3Ryb25nPjwvc3Bhbj48Yj48aT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMwMEIwNTAiPuKAnTwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PlllcywgYnV0ICZxdW90O1RMUyBvdmVyIENyb3diYXImcXVvdDsgZG9lcyBwcm92aWRlIGNvbmZp
ZGVudGlhbGl0eSwgYW5kIHRoYXQgaXMgdGhlIGFsdGVybmF0aXZlIHRvIEFUTFMgdGhhdCBJIGFt
IHByb3Bvc2luZyBpbiB0aGlzIHNlbnRlbmNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltvZnJpZWxdIE9uIGJyb3dzaW5n
IHdoYXQgY3Jvd2JhciBjb2RlIGFjdHVhbGx5IGRvZXMsIHRoaXMgbWFrZXMgc2Vuc2UuIFRoZSBj
cm93YmFyIHNvbHV0aW9uIGluY2x1ZGVzIGEgY3Jvd2Jhci1mb3J3YXJkIGFnZW50IHRoYXQgY2xp
ZW50IGFwcHMgdGFsayB0bywgYW5kIHRoaXMgc2VuZHMgdGhlIHBhY2tldHMNCiByZWNlaXZlZCBv
dmVyIFRDUCBmcm9tIHRoZSBjbGllbnQgYXBwIGluc2lkZSBIVFRQIGJvZGllcyB0byBhIGNyb3di
YXJkIHNlcnZlciwgd2hpY2ggaW4gdHVybiBmb3J3YXJkcyB0aGVtIHRvIHRoZSB0YXJnZXQgc2Vy
dmVyIGhvc3Q6cG9ydC4gSXQgYWxzbyBpbmNsdWRlcyBzb21lIGZ1bmt5IFVSSSBhbmQgbWVzc2Fn
ZSBib2R5IHByZWZpeGVzIGluDQo8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vcTNrL2Nyb3di
YXIvYmxvYi9tYXN0ZXIvcHJvdG8uZ28iPmh0dHBzOi8vZ2l0aHViLmNvbS9xM2svY3Jvd2Jhci9i
bG9iL21hc3Rlci9wcm90by5nbzwvYT4gYW5kIHNvbWUgcnVkaW1lbnRhcnkgSE1BQyhwd2QpIGJh
c2VkIGF1dGhlbnRpY2F0aW9uLiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+V2hpbGUgY3Jvd2JhciBk
b2VzIHN1cHBvcnQgbGlzdGVuaW5nIGZvciBhbnkgVENQIHBhY2tldCBzdHJlYW0gKHdoaWNoIGNv
dWxkIGJlIGEgVExTIHN0cmVhbSkgYW5kIGZvcndhcmRpbmcgdGhlbSBpbnNpZGUgSFRUUCBib2Rp
ZXMgKHZpYSBjcm93YmFyLWZvcndhcmQgYW5kIGNyb3diYXJkIHNlcnZlcikNCiB0byBhIHRhcmdl
dCBob3N0OnBvcnQ7IHdlIGFyZSBnZXR0aW5nIGludG8gdGhlIHJlYWxtcyBvZiByZXF1aXJlbWVu
dHMgaGVyZS4gV2hhdCB3ZSBoYWQgc2V0IG91dCB0byBhY2hpZXZlIHdhcyBlMmUgZW5jcnlwdGlv
biBiZXR3ZWVuIGEgY2xpZW50IGFuZCBhIHNlcnZpY2UgYWNyb3NzIGEgVExTIGludGVyY2VwdGlu
ZyBtaWRkbGVib3gsIGJ5IHNpbXBsZSByZXVzZSBvZiB0aGUgc3RhbmRhcmQgVExTIHN0YWNrLCB3
aXRob3V0IHJlcXVpcmluZyBhbnkNCiBleHRyYSBzZXJ2aWNlcy4gTW9yZSBvbiB0aGlzIGJlbG93
Li48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNt
IDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw
dDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gbGFuZz0iRU4tR0IiPihPciBqdXN0IGRvY3VtZW50IHRoYXQgcmV2ZXJzZSBwcm94aWVzIGFu
ZCBmcmFtZXdvcmtzIG91Z2h0IHRvIGRvIHNvbWV0aGluZyByZWFzb25hYmxlIHdpdGggQ09OTkVD
VC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxz
cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwQjA1MCI+W29mcmllbF0gQ09OTkVD
VCB3b3VsZCBqdXN0IG9wZW4gYSB0dW5uZWwgdG8gZ2V0IHBhY2tldHMgdGhyb3VnaCB0aGUgcHJv
eHkgdG8gdGhlDQogc2VydmljZSwgYnV0IHdvdWxkIHJlcXVpcmUgdGhlIHByb3h5IHRvICpub3Qq
IGF0dGVtcHQgdG8gZG8gVExTIGludGVyY2VwdGlvbiwgd2hpY2ggaXMgZXhhY3RseSB3aGF0IHdl
IGFyZSB0cnlpbmcgdG8gYWxsb3cuIElmIHBvbGljeSBkaWN0YXRlcyB0aGF0IGV2ZXJ5dGhpbmcg
bXVzdCBiZSBpbnRlcmNlcHRlZCwgdGhpcyBtZWNoYW5pc20gZW5hYmxlcyB0aGF0Ljwvc3Bhbj48
L2k+PC9iPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5JIGRvbid0IHVuZGVyc3RhbmQgd2hpY2ggcHJveHkgeW91J3JlIHJlZmVycmluZyB0bywg
b3IgaG93IHRoaXMgZGlzdGluZ3Vpc2hlcyBBVExTIGZyb20gJnF1b3Q7VExTIG92ZXIgSFRUUCBD
T05ORUNUJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltvZnJpZWxdIEkgaG9wZSBJIGNsYXJpZmllZCB0aGlzIGFi
b3ZlLiBUTFMgb3ZlciBIVFRQIENPTk5FQ1QgaXMgZTJlIG5ldHdvcmsgbGF5ZXIgVExTIGZyb20g
Qy0mZ3Q7UywgdGhlIG1pZGRsZWJveCBpcyBub3QgaW5zcGVjdGluZyBjb250ZW50LCBhbmQgQVRM
UyBpc27igJl0IG5lZWRlZCBpZiB0aGUgbWlkZGxlYm94DQogYWxsb3dzIHRoaXMuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti
b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7
bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYg
c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow
Y20gMGNtIDBjbSA0LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO
LUdCIj4pJm5ic3A7IE90aGVyd2lzZSB0aGlzIHNlZW1zIHRvIGJlIG9zc2lmeWluZyB0aGUgcHJv
eHksIHByaXZpbGVnaW5nIFRMUyBhbmQgcHJldmVudGluZyBkZXBsb3ltZW50IG9mJm5ic3A7PGEg
aHJlZj0iaHR0cDovL25vaXNlcHJvdG9jb2wub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPk5vaXNlIHBy
b3RvY29sPC9hPiZuYnNwO29yDQogd2hhdGV2ZXIgdGhlIGZ1dHVyZSBtYXkgaG9sZC48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIGxhbmc9
IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwQjA1MCI+W29mcmllbF0gT25lIG9mIHRoZSByZWFz
b24gZm9yIGJsaW5kbHkgdHJhbnNwb3J0aW5nIFRMUyBhbmQgbm90IGluIGFueSB3YXkgcmVzdHJp
Y3RpbmcNCiBvciBjdXN0b21pc2luZyB0aGUgVExTIHJlY29yZHMgdHJhbnNmZXJyZWQgd2FzIHRv
IGJlIGZ1dHVyZSBjb21wYXRpYmxlIHdpdGggYWxsIGZ1dHVyZSB2ZXJzaW9ucyBvZiBUTFM7IGFu
ZCBhbHNvIHRvIGFsbG93IGFuIGFwcGxpY2F0aW9uIHRvIGxldmVyYWdlIGEgc2luZ2xlIHNvZnR3
YXJlIGxpYnJhcnkgZm9yIGJvdGggbmV0d29yayB0cmFuc3BvcnQgYW5kIGFwcGxpY2F0aW9uIGNy
eXB0byBleGNoYW5nZXMuPC9zcGFuPjwvaT48L2I+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9LLCBidXQgeW91IGNhbiBiZSBldmVuIG1vcmUg
YWJzdHJhY3RlZCBieSBzaW1wbHkgdHJhbnNwb3J0aW5nIGEgYnl0ZS1zdHJlYW0sIGFuZCBsZXR0
aW5nIHRoZSBhcHBsaWNhdGlvbiBkZXZlbG9wZXIgY2hvb3NlIHdoYXQgcHJvdG9jb2wgdG8gc3Bl
YWsgaW4gdGhhdCBzdHJlYW0uJm5ic3A7IFRoaXMgc2hhcmVzIGV2ZW4gbW9yZSBjb2RlIGJldHdl
ZW4gdGhlICZxdW90O25ldHdvcmsmcXVvdDsgYW5kICZxdW90O2FwcGxpY2F0aW9uJnF1b3Q7IHVz
YWdlDQogb2YgVExTLCBzaW5jZSB0aGV5IGJvdGggZmxvdyBvdmVyIGJ5dGVzdHJlYW0gYWJzdHJh
Y3Rpb25zIChubyBuZWVkIHRvIGV4cG9zZSB0aGUgVExTIHJlY29yZCBsYXllcikuPG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+
W29mcmllbF0gQW5vdGhlciBwYWNrYWdpbmcgb2YgY29udGVudCB3ZSBoYWQgY29uc2lkZXJlZCwg
YW5kIHdoaWNoIGlzIGVxdWFsbHkgdmFsaWQsIGlzIHRvIGp1c3Qgc2VuZCB0aGUgcmF3IFRMUyBS
ZWNvcmRzIGluIHRoZSBib2R5IGFuZCBzcGVjaWZ5IENvbnRlbnQtVHlwZSBhcyBzb21ldGhpbmcg
bGlrZQ0KIGFwcGxpY2F0aW9uL2F0bHMmIzQzO29jdGV0LXN0cmVhbSwgbm90IGV4cGxpY2l0bHkg
aW5jbHVkZSB0aGUgVExTIOKAnHNlc3Npb27igJ0gaWRlbnRpZmllciBpbiB0aGUgbWVzc2FnZSBi
b2R5IGFuZCBoYXZlIGl0IHNldCBieSB0aGUgc2VydmljZSBpbiBhIHN1aXRhYmxlIFNldC1Db29r
aWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWYiPk5vdGUgdGhhdCB0aGUgVExTIHJlY29yZCBsYXllciBpc27igJl0
IHJlYWxseSBleHBvc2VkIHBlci1zZSB0byB0aGUgYXBwbGljYXRpb24gaW4gZWl0aGVyIGNhc2Uu
IFRoZSBUTFMgc3RhY2tzIChPcGVuU1NMIGFuZCBKU1NFIGF0IGxlYXN0KSBwcm9kdWNlIHJhdyBi
eXRlIHN0cmVhbXMgdGhhdCBoYXBwZW4NCiB0byBiZSBUTFMgcmVjb3JkcywgYnV0IHRoZSBhcHBs
aWNhdGlvbiBoYXMgbm8gaWRlYSB0aGF0IHRoZXkgYWN0dWFsbHkgYXJlIFRMUyByZWNvcmRzLiBJ
biBmYWN0LCB0aGUgc3RhY2tzIGRvbuKAmXQgZXZlbiBleHBvc2UgQVBJcyBkaXJlY3RseSB0byBj
b25zdW1lcnMgZm9yIHBhcnNpbmcgdGhlIGJ5dGUgc3RyZWFtcyBwcm9kdWNlZCBldmVuIGlmIHRo
ZSBhcHAgd2FudGVkIHRvIGdyb2sgdGhlIFRMUyByZWNvcmRzLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5PbmUg
b3B0aW9uIGZvciBtYWtpbmcgdGhlIHRyYW5zcG9ydCBtb3JlIGdlbmVyaWMgaXMgdG8gc2ltcGx5
IGluY2x1ZGUgcmF3IGJ5dGVzdHJlYW1zIChTU0gsIFRMUywgd2hhdGV2ZXIpIGluIEhUVFAgYm9k
aWVzIGFuZCBkZWZpbmUgc3VpdGFibGUgYXBwbGljYXRpb24veHh4eCYjNDM7b2N0ZXQtc3RyZWFt
Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl
cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBj
bSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw
YWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u
ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w
cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIGxhbmc9IkVOLUdCIj5JdCB3YXMgYWxzbyBwb2ludGVkIHRvIG1lIG9mZi1saXN0IHRo
YXQgeW91IGNhbiBnZW5lcmF0ZSBQT1NUIHJlcXVlc3RzIGZyb20gSmF2YXNjcmlwdCBpbiBYSFIs
IGJ1dCBub3QgQ09OTkVDVCByZXF1ZXN0cy4mbmJzcDsgU28gZG9pbmcgdGhpcyBvdmVyIFBPU1Rz
IGFsc28gbWFrZXMNCiBpdCBhY2Nlc3NpYmxlIHRvIHdlYiBhcHBzLiZuYnNwOyAoYGVtc2NyaXB0
ZW4gbGlic3NsLmFgIGxlZnQgYXMgYW4gZXhlcmNpc2UgdG8gdGhlIHJlYWRlci4pPG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh
bmc9IkVOLUdCIj5JdCBzZWVtcyB5b3VyIHRocmVhdCBtb2RlbCBhc3N1bWVzIGFuIGFkdmVyc2Fy
eSB3aG8gaXMgYW4gYWN0aXZlIGludGVybWVkaWFyeSBpbiB5b3VyIEhUVFAgc2Vzc2lvbi4mbmJz
cDsgSWYgc28sIHRoZW4gdGhpcyB3b3VsZG4ndCBzZWVtIHRvIHByb3RlY3QgdGhlIHVzZXIgYWdh
aW5zdA0KIHRoZSB0aHJlYXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48Yj48aT48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMEIwNTAi
PltvZnJpZWxdIENhbiB5b3UgY2xhcmlmeSB3aHkgdGhpcyBkb2VzbuKAmXQgcHJvdGVjdCBhZ2Fp
bnN0IGFuIGFjdGl2ZSBpbnRlcm1lZGlhcnkNCiBpbiB0aGUgSFRUUCBzZXNzaW9uPyBUcmFuc2Zl
cnJpbmcgdGhlIFRMUyByZWNvcmRzIHBheWxvYWRzIGluIEhUVFAgYm9kaWVzIGlzIGRpcmVjdGx5
IGFuYWxvZ291cyB0byAmbmJzcDt0cmFuc2ZlcnJpbmcgVExTIHJlY29yZHMgb3ZlciB1bnRydXN0
ZWQgVENQIG5ldHdvcmsgdHJhbnNwb3J0Ljwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9IkVOLUdC
Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIGEgJnF1b3Q7
d2ViIGFwcCZxdW90OywgdGhlIGVtc2NyaXB0ZW4tY29tcGlsZWQgY29weSBvZiBsaWJzc2wmbmJz
cDt3b3VsZCBuZWNlc3NhcmlseSBiZSB0cmFuc21pdHRlZCBvdmVyIHRoZSBpbnNlY3VyZSBIVFRQ
IGNvbm5lY3Rpb24gdGhhdCBhbHNvIGNvbnRhaW5zIEFUTFMuJm5ic3A7IEFuIGFjdGl2ZSBpbnRl
cm1lZGlhcnkgdGhlcmVmb3JlIGNvdWxkLCBmb3IgZXhhbXBsZSwgcmVwbGFjZSB0aGUgbGlicmFy
eSB3aXRoIGEgbW9kaWZpZWQNCiB2ZXJzaW9uIHRoYXQgdXNlcyBhIGJyb2tlbiBQUk5HLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltvZnJp
ZWxdIE9rLiBUaGF04oCZcyB0cnVlIGZvciB3ZWJhcHBzIGRvd25sb2FkaW5nIEphdmFTY3JpcHQg
b3ZlciB0aGUgSFRUUCBjb25uZWN0aW9uLiBCdXQgbm90IHRydWUgZm9yIGRldmljZXMgdGhhdCB3
b3VsZCBiZSB1c2luZyB0aGUgVExTIHN0YWNrIGJha2VkIGludG8gdGhlaXIgZmlybXdhcmUuDQog
QW4gYWN0aXZlIGludGVybWVkaWFyeSBjb3VsZG7igJl0IG1lc3Mgd2l0aCB0aGUgQVRMUyBzdGFj
ayBpbiB0aGF0IGluc3RhbmNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr
cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7
cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6
MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6
c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJs
b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w
cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w
OjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4mbmJzcDs8L3NwYW4+PHNw
YW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjojODg4
ODg4Ij4tLVJpY2hhcmQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+T24gTW9uLCBPY3QgMzAsIDIwMTcgYXQgNjo0MyBQTSwg
QmVuIFNjaHdhcnR6ICZsdDs8YSBocmVmPSJtYWlsdG86YmVtYXNjQGdvb2dsZS5jb20iIHRhcmdl
dD0iX2JsYW5rIj5iZW1hc2NAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl
ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s
ZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9t
OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdC
Ij5JIGRvbid0IHVuZGVyc3RhbmQgd2h5IEFUTFMgYWxsb3dzIHRoZSBhcHAgdG8gYmUgbGVzcyAm
cXVvdDthd2FyZSZxdW90OyB0aGFuIEhUVFAgQ09OTkVDVC4mbmJzcDsgSSBhbHNvIGRvbid0IHVu
ZGVyc3RhbmQgaG93IGFuIEFUTFMgY2xpZW50IGlzIGNsb3NlciB0byAmcXVvdDtvbmUgY29kZSBw
YXRoJnF1b3Q7IHRoYW4NCiBIVFRQIENPTk5FQ1QuJm5ic3A7IEl0IHNlZW1zIHRvIG1lIHRoYXQg
eW91ciBkZXNjcmlwdGlvbiBvZiBjbGllbnQgYmVoYXZpb3IgYXBwbGllcyBlcXVhbGx5IHRvIEFU
TFMgYW5kIEhUVFAgQ09OTkVDVC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0Ii
PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5PbiBNb24sIE9jdCAzMCwgMjAxNyBhdCA2OjM4IFBNLCBS
aWNoYXJkIEJhcm5lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJsYkBpcHYuc3giIHRhcmdldD0iX2Js
YW5rIj5ybGJAaXB2LnN4PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJs
b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w
cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w
OjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+QnV0IEkgYWdyZWUsIGl0IHdv
dWxkIGJlIGdvb2QgdG8gaGF2ZSBzb21lIG1vcmUgY2xhcml0eSBhcm91bmQgdXNlIGNhc2VzIGFu
ZCB3aHkgbm90IG90aGVyIHNvbHV0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i
RU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5PbiBNb24sIE9jdCAzMCwgMjAxNyBhdCA2OjM3
IFBNLCBSaWNoYXJkIEJhcm5lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJsYkBpcHYuc3giIHRhcmdl
dD0iX2JsYW5rIj5ybGJAaXB2LnN4PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND
Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+SFRUUCBDT05ORUNU
IGlzIG5vdCBncmVhdCBmb3Igc29tZSB1c2UgY2FzZXMgYmVjYXVzZSBpdCByZXF1aXJlcyB0aGUg
YXBwIHRvIGJlIGF3YXJlIHRoYXQgaXQncyBkZWFsaW5nIHdpdGggYSBwcm94eS4mbmJzcDsgSXQn
cyBzaW1wbGVyIGlmIHlvdSBjYW4ganVzdCBoYXZlIG9uZSBjb2RlDQogcGF0aCB0aGF0IHdvcmtz
IHdoZXRoZXIgeW91ciBUTFMgaXMgaW50ZXJtZWRpYXRlZCBvciBub3QuJm5ic3A7IFdpdGggdGhl
IHNvbHV0aW9uIG91dGxpbmVkIGluIHRoZSBkcmFmdCwgeW91IGNhbiBqdXN0IGFsd2F5cyBpZ25v
cmUgdGhlIGNlcnRpZmljYXRlIHRoZSBzZXJ2ZXIgc2VuZHMgaW4gdGhlIGZpcnN0IFRMUyBjb25u
ZWN0aW9uIChiZWNhdXNlIGl0IG1pZ2h0IGJlIGZyb20gYSBNaXRNKSwgYW5kIHRoZW4gZG8gYWxs
IHlvdXIgY2VydCB2YWxpZGF0aW9uLA0KIHBpbiBjaGVja3MsIGV0Yy4gYXQgdGhlIGFwcGxpY2F0
aW9uIGxheWVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86
cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
bGFuZz0iRU4tR0IiPk9uIE1vbiwgT2N0IDMwLCAyMDE3IGF0IDY6MjYgUE0sIEJlbiBTY2h3YXJ0
eiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlbWFzY0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+
YmVtYXNjQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx
LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10
b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5XaHkgbm90IHVzZSBIVFRQ
IENPTk5FQ1Q/Jm5ic3A7IE9yIHJhdGhlciwgaXQgd291bGQgYmUgaGVscGZ1bCB0byBoYXZlIGEg
c2VjdGlvbiBvbiB3aGVuL3doeSBvbmUgd291bGQgZG8gdGhpcyB2cy4gQ09OTkVDVC48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5PbiBN
b24sIE9jdCAzMCwgMjAxNyBhdCA2OjE3IFBNLCBSaWNoYXJkIEJhcm5lcyAmbHQ7PGEgaHJlZj0i
bWFpbHRvOnJsYkBpcHYuc3giIHRhcmdldD0iX2JsYW5rIj5ybGJAaXB2LnN4PC9hPiZndDsgd3Jv
dGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0
eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6
MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn
aW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPkhleSBUTFMg
Zm9sa3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1H
QiI+T3dlbiwgTWF4LCBhbmQgSSBoYXZlIGJlZW4ga2lja2luZyBhcm91bmQgc29tZSBpZGVhcyBm
b3IgaG93IHRvIG1ha2Ugc2VjdXJlIGNvbm5lY3Rpb25zIGluIGVudmlyb25tZW50cyB3aGVyZSBI
VFRQUyBpcyBzdWJqZWN0IHRvIE1pdE0gLyBwcm94eWluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdC
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj5UaGUgYmVsb3cgZHJhZnQgbGF5cyBvdXQg
YSB3YXkgdG8gdHVubmVsIFRMUyBvdmVyIEhUVFBTLCBpbiBob3BlcyBvZiBjcmVhdGluZyBhIGNo
YW5uZWwgeW91IGNvdWxkIHVzZSB3aGVuIHlvdSByZWFsbHkgbmVlZCB0aGluZ3MgdG8gYmUgcHJp
dmF0ZSwgZXZlbiBmcm9tIHRoZQ0KIGxvY2FsIE1pdE0uJm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i
RU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPkZlZWRiYWNrIG9idmlvdXNseSB2
ZXJ5IHdlbGNvbWUuJm5ic3A7IEludGVyZXN0ZWQgaW4gd2hldGhlciBmb2xrcyB0aGluayB0aGlz
IGlzIGEgdXNlZnVsIGFyZWEgaW4gd2hpY2ggdG8gZGV2ZWxvcCBhbiBSRkMsIGFuZCBhbnkgdGhv
dWdodHMgb24gaG93IHRvIGRvIHRoaXMgYmV0dGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZu
YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdC
Ij4tLVJpY2hhcmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9
IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+T24gTW9uLCBPY3QgMzAsIDIwMTcgYXQgMzo0
NyBQTSwgJmx0OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdl
dD0iX2JsYW5rIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl
ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s
ZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9t
OjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxicj4NCkEgbmV3
IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1mcmllbC10bHMtb3Zlci1odHRwLTAwLnR4dDxicj4NCmhh
cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgT3dlbiBGcmllbCBhbmQgcG9zdGVkIHRv
IHRoZTxicj4NCklFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOiZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQtZnJpZWwtdGxzLW92ZXItaHR0cDxicj4N
ClJldmlzaW9uOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzAwPGJyPg0KVGl0bGU6Jm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBcHBsaWNhdGlvbi1MYXllciBUTFM8YnI+DQpE
b2N1bWVudCBkYXRlOiZuYnNwOyAyMDE3LTEwLTMwPGJyPg0KR3JvdXA6Jm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+DQpQYWdlczombmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDIwPGJyPg0KVVJMOiZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn
L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1mcmllbC10bHMtb3Zlci1odHRwLTAwLnR4dCIgdGFyZ2V0
PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWZy
aWVsLXRscy1vdmVyLWh0dHAtMDAudHh0PC9hPjxicj4NClN0YXR1czombmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k
b2MvZHJhZnQtZnJpZWwtdGxzLW92ZXItaHR0cC8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2Rh
dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1mcmllbC10bHMtb3Zlci1odHRwLzwvYT48YnI+
DQpIdG1saXplZDombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwczovL3Rv
b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZnJpZWwtdGxzLW92ZXItaHR0cC0wMCIgdGFyZ2V0PSJf
YmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mcmllbC10bHMtb3Zlci1o
dHRwLTAwPC9hPjxicj4NCkh0bWxpemVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhy
ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtZnJpZWwtdGxz
LW92ZXItaHR0cC0wMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v
cmcvZG9jL2h0bWwvZHJhZnQtZnJpZWwtdGxzLW92ZXItaHR0cC0wMDwvYT48YnI+DQo8YnI+DQo8
YnI+DQpBYnN0cmFjdDo8YnI+DQombmJzcDsgJm5ic3A7TWFueSBjbGllbnRzIG5lZWQgdG8gZXN0
YWJsaXNoIHNlY3VyZSBjb25uZWN0aW9ucyB0byBhcHBsaWNhdGlvbjxicj4NCiZuYnNwOyAmbmJz
cDtzZXJ2aWNlcyBidXQgZmFjZSBjaGFsbGVuZ2VzIGVzdGFibGlzaGluZyB0aGVzZSBjb25uZWN0
aW9ucyBkdWUgdG88YnI+DQombmJzcDsgJm5ic3A7dGhlIHByZXNlbmNlIG9mIG1pZGRsZWJveGVz
IHRoYXQgdGVybWluYXRlIFRMUyBjb25uZWN0aW9ucyBmcm9tIHRoZTxicj4NCiZuYnNwOyAmbmJz
cDtjbGllbnQgYW5kIHJlc3RhYmxpc2ggbmV3IFRMUyBjb25uZWN0aW9ucyB0byB0aGUgc2Vydmlj
ZS4mbmJzcDsgVGhpczxicj4NCiZuYnNwOyAmbmJzcDtkb2N1bWVudCBkZWZpbmVzIGEgbWVjaGFu
aXNtIGZvciB0cmFuc3BvcnRpbmcgVExTIHJlY29yZHMgaW4gSFRUUDxicj4NCiZuYnNwOyAmbmJz
cDttZXNzYWdlIGJvZGllcyBiZXR3ZWVuIGNsaWVudHMgYW5kIHNlcnZpY2VzLiZuYnNwOyBUaGlz
IGVuYWJsZXMgY2xpZW50czxicj4NCiZuYnNwOyAmbmJzcDthbmQgc2VydmljZXMgdG8gZXN0YWJs
aXNoIHNlY3VyZSBjb25uZWN0aW9ucyB1c2luZyBUTFMgYXQgdGhlPGJyPg0KJm5ic3A7ICZuYnNw
O2FwcGxpY2F0aW9uIGxheWVyLCBhbmQgdHJlYXQgYW55IG1pZGRsZWJveGVzIHRoYXQgYXJlIGlu
dGVyY2VwdGluZzxicj4NCiZuYnNwOyAmbmJzcDt0cmFmZmljIGF0IHRoZSBuZXR3b3JrIGxheWVy
IGFzIHVudHJ1c3RlZCB0cmFuc3BvcnQuJm5ic3A7IEluIHNob3J0LCB0aGlzPGJyPg0KJm5ic3A7
ICZuYnNwO21lY2hhbmlzbSBtb3ZlcyB0aGUgVExTIGhhbmRzaGFrZSB1cCB0aGUgT1NJIHN0YWNr
IHRvIHRoZSBhcHBsaWNhdGlvbjxicj4NCiZuYnNwOyAmbmJzcDtsYXllci48YnI+DQo8YnI+DQo8
YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9m
IG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0bWxp
emVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJodHRwOi8vdG9v
bHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnRvb2xzLmlldGYub3JnPC9hPi48YnI+DQo8
YnI+DQpUaGUgSUVURiBTZWNyZXRhcmlhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2tx
dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+
Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLUdCIj5f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClRMUyBt
YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VExTQGlldGYub3JnIiB0YXJnZXQ9Il9i
bGFuayI+VExTQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vdGxzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby90bHM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9j
a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdC
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJz
cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr
cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0Ii
PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF
Ti1HQiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1
b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_9668bf1b98474e50a46347d9199ffd8cXCHRCD012ciscocom_--


From nobody Mon Nov  6 18:47:50 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9F713FB5D for ; Mon,  6 Nov 2017 18:47:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 426tGvPiqhW9 for ; Mon,  6 Nov 2017 18:47:48 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F5B213FB0D for ; Mon,  6 Nov 2017 18:47:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2482; q=dns/txt; s=iport; t=1510022868; x=1511232468; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=JpwbW0L+q5Qb179qjnMZDfuoPHYDYXktBieUnvRpc1E=; b=eaJvnEkKnYpWDm50ERAtmXNl7vxYmlgRg18fTimyc18drALogLamWBVx 6qDX2qPLB7JPks+HoAiG0XVJb6iNqc1ZeCsYdqjc9OqWhQPHNBDOvK90f twolwKVP4QKd3kTdoR7gVnnsA3yCl3nW1FxtHqwVNCGKzT0q+GH+Nb1z0 8=;
X-IronPort-AV: E=Sophos;i="5.44,355,1505779200"; d="scan'208";a="315452544"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Nov 2017 02:47:47 +0000
Received: from [10.118.10.19] (rtp-fandreas-2-8812.cisco.com [10.118.10.19]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vA72lktd013999; Tue, 7 Nov 2017 02:47:47 GMT
To: Florian Weimer , "Nancy Cam-Winget (ncamwing)" 
Cc: "tls@ietf.org" 
References: <895D1206-28D1-43AB-8A45-11DEEC86A71D@cisco.com> <874lq868t3.fsf@mid.deneb.enyo.de>
From: Flemming Andreasen 
Message-ID: 
Date: Mon, 6 Nov 2017 21:48:38 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <874lq868t3.fsf@mid.deneb.enyo.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [TLS] network-based security solution use cases
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Nov 2017 02:47:50 -0000

On 11/5/17 10:31 AM, Florian Weimer wrote:
> * Nancy Cam-Winget:
>
>> @IETF99, awareness was raised to some of the security WGs (thanks
>> Kathleen ☺) that TLS 1.3 will obscure visibility currently afforded in
>> TLS 1.2 and asked what the implications would be for the security
>> solutions today.
>> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00 is an
>> initial draft to describe some of the impacts relating to current
>> network security solutions.  The goal of the draft is NOT to propose
>> any solution as a few have been proposed, but rather to raise
>> awareness to how current network-based security solutions work today
>> and their impact on them based on the current TLS 1.3 specification.
> I'm not sure if this approach is useful, I'm afraid.  The draft is
> basically a collection of man-in-the-middle attacks many people would
> consider benign.  It's unclear where the line is drawn: traffic
> optimization/compression and ad suppression/replacement aren't
> mentioned, for example, and I would expect both to be rather low on
> the scale of offensiveness.
We didn't draw any particular line, but the use case scenarios that we 
tried to highlight are those related to overall security and regulatory 
requirements (including public sector) where a network-based solution 
currently exists, and (we believe) is not easily replaced. A number of 
these are routinely encountered in present-day enterprise, cloud and 
public sector, and we believe they will continue to be relevant. On top 
of that, we have a rapidly expanding base of IoT endpoints with limited 
capabilities, which presents a whole new and highly vulnerable attack 
surface.

> What the draft is essentially arguing is that many user cannot afford
> end-to-end encryption for various reasons, some legal, some technical,
> some political.  But it seems to me that this is currently not a
> viewpoint shared by the IETF.
That is our read of the current situation as well, however the concern 
is that by focusing solely on privacy and e2e security, there are 
additional important considerations that are being ignored. Our intent 
with the draft is to illustrate some of those and see if we can get to 
some consensus around the need to address those (and/or possibly others).

Thanks

-- Flemming


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


From nobody Tue Nov  7 01:18:56 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78CFF13FD2D for ; Tue,  7 Nov 2017 01:18:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 TKA4Zj7G8UfW for ; Tue,  7 Nov 2017 01:18:52 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A19813FD6D for ; Tue,  7 Nov 2017 01:13:23 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8AE89BE2E; Tue,  7 Nov 2017 09:13:21 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJwTQ52GdfND; Tue,  7 Nov 2017 09:13:20 +0000 (GMT)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E8307BDF9; Tue,  7 Nov 2017 09:13:19 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1510046000; bh=vZ4K7A4Vb8F0Ub5Y9oap6lXt2cL3woMwCiMeJ3zZ1J4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ORqhQaBO5eeFOix8LKordFuJZVEVxpbR56JSR2Xj3+V2JcqCbyTHHMaVTygj8XvtQ tYNIF3+BGSpEasD6NlypDD4srBUiuSVnQSj3R/tEnWs6BZgp9f60kkVjlp6oHB1aNq zUJ7W/HQvOCsquDap9kLkwyR/deoYWquQBqwDXdg=
To: Flemming Andreasen , Florian Weimer , "Nancy Cam-Winget (ncamwing)" 
Cc: "tls@ietf.org" 
References: <895D1206-28D1-43AB-8A45-11DEEC86A71D@cisco.com> <874lq868t3.fsf@mid.deneb.enyo.de> 
From: Stephen Farrell 
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <6966da46-0f07-b518-4b6e-f2b5f599b050@cs.tcd.ie>
Date: Tue, 7 Nov 2017 09:13:19 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XMNfiVgIWDB3nQOvVQgMxXqXV3KxBhqFR"
Archived-At: 
Subject: Re: [TLS] network-based security solution use cases
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Nov 2017 09:18:54 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--XMNfiVgIWDB3nQOvVQgMxXqXV3KxBhqFR
Content-Type: multipart/mixed; boundary="FXvH3AxlFSUJ5rXR4MF7k3xWXGXtWqsGq";
 protected-headers="v1"
From: Stephen Farrell 
To: Flemming Andreasen , Florian Weimer
 , "Nancy Cam-Winget (ncamwing)" 
Cc: "tls@ietf.org" 
Message-ID: <6966da46-0f07-b518-4b6e-f2b5f599b050@cs.tcd.ie>
Subject: Re: [TLS] network-based security solution use cases
References: <895D1206-28D1-43AB-8A45-11DEEC86A71D@cisco.com>
 <874lq868t3.fsf@mid.deneb.enyo.de>
 
In-Reply-To: 

--FXvH3AxlFSUJ5rXR4MF7k3xWXGXtWqsGq
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: quoted-printable


Hiya,

On 07/11/17 02:48, Flemming Andreasen wrote:
>>
> We didn't draw any particular line, but the use case scenarios that we
> tried to highlight are those related to overall security and regulatory=

> requirements (including public sector)

I had a quick look at the draft (will try read properly en-route to
ietf-100) and I followed the reference to [1] but that only lead to a
forest of documents in which I didn't find any reference to breaking
TLS so far at least. Can you provide an explicit pointer to the
exact document on which that claim is based?

I'd also claim that your reference to PCI-DSS is misleading, as that
same spec also explicitly calls for there to be good key management
specifically including minimising the number of copies of keys, so
at most, one might be able to claim that PCI-DSS is ok with people
who break TLS in a nod-and-a-wink manner. But if you do have a real
quote from PCI-DSS that calls for breaking TLS then please do also
send that (it's been asked for a bunch of times without any answer
being provided so far).

Thanks,
S.


[1]
https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00.html#ref-NER=
CCIP


--FXvH3AxlFSUJ5rXR4MF7k3xWXGXtWqsGq--

--XMNfiVgIWDB3nQOvVQgMxXqXV3KxBhqFR
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJaAXkvAAoJEC88hzaAX42iWxIH/1tafo5T7ExXJ3nwBIoJn3Xk
lTUP4cRCXVhHnKN2wb1H2PuQMK3IInsr0UI+TpiUZ/J5CY5DslTAi2JmU9aLGdfL
YV+0tOvGQWrV7fbY9h5xg+lWYtRmrzr8d7LdAOUfQcu0xq/wLQAt0nyYXgayOx+P
ViS1QITQGhVjNm8cbUP2Htg2PgFudz7uDcRrVgQ5PpgooxEO/WDk6Fw9+RCJTB/I
/K26QO0JdAIbiIOhhezKK7Mkkj406iz+VcYPFqUzC6LTVomein+0mskCHnxqaNYZ
k6rGcax9kVjcxPD8L1H1Gg2WyrrgL+of5CA5Ix3dKBd//IlQSXOnP3KZQ1Ol/J0=
=pxA3
-----END PGP SIGNATURE-----

--XMNfiVgIWDB3nQOvVQgMxXqXV3KxBhqFR--


From nobody Tue Nov  7 01:26:45 2017
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D1D13FD50 for ; Tue,  7 Nov 2017 01:26:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 XDM6hKg_qIk5 for ; Tue,  7 Nov 2017 01:26:39 -0800 (PST)
Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 0808913FD42 for ; Tue,  7 Nov 2017 01:21:39 -0800 (PST)
Received: by mail-vk0-x231.google.com with SMTP id o145so110513vkd.0 for ; Tue, 07 Nov 2017 01:21:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7eMPjcwHFVFpmBpSqU+ic3l/iuejDyTZPYkc5wNRQAE=; b=EmlU/klpPITM6GI7NpjuUOVODJKoNPsLU8FVObFPdskUU3GV/HGwKqNwb+qRSjkTNo g97vG3ETUu9DpSaVGWWN7hNPH6i1cY7Z3vrVKd8Fv6ZYuWPWBgN78vYhq8FVfYqfajuT NnVe2IKVrOI7TbzVOkvxpe0yBgNWMFK1nu20Ap/jlT73UJAa192View1jNGj7rM8YUjz OPhvvpqtEuMqqqQB+OaZSE+VT0Hg75oTE1PJhBGQ3lBtHkOi56B0gj8Kg1J1E0sU7zdU xNNOtibetlhMTQm5ZxKA4yJg3y+CBcBr80PlNjSKReR7ONWGsay/swCNw5zKoAlrafij S/eg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7eMPjcwHFVFpmBpSqU+ic3l/iuejDyTZPYkc5wNRQAE=; b=bwJBQyttkHrCQebAyVs84snOjynG5/Fye7M0SQhRmXL31FonSsQrwoXY57cij4VehH 3TA5Fu0Wj3CwNkM67keVtvA+WGTCTbPjSkgwCqRQGJzKUXRmJajeKEMbe6hetAK1kgA5 MkvBiPN4HajclS2PtQO7oHsFkhdsjm4Bs7+XS/wqO41J0pd8vYf/z0yhu7kvY2MZoIPf VFKedFuFWwA2sdyEp5HLtnDEEqeqnhoeNDMzKdyVpzrTrV+ruc4K7AkOKAPbli6c+Lla 87m1FI3rQ2PhZuYSdEzyeqvs1vlArGPXwTT0OOdY4j97NMzgzGje/jR6mb255BVAuKbe OCrw==
X-Gm-Message-State: AJaThX6afNGFKxWEstRe76Kf6J2mxXwybr7wgyCDmOLZDP7IXXRsY99W U53uLdZg4NkcFzmuEfIkRmeQOQca8tKD9/PNAlY=
X-Google-Smtp-Source: ABhQp+TGIHmC1Nep45aA6LbVoAOcKafEUPZuJX2c7ZnHr65EaUT3DGmPvVCilbCEyb9UBSDlWfL9fC3Fyus6BRGm0Xo=
X-Received: by 10.31.53.204 with SMTP id c195mr14460203vka.97.1510046498061; Tue, 07 Nov 2017 01:21:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.34.67 with HTTP; Tue, 7 Nov 2017 01:21:37 -0800 (PST)
In-Reply-To: 
References: <150939282345.7694.10153977158870845060.idtracker@ietfa.amsl.com> 
From: Alex C 
Date: Tue, 7 Nov 2017 22:21:37 +1300
Message-ID: 
To: Richard Barnes 
Cc: "" 
Content-Type: multipart/alternative; boundary="001a114476081c843c055d6119b4"
Archived-At: 
Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Nov 2017 09:26:43 -0000

--001a114476081c843c055d6119b4
Content-Type: text/plain; charset="UTF-8"

What exactly is the threat model here?

Are you trying to hide a connection from a reverse proxy at the server end?
If so, the server operator should not have deployed a reverse proxy in the
first place.

Are you trying to hide from a MITM proxy that supplies its own certificate?
If so, then what prevents the proxy from doing the same to the tunnelled
session?
When MITM proxies learn to do that, will we create another tunnelling
protocol inside this one?

This is a cat-and-mouse game with middleboxes (much like the version
negotiation problem, but in a different way). Keep playing and everyone
loses.

On Tue, Oct 31, 2017 at 11:17 AM, Richard Barnes  wrote:

> Hey TLS folks,
>
> Owen, Max, and I have been kicking around some ideas for how to make
> secure connections in environments where HTTPS is subject to MitM /
> proxying.
>
> The below draft lays out a way to tunnel TLS over HTTPS, in hopes of
> creating a channel you could use when you really need things to be private,
> even from the local MitM.
>
> Feedback obviously very welcome.  Interested in whether folks think this
> is a useful area in which to develop an RFC, and any thoughts on how to do
> this better.
>
> Thanks,
> --Richard
>
>
> On Mon, Oct 30, 2017 at 3:47 PM,  wrote:
>
>>
>> A new version of I-D, draft-friel-tls-over-http-00.txt
>> has been successfully submitted by Owen Friel and posted to the
>> IETF repository.
>>
>> Name:           draft-friel-tls-over-http
>> Revision:       00
>> Title:          Application-Layer TLS
>> Document date:  2017-10-30
>> Group:          Individual Submission
>> Pages:          20
>> URL:            https://www.ietf.org/internet-
>> drafts/draft-friel-tls-over-http-00.txt
>> Status:         https://datatracker.ietf.org/
>> doc/draft-friel-tls-over-http/
>> Htmlized:       https://tools.ietf.org/html/draft-friel-tls-over-http-00
>> Htmlized:       https://datatracker.ietf.org/
>> doc/html/draft-friel-tls-over-http-00
>>
>>
>> Abstract:
>>    Many clients need to establish secure connections to application
>>    services but face challenges establishing these connections due to
>>    the presence of middleboxes that terminate TLS connections from the
>>    client and restablish new TLS connections to the service.  This
>>    document defines a mechanism for transporting TLS records in HTTP
>>    message bodies between clients and services.  This enables clients
>>    and services to establish secure connections using TLS at the
>>    application layer, and treat any middleboxes that are intercepting
>>    traffic at the network layer as untrusted transport.  In short, this
>>    mechanism moves the TLS handshake up the OSI stack to the application
>>    layer.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>

--001a114476081c843c055d6119b4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


What exactly is the threat model here?
<=
br>
Are you trying to hide a connection from a reverse proxy at the se=
rver end? If so, the server operator should not have deployed a reverse pro=
xy in the first place.

Are you trying to hide from a MITM prox=
y that supplies its own certificate? If so, then what prevents the proxy fr=
om doing the same to the tunnelled session?
When MITM proxies=
 learn to do that, will we create another tunnelling protocol inside this o=
ne?

This is a cat-and-mouse game with middleboxes (=
much like the version negotiation problem, but in a different way). Keep pl=
aying and everyone loses.

On Tue, Oct 31, 2017 at 11:17 AM, Richard Barnes <rlb@ipv.sx> wrote:
Hey TLS folks,

Owen, Max, and I have been kicking=
 around some ideas for how to make secure connections in environments where=
 HTTPS is subject to MitM / proxying.

The below dr=
aft lays out a way to tunnel TLS over HTTPS, in hopes of creating a channel=
 you could use when you really need things to be private, even from the loc=
al MitM.=C2=A0 

Feedback obviously very welcom=
e.=C2=A0 Interested in whether folks think this is a useful area in which t=
o develop an RFC, and any thoughts on how to do this better.
=

Thanks,
--Richard


On Mon, Oct 30, 2017 =
at 3:47 PM,  <internet-drafts@ietf.org> wrote:


A new version of I-D, draft-friel-tls-over-http-00.txt

has been successfully submitted by Owen Friel and posted to the

IETF repository.



Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-friel-tls-over-http

Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000

Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Application-Layer TLS

Document date:=C2=A0 2017-10-30

Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission

Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 20

URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-friel-tls-ov=
er-http-00.txt

Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
https://datatracker.ietf.org/doc/draft-friel-tls-over-http/

Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://=
tools.ietf.org/html/draft-friel-tls-over-http-00

Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-friel-tls-over-http=
-00





Abstract:

=C2=A0 =C2=A0Many clients need to establish secure connections to applicati=
on

=C2=A0 =C2=A0services but face challenges establishing these connections du=
e to

=C2=A0 =C2=A0the presence of middleboxes that terminate TLS connections fro=
m the

=C2=A0 =C2=A0client and restablish new TLS connections to the service.=C2=
=A0 This

=C2=A0 =C2=A0document defines a mechanism for transporting TLS records in H=
TTP

=C2=A0 =C2=A0message bodies between clients and services.=C2=A0 This enable=
s clients

=C2=A0 =C2=A0and services to establish secure connections using TLS at the<=
br>
=C2=A0 =C2=A0application layer, and treat any middleboxes that are intercep=
ting

=C2=A0 =C2=A0traffic at the network layer as untrusted transport.=C2=A0 In =
short, this

=C2=A0 =C2=A0mechanism moves the TLS handshake up the OSI stack to the appl=
ication

=C2=A0 =C2=A0layer.









Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at tools.ietf.org.



The IETF Secretariat







_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf.org/mailman/listinfo/tls