From cfinss@dial.pipex.com  Sun Aug  2 03:19:35 2009
Return-Path: <cfinss@dial.pipex.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1E5B3A690C; Sun,  2 Aug 2009 03:19:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.451
X-Spam-Level: 
X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[AWL=-0.941, BAYES_05=-1.11, J_CHICKENPOX_35=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxn2lNfMndAD; Sun,  2 Aug 2009 03:19:34 -0700 (PDT)
Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id A0B693A68B3; Sun,  2 Aug 2009 03:19:33 -0700 (PDT)
X-Trace: 238410600/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.192/None/cfinss@dial.pipex.com
X-SBRS: None
X-RemoteIP: 62.188.105.192
X-IP-MAIL-FROM: cfinss@dial.pipex.com
X-SMTP-AUTH: 
X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106
X-IP-BHB: Once
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArcEAPMEdUo+vGnA/2dsb2JhbACDLTyMZ8ByCYQPBQ
X-IronPort-AV: E=Sophos;i="4.43,308,1246834800"; d="scan'208";a="238410600"
X-IP-Direction: IN
Received: from 1cust192.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.192]) by smtp.pipex.tiscali.co.uk with SMTP; 02 Aug 2009 11:19:33 +0100
Message-ID: <000201ca1352$42b53ba0$0601a8c0@allison>
From: "tom.petch" <cfinss@dial.pipex.com>
To: "Michael Tuexen" <tuexen@fh-muenster.de>
References: <4A6EB9BB.9040002@net.in.tum.de> <000401ca111a$3bb01da0$0601a8c0@allison> <EB76C973-49C7-494C-8281-52559BC61F40@fh-muenster.de>
Date: Sun, 2 Aug 2009 11:11:03 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Cc: ipfix@ietf.org, Daniel Mentz <mentz@in.tum.de>, Gerhard Muenz <muenz@net.in.tum.de>, syslog <syslog@ietf.org>, tls@ietf.org
Subject: Re: [TLS] [Syslog] Missing dead peer detection in DTLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "tom.petch" <cfinss@dial.pipex.com>
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 02 Aug 2009 10:19:35 -0000

Reply inline, twice

Tom Petch

----- Original Message -----
From: "Michael Tuexen" <tuexen@fh-muenster.de>
To: "tom.petch" <cfinss@dial.pipex.com>
Sent: Thursday, July 30, 2009 5:24 PM

a question in-line.

Michael

On Jul 30, 2009, at 11:44 AM, tom.petch wrote:

> Gerhard
>
> Thank you for pointing this out; it had escaped me.
>
> What I had thought though was that the lack of flow control with
> DTLS over UDP
> is a problem, and that the lack of this with syslog over UDP led the
> syslog RFC
> [RFC5424] to make syslog over TLS the RECOMMENDED transport, not, as
> might be
> expected, syslog over UDP.

So I think it is actually congestion control what you are looking
for, which is provided by TCP when using SYSLOG/TLS/TCP/IP, right?

<tp>
For myself, no, I was not looking for or caring about congestion control, rather
security.

But when the syslog I-D got to the IESG, they did care about congestion, and so
the syslog I-D was modified to make syslog over TLS the RECOMMENDED transport,
not because it might or might not improve security but because it
offered congestion control, which UDP by itself does not.
</tp>
>
> This in turn led me to expect that syslog over DTLS over UDP would
> not be
> acceptable to the IESG, rather that syslog over DTLS over SCTP would
> become the
> RECOMMENDED transport.

This would mean, that
* SYSLOG/TLS/TCP/IP
* SYSLOG/DTLS/SCTP/IP
* SYSLOG/DTLS/DCCP/IP
are in principle acceptable, whereas
* SYSLOG/DTLS/UDP/IP
is not.
You would (from the congestion control perspective) have the same
classification when taking out the DTLS or TLS layer, right?

<tp>
I am unclear about your second sentence, but the first one, yes, I would expect
the first three to be acceptable to the IESG (which is rather important if you
want an I-D to become an RFC) and the last one not to be.  TLS (by using TCP),
SCTP, DCCP have acceptable congestion control, DTLS and UDP do not.

Tom Petch

> So; several thoughts.
>
> This is an update to the extensions RFC, RFC4366, which itself is
> being updated
> by the TLS working group (hence my addition of them to the list) and
> I would
> much rather have one extensions RFC rather than several.  This is a
> good concept
> and fills a need; perhaps the TLS working group would take this on.
>
> Flow control remains an issue which I do not think that this extension
> addresses.
>
> Is this a security exposure? or just, like syslog over UDP, an
> inconvenient
> truth?
>
> The petch-gerhards draft allows the recipient of the unidirectional
> flow to
> initiate the DTLS 'connection', and so enables it to re-establish
> the connection
> when anything goes wrong.  This would seem an alternative to consider.
>
> Tom Petch
<snip>


From jsalowey@cisco.com  Mon Aug  3 11:29:08 2009
Return-Path: <jsalowey@cisco.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B6583A6E78 for <tls@core3.amsl.com>; Mon,  3 Aug 2009 11:29:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.543
X-Spam-Level: 
X-Spam-Status: No, score=-6.543 tagged_above=-999 required=5 tests=[AWL=0.057,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R34JSfnjmc47 for <tls@core3.amsl.com>; Mon,  3 Aug 2009 11:29:07 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id EE37A28C1DB for <tls@ietf.org>; Mon,  3 Aug 2009 11:28:54 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEABDJdkqrR7PE/2dsb2JhbAC8D4gpjlwFhBg
X-IronPort-AV: E=Sophos;i="4.43,315,1246838400"; d="scan'208";a="359460051"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 03 Aug 2009 18:28:57 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n73ISvbf002715 for <tls@ietf.org>; Mon, 3 Aug 2009 11:28:57 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n73ISvxR008977 for <tls@ietf.org>; Mon, 3 Aug 2009 18:28:57 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 3 Aug 2009 11:28:57 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 3 Aug 2009 11:28:56 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE5087BCE4B@xmb-sjc-225.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Draft minutes for IETF-75 available
Thread-Index: AcoUaELX0RiG8oKyRE2XGsqbmP6kmg==
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: <tls@ietf.org>
X-OriginalArrivalTime: 03 Aug 2009 18:28:57.0483 (UTC) FILETIME=[437BEDB0:01CA1468]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=159; t=1249324137; x=1250188137; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20<jsalowey@ci sco.com> |Subject:=20Draft=20minutes=20for=20IETF-75=20available |Sender:=20; bh=uVDAXOYLb/9sVYcNK9LCPjT+pF+7aOvtxjGY9bXY6kI=; b=TAFr6GMi92v4Q4Q/6NHcaOka+tSodsDwT5l9/p+iHkTEemnIlodmagUn2V sOd01kq+lcpbgnQVLBH98nPvYuV8IaWWUGzFsWnG2+QTry/1IsjoE6l1YKO8 wDQY38sN6/;
Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 
Subject: [TLS] Draft minutes for IETF-75 available
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Aug 2009 18:29:08 -0000

Draft minutes for IETF 75 are available here:

http://www.ietf.org/proceedings/75/minutes/tls.txt

Let me know if you have corrections.

Thanks,

Joe

From muenz@net.in.tum.de  Mon Aug  3 13:03:32 2009
Return-Path: <muenz@net.in.tum.de>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8965A28C26C for <tls@core3.amsl.com>; Mon,  3 Aug 2009 13:03:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.063
X-Spam-Level: 
X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[AWL=0.186,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hv0i4qvs6cTp for <tls@core3.amsl.com>; Mon,  3 Aug 2009 13:03:31 -0700 (PDT)
Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id 76F2728C23C for <tls@ietf.org>; Mon,  3 Aug 2009 13:03:31 -0700 (PDT)
Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 70C0F48588 for <tls@ietf.org>; Mon,  3 Aug 2009 22:03:32 +0200 (CEST)
Received: from [131.159.20.251] (vpn-1.net.in.tum.de [131.159.20.251]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 3CCBD3F04 for <tls@ietf.org>; Mon,  3 Aug 2009 22:03:32 +0200 (CEST)
Message-ID: <4A77429B.9080506@net.in.tum.de>
Date: Mon, 03 Aug 2009 22:03:39 +0200
From: Gerhard Muenz <muenz@net.in.tum.de>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: tls@ietf.org
References: <mailman.77.1249326021.24683.tls@ietf.org>
In-Reply-To: <mailman.77.1249326021.24683.tls@ietf.org>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000109010507050101030809"
X-Virus-Scanned: ClamAV using ClamSMTP
Subject: Re: [TLS] Draft minutes for IETF-75 available
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Aug 2009 20:03:32 -0000

This is a cryptographically signed message in MIME format.

--------------ms000109010507050101030809
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


Hi,

> Draft minutes for IETF 75 are available here:
> 
> http://www.ietf.org/proceedings/75/minutes/tls.txt
> 
> Let me know if you have corrections.

Probably here:

> 3. DTLS Heartbeat - Presented by Michael Tuexen
> 
> Draft: http://www.ietf.org/internet-drafts/draft-seggelmann-tls-dtls-heartbeat-00.txt
> 
> Pasi Eronen (AD): I can see this being useful in cases, but I can also see
>       it being solved in the lower layer protocols.  EG, in IPFIX I

lower => upper ? (otherwise, it does not make sense)

>       can very much see them solving it at their layer.
> Michael Tuexen: I see your point but...
> Pasi: I can also see this useful for PMTU discovery.
> Michael: That's true but it doesn't necessarily work for bi-directional
> 	differences.  You can another message which contains extra

missing verb?

> 	stuff for doing discovery.  SCTP has opaque data for doing
> 	things like that.  I like the discovery message, but I think
> 	it should be another message.
> Eric (Jabber): this is relevant in TCP cases as well.
> 
> Question: if you use this in UDP, the draft says you must not send them
>       while you're waiting for a response.
> Michael: Only one heart-beat request in flight at a time.  I don't want
> 	to have a congestion control problem
> 
> Wes Hardaker: agree with EKR that it is useful it TCP as well,
>       though you need to document differences.  Longer discussion on
>       the rational behind it.  

Some thoughts about the proposal to solve Heartbeat at the IPFIX layer
(from me as a contributor to IPFIX):
It is extremely unlikely that we will change the IPFIX protocol from
unidirectional to bidirectional just because DTLS-over-UDP requires it.
In my opinion, if we had to choose, it would be more likely that we
would update RFC5101 saying that DTLS is not required any more for
IPFIX-over-UDP implementations, and that the usage of
IPFIX-over-DTLS/UDP is not recommended because of the dead peer
detection problem.
IPFIX cannot reasonably deploy DTLS for UDP without the proposed
Heartbeat extension. The available workarounds are not very nice.

Regards,
Gerhard

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC
Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI
EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv
bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi
BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy
c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5
NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM
dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy
Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC
dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB
kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh
d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD
gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi
w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb
NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP
MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs
dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz
dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN
dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG
SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN
AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH
LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s
ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t
PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG
Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB
BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l
dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr
33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX
i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc
T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF
BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0
ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5
MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq
EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu
ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l
dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq
9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb
woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW
WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga
ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk
impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11
ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM
BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp
QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5
vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID
ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg
KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg
Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG
SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwODAzMjAwMzM5WjAjBgkqhkiG9w0BCQQxFgQU
1LvNWfkdFLSr0XZjwW4dTT9iaGswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq
hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG
CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0
aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1
aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP
MA0GCSqGSIb3DQEBAQUABIIBALebub2x0h5fE/WQLG1nZRnyEKnQVBcPzBJZdngRWcrtTvmO
z6VQSJSe7LAjVB4kz+7HnczXQEW0CRixi2aubmHSxNUMZnDcjoV7blODp1JNum+yuyzOaoVQ
inCCpiB6oOrHlrEWx8cD/V5AzT+im8F7OoNDo8tZjr9ZOuqxHlAAIrBP7fQyDkdMpVPh/J7p
CcpkwC/0UvxUePdbHItjuT7JS6MaMBhASFL77JTWrq7j7v/iq+qIMcf6M4u3jdrFQGpjAveL
vq54PkbW7e1+ifDFB2D4BENbPqOSZ4wT/SOwZtnkHfgH8e8YEViU9dE/MwiXldM6TdE0KMFM
PsixN9gAAAAAAAA=
--------------ms000109010507050101030809--

From jsalowey@cisco.com  Mon Aug  3 13:35:07 2009
Return-Path: <jsalowey@cisco.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 153063A67BD for <tls@core3.amsl.com>; Mon,  3 Aug 2009 13:35:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.548
X-Spam-Level: 
X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.051,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMWhussFhK+9 for <tls@core3.amsl.com>; Mon,  3 Aug 2009 13:35:06 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 089F628C24C for <tls@ietf.org>; Mon,  3 Aug 2009 13:34:17 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEANPmdkqrR7PE/2dsb2JhbAC7XogpjnMFhBg
X-IronPort-AV: E=Sophos;i="4.43,316,1246838400"; d="scan'208";a="222800916"
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 03 Aug 2009 20:34:19 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n73KYJ4x025471;  Mon, 3 Aug 2009 13:34:19 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n73KYJYi026818; Mon, 3 Aug 2009 20:34:19 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 3 Aug 2009 13:34:19 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 3 Aug 2009 13:34:18 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE5087BCF21@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <4A77429B.9080506@net.in.tum.de>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [TLS] Draft minutes for IETF-75 available
Thread-Index: AcoUdX0JBU+vCrS0Q4u54v5OsAFraAAA2GUQ
References: <mailman.77.1249326021.24683.tls@ietf.org> <4A77429B.9080506@net.in.tum.de>
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: "Gerhard Muenz" <muenz@net.in.tum.de>, <tls@ietf.org>
X-OriginalArrivalTime: 03 Aug 2009 20:34:19.0626 (UTC) FILETIME=[C707DCA0:01CA1479]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=969; t=1249331659; x=1250195659; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20<jsalowey@ci sco.com> |Subject:=20RE=3A=20[TLS]=20Draft=20minutes=20for=20IETF-75 =20available |Sender:=20; bh=Hcjm4ZDS6Ll6pOQAw3ui7jTtp/PRxyJy0dALyi9+h4M=; b=f6R6RdIPDj1nqh8cHTiIuo+FXdWVAjp0NCoAga0hjikLQMCmFXMsT9TDOs cF8lUTLqr3upZrJleC6lIyMpFR/cWrr7vT6evHCdk5tkhModsfOQthpI8zrG zdcoARXbVR;
Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); 
Subject: Re: [TLS] Draft minutes for IETF-75 available
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Aug 2009 20:35:07 -0000

Thanks Gerhard,

Minutes updated.  =20

Some questions below:

<snip>=20
> Some thoughts about the proposal to solve Heartbeat at the=20
> IPFIX layer (from me as a contributor to IPFIX):
> It is extremely unlikely that we will change the IPFIX=20
> protocol from unidirectional to bidirectional just because=20
> DTLS-over-UDP requires it.
> In my opinion, if we had to choose, it would be more likely=20
> that we would update RFC5101 saying that DTLS is not required=20
> any more for IPFIX-over-UDP implementations, and that the=20
> usage of IPFIX-over-DTLS/UDP is not recommended because of=20
> the dead peer detection problem.

[Joe] Is IPFIX defined over UDP without DTLS?  If so, would
IPFIX-over-UDP have a dead peer detection problem of its own? =20

> IPFIX cannot reasonably deploy DTLS for UDP without the=20
> proposed Heartbeat extension. The available workarounds are=20
> not very nice.
>=20


> Regards,
> Gerhard
>=20

From muenz@net.in.tum.de  Mon Aug  3 14:03:16 2009
Return-Path: <muenz@net.in.tum.de>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D03F53A6986 for <tls@core3.amsl.com>; Mon,  3 Aug 2009 14:03:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level: 
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=0.163,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfbtr6v3JKQ2 for <tls@core3.amsl.com>; Mon,  3 Aug 2009 14:03:16 -0700 (PDT)
Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) by core3.amsl.com (Postfix) with ESMTP id C07C73A687F for <tls@ietf.org>; Mon,  3 Aug 2009 14:03:15 -0700 (PDT)
Received: from phoenix.net.informatik.tu-muenchen.de (phoenix.net.in.tum.de [131.159.14.1]) by services.net.informatik.tu-muenchen.de (Postix Mailer @ mail) with ESMTP id 7C3F847FB7; Mon,  3 Aug 2009 23:03:15 +0200 (CEST)
Received: from [131.159.20.251] (vpn-1.net.in.tum.de [131.159.20.251]) by phoenix.net.informatik.tu-muenchen.de (Postfix) with ESMTP id 1E916509D; Mon,  3 Aug 2009 23:03:15 +0200 (CEST)
Message-ID: <4A775099.5040003@net.in.tum.de>
Date: Mon, 03 Aug 2009 23:03:21 +0200
From: Gerhard Muenz <muenz@net.in.tum.de>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
References: <mailman.77.1249326021.24683.tls@ietf.org> <4A77429B.9080506@net.in.tum.de> <AC1CFD94F59A264488DC2BEC3E890DE5087BCF21@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE5087BCF21@xmb-sjc-225.amer.cisco.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010103030504050806070309"
X-Virus-Scanned: ClamAV using ClamSMTP
Cc: tls@ietf.org
Subject: Re: [TLS] Draft minutes for IETF-75 available
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Aug 2009 21:03:16 -0000

This is a cryptographically signed message in MIME format.

--------------ms010103030504050806070309
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


Joseph,

Joseph Salowey (jsalowey) wrote:
> Thanks Gerhard,
> 
> Minutes updated.   
> 
> Some questions below:
> 
> <snip> 
>> Some thoughts about the proposal to solve Heartbeat at the 
>> IPFIX layer (from me as a contributor to IPFIX):
>> It is extremely unlikely that we will change the IPFIX 
>> protocol from unidirectional to bidirectional just because 
>> DTLS-over-UDP requires it.
>> In my opinion, if we had to choose, it would be more likely 
>> that we would update RFC5101 saying that DTLS is not required 
>> any more for IPFIX-over-UDP implementations, and that the 
>> usage of IPFIX-over-DTLS/UDP is not recommended because of 
>> the dead peer detection problem.
> 
> [Joe] Is IPFIX defined over UDP without DTLS?  If so, would
> IPFIX-over-UDP have a dead peer detection problem of its own?  

Thanks for you interest in this problem.

The answer is yes and no.

Yes, it is a problem because with UDP the Exporter will never know
exactly if the Collector is up and receiving IPFIX Messages. A
non-existing Collector can be detected via returned ICMP messages
(destination unreachable and the like). However, such messages are often
blocked by firewalls.

However, no, it is not such a big problem because UDP is unrealiable anyway.

The big difference between IPFIX-over-UDP and IPFIX-over-DTLS/UDP is
that you can always start or restart a UDP Collector without touching
the Exporter. If the Collector is listening on the correct UDP port, it
will receive the Templates after a while (Templates are retransmitted
periodically when UDP is used), and then, it will be able to start or
resume decoding IPFIX Messages.

With DTLS/UDP, the Exporter must initiate the DTLS renegotiation after
the Collector has restarted. This is because the Collector does not know
which Exporters actually exist (like a server which does not know its
clients in advance). So, the Exporter should somehow know when a
renegotiation is necessary. It seems that DTLS Heartbeat would nicely
solve this.

Regards,
Gerhard


>> IPFIX cannot reasonably deploy DTLS for UDP without the 
>> proposed Heartbeat extension. The available workarounds are 
>> not very nice.
>>
> 
> 
>> Regards,
>> Gerhard
>>

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ6TCC
Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI
EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv
bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi
BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy
c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5
NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM
dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN
BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy
Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC
dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB
kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh
d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD
gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi
w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb
NU1341YheILcIRk13iSx0x1G/11fZU8wggNPMIICuKADAgECAhAqxerdN2XVRkUZsuk5IKdP
MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs
dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz
dWluZyBDQTAeFw0wOTAyMTkxMDI5NDVaFw0xMDAyMTkxMDI5NDVaMIGQMQ4wDAYDVQQEEwVN
dWVuejEQMA4GA1UEKhMHR2VyaGFyZDEWMBQGA1UEAxMNR2VyaGFyZCBNdWVuejEwMC4GCSqG
SIb3DQEJARYhbXVlbnpAaW5mb3JtYXRpay51bmktdHVlYmluZ2VuLmRlMSIwIAYJKoZIhvcN
AQkBFhNtdWVuekBuZXQuaW4udHVtLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAxC8p+6KRpyQyKvT9LAxUB2m8azrci+c5oQUYac2A4WsjoqiCqi2k/wgCrCIHrN0USQeH
LmcbtSWT5O+1kMai28KGUdZG5xmJ7PLuLejKlYIu2TkR8tI1Q4gyu1Gs45yn9Rf+EGWmqa/s
ebjMV3tc/zrpEN2b1ls8U9rM2/h0NcUUU+g170e8DlXNOL7+bsQD+tLH5G3nlV9mZntMQ68t
PaaLG4MtupHuS99YGoo0yB4rzuTxiWRKTJgqjboQL0eS9+6dxsrT01g7sOc2QtXbO45PBnsG
Ra5CAMpGLrqGT1ISZIpqYrGuMH9Rv7HTR3rLygL81WMDtNCa6W5/PPMlSwIDAQABo1MwUTBB
BgNVHREEOjA4gSFtdWVuekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGWBE211ZW56QG5l
dC5pbi50dW0uZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQBOkMsohjpIH4Mr
33zNnhc5PkzAi0RZ6UAOB28nTtfjVZ25UVLWqmLgYEszbloTd07y5PcUZhSuPuwGzEwn4XdX
i3VWl6qk5VcPpyP7+b5XEY5CU1A8cqeaXS88qWyshu1dXm2ToqueRPv+E2b3GJHAciNt2Qfc
T4SNWymkvUyPSjCCA08wggK4oAMCAQICECrF6t03ZdVGRRmy6Tkgp08wDQYJKoZIhvcNAQEF
BQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0
ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5
MDIxOTEwMjk0NVoXDTEwMDIxOTEwMjk0NVowgZAxDjAMBgNVBAQTBU11ZW56MRAwDgYDVQQq
EwdHZXJoYXJkMRYwFAYDVQQDEw1HZXJoYXJkIE11ZW56MTAwLgYJKoZIhvcNAQkBFiFtdWVu
ekBpbmZvcm1hdGlrLnVuaS10dWViaW5nZW4uZGUxIjAgBgkqhkiG9w0BCQEWE211ZW56QG5l
dC5pbi50dW0uZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDELyn7opGnJDIq
9P0sDFQHabxrOtyL5zmhBRhpzYDhayOiqIKqLaT/CAKsIges3RRJB4cuZxu1JZPk77WQxqLb
woZR1kbnGYns8u4t6MqVgi7ZORHy0jVDiDK7UazjnKf1F/4QZaapr+x5uMxXe1z/OukQ3ZvW
WzxT2szb+HQ1xRRT6DXvR7wOVc04vv5uxAP60sfkbeeVX2Zme0xDry09posbgy26ke5L31ga
ijTIHivO5PGJZEpMmCqNuhAvR5L37p3GytPTWDuw5zZC1ds7jk8GewZFrkIAykYuuoZPUhJk
impisa4wf1G/sdNHesvKAvzVYwO00Jrpbn888yVLAgMBAAGjUzBRMEEGA1UdEQQ6MDiBIW11
ZW56QGluZm9ybWF0aWsudW5pLXR1ZWJpbmdlbi5kZYETbXVlbnpAbmV0LmluLnR1bS5kZTAM
BgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBAE6QyyiGOkgfgyvffM2eFzk+TMCLRFnp
QA4HbydO1+NVnblRUtaqYuBgSzNuWhN3TvLk9xRmFK4+7AbMTCfhd1eLdVaXqqTlVw+nI/v5
vlcRjkJTUDxyp5pdLzypbKyG7V1ebZOiq55E+/4TZvcYkcByI23ZB9xPhI1bKaS9TI9KMYID
ZDCCA2ACAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg
KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg
Q0ECECrF6t03ZdVGRRmy6Tkgp08wCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqG
SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDkwODAzMjEwMzIxWjAjBgkqhkiG9w0BCQQxFgQU
tcDbAklv/0Lcvml3wUnLYKgphP4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggq
hkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUG
CSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0
aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1
aW5nIENBAhAqxerdN2XVRkUZsuk5IKdPMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UE
BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAqxerdN2XVRkUZsuk5IKdP
MA0GCSqGSIb3DQEBAQUABIIBABBOHkDuEYr2ivtmN7BBEhQr2Wv9VIFObgs9iz+ERjmZKZou
4RTlHmH21NOwp5rZFnD6B+hGIsHLKCMctuPkgdO7SN3HDaId8JyTADKDo1M2r+aib805PA9F
iJ2qm+JJ5kgo13yEx31icu36GIBjjrD7GCILR+ZwD+ItW2jivd4UuMtLWaNM7i7o6NSViS05
XqolhkbnKrOYB7mqwEIhewttebDEPDyqmE4BSfUzXa6AJwMb6ew+8E26agZfc3J9hpXMjDnZ
9R+srDtRVCNmRZLVfDHnzFtV2MEayZmg67SX6HTDdlfb5Qkcv5MGiXXAtuewH+cJYglMBECq
NbkBwecAAAAAAAA=
--------------ms010103030504050806070309--

From jsalowey@cisco.com  Mon Aug  3 14:27:10 2009
Return-Path: <jsalowey@cisco.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46BEE28C1CE for <tls@core3.amsl.com>; Mon,  3 Aug 2009 14:27:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level: 
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2ypYPOT6CIm for <tls@core3.amsl.com>; Mon,  3 Aug 2009 14:27:09 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 1451C3A6CF2 for <tls@ietf.org>; Mon,  3 Aug 2009 14:27:09 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAJXydkqrR7O6/2dsb2JhbAC7ZYgpjn4FhBg
X-IronPort-AV: E=Sophos;i="4.43,316,1246838400"; d="scan'208";a="222828164"
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 03 Aug 2009 21:27:10 +0000
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n73LRA0C015968 for <tls@ietf.org>; Mon, 3 Aug 2009 14:27:10 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n73LRA2p018968 for <tls@ietf.org>; Mon, 3 Aug 2009 21:27:10 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 3 Aug 2009 14:27:10 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 3 Aug 2009 14:27:09 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE5087BCF66@xmb-sjc-225.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Proto write-up for draft-ietf-tls-rfc4366-bis-05
Thread-Index: AcoUgShzIfCV2zGIR7eo55I7CtBLqA==
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: <tls@ietf.org>
X-OriginalArrivalTime: 03 Aug 2009 21:27:10.0413 (UTC) FILETIME=[28F78FD0:01CA1481]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6415; t=1249334830; x=1250198830; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20<jsalowey@ci sco.com> |Subject:=20Proto=20write-up=20for=20draft-ietf-tls-rfc4366 -bis-05 |Sender:=20; bh=5dR9rVq2dkH59yGzMlP6Igmew7tR81Rdh2iXUAGb5L4=; b=e3SpSsb6xVXTl0nVr9u/dVyy+9rWykDugyzN3gXezIjA88Pl3GKC7Tfpzl x92skPe8XjTo7cDbIyKHXcid283FJxsXmAj/cgYZOLGkYiGfrIs+cxPPfdTY 6Ba8U1yBer;
Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); 
Subject: [TLS] Proto write-up for draft-ietf-tls-rfc4366-bis-05
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Aug 2009 21:27:10 -0000

Below is the proto write-up for  draft-ietf-tls-rfc4366-bis-05 (TLS
Extensions)

Cheers,

Joe


  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the=20
        document and, in particular, does he or she believe this=20
        version is ready for forwarding to the IESG for publication?=20

Joe Salowey, TLS WG co-chair, is the document shepherd for this
document, draft-ietf-tls-rfc4366-bis-05,  and believes it is ready for
publication.=20

  (1.b) Has the document had adequate review both from key WG members=20
        and from key non-WG members? Does the Document Shepherd have=20
        any concerns about the depth or breadth of the reviews that=20
        have been performed? =20

The document has had adequate review.  The document shepherd does not
have any concerns about the breadth  of reviews.=20

  (1.c) Does the Document Shepherd have concerns that the document=20
        needs more review from a particular or broader perspective,=20
        e.g., security, operational complexity, someone familiar with=20
        AAA, internationalization or XML?=20

no

  (1.d) Does the Document Shepherd have any specific concerns or=20
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he=20
        or she is uncomfortable with certain parts of the document, or=20
        has concerns whether there really is a need for it. In any=20
        event, if the WG has discussed those issues and has indicated=20
        that it still wishes to advance the document, detail those=20
        concerns here. Has an IPR disclosure related to this document=20
        been filed? If so, please include a reference to the=20
        disclosure and summarize the WG discussion and conclusion on=20
        this issue.=20

There is no IPR disclosure specifically for this draft, however RFC 4366
is listed as related material for  the Certicom IPR Disclosure
https://datatracker.ietf.org/ipr/1154/.

  (1.e) How solid is the WG consensus behind this document? Does it=20
        represent the strong concurrence of a few individuals, with=20
        others being silent, or does the WG as a whole understand and=20
        agree with it?  =20


There as a good amount of consensus around this document within the
working group.=20

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme=20
        discontent? If so, please summarise the areas of conflict in=20
        separate email messages to the Responsible Area Director. (It=20
        should be in a separate email because this questionnaire is=20
        entered into the ID Tracker.)=20

No.

  (1.g) Has the Document Shepherd personally verified that the=20
        document satisfies all ID nits? (See the Internet-Drafts
Checklist=20
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are

        not enough; this check needs to be thorough. Has the document=20
        met all formal review criteria it needs to, such as the MIB=20
        Doctor, media type and URI type reviews?=20

Yes

  (1.h) Has the document split its references into normative and=20
        informative? Are there normative references to documents that=20
        are not ready for advancement or are otherwise in an unclear=20
        state? If such normative references exist, what is the=20
        strategy for their completion? Are there normative references=20
        that are downward references, as described in [RFC3967]? If=20
        so, list these downward references to support the Area=20
        Director in the Last Call procedure for them [RFC3967].=20

The references are split between normative and informative.  Downrefs
are informational.=20


  (1.i) Has the Document Shepherd verified that the document IANA=20
        consideration section exists and is consistent with the body=20
        of the document? If the document specifies protocol=20
        extensions, are reservations requested in appropriate IANA=20
        registries? Are the IANA registries clearly identified? If=20
        the document creates a new registry, does it define the=20
        proposed initial contents of the registry and an allocation=20
        procedure for future registrations? Does it suggest a=20
        reasonable name for the new registry? See [RFC5226]. If the=20
        document describes an Expert Review process has Shepherd=20
        conferred with the Responsible Area Director so that the IESG=20
        can appoint the needed Expert during the IESG Evaluation?=20

The document does not define any new registries or values, it does
however update the reference from  previous the previous RFC 4366 to
this one. =20


  (1.j) Has the Document Shepherd verified that sections of the=20
        document that are written in a formal language, such as XML=20
        code, BNF rules, MIB definitions, etc., validate correctly in=20
        an automated checker?=20

Not Applicable.=20

  (1.k) The IESG approval announcement includes a Document=20
        Announcement Write-Up. Please provide such a Document=20
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval=20
        announcement contains the following sections:=20

     Technical Summary=20

This document provides specifications for existing TLS extensions. It is
a companion document for the TLS  1.2 specification [RFC5246]. The
extensions specified are server_name, max_fragment_length,
client_certificate_url, trusted_ca_keys, truncated_hmac, and
status_request.  This document obsoletes RFC  4366.=20


     Working Group Summary=20

This is an update of an existing document to fit the new partitioning of
material between the base spec and  the extensions spec. There were some
technical changes that were discussed extensively in the working  group.
The document represents the current consensus of the working group.

=09

     Document Quality=20

A number of extensions in the document have been implemented by several
parties.  Many of the implementers  participate in the TLS working group
and have contributed to the discussion of the document. =20

From dean@av8.com  Wed Aug  5 07:06:57 2009
Return-Path: <dean@av8.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA2C33A71D0; Wed,  5 Aug 2009 07:06:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level: 
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmpoxyQf0wTI; Wed,  5 Aug 2009 07:06:56 -0700 (PDT)
Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id B5AE83A71ED; Wed,  5 Aug 2009 07:05:16 -0700 (PDT)
Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id n75E561V025437 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 5 Aug 2009 10:05:06 -0400
Date: Wed, 5 Aug 2009 10:05:06 -0400 (EDT)
From: Dean Anderson <dean@av8.com>
X-X-Sender: dean@citation2.av8.net
To: ned+ietf@mauve.mrochek.com
In-Reply-To: <01NBX9A6TRJG00007A@mauve.mrochek.com>
Message-ID: <Pine.LNX.4.44.0908050955040.25022-100000@citation2.av8.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: tls@ietf.org, ietf-honest@lists.iadl.org, Stephen Kent <kent@bbn.com>, ietf@ietf.org
Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Aug 2009 14:06:57 -0000

Ned and Stephen,

If you mean the recent message traffic about the 'intention to remove'
extractor from a list of patented documents, that hasn't happened so far
and an 'intention to remove' doesn't mean it isn't patented. It is
possible that Certicom can later say it was a misunderstanding and that
the official documents were correct. As evidence of their view, they
have the official documents.  As evidence of your view, you have an
unofficial and vague email message apparently contrary to the official
documents, and you will have to argue you based your decision on the
unofficial and vague message rather than the official IPR Disclosures.  
I think one cannot get to a Qualcomm v. Broadcomm finding under such
circumstances.

So, if your objection is removed once the patent threat is removed, then
you should wait until the patent threat is actually removed, which
hasn't happened yet.

As the recent discussions about destroying evidence of participation in
bluesheets shows, some people are willing to engage in deceptive
practices, which may obviously include deceiving people about their
intent to assert patent coverage.

		--Dean

On Thu, 30 Jul 2009 ned+ietf@mauve.mrochek.com wrote:

> > I too support publication of this document as a Standards Track RFC,
> > in light of the salient message traffic of late.
> 
> +1
> 
> 				Ned
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   



From tuexen@fh-muenster.de  Wed Aug  5 05:35:19 2009
Return-Path: <tuexen@fh-muenster.de>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFEFB3A6B84; Wed,  5 Aug 2009 05:35:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.169
X-Spam-Level: 
X-Spam-Status: No, score=0.169 tagged_above=-999 required=5 tests=[AWL=-2.169,  BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311,  J_CHICKENPOX_35=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gOAb9nhQ9-O; Wed,  5 Aug 2009 05:35:13 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 9F7823A6B82; Wed,  5 Aug 2009 05:35:09 -0700 (PDT)
Received: from [192.168.1.100] (p508FD425.dip.t-dialin.net [80.143.212.37]) by mail-n.franken.de (Postfix) with ESMTP id 4919A1C0B4619; Wed,  5 Aug 2009 14:35:09 +0200 (CEST)
From: Michael Tuexen <tuexen@fh-muenster.de>
To: "tom.petch" <cfinss@dial.pipex.com>
In-Reply-To: <000201ca1352$42b53ba0$0601a8c0@allison>
X-Priority: 3
References: <4A6EB9BB.9040002@net.in.tum.de> <000401ca111a$3bb01da0$0601a8c0@allison> <EB76C973-49C7-494C-8281-52559BC61F40@fh-muenster.de> <000201ca1352$42b53ba0$0601a8c0@allison>
Message-Id: <2534D5E9-2595-427A-86FD-562890F0D74B@fh-muenster.de>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Wed, 5 Aug 2009 14:35:07 +0200
X-Mailer: Apple Mail (2.935.3)
X-Mailman-Approved-At: Wed, 05 Aug 2009 08:06:12 -0700
Cc: ipfix@ietf.org, Daniel Mentz <mentz@in.tum.de>, Gerhard Muenz <muenz@net.in.tum.de>, syslog <syslog@ietf.org>, tls@ietf.org
Subject: Re: [TLS] [Syslog] Missing dead peer detection in DTLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Aug 2009 12:35:19 -0000

Hi Tom,

understood. Thanks for the clarification.

Best regards
Michael

On Aug 2, 2009, at 11:11 AM, tom.petch wrote:

> Reply inline, twice
>
> Tom Petch
>
> ----- Original Message -----
> From: "Michael Tuexen" <tuexen@fh-muenster.de>
> To: "tom.petch" <cfinss@dial.pipex.com>
> Sent: Thursday, July 30, 2009 5:24 PM
>
> a question in-line.
>
> Michael
>
> On Jul 30, 2009, at 11:44 AM, tom.petch wrote:
>
>> Gerhard
>>
>> Thank you for pointing this out; it had escaped me.
>>
>> What I had thought though was that the lack of flow control with
>> DTLS over UDP
>> is a problem, and that the lack of this with syslog over UDP led the
>> syslog RFC
>> [RFC5424] to make syslog over TLS the RECOMMENDED transport, not, as
>> might be
>> expected, syslog over UDP.
>
> So I think it is actually congestion control what you are looking
> for, which is provided by TCP when using SYSLOG/TLS/TCP/IP, right?
>
> <tp>
> For myself, no, I was not looking for or caring about congestion  
> control, rather
> security.
>
> But when the syslog I-D got to the IESG, they did care about  
> congestion, and so
> the syslog I-D was modified to make syslog over TLS the RECOMMENDED  
> transport,
> not because it might or might not improve security but because it
> offered congestion control, which UDP by itself does not.
> </tp>
>>
>> This in turn led me to expect that syslog over DTLS over UDP would
>> not be
>> acceptable to the IESG, rather that syslog over DTLS over SCTP would
>> become the
>> RECOMMENDED transport.
>
> This would mean, that
> * SYSLOG/TLS/TCP/IP
> * SYSLOG/DTLS/SCTP/IP
> * SYSLOG/DTLS/DCCP/IP
> are in principle acceptable, whereas
> * SYSLOG/DTLS/UDP/IP
> is not.
> You would (from the congestion control perspective) have the same
> classification when taking out the DTLS or TLS layer, right?
>
> <tp>
> I am unclear about your second sentence, but the first one, yes, I  
> would expect
> the first three to be acceptable to the IESG (which is rather  
> important if you
> want an I-D to become an RFC) and the last one not to be.  TLS (by  
> using TCP),
> SCTP, DCCP have acceptable congestion control, DTLS and UDP do not.
>
> Tom Petch
>
>> So; several thoughts.
>>
>> This is an update to the extensions RFC, RFC4366, which itself is
>> being updated
>> by the TLS working group (hence my addition of them to the list) and
>> I would
>> much rather have one extensions RFC rather than several.  This is a
>> good concept
>> and fills a need; perhaps the TLS working group would take this on.
>>
>> Flow control remains an issue which I do not think that this  
>> extension
>> addresses.
>>
>> Is this a security exposure? or just, like syslog over UDP, an
>> inconvenient
>> truth?
>>
>> The petch-gerhards draft allows the recipient of the unidirectional
>> flow to
>> initiate the DTLS 'connection', and so enables it to re-establish
>> the connection
>> when anything goes wrong.  This would seem an alternative to  
>> consider.
>>
>> Tom Petch
> <snip>
>
>


From kent@bbn.com  Wed Aug  5 17:48:27 2009
Return-Path: <kent@bbn.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 470373A6CBD; Wed,  5 Aug 2009 17:48:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.463
X-Spam-Level: 
X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgaNphTaeMJl; Wed,  5 Aug 2009 17:48:26 -0700 (PDT)
Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 887383A6C37; Wed,  5 Aug 2009 17:48:26 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15] helo=[172.16.1.74]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <kent@bbn.com>) id 1MYqDY-0006os-FF; Wed, 05 Aug 2009 19:48:25 -0400
Mime-Version: 1.0
Message-Id: <p06240809c69fd6dad22e@[172.16.1.74]>
In-Reply-To: <Pine.LNX.4.44.0908050955040.25022-100000@citation2.av8.net>
References: <Pine.LNX.4.44.0908050955040.25022-100000@citation2.av8.net>
Date: Wed, 5 Aug 2009 20:41:45 -0400
To: Dean Anderson <dean@av8.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: ned+ietf@mauve.mrochek.com, ietf-honest@lists.iadl.org, ietf@ietf.org, tls@ietf.org
Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Aug 2009 00:48:27 -0000

At 10:05 AM -0400 8/5/09, Dean Anderson wrote:
>Ned and Stephen,
>
>If you mean the recent message traffic about the 'intention to remove'
>extractor from a list of patented documents, that hasn't happened so far
>and an 'intention to remove' doesn't mean it isn't patented. It is
>possible that Certicom can later say it was a misunderstanding and that
>the official documents were correct. As evidence of their view, they
>have the official documents.  As evidence of your view, you have an
>unofficial and vague email message apparently contrary to the official
>documents, and you will have to argue you based your decision on the
>unofficial and vague message rather than the official IPR Disclosures. 
>I think one cannot get to a Qualcomm v. Broadcomm finding under such
>circumstances.

I reiterate my support for the cited I-D. period.

Steve


From cfinss@dial.pipex.com  Thu Aug  6 03:30:09 2009
Return-Path: <cfinss@dial.pipex.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 332EA3A6B15 for <tls@core3.amsl.com>; Thu,  6 Aug 2009 03:30:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.255
X-Spam-Level: 
X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.344,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TprOz2ZWNslw for <tls@core3.amsl.com>; Thu,  6 Aug 2009 03:30:08 -0700 (PDT)
Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id B83C93A6D90 for <tls@ietf.org>; Thu,  6 Aug 2009 03:29:00 -0700 (PDT)
X-Trace: 239573520/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.244/None/cfinss@dial.pipex.com
X-SBRS: None
X-RemoteIP: 62.188.100.244
X-IP-MAIL-FROM: cfinss@dial.pipex.com
X-SMTP-AUTH: 
X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106
X-IP-BHB: Once
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiMFAEpNeko+vGT0/2dsb2JhbACDMEEfjF3DcAmEDwWBTA
X-IronPort-AV: E=Sophos;i="4.43,332,1246834800"; d="scan'208";a="239573520"
X-IP-Direction: IN
Received: from 1cust244.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.244]) by smtp.pipex.tiscali.co.uk with SMTP; 06 Aug 2009 11:29:01 +0100
Message-ID: <000a01ca1678$3bfe7960$0601a8c0@allison>
From: "tom.petch" <cfinss@dial.pipex.com>
To: "Joseph Salowey \(jsalowey\)" <jsalowey@cisco.com>, <tls@ietf.org>
References: <AC1CFD94F59A264488DC2BEC3E890DE5087BCE4B@xmb-sjc-225.amer.cisco.com>
Date: Thu, 6 Aug 2009 09:30:46 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Subject: [TLS] Matters arising was: Re: Draft minutes for IETF-75 available
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "tom.petch" <cfinss@dial.pipex.com>
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Aug 2009 10:30:09 -0000

I see that the TLS heartbeat extension is mentioned in the minutes.

Discussion of this on the syslog and IPFIX lists said
"However, it's not clear if the TLS WG will support the draft."

I would like to see it supported.

Tom Petch


----- Original Message -----
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: <tls@ietf.org>
Sent: Monday, August 03, 2009 8:28 PM

> Draft minutes for IETF 75 are available:
>
> Transport Layer Security (TLS) Working Group Minutes
> Meeting : IETF75, July 31, 2009
> Location: Stockholm, Sweden, Room 307, 1300-1400
> Chairs  : Joseph Salowey <jsalowey@cisco.com>,
> Eric Rescorla <ekr@networkresonance.com>
> Minutes : Wes Hardaker, Jeff Hodges
> Version 2
>
>
> 3. DTLS Heartbeat - Presented by Michael Tuexen
>
> Draft:
http://www.ietf.org/internet-drafts/draft-seggelmann-tls-dtls-heartbeat-00.txt
>
> Pasi Eronen (AD): I can see this being useful in cases, but I can also see
>       it being solved in the lower layer protocols.  For example, in IPFIX I
>       can very much see them solving it at their layer.
> Michael Tuexen: I see your point but...
> Pasi: I can also see this useful for PMTU discovery.
> Michael: That's true but it doesn't necessarily work for bi-directional
> differences.  You can send another message which contains extra
> stuff for doing discovery.  SCTP has opaque data for doing
> things like that.  I like the discovery message, but I think
> it should be another message.
> Eric (Jabber): this is relevant in TCP cases as well.
>
> Question: if you use this in UDP, the draft says you must not send them
>       while you're waiting for a response.
> Michael: Only one heart-beat request in flight at a time.  I don't want
> to have a congestion control problem
>
> Wes Hardaker: agree with EKR that it is useful it TCP as well,
>       though you need to document differences.  Longer discussion on
>       the rational behind it.


From Pasi.Eronen@nokia.com  Fri Aug  7 02:09:37 2009
Return-Path: <Pasi.Eronen@nokia.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23AA03A6EB8 for <tls@core3.amsl.com>; Fri,  7 Aug 2009 02:09:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.906
X-Spam-Level: 
X-Spam-Status: No, score=-5.906 tagged_above=-999 required=5 tests=[AWL=0.693,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+aCxyzA55Km for <tls@core3.amsl.com>; Fri,  7 Aug 2009 02:09:36 -0700 (PDT)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 085D93A696C for <tls@ietf.org>; Fri,  7 Aug 2009 02:08:37 -0700 (PDT)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n7798FDY009985; Fri, 7 Aug 2009 12:08:27 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 7 Aug 2009 12:08:33 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 7 Aug 2009 12:08:33 +0300
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Fri, 7 Aug 2009 11:08:32 +0200
From: <Pasi.Eronen@nokia.com>
To: <martin.rex@sap.com>, <tls@ietf.org>
Date: Fri, 7 Aug 2009 11:08:32 +0200
Thread-Topic: [TLS] Last Call: draft-ietf-tls-extractor (Keying
Thread-Index: AcoL3XSrNxb1zttnSu2mLBa+lRFBLALYBq2A
Message-ID: <808FD6E27AD4884E94820BC333B2DB773A72364235@NOK-EUMSG-01.mgdnok.nokia.com>
References: <Pine.LNX.4.44.0907231459420.13344-100000@citation2.av8.net> from	"Dean Anderson" at Jul 23, 9 03:11:52 pm <200907232134.n6NLYGOq008369@fs4113.wdf.sap.corp>
In-Reply-To: <200907232134.n6NLYGOq008369@fs4113.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 07 Aug 2009 09:08:33.0436 (UTC) FILETIME=[A3A485C0:01CA173E]
X-Nokia-AV: Clean
Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Aug 2009 09:09:37 -0000

Martin Rex wrote:

> The problem here is that submitting an URL for the real IPR
> disclosure in the IETF disclosure form is subverting to idea that
> the IETF can archive the IPR disclosures in their original form.

No matter what the contents of the IPR disclosure are, I agree that
having them archived by the IETF is a good idea (after all, the link=20
might get broken when Certicom redesigns their web site, or something).

The secretariat has now placed the PDF file in the same directory=20
on www.ietf.org as other IPR disclosure files:

http://www.ietf.org/ietf-ftp/IPR/certicom%2520-ipr-contribution-to-ietfsept=
08.pdf

Best regards,
Pasi

From Pasi.Eronen@nokia.com  Fri Aug  7 02:19:49 2009
Return-Path: <Pasi.Eronen@nokia.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A568828C156 for <tls@core3.amsl.com>; Fri,  7 Aug 2009 02:19:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.944
X-Spam-Level: 
X-Spam-Status: No, score=-5.944 tagged_above=-999 required=5 tests=[AWL=0.655,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCmnmRPqr-6k for <tls@core3.amsl.com>; Fri,  7 Aug 2009 02:19:49 -0700 (PDT)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id C92BE3A6ECB for <tls@ietf.org>; Fri,  7 Aug 2009 02:18:52 -0700 (PDT)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n779IGOQ017459; Fri, 7 Aug 2009 04:18:36 -0500
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 7 Aug 2009 12:18:15 +0300
Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 7 Aug 2009 12:18:15 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 7 Aug 2009 12:18:08 +0300
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Fri, 7 Aug 2009 11:18:07 +0200
From: <Pasi.Eronen@nokia.com>
To: <muenz@net.in.tum.de>
Date: Fri, 7 Aug 2009 11:18:06 +0200
Thread-Topic: DTLS heartbeat (was: Draft minutes for IETF-75 available)
Thread-Index: AcoUfdmlxn93qlnGTrG0Cetb4ert5gCwWCYw
Message-ID: <808FD6E27AD4884E94820BC333B2DB773A72364250@NOK-EUMSG-01.mgdnok.nokia.com>
References: <mailman.77.1249326021.24683.tls@ietf.org> <4A77429B.9080506@net.in.tum.de> <AC1CFD94F59A264488DC2BEC3E890DE5087BCF21@xmb-sjc-225.amer.cisco.com> <4A775099.5040003@net.in.tum.de>
In-Reply-To: <4A775099.5040003@net.in.tum.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 07 Aug 2009 09:18:08.0723 (UTC) FILETIME=[FA8A5A30:01CA173F]
X-Nokia-AV: Clean
Cc: tls@ietf.org
Subject: [TLS] DTLS heartbeat (was: Draft minutes for IETF-75 available)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Aug 2009 09:19:49 -0000

Gerhard Muenz wrote:

> The big difference between IPFIX-over-UDP and IPFIX-over-DTLS/UDP is
> that you can always start or restart a UDP Collector without touching
> the Exporter. If the Collector is listening on the correct UDP port, it
> will receive the Templates after a while (Templates are retransmitted
> periodically when UDP is used), and then, it will be able to start or
> resume decoding IPFIX Messages.
>=20
> With DTLS/UDP, the Exporter must initiate the DTLS renegotiation
> after the Collector has restarted. This is because the Collector
> does not know which Exporters actually exist (like a server which
> does not know its clients in advance). So, the Exporter should
> somehow know when a renegotiation is necessary. It seems that DTLS
> Heartbeat would nicely solve this.

<not wearing any hats>

Thanks for the explanation! I now agree that IPFIX-over-UDP and
IPFIX-over-DTLS/UDP indeed have a crucial difference here, and=20
the heartbeat extension would nicely solve this problem.=20

It's also very simple extension, and might be useful for other
situations, too (it could be useful for TLS-over-TCP -- and
it would allow the DTLS library to implement Path MTU Discovery,
instead of leaving that to applications), so I support doing
this work.

Best regards,
Pasi

From dean@av8.com  Fri Aug  7 08:20:07 2009
Return-Path: <dean@av8.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18D3F28C0D9 for <tls@core3.amsl.com>; Fri,  7 Aug 2009 08:20:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level: 
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCyJCdegLMR2 for <tls@core3.amsl.com>; Fri,  7 Aug 2009 08:20:06 -0700 (PDT)
Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id EC0AB28C193 for <tls@ietf.org>; Fri,  7 Aug 2009 08:19:03 -0700 (PDT)
Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id n77FJ4Ui001909 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 7 Aug 2009 11:19:05 -0400
Date: Fri, 7 Aug 2009 11:19:04 -0400 (EDT)
From: Dean Anderson <dean@av8.com>
X-X-Sender: dean@citation2.av8.net
To: Pasi.Eronen@nokia.com
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773A72364235@NOK-EUMSG-01.mgdnok.nokia.com>
Message-ID: <Pine.LNX.4.44.0908071049590.2679-100000@citation2.av8.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: tls@ietf.org
Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Aug 2009 15:20:07 -0000

The IETF has previously demonstrated itself to be unreliable and 
untrustworthy with respect to preserving IPR disclosures.  We still do 
not have the original IPR 765 disclosure.

>From http://www.av8.net/IETF-watch/ 

=========================
February 2009 More TLS-AUTHZ Misconduct: IESG removes Redphone IPR 
Disclosure  Despite giving assurances that IPR documents would never be 
removed, and despite a corporate policy of not deleting history, and 
despite a duty not to destroy evidence, the IESG reneged on all of that 
to remove IPR 765, the first disclosure by Redphone that set off the 
TLS-AUTHZ controversy. This disclosure has been cited by critics of 
Redphone, Russ Housley, Tim Polk and the IESG as evidence of bad faith.
=========================

And some people want to destroy the participation records (bluesheets)
in order to deceive other people about their participation and thereby
deceive and defraud other IETF participants and their counsel in future
litigation about their participation and duty to disclose patents (e.g.
Qualcomm v. Broadcom).  See this discussion:

http://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=47819&tid=1249657487
http://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=47828&tid=1249657487

These people (some are Qualcomm employees)  are well aware of a duty to
disclose patents to standards bodies, and have been penalized in the
past for failure perform their duties.  Now they want to destroy records
of their participation "to avoid legal liability". The liability is due
to failure to perform their duty to disclose, not from records of their
participation.

I've asserted (with evidence) in the past that the IETF is run by a
mafia which has no regard for the law. Some people disagree with my
assessment, but quite plainly, another organization must preserve these
records since the IETF most evidently cannot be trusted to do so.


		--Dean




On Fri, 7 Aug 2009 Pasi.Eronen@nokia.com wrote:

> Martin Rex wrote:
> 
> > The problem here is that submitting an URL for the real IPR
> > disclosure in the IETF disclosure form is subverting to idea that
> > the IETF can archive the IPR disclosures in their original form.
> 
> No matter what the contents of the IPR disclosure are, I agree that
> having them archived by the IETF is a good idea (after all, the link 
> might get broken when Certicom redesigns their web site, or something).
> 
> The secretariat has now placed the PDF file in the same directory 
> on www.ietf.org as other IPR disclosure files:
> 
> http://www.ietf.org/ietf-ftp/IPR/certicom%2520-ipr-contribution-to-ietfsept08.pdf
> 
> Best regards,
> Pasi
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   




From stefan@aaa-sec.com  Mon Aug 10 02:44:23 2009
Return-Path: <stefan@aaa-sec.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05BCF3A6D50 for <tls@core3.amsl.com>; Mon, 10 Aug 2009 02:44:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.595
X-Spam-Level: 
X-Spam-Status: No, score=-1.595 tagged_above=-999 required=5 tests=[AWL=0.257,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHHwGQ0wte5u for <tls@core3.amsl.com>; Mon, 10 Aug 2009 02:44:18 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by core3.amsl.com (Postfix) with ESMTP id 2804E3A6D8B for <TLS@ietf.org>; Mon, 10 Aug 2009 02:44:17 -0700 (PDT)
Received: (qmail 9357 invoked from network); 10 Aug 2009 09:21:31 -0000
Received: from s34.loopia.se (HELO s60.loopia.se) ([194.9.94.70]) (envelope-sender <stefan@aaa-sec.com>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <TLS@ietf.org>; 10 Aug 2009 09:21:31 -0000
Received: (qmail 82271 invoked from network); 10 Aug 2009 09:21:25 -0000
Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.5]) (stefan@fiddler.nu@[213.64.142.97]) (envelope-sender <stefan@aaa-sec.com>) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <stefan@aaa-sec.com>; 10 Aug 2009 09:21:25 -0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Mon, 10 Aug 2009 11:21:19 +0200
From: Stefan Santesson <stefan@aaa-sec.com>
To: Stefan Santesson <stefan@aaa-sec.com>, TLS wg <TLS@ietf.org>
Message-ID: <C6A5B32F.3C9E%stefan@aaa-sec.com>
Thread-Topic: [TLS] Comments on cached info at TLS meeting
Thread-Index: AcoR1ISq1JdPWHfMEE23Lw3azRBGIQHx2aFc
In-Reply-To: <C698A62B.3AC7%stefan@aaa-sec.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3332748085_2731255"
Subject: Re: [TLS] Comments on cached info at TLS meeting
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Aug 2009 09:44:23 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3332748085_2731255
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

I guess the main thing to discuss after the IETF meeting is whether the
server need to signal in its server hello exactly what data it will replace
in the server hello OR if the server can return an empty cached info
extension and decide later what to replace.

Both models should work IMO but they have different pros and cons.

Does anyone have any strong arguments?

/Stefan

On 09-07-31 1:46 PM, "Stefan Santesson" <stefan@aaa-sec.com> wrote:

> Recap of comments on cached info during the IETF meeting in Stockholm.
>=20
> Simon thought that it would be OK to send just the hash as replacement fo=
r the
> cached data if the client treats the hash as an index that identifies the
> replaced data. Doing so avoids guessing by the client. A clarification sh=
ould
> be made in the draft.
>=20
> Eric made a comment on Jabber that =B3now that I see this problem suggested=
,
> this seems pretty gross from an implementation perspective. I think I'd p=
refer
> that the cache hits be returned explicitly in the extension=B2
>=20
> I interpret this to mean that Eric wants the server to acknowledge exactl=
y
> what data it will replace when it sends its server hello.
> This means that we have different opinions on the list whether the server=
 have
> to know what data it will replace at server hello exchange.
> I=B9m personally pretty agnostic about this, but we need to agree on one
> approach.
>=20
> Other than that it was suggested that other objects could be of interest =
to
> define in the draft. We may see proposals on the list.
>=20
> /Stefan
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


--B_3332748085_2731255
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [TLS] Comments on cached info at TLS meeting</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>I guess the main thing to discuss after the IETF meeting is whether the se=
rver need to signal in its server hello exactly what data it will replace in=
 the server hello OR if the server can return an empty cached info extension=
 and decide later what to replace.<BR>
<BR>
Both models should work IMO but they have different pros and cons.<BR>
<BR>
Does anyone have any strong arguments?<BR>
<BR>
/Stefan<BR>
<BR>
On 09-07-31 1:46 PM, &quot;Stefan Santesson&quot; &lt;<a href=3D"stefan@aaa-s=
ec.com">stefan@aaa-sec.com</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>Recap of comments on cached info during the IETF=
 meeting in Stockholm.<BR>
<BR>
Simon thought that it would be OK to send just the hash as replacement for =
the cached data if the client treats the hash as an index that identifies th=
e replaced data. Doing so avoids guessing by the client. A clarification sho=
uld be made in the draft.<BR>
<BR>
Eric made a comment on Jabber that &#8220;now that I see this problem sugge=
sted, this seems pretty gross from an implementation perspective. I think I'=
d prefer that the cache hits be returned explicitly in the extension&#8221;<=
BR>
<BR>
I interpret this to mean that Eric wants the server to acknowledge exactly =
what data it will replace when it sends its server hello.<BR>
This means that we have different opinions on the list whether the server h=
ave to know what data it will replace at server hello exchange.<BR>
I&#8217;m personally pretty agnostic about this, but we need to agree on on=
e approach.<BR>
<BR>
Other than that it was suggested that other objects could be of interest to=
 &nbsp;define in the draft. We may see proposals on the list.<BR>
<BR>
/Stefan<BR>
<HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"></SPAN></FONT><FONT SIZE=3D"2"><FONT FA=
CE=3D"Consolas, Courier New, Courier"><SPAN STYLE=3D'font-size:10pt'>___________=
____________________________________<BR>
TLS mailing list<BR>
<a href=3D"TLS@ietf.org">TLS@ietf.org</a><BR>
<a href=3D"https://www.ietf.org/mailman/listinfo/tls">https://www.ietf.org/ma=
ilman/listinfo/tls</a><BR>
</SPAN></FONT></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--B_3332748085_2731255--



From Martin.Rex@sap.com  Tue Aug 11 05:39:42 2009
Return-Path: <Martin.Rex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E7AB3A6EF3 for <tls@core3.amsl.com>; Tue, 11 Aug 2009 05:39:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.925
X-Spam-Level: 
X-Spam-Status: No, score=-4.925 tagged_above=-999 required=5 tests=[AWL=0.332,  BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1HfJj8Ylbno for <tls@core3.amsl.com>; Tue, 11 Aug 2009 05:39:41 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 61AB93A70FF for <tls@ietf.org>; Tue, 11 Aug 2009 05:39:20 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n7BCbqCm001781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <tls@ietf.org>; Tue, 11 Aug 2009 14:37:52 +0200 (MEST)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200908111237.n7BCbpC5012878@fs4113.wdf.sap.corp>
Orig-To: stefan@aaa-sec.com (Stefan Santesson)
To: tls@ietf.org
Date: Tue, 11 Aug 2009 00:16:00 +0200 (MEST)
In-Reply-To: <C6A5B32F.3C9E%stefan@aaa-sec.com> from "Stefan Santesson" at Aug 10, 9 11:21:19 am
Cc: tls@ietf.org
Sender: Martin.Rex@sap.com
X-Scanner: Virus Scanner virwal07
X-SAP: out
Subject: Re: [TLS] Comments on cached info at TLS meeting
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: martin.rex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Aug 2009 12:39:42 -0000

Stefan Santesson wrote:
> 
> I guess the main thing to discuss after the IETF meeting is whether the
> server need to signal in its server hello exactly what data it will replace
> in the server hello OR if the server can return an empty cached info
> extension and decide later what to replace.

What I would really like to see is a possibility to
negotiate the use of this extension on the first contact to a
new server, so that the client can learn right away whether
the server supports the extension, and which hash algorithm server
and client share.

With this knowledge, the client does not need to populate his
cache with data that will never get used at all (because the
server does not support caching for this information or does
not support caching at all).

And the client will not have to ever propose more than one hash
value for a piece of information, because the client then will
already know the common hash algorithm (if any) when it adds
the information to its cache.


-Martin 


From simon@josefsson.org  Tue Aug 11 10:48:14 2009
Return-Path: <simon@josefsson.org>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA3B83A6C23 for <tls@core3.amsl.com>; Tue, 11 Aug 2009 10:48:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.585
X-Spam-Level: 
X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMT0ObdSXDlm for <tls@core3.amsl.com>; Tue, 11 Aug 2009 10:48:14 -0700 (PDT)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id BE3983A6A2F for <tls@ietf.org>; Tue, 11 Aug 2009 10:48:13 -0700 (PDT)
Received: from mocca.josefsson.org (c80-216-31-183.bredband.comhem.se [80.216.31.183]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n7BHjKqJ007066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 11 Aug 2009 19:45:22 +0200
From: Simon Josefsson <simon@josefsson.org>
To: martin.rex@sap.com
References: <C6A5B32F.3C9E%stefan@aaa-sec.com> <200908111237.n7BCbpC5012878@fs4113.wdf.sap.corp>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090811:tls@ietf.org::8OXIu2/abQEv2vAi:3f5n
X-Hashcash: 1:22:090811:martin.rex@sap.com::jPbBxbNZK3V2yh/y:5gju
Date: Tue, 11 Aug 2009 19:45:20 +0200
In-Reply-To: <200908111237.n7BCbpC5012878@fs4113.wdf.sap.corp> (Martin Rex's message of "Tue, 11 Aug 2009 00:16:00 +0200 (MEST)")
Message-ID: <87d472kzwv.fsf@mocca.josefsson.org>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Cc: tls@ietf.org
Subject: Re: [TLS] Comments on cached info at TLS meeting
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Aug 2009 17:48:14 -0000

Martin Rex <Martin.Rex@sap.com> writes:

> Stefan Santesson wrote:
>> 
>> I guess the main thing to discuss after the IETF meeting is whether the
>> server need to signal in its server hello exactly what data it will replace
>> in the server hello OR if the server can return an empty cached info
>> extension and decide later what to replace.
>
> What I would really like to see is a possibility to
> negotiate the use of this extension on the first contact to a
> new server, so that the client can learn right away whether
> the server supports the extension, and which hash algorithm server
> and client share.
>
> With this knowledge, the client does not need to populate his
> cache with data that will never get used at all (because the
> server does not support caching for this information or does
> not support caching at all).

This sounds like a good idea to me.

> And the client will not have to ever propose more than one hash
> value for a piece of information, because the client then will
> already know the common hash algorithm (if any) when it adds
> the information to its cache.

There is a concern if the server migrates to another system or software,
and the cached information becomes stale.  There needs to be some
discussion in the document around that, and it isn't exactly clear to me
how it could be worded.  For example, how does the client detect this?

/Simon

From stefan@aaa-sec.com  Wed Aug 12 05:37:10 2009
Return-Path: <stefan@aaa-sec.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 824233A6B37 for <tls@core3.amsl.com>; Wed, 12 Aug 2009 05:37:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.314
X-Spam-Level: 
X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=0.935,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCjGjpBwoslR for <tls@core3.amsl.com>; Wed, 12 Aug 2009 05:37:09 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by core3.amsl.com (Postfix) with ESMTP id 2434C3A696B for <tls@ietf.org>; Wed, 12 Aug 2009 05:37:08 -0700 (PDT)
Received: (qmail 71893 invoked from network); 12 Aug 2009 12:34:58 -0000
Received: from s34.loopia.se (HELO s57.loopia.se) ([194.9.94.70]) (envelope-sender <stefan@aaa-sec.com>) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for <tls@ietf.org>; 12 Aug 2009 12:34:58 -0000
Received: (qmail 62878 invoked from network); 12 Aug 2009 12:34:53 -0000
Received: from 213-64-142-97-no153.business.telia.com (HELO [192.168.1.3]) (stefan@fiddler.nu@[213.64.142.97]) (envelope-sender <stefan@aaa-sec.com>) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <simon@josefsson.org>; 12 Aug 2009 12:34:53 -0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Wed, 12 Aug 2009 14:34:50 +0200
From: Stefan Santesson <stefan@aaa-sec.com>
To: Simon Josefsson <simon@josefsson.org>, <martin.rex@sap.com>
Message-ID: <C6A8838A.3D50%stefan@aaa-sec.com>
Thread-Topic: [TLS] Comments on cached info at TLS meeting
Thread-Index: AcobSUi34XeDlhwhR0+dS6w2Ly64+w==
In-Reply-To: <87d472kzwv.fsf@mocca.josefsson.org>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] Comments on cached info at TLS meeting
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Aug 2009 12:37:10 -0000

On 09-08-11 7:45 PM, "Simon Josefsson" <simon@josefsson.org> wrote:

> Martin Rex <Martin.Rex@sap.com> writes:
> 
>> Stefan Santesson wrote:
>>> 
>>> I guess the main thing to discuss after the IETF meeting is whether the
>>> server need to signal in its server hello exactly what data it will replace
>>> in the server hello OR if the server can return an empty cached info
>>> extension and decide later what to replace.
>> 
>> What I would really like to see is a possibility to
>> negotiate the use of this extension on the first contact to a
>> new server, so that the client can learn right away whether
>> the server supports the extension, and which hash algorithm server
>> and client share.
>> 
>> With this knowledge, the client does not need to populate his
>> cache with data that will never get used at all (because the
>> server does not support caching for this information or does
>> not support caching at all).
> 
> This sounds like a good idea to me.

I wander if this is a worthwhile optimization. We are not talking about a
huge amount of data here.

But I don't mind either way. I just wanted Eric to say why he want the
cached data to be selected, accepted and negotiated at client/server hello
time.

> 
>> And the client will not have to ever propose more than one hash
>> value for a piece of information, because the client then will
>> already know the common hash algorithm (if any) when it adds
>> the information to its cache.
> 
> There is a concern if the server migrates to another system or software,
> and the cached information becomes stale.  There needs to be some
> discussion in the document around that, and it isn't exactly clear to me
> how it could be worded.  For example, how does the client detect this?
> 
> /Simon

I think the simple answer is that the client will know that the caching
proposal failed if the server rejects the offer to replace cached data with
a hash provided by the client.

The client response to such situation may vary. I can see several options,
all valid.

1) The client updates its cache with the data sent by the server and upon
next connection will send multiple hashes to the server (assuming that the
server may have been updated).

2) Upon multiple failures by the server to accept information caching, the
client may set the caching on hold for that server and may apply different
logic for when and how to retry caching to that server.

3) The client may decide to always send caching info to all servers at all
times except for those where the result is repeated unexpected failures.

I have no objection to clarify this in the draft.

/Stefan



From Martin.Rex@sap.com  Wed Aug 12 08:28:41 2009
Return-Path: <Martin.Rex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3003C3A6AD0 for <tls@core3.amsl.com>; Wed, 12 Aug 2009 08:28:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.476
X-Spam-Level: 
X-Spam-Status: No, score=-5.476 tagged_above=-999 required=5 tests=[AWL=0.773,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vn4uFppRGgSa for <tls@core3.amsl.com>; Wed, 12 Aug 2009 08:28:40 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id F1F563A69EE for <tls@ietf.org>; Wed, 12 Aug 2009 08:28:39 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n7BIWlAT002650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Aug 2009 20:32:47 +0200 (MEST)
Received: from fs4113.wdf.sap.corp (fs4113.wdf.sap.corp [10.21.76.84]) by mail.sap.corp (mail03-25) with ESMTP id n7BIWk5s014807 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 11 Aug 2009 20:32:47 +0200 (MEST)
Received: (from d019080@localhost) by fs4113.wdf.sap.corp (8.13.4+Sun/8.13.4/Submit) id n7BIWkdH007068; Tue, 11 Aug 2009 20:32:46 +0200 (MEST)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200908111832.n7BIWkdH007068@fs4113.wdf.sap.corp>
To: simon@josefsson.org (Simon Josefsson)
Date: Tue, 11 Aug 2009 20:32:46 +0200 (MEST)
In-Reply-To: <87d472kzwv.fsf@mocca.josefsson.org> from "Simon Josefsson" at Aug 11, 9 07:45:20 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Comments on cached info at TLS meeting
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: martin.rex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Aug 2009 15:28:41 -0000

Simon Josefsson wrote:
> 
> There is a concern if the server migrates to another system or software,
> and the cached information becomes stale.  There needs to be some
> discussion in the document around that, and it isn't exactly clear to me
> how it could be worded.  For example, how does the client detect this?


If the hash value sent by the client does no longer match the
hash value over the new/changed data on the server, the server
is going to send the new/full handshake data.  So the handshake
should always automatically fallback to the full handshake, unless
there is a hash value collision.

What is it exactly that you're asking for?

Guidance about when the client should update his cache entries?

The client should probably drop/replace cache entries whenever
the server sends new/full data instead of using cached values.

The more interesting question might be to "key" the cache entries.

The key into the cache should probably distinguish the server
name from the URL / connection-info in order to support the
TLS extension "Server Name Indication",

The server certificate will probably depend on the public key type
used for the key exchange algorithm (RSA,DH,DSA,ECDSA,...) of the
negotiated TLS ciphersuite.

The list of trusted CAs, on the other hand, may vary with the
server name, but should be fairly independent from the public
key type used by the key exchange algorithm of the negotiated
TLS ciphersuite.


-Martin

From dean@av8.com  Tue Aug 18 12:44:31 2009
Return-Path: <dean@av8.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF0A43A6872 for <tls@core3.amsl.com>; Tue, 18 Aug 2009 12:44:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.404
X-Spam-Level: 
X-Spam-Status: No, score=-1.404 tagged_above=-999 required=5 tests=[AWL=-1.219, BAYES_40=-0.185]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlyWzA64Ngjh for <tls@core3.amsl.com>; Tue, 18 Aug 2009 12:44:30 -0700 (PDT)
Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 109A128C215 for <tls@ietf.org>; Tue, 18 Aug 2009 12:44:20 -0700 (PDT)
Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id n7IJiOxP012201 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 18 Aug 2009 15:44:24 -0400
Date: Tue, 18 Aug 2009 15:44:24 -0400 (EDT)
From: Dean Anderson <dean@av8.com>
X-X-Sender: dean@citation2.av8.net
To: Pasi.Eronen@nokia.com
In-Reply-To: <Pine.LNX.4.44.0908071049590.2679-100000@citation2.av8.net>
Message-ID: <Pine.LNX.4.44.0908181519470.1161-100000@citation2.av8.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: ietf-honest@lists.iadl.org, tls@ietf.org, ipr-wg-honest@lists.iadl.org
Subject: [TLS] Archiving IETF IPR documents was Re: Last Call: draft-ietf-tls-extractor (Keying
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Aug 2009 19:44:31 -0000

This is probably an unsatisfactory way to leave things.

We have no solution, but I think there is agreement that IETF IPR
documents need to be archived and preserved despite the demonstrated
unreliability of vendors and the ISOC to preserve these documents.

I think a solution is a systematic effort to mirror and preserve every
document on the IETF TOOLS website needs to be undertaken in such a way
that the administrators of the IETF TOOLS website can't destroy
documents, even with IESG approval.  I think an separate incorporated,
responsible organization should take the responsibility for maintaining
these documents.  I /could/ propose to the LPF to take this on, but
would need volunteers to do the work--the LPF at present cannot fund the
work--it might (after approval) be able to preserve the records.  But a
new organization may needed for this specific purpose.

But before we get too deep into the solution, I think that this subject
and its solution is very quickly going to be beyond the scope of the TLS
Working Group, but is apparently of interest to many TLS WG members.  
Of course, despite an interest by TLS WG members, the TLS Working Group
also can't really recharter itself to compensate for the unreliability
of another part of the IETF--sort of absurd. So it seems this discussion
should be moved somewhere else; perhaps ietf-honest@lists.iadl.org or
ipr-wg-honest@lists.iadl.org.  So, I ask the TLS Chairs and other TLS WG
members for suggestions on how to proceed.

		--Dean



On Fri, 7 Aug 2009, Dean Anderson wrote:

> The IETF has previously demonstrated itself to be unreliable and 
> untrustworthy with respect to preserving IPR disclosures.  We still do 
> not have the original IPR 765 disclosure.
> 
> From http://www.av8.net/IETF-watch/ 
> 
> =========================
> February 2009 More TLS-AUTHZ Misconduct: IESG removes Redphone IPR 
> Disclosure  Despite giving assurances that IPR documents would never be 
> removed, and despite a corporate policy of not deleting history, and 
> despite a duty not to destroy evidence, the IESG reneged on all of that 
> to remove IPR 765, the first disclosure by Redphone that set off the 
> TLS-AUTHZ controversy. This disclosure has been cited by critics of 
> Redphone, Russ Housley, Tim Polk and the IESG as evidence of bad faith.
> =========================
> 
> And some people want to destroy the participation records (bluesheets)
> in order to deceive other people about their participation and thereby
> deceive and defraud other IETF participants and their counsel in future
> litigation about their participation and duty to disclose patents (e.g.
> Qualcomm v. Broadcom).  See this discussion:
> 
> http://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=47819&tid=1249657487
> http://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=47828&tid=1249657487
> 
> These people (some are Qualcomm employees)  are well aware of a duty to
> disclose patents to standards bodies, and have been penalized in the
> past for failure perform their duties.  Now they want to destroy records
> of their participation "to avoid legal liability". The liability is due
> to failure to perform their duty to disclose, not from records of their
> participation.
> 
> I've asserted (with evidence) in the past that the IETF is run by a
> mafia which has no regard for the law. Some people disagree with my
> assessment, but quite plainly, another organization must preserve these
> records since the IETF most evidently cannot be trusted to do so.
> 
> 
> 		--Dean
> 
> 
> 
> 
> On Fri, 7 Aug 2009 Pasi.Eronen@nokia.com wrote:
> 
> > Martin Rex wrote:
> > 
> > > The problem here is that submitting an URL for the real IPR
> > > disclosure in the IETF disclosure form is subverting to idea that
> > > the IETF can archive the IPR disclosures in their original form.
> > 
> > No matter what the contents of the IPR disclosure are, I agree that
> > having them archived by the IETF is a good idea (after all, the link 
> > might get broken when Certicom redesigns their web site, or something).
> > 
> > The secretariat has now placed the PDF file in the same directory 
> > on www.ietf.org as other IPR disclosure files:
> > 
> > http://www.ietf.org/ietf-ftp/IPR/certicom%2520-ipr-contribution-to-ietfsept08.pdf
> > 
> > Best regards,
> > Pasi
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> > 
> > 
> 
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 256 5494



From simon@josefsson.org  Tue Aug 18 15:45:39 2009
Return-Path: <simon@josefsson.org>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C1873A69AE for <tls@core3.amsl.com>; Tue, 18 Aug 2009 15:45:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level: 
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDmD11ijrlnS for <tls@core3.amsl.com>; Tue, 18 Aug 2009 15:45:38 -0700 (PDT)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id EC5B43A67B7 for <tls@ietf.org>; Tue, 18 Aug 2009 15:45:37 -0700 (PDT)
Received: from mocca.josefsson.org (c80-216-31-183.bredband.comhem.se [80.216.31.183]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n7IMjHA8001016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Aug 2009 00:45:19 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Nicolas Williams <Nicolas.Williams@sun.com>
References: <20090818213427.GU1043@Sun.COM>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090818:ietf-sasl@imc.org::phGjYQ2dCe/ST4ZG:27Ek
X-Hashcash: 1:22:090818:nicolas.williams@sun.com::Sp9lVljf2yG9TozZ:1dgY
X-Hashcash: 1:22:090818:tls@ietf.org::HHy/gYRdIGhZPWU0:AZ1D
Date: Wed, 19 Aug 2009 00:45:17 +0200
In-Reply-To: <20090818213427.GU1043@Sun.COM> (Nicolas Williams's message of "Tue, 18 Aug 2009 16:34:28 -0500")
Message-ID: <87ljlgbv2a.fsf@mocca.josefsson.org>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Cc: ietf-sasl@imc.org, tls@ietf.org
Subject: Re: [TLS] "Last call" on draft-altman-tls-channel-bindings-05.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Aug 2009 22:45:39 -0000

Quoting:

   Description: The hash of the TLS server's end entity certificate
   [RFC5280] as it appears, octet for octet, in the server's Certificate
   message (note that the Certificate message contains a
   certificate_list, the first element of which is the server's end
   entity certificate.)

I suggest replacing "server's end entity certificate" with "server's
certificate".  As far as I understand, it is possibly to use non-EE
certs, e.g. proxy certs, as a server certificate.  The RFC 5246
terminology is to say "sender's certificate" and there is no requirement
to use a EE cert.

Quoting:

   agility.  The algorithm to be used, however, is derived from the
   certificate itself: use SHA-256 if the certificate uses MD5 or SHA-1,
   else use whatever hash function the certificate uses.  This

Please say "is signed with" instead of "uses".  Hash values may be
present for other purposes in a certificate, but signature fields will
typically only use one hash function.

For completeness, I would add:

   This algorithm agility resolution mechanism assumes that there is a
   mapping from every Public-key signature algorithm to one hash
   function algorithm.  This is the case for all practically used public
   key signature algorithms today, but if future public-key signature
   algorithms would employ multiple hash functions (or none at all) this
   specification needs to be updated to resolve which hash function
   should be used.

Nits:

   note (that is, the first such note in the descritption is a new
                                                   ^
/Simon

From Nicolas.Williams@Sun.COM  Tue Aug 18 16:09:57 2009
Return-Path: <Nicolas.Williams@Sun.COM>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 158EA28C22F for <tls@core3.amsl.com>; Tue, 18 Aug 2009 16:09:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.914
X-Spam-Level: 
X-Spam-Status: No, score=-5.914 tagged_above=-999 required=5 tests=[AWL=0.132,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMoo16tB4wYN for <tls@core3.amsl.com>; Tue, 18 Aug 2009 16:09:56 -0700 (PDT)
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 3893A3A6BF3 for <tls@ietf.org>; Tue, 18 Aug 2009 16:09:15 -0700 (PDT)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7ILjDjj018275 for <tls@ietf.org>; Tue, 18 Aug 2009 21:45:14 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n7ILjDn4018674 for <tls@ietf.org>; Tue, 18 Aug 2009 15:45:13 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7ILYUbQ003684; Tue, 18 Aug 2009 16:34:30 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7ILYSfi003683;  Tue, 18 Aug 2009 16:34:28 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Tue, 18 Aug 2009 16:34:28 -0500
From: Nicolas Williams <Nicolas.Williams@Sun.COM>
To: ietf-sasl@imc.org, tls@ietf.org
Message-ID: <20090818213427.GU1043@Sun.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.7i
Subject: [TLS] "Last call" on draft-altman-tls-channel-bindings-05.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Aug 2009 23:09:57 -0000

Per RFC5056, three channel binding types for TLS have been registered in
the IANA channel binding type registry.  Recently we've decided that we
actually need a Standards-Track RFC to define these channel binding
types so as to make it easier to make normative reference to them.

Therefore we've revived and updated draft-altman-tls-channel-bindings to
include the text of those three channel binding type registrations, as
well as to update introductory and security considerations text.

We seek comments on draft-altman-tls-channel-bindings-05.  In two weeks
we'll request that an AD shepherd this individual submission.  We seek
Proposed Standard status for the resulting RFC.

Consider this a pseudo-WGLC.  Please review and comment.

Thanks,

Nico
-- 

From Nicolas.Williams@sun.com  Tue Aug 18 16:10:19 2009
Return-Path: <Nicolas.Williams@sun.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82FCA3A6BBC for <tls@core3.amsl.com>; Tue, 18 Aug 2009 16:10:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.916
X-Spam-Level: 
X-Spam-Status: No, score=-5.916 tagged_above=-999 required=5 tests=[AWL=0.130,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QAM-RcLhUf5 for <tls@core3.amsl.com>; Tue, 18 Aug 2009 16:10:18 -0700 (PDT)
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id 51DA23A6B14 for <tls@ietf.org>; Tue, 18 Aug 2009 16:10:18 -0700 (PDT)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7INALgM001923 for <tls@ietf.org>; Tue, 18 Aug 2009 23:10:21 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n7INALvm034673 for <tls@ietf.org>; Tue, 18 Aug 2009 17:10:21 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7IMxbUN003790; Tue, 18 Aug 2009 17:59:37 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7IMxYwu003789;  Tue, 18 Aug 2009 17:59:34 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Tue, 18 Aug 2009 17:59:34 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Simon Josefsson <simon@josefsson.org>
Message-ID: <20090818225934.GW1043@Sun.COM>
References: <20090818213427.GU1043@Sun.COM> <87ljlgbv2a.fsf@mocca.josefsson.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87ljlgbv2a.fsf@mocca.josefsson.org>
User-Agent: Mutt/1.5.7i
Cc: ietf-sasl@imc.org, tls@ietf.org
Subject: Re: [TLS] "Last call" on draft-altman-tls-channel-bindings-05.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Aug 2009 23:10:19 -0000

On Wed, Aug 19, 2009 at 12:45:17AM +0200, Simon Josefsson wrote:
> Quoting:
> 
>    Description: The hash of the TLS server's end entity certificate
>    [RFC5280] as it appears, octet for octet, in the server's Certificate
>    message (note that the Certificate message contains a
>    certificate_list, the first element of which is the server's end
>    entity certificate.)
> 
> I suggest replacing "server's end entity certificate" with "server's
> certificate".  As far as I understand, it is possibly to use non-EE
> certs, e.g. proxy certs, as a server certificate.  The RFC 5246
> terminology is to say "sender's certificate" and there is no requirement
> to use a EE cert.

OK.  The thing to emphasize is that we're talking about the first cert
in the certificate_list that would be sent by the server.

(I say "would be" just to be mindful of the TLS client caching
extensions, but I don't think the I-D has to say "would" since the
certificate_list will always have been sent at one point or another.)

So how about:

   Description: The hash of the TLS server's certificate [RFC5280] as it
   appears, octet for octet, in the server's Certificate message (note
   that the Certificate message contains a certificate_list, the first
   element of which is the server's certificate.)  The hash function ...

> Quoting:
> 
>    agility.  The algorithm to be used, however, is derived from the
>    certificate itself: use SHA-256 if the certificate uses MD5 or SHA-1,
>    else use whatever hash function the certificate uses.  This
> 
> Please say "is signed with" instead of "uses".  Hash values may be
> present for other purposes in a certificate, but signature fields will
> typically only use one hash function.

The text you quote is security considerations text; the normative text
already says exactly what you ask for.  But OK:

        ...  The algorithm to be used, however, is derived from the
   certificate's signature as described in Section 4.1; to recap: use
   SHA-256 if the certificate signature algorithm uses MD5 or SHA-1,
   else use whatever hash function the certificate uses.

Now, section 4.1 says "if the certificate's signature hash algorithm is
...".  But perhaps it should say "if the hash algorithm used in the
certificate's signatureAlgorithm is ...", just to be really accurate and
avoid any possible confusion (with, say, the algorithm field of
SubjectPublicKeyInfo).  Yes?

> For completeness, I would add:
> 
>    This algorithm agility resolution mechanism assumes that there is a
>    mapping from every Public-key signature algorithm to one hash
>    function algorithm.  This is the case for all practically used public
>    key signature algorithms today, but if future public-key signature
>    algorithms would employ multiple hash functions (or none at all) this
>    specification needs to be updated to resolve which hash function
>    should be used.

Good point.

Thanks!

Nico
-- 

From simon@josefsson.org  Tue Aug 18 17:14:49 2009
Return-Path: <simon@josefsson.org>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18D293A6BDB for <tls@core3.amsl.com>; Tue, 18 Aug 2009 17:14:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level: 
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCkV4Jp4DOWi for <tls@core3.amsl.com>; Tue, 18 Aug 2009 17:14:48 -0700 (PDT)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 098993A6CA8 for <tls@ietf.org>; Tue, 18 Aug 2009 17:14:46 -0700 (PDT)
Received: from mocca.josefsson.org (c80-216-31-183.bredband.comhem.se [80.216.31.183]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n7J0Ect1002404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 19 Aug 2009 02:14:47 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Nicolas Williams <Nicolas.Williams@sun.com>
References: <20090818213427.GU1043@Sun.COM> <87ljlgbv2a.fsf@mocca.josefsson.org> <20090818225934.GW1043@Sun.COM>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090819:ietf-sasl@imc.org::XcO9khQ7yKWKB+bJ:1zR4
X-Hashcash: 1:22:090819:nicolas.williams@sun.com::xQBD+AnB68GkFtvc:5LOR
X-Hashcash: 1:22:090819:tls@ietf.org::9tI8e5seg85tFhXg:Bi0/
Date: Wed, 19 Aug 2009 02:14:38 +0200
In-Reply-To: <20090818225934.GW1043@Sun.COM> (Nicolas Williams's message of "Tue, 18 Aug 2009 17:59:34 -0500")
Message-ID: <87bpmcbqxd.fsf@mocca.josefsson.org>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Cc: ietf-sasl@imc.org, tls@ietf.org
Subject: Re: [TLS] "Last call" on draft-altman-tls-channel-bindings-05.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Aug 2009 00:14:49 -0000

Nicolas Williams <Nicolas.Williams@sun.com> writes:

> On Wed, Aug 19, 2009 at 12:45:17AM +0200, Simon Josefsson wrote:
>> Quoting:
>> 
>>    Description: The hash of the TLS server's end entity certificate
>>    [RFC5280] as it appears, octet for octet, in the server's Certificate
>>    message (note that the Certificate message contains a
>>    certificate_list, the first element of which is the server's end
>>    entity certificate.)
>> 
>> I suggest replacing "server's end entity certificate" with "server's
>> certificate".  As far as I understand, it is possibly to use non-EE
>> certs, e.g. proxy certs, as a server certificate.  The RFC 5246
>> terminology is to say "sender's certificate" and there is no requirement
>> to use a EE cert.
>
> OK.  The thing to emphasize is that we're talking about the first cert
> in the certificate_list that would be sent by the server.
>
> (I say "would be" just to be mindful of the TLS client caching
> extensions, but I don't think the I-D has to say "would" since the
> certificate_list will always have been sent at one point or another.)
>
> So how about:
>
>    Description: The hash of the TLS server's certificate [RFC5280] as it
>    appears, octet for octet, in the server's Certificate message (note
>    that the Certificate message contains a certificate_list, the first
>    element of which is the server's certificate.)  The hash function ...

Looks fine to me.

>> Quoting:
>> 
>>    agility.  The algorithm to be used, however, is derived from the
>>    certificate itself: use SHA-256 if the certificate uses MD5 or SHA-1,
>>    else use whatever hash function the certificate uses.  This
>> 
>> Please say "is signed with" instead of "uses".  Hash values may be
>> present for other purposes in a certificate, but signature fields will
>> typically only use one hash function.
>
> The text you quote is security considerations text; the normative text
> already says exactly what you ask for.  But OK:
>
>         ...  The algorithm to be used, however, is derived from the
>    certificate's signature as described in Section 4.1; to recap: use
>    SHA-256 if the certificate signature algorithm uses MD5 or SHA-1,
>    else use whatever hash function the certificate uses.

There were two uses of "uses" in the sentence, and the second is still
present, but at least this is better than before.

> Now, section 4.1 says "if the certificate's signature hash algorithm is
> ...".  But perhaps it should say "if the hash algorithm used in the
> certificate's signatureAlgorithm is ...", just to be really accurate and
> avoid any possible confusion (with, say, the algorithm field of
> SubjectPublicKeyInfo).  Yes?

The more precise the better, although SubjectPublicKeyInfo generally do
not imply any particular hash function.  But for new implementers, it is
easy to go wrong if the text is not specific.

/Simon

From Nicolas.Williams@sun.com  Wed Aug 19 09:28:31 2009
Return-Path: <Nicolas.Williams@sun.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B1A23A6D6A for <tls@core3.amsl.com>; Wed, 19 Aug 2009 09:28:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.921
X-Spam-Level: 
X-Spam-Status: No, score=-5.921 tagged_above=-999 required=5 tests=[AWL=0.125,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bTuJpouz6wT for <tls@core3.amsl.com>; Wed, 19 Aug 2009 09:28:30 -0700 (PDT)
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 986D73A6A3C for <tls@ietf.org>; Wed, 19 Aug 2009 09:28:18 -0700 (PDT)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7JGSKVG023035 for <tls@ietf.org>; Wed, 19 Aug 2009 16:28:20 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n7JGSJpP038642 for <tls@ietf.org>; Wed, 19 Aug 2009 10:28:19 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7JGHXVB004013; Wed, 19 Aug 2009 11:17:33 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7JGHSpp004012;  Wed, 19 Aug 2009 11:17:28 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Wed, 19 Aug 2009 11:17:28 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Simon Josefsson <simon@josefsson.org>
Message-ID: <20090819161728.GB1043@Sun.COM>
References: <20090818213427.GU1043@Sun.COM> <87ljlgbv2a.fsf@mocca.josefsson.org> <20090818225934.GW1043@Sun.COM> <87bpmcbqxd.fsf@mocca.josefsson.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87bpmcbqxd.fsf@mocca.josefsson.org>
User-Agent: Mutt/1.5.7i
Cc: ietf-sasl@imc.org, tls@ietf.org
Subject: Re: [TLS] "Last call" on draft-altman-tls-channel-bindings-05.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Aug 2009 16:28:31 -0000

On Wed, Aug 19, 2009 at 02:14:38AM +0200, Simon Josefsson wrote:
> Nicolas Williams <Nicolas.Williams@sun.com> writes:
> >    Description: ...
> 
> Looks fine to me.
> 
> > The text you quote is security considerations text; the normative text
> > already says exactly what you ask for.  But OK:
> >
> >         ...  The algorithm to be used, however, is derived from the
> >    certificate's signature as described in Section 4.1; to recap: use
> >    SHA-256 if the certificate signature algorithm uses MD5 or SHA-1,
> >    else use whatever hash function the certificate uses.
> 
> There were two uses of "uses" in the sentence, and the second is still
> present, but at least this is better than before.

Ah yes:

        ...  The algorithm to be used, however, is derived from the
   certificate's signature as described in Section 4.1; to recap: use
   SHA-256 if the certificate signature algorithm uses MD5 or SHA-1,
   else use whatever hash function the certificate signature algorithm
   uses.

> > Now, section 4.1 says "if the certificate's signature hash algorithm is
> > ...".  But perhaps it should say "if the hash algorithm used in the
> > certificate's signatureAlgorithm is ...", just to be really accurate and
> > avoid any possible confusion (with, say, the algorithm field of
> > SubjectPublicKeyInfo).  Yes?
> 
> The more precise the better, although SubjectPublicKeyInfo generally do
> not imply any particular hash function.  But for new implementers, it is
> easy to go wrong if the text is not specific.

So let's add that precision and address signature algs that don't use
hash functions:

   Description: The hash of the TLS server's certificate [RFC5280] as it
   appears, octet for octet, in the server's Certificate message (note
   that the Certificate message contains a certificate_list, the first
   element of which is the server's certificate.)  The hash function is
   to be selected as follows: if the hash algorithm used in the
   certificate's signatureAlgorithm is either MD5 [RFC1321] or SHA-1
   [RFC3174] or if the certificate's signatureAlgorithm does not use any
   hash functions, then use SHA-256 [FIPS-180-2], otherwise use whatever
   hash algorithm is used by the certificate's signatureAlgorithm.

Nico
-- 

From Nicolas.Williams@sun.com  Wed Aug 19 14:33:16 2009
Return-Path: <Nicolas.Williams@sun.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1623D3A6A9C for <tls@core3.amsl.com>; Wed, 19 Aug 2009 14:33:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.029
X-Spam-Level: 
X-Spam-Status: No, score=-5.029 tagged_above=-999 required=5 tests=[AWL=-0.783, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_12=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uphyd899AbLw for <tls@core3.amsl.com>; Wed, 19 Aug 2009 14:33:14 -0700 (PDT)
Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id 2AA4C3A69DE for <tls@ietf.org>; Wed, 19 Aug 2009 14:33:02 -0700 (PDT)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7JLX7JI026625 for <tls@ietf.org>; Wed, 19 Aug 2009 21:33:07 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n7JLX7U4045974 for <tls@ietf.org>; Wed, 19 Aug 2009 15:33:07 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7JLMOoK004480; Wed, 19 Aug 2009 16:22:24 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7JLMOUh004479;  Wed, 19 Aug 2009 16:22:24 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Wed, 19 Aug 2009 16:22:24 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Simon Josefsson <simon@josefsson.org>
Message-ID: <20090819212223.GN1043@Sun.COM>
References: <20090818213427.GU1043@Sun.COM> <87ljlgbv2a.fsf@mocca.josefsson.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87ljlgbv2a.fsf@mocca.josefsson.org>
User-Agent: Mutt/1.5.7i
Cc: ietf-sasl@imc.org, tls@ietf.org
Subject: Re: [TLS] "Last call" on draft-altman-tls-channel-bindings-05.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Aug 2009 21:33:16 -0000

On Wed, Aug 19, 2009 at 12:45:17AM +0200, Simon Josefsson wrote:
> For completeness, I would add:
> 
>    This algorithm agility resolution mechanism assumes that there is a
>    mapping from every Public-key signature algorithm to one hash
>    function algorithm.  This is the case for all practically used public
>    key signature algorithms today, but if future public-key signature
>    algorithms would employ multiple hash functions (or none at all) this
>    specification needs to be updated to resolve which hash function
>    should be used.

This brings up a question: what to do in the case of randomized digital
signatures?  In the case of NIST-SP-800-106 there's still a hash
function, so that's OK.  But one can imagine a digital signature
algorithm where a MAC and random key are used instead of a hash.

Traditionally a digital signature

	S'(Kp, M) = S(Kp, H(M))

while in NIST-SP-800-106

	S'(Kp, M) = {rv = rng(rv_len),
		     S(Kp, H(rv ||
			     (pad(M, rv_len) XOR xor_pad_gen(rv) ||
			     rv_length_indicator(rv_len))))
		    }

One could imagine this, however:

	S'(Kp, M) = {mk = rng(),
		     S(Kp, MAC(k, M))}

in which case there'd be no hash function.  Of course, we could define a
pseudo-hash function in that case: H(x) = MAC(mk, x), where mk is the mk
that would appear in the signature.

But I don't want to guess at what might happen in the future
of digital signatures.  Instead I'd rather either say either
that tls-server-end-point CB is undefined if the cert's
signature alg does not use a signature, or pick a hash
function (e.g., SHA-512) to use in such cases.

Comments?

Nico
-- 

From simon@josefsson.org  Wed Aug 19 15:25:39 2009
Return-Path: <simon@josefsson.org>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 644313A6CFA for <tls@core3.amsl.com>; Wed, 19 Aug 2009 15:25:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level: 
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWWwpgEvu0nG for <tls@core3.amsl.com>; Wed, 19 Aug 2009 15:25:38 -0700 (PDT)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 490F03A6C9F for <tls@ietf.org>; Wed, 19 Aug 2009 15:25:38 -0700 (PDT)
Received: from mocca.josefsson.org (c80-216-31-183.bredband.comhem.se [80.216.31.183]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n7JMPcBJ031296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Aug 2009 00:25:40 +0200
From: Simon Josefsson <simon@josefsson.org>
To: Nicolas Williams <Nicolas.Williams@sun.com>
References: <20090818213427.GU1043@Sun.COM> <87ljlgbv2a.fsf@mocca.josefsson.org> <20090819212223.GN1043@Sun.COM>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:090819:ietf-sasl@imc.org::KeyHv/WeE0AMzTIv:03lZ
X-Hashcash: 1:22:090819:tls@ietf.org::0rTKIlPk8SZjIqkT:ZnPW
X-Hashcash: 1:22:090819:nicolas.williams@sun.com::wy96xQShYma/iDOS:g3wg
Date: Thu, 20 Aug 2009 00:25:38 +0200
In-Reply-To: <20090819212223.GN1043@Sun.COM> (Nicolas Williams's message of "Wed, 19 Aug 2009 16:22:24 -0500")
Message-ID: <87d46r4f19.fsf@mocca.josefsson.org>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Cc: ietf-sasl@imc.org, tls@ietf.org
Subject: Re: [TLS] "Last call" on draft-altman-tls-channel-bindings-05.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Aug 2009 22:25:39 -0000

Nicolas Williams <Nicolas.Williams@sun.com> writes:

> But I don't want to guess at what might happen in the future
> of digital signatures.

I agree, we could decide to not resolve this concern.

> Instead I'd rather either say either that tls-server-end-point CB is
> undefined if the cert's signature alg does not use a signature, or
> pick a hash function (e.g., SHA-512) to use in such cases.

If use of SHA-512 is hard-coded, we run into problem when it is phased
out.  Negotiation any other hash function will be tricky.  Alas, I'm not
sure leaving it undefined is any better: negotiating what hash function
to use in that situation seems equally tricky.

This is one reason where deriving channel binding data from the TLS
channel using tls-extractor appears more robust: it leaves negotiation
of the hash function to the TLS protocol.

/Simon

From Nicolas.Williams@sun.com  Wed Aug 19 15:33:20 2009
Return-Path: <Nicolas.Williams@sun.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 673CC3A6A6A for <tls@core3.amsl.com>; Wed, 19 Aug 2009 15:33:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.905
X-Spam-Level: 
X-Spam-Status: No, score=-5.905 tagged_above=-999 required=5 tests=[AWL=0.141,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uo2OdIg-rQTz for <tls@core3.amsl.com>; Wed, 19 Aug 2009 15:33:19 -0700 (PDT)
Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 1A5BB3A69DE for <tls@ietf.org>; Wed, 19 Aug 2009 15:33:07 -0700 (PDT)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7JMXCbQ003220 for <tls@ietf.org>; Wed, 19 Aug 2009 22:33:12 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n7JMXBRx058469 for <tls@ietf.org>; Wed, 19 Aug 2009 16:33:11 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7JMMU9U004576; Wed, 19 Aug 2009 17:22:30 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7JMMUYM004575;  Wed, 19 Aug 2009 17:22:30 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Wed, 19 Aug 2009 17:22:29 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Simon Josefsson <simon@josefsson.org>
Message-ID: <20090819222229.GS1043@Sun.COM>
References: <20090818213427.GU1043@Sun.COM> <87ljlgbv2a.fsf@mocca.josefsson.org> <20090819212223.GN1043@Sun.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20090819212223.GN1043@Sun.COM>
User-Agent: Mutt/1.5.7i
Cc: ietf-sasl@imc.org, tls@ietf.org
Subject: Re: [TLS] "Last call" on draft-altman-tls-channel-bindings-05.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Aug 2009 22:33:20 -0000

On Wed, Aug 19, 2009 at 04:22:24PM -0500, Nicolas Williams wrote:
> On Wed, Aug 19, 2009 at 12:45:17AM +0200, Simon Josefsson wrote:
> > For completeness, I would add:
> > 
> >    This algorithm agility resolution mechanism assumes that there is a
> >    mapping from every Public-key signature algorithm to one hash
> >    function algorithm.  This is the case for all practically used public
> >    key signature algorithms today, but if future public-key signature
> >    algorithms would employ multiple hash functions (or none at all) this
> >    specification needs to be updated to resolve which hash function
> >    should be used.
> 
> This brings up a question: what to do in the case of randomized digital
> signatures?  In the case of NIST-SP-800-106 there's still a hash
> function, so that's OK.  But one can imagine a digital signature
> algorithm where a MAC and random key are used instead of a hash.
> 
> ...
> 
> But I don't want to guess at what might happen in the future
> of digital signatures.  Instead I'd rather either say either
> that tls-server-end-point CB is undefined if the cert's
> signature alg does not use a signature, or pick a hash
> function (e.g., SHA-512) to use in such cases.

After asking others I propose the former solution:

   Description: The hash of the TLS server's certificate [RFC5280] as it
   appears, octet for octet, in the server's Certificate message (note
   that the Certificate message contains a certificate_list, the first
   element of which is the server's certificate.)

   The hash function is to be selected as follows:

    - if the certificate's signatureAlgorithm uses a single hash
      function, and that hash function is either MD5 [RFC1321] or SHA-1
      [RFC3174] then use SHA-256 [FIPS-180-2];

    - if the certificate's signatureAlgorithm uses a single hash
      function and that hash function neither MD5 nor SHA-1, then use
      the hash function associated with the certificate's
      signatureAlgorithm;

    - if the certificate's signatureAlgorithm uses no hash functions, or
      multiple hash functions, then this channel binding type's channel
      bindings are undefined at this time (updates to is channel binding
      type may occur to address this issue if it ever arises).

Nico
-- 

From Nicolas.Williams@sun.com  Wed Aug 19 15:37:36 2009
Return-Path: <Nicolas.Williams@sun.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F82D3A6FEA for <tls@core3.amsl.com>; Wed, 19 Aug 2009 15:37:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.908
X-Spam-Level: 
X-Spam-Status: No, score=-5.908 tagged_above=-999 required=5 tests=[AWL=0.138,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4KgJiHRt9qD for <tls@core3.amsl.com>; Wed, 19 Aug 2009 15:37:35 -0700 (PDT)
Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 5B8653A6C93 for <tls@ietf.org>; Wed, 19 Aug 2009 15:37:35 -0700 (PDT)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7JMbeSs020617 for <tls@ietf.org>; Wed, 19 Aug 2009 22:37:40 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n7JMbeua060798 for <tls@ietf.org>; Wed, 19 Aug 2009 16:37:40 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7JMQw4c004584; Wed, 19 Aug 2009 17:26:58 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7JMQwpe004583;  Wed, 19 Aug 2009 17:26:58 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Wed, 19 Aug 2009 17:26:58 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Simon Josefsson <simon@josefsson.org>
Message-ID: <20090819222658.GT1043@Sun.COM>
References: <20090818213427.GU1043@Sun.COM> <87ljlgbv2a.fsf@mocca.josefsson.org> <20090819212223.GN1043@Sun.COM> <87d46r4f19.fsf@mocca.josefsson.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87d46r4f19.fsf@mocca.josefsson.org>
User-Agent: Mutt/1.5.7i
Cc: ietf-sasl@imc.org, tls@ietf.org
Subject: Re: [TLS] "Last call" on draft-altman-tls-channel-bindings-05.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Aug 2009 22:37:36 -0000

On Thu, Aug 20, 2009 at 12:25:38AM +0200, Simon Josefsson wrote:
> Nicolas Williams <Nicolas.Williams@sun.com> writes:
> > But I don't want to guess at what might happen in the future
> > of digital signatures.
> 
> I agree, we could decide to not resolve this concern.
> 
> > Instead I'd rather either say either that tls-server-end-point CB is
> > undefined if the cert's signature alg does not use a signature, or
> > pick a hash function (e.g., SHA-512) to use in such cases.
> 
> If use of SHA-512 is hard-coded, we run into problem when it is phased
> out.  Negotiation any other hash function will be tricky.  Alas, I'm not
> sure leaving it undefined is any better: negotiating what hash function
> to use in that situation seems equally tricky.

I chatted with Jeff Hutzelman about this, and we both concluded that
leaving tls-server-end-point undefined in this case is acceptable
because we could change the spec to define tls-server-end-point for such
signature algorithms when they arise.

> This is one reason where deriving channel binding data from the TLS
> channel using tls-extractor appears more robust: it leaves negotiation
> of the hash function to the TLS protocol.

tls-unique does that already (though not using the extractor).  We're
talking about end-point channel binding types here, which are
independent of actual channels, therefore we couldn't use the extractor.

Nico
-- 

From jhutz@cmu.edu  Thu Aug 20 07:07:18 2009
Return-Path: <jhutz@cmu.edu>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A312F3A6833 for <tls@core3.amsl.com>; Thu, 20 Aug 2009 07:07:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.501
X-Spam-Level: 
X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zZYCtkUWebo for <tls@core3.amsl.com>; Thu, 20 Aug 2009 07:07:18 -0700 (PDT)
Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by core3.amsl.com (Postfix) with ESMTP id CAEA43A67FE for <tls@ietf.org>; Thu, 20 Aug 2009 07:07:17 -0700 (PDT)
Received: from ATLANTIS-GHC.PC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.216.216]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n7KE7LoK007948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Aug 2009 10:07:21 -0400 (EDT)
Date: Thu, 20 Aug 2009 10:07:20 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Nicolas Williams <Nicolas.Williams@sun.com>, Simon Josefsson <simon@josefsson.org>
Message-ID: <A7B99A36C9F4DEA5F4F250FF@atlantis.pc.cs.cmu.edu>
In-Reply-To: <20090819222229.GS1043@Sun.COM>
References: <20090818213427.GU1043@Sun.COM> <87ljlgbv2a.fsf@mocca.josefsson.org> <20090819212223.GN1043@Sun.COM> <20090819222229.GS1043@Sun.COM>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.217.196
X-Mailman-Approved-At: Thu, 20 Aug 2009 08:01:54 -0700
Cc: ietf-sasl@imc.org, tls@ietf.org, jhutz@cmu.edu
Subject: Re: [TLS] "Last call" on draft-altman-tls-channel-bindings-05.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Aug 2009 14:07:18 -0000

--On Wednesday, August 19, 2009 05:22:29 PM -0500 Nicolas Williams 
<Nicolas.Williams@sun.com> wrote:

> After asking others I propose the former solution:
>
>    Description: The hash of the TLS server's certificate [RFC5280] as it
>    appears, octet for octet, in the server's Certificate message (note
>    that the Certificate message contains a certificate_list, the first
>    element of which is the server's certificate.)
>
>    The hash function is to be selected as follows:
>
>     - if the certificate's signatureAlgorithm uses a single hash
>       function, and that hash function is either MD5 [RFC1321] or SHA-1
>       [RFC3174] then use SHA-256 [FIPS-180-2];
>
>     - if the certificate's signatureAlgorithm uses a single hash
>       function and that hash function neither MD5 nor SHA-1, then use
>       the hash function associated with the certificate's
>       signatureAlgorithm;
>
>     - if the certificate's signatureAlgorithm uses no hash functions, or
>       multiple hash functions, then this channel binding type's channel
>       bindings are undefined at this time (updates to is channel binding
>       type may occur to address this issue if it ever arises).

+1

From simon@josefsson.org  Thu Aug 20 08:46:58 2009
Return-Path: <simon@josefsson.org>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD3833A6D9C; Thu, 20 Aug 2009 08:46:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.634
X-Spam-Level: 
X-Spam-Status: No, score=-1.634 tagged_above=-999 required=5 tests=[AWL=-1.047, BAYES_00=-2.599, FAKE_REPLY_C=2.012]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOd11s3Dabeo; Thu, 20 Aug 2009 08:46:58 -0700 (PDT)
Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id D565D3A6A4D; Thu, 20 Aug 2009 08:46:57 -0700 (PDT)
Received: from mocca.josefsson.org (c80-216-31-183.bredband.comhem.se [80.216.31.183]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n7KFkxHa021081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 20 Aug 2009 17:47:01 +0200
X-Hashcash: 1:22:090820:ietf@ietf.org::CCggUjTrpRuSV9bX:Qdq4
X-Hashcash: 1:22:090820:tls@ietf.org::CR18IbrGWAGh5zOh:L7PH
From: Simon Josefsson <simon@josefsson.org>
To: ietf@ietf.org
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 20 Aug 2009 17:46:59 +0200
Message-ID: <87my5uwkr0.fsf@mocca.josefsson.org>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: clamav-milter 0.95.2 at yxa-v
X-Virus-Status: Clean
Cc: tls@ietf.org
Subject: Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Aug 2009 15:46:59 -0000

I am aware that the last call period has ended, but maybe this comment
will aid IESG processing of the document.

After having talked to the SFLC and the FSF about the patent threat on
this document, I no longer oppose publication of the tls-extractor
document on the standards track.  It appears as if the patent threat on
the document (as I perceived it) was resolved when Certicom's agent
clarified their intentions on the mailing list.  Thanks to Pasi for
nudging me to escalate the issue, and also thanks to the SFLC for giving
me advice on the matter.

Generally, it appears sub-optimal that implementers needs to review not
only the patent disclosure page but also review mailing list archives to
be able to evaluate the patent status on a document.

Finally, I note that the time period a document is in IETF Last Call,
even if the time window is extended as it was for tls-extractor, is too
short to allow matters to be resolved that requires coordination between
multiple organizations and feedback from legal people.

Thanks,
/Simon

From Michael.Tuexen@lurchi.franken.de  Fri Aug 21 00:53:18 2009
Return-Path: <Michael.Tuexen@lurchi.franken.de>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B55563A6DFE for <tls@core3.amsl.com>; Fri, 21 Aug 2009 00:53:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.265
X-Spam-Level: 
X-Spam-Status: No, score=-1.265 tagged_above=-999 required=5 tests=[AWL=-0.517, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhJ4dG3od-3A for <tls@core3.amsl.com>; Fri, 21 Aug 2009 00:53:17 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 741D63A6DD3 for <tls@ietf.org>; Fri, 21 Aug 2009 00:53:17 -0700 (PDT)
Received: from [10.0.1.102] (unknown [194.95.73.188]) by mail-n.franken.de (Postfix) with ESMTP id 44DDA1C0C0BD8 for <tls@ietf.org>; Fri, 21 Aug 2009 09:53:20 +0200 (CEST)
Message-Id: <FE65B6EF-3810-4D33-89C2-1F34A0941C89@lurchi.franken.de>
From: =?ISO-8859-1?Q?Michael_T=FCxen?= <Michael.Tuexen@lurchi.franken.de>
To: tls@ietf.org
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 21 Aug 2009 09:53:21 +0200
X-Mailer: Apple Mail (2.936)
Subject: [TLS] draft-seggelmann-tls-dtls-heartbeat-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Aug 2009 07:53:18 -0000

Dear all,

an updated version of the heartbeat ID is available at:
http://www.ietf.org/internet-drafts/draft-seggelmann-tls-dtls-heartbeat-01.txt

We have added padding data to request messages such that the message
can be used for used for PMTU discovery. We also added text describing
the usage of the extension in combination with TLS.

This should cover the suggestions during the presentation at the last  
IETF
meeting.

Any more comments and/or suggestions.

An updated implementation of this extension of OpenSSL will be  
available from
http://sctp.fh-muenster.de
later today.

Best regards
Michael

From Pasi.Eronen@nokia.com  Mon Aug 24 03:24:25 2009
Return-Path: <Pasi.Eronen@nokia.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BE3B3A6DBE for <tls@core3.amsl.com>; Mon, 24 Aug 2009 03:24:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.303
X-Spam-Level: 
X-Spam-Status: No, score=-6.303 tagged_above=-999 required=5 tests=[AWL=0.296,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWXSElPQL74s for <tls@core3.amsl.com>; Mon, 24 Aug 2009 03:24:24 -0700 (PDT)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 800083A6E08 for <tls@ietf.org>; Mon, 24 Aug 2009 03:23:59 -0700 (PDT)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n7OANC5R018000; Mon, 24 Aug 2009 05:23:28 -0500
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 24 Aug 2009 13:23:50 +0300
Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 24 Aug 2009 13:23:45 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 24 Aug 2009 13:23:39 +0300
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Mon, 24 Aug 2009 12:23:38 +0200
From: <Pasi.Eronen@nokia.com>
To: <tls@ietf.org>, <d3e3e3@gmail.com>, <jsalowey@cisco.com>
Date: Mon, 24 Aug 2009 12:23:31 +0200
Thread-Topic: AD review comments for draft-ietf-tls-rfc4366-bis-05
Thread-Index: AcokpO2Tjc9RxlVzSkCxmccz7s1qdg==
Message-ID: <808FD6E27AD4884E94820BC333B2DB773C01115ED2@NOK-EUMSG-01.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 24 Aug 2009 10:23:39.0444 (UTC) FILETIME=[F2748740:01CA24A4]
X-Nokia-AV: Clean
Subject: [TLS] AD review comments for draft-ietf-tls-rfc4366-bis-05
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Aug 2009 10:24:25 -0000

I've now done my AD review for draft-ietf-tls-rfc4366-bis-05.  All my
comments are relatively minor, so I've requested the secretariat to
start IETF last call (these can be considered as the first last call
comments):

- The document doesn't seem to say anything about issue #102
(extensibility of server_name NameTypes) yet. One option would be to
say that all future NameTypes must begin with a 16-bit length field
(so the recipient can skip over unrecognized NameTypes). Another
obvious alternative is to say NameTypes will not be extended (perhaps
this would be even simpler).

- Section 3 of RFC 4366 used to have text describing how these
extensions behave during resumption. Probably we still need this text?
(RFC 5246 says each extension type needs to describe this)

- As noted in issue #100, the last sentence of Section 4 probably
needs to be qualified for DTLS case.

- In Section 5, the notation "opaque padding<1>" isn't valid notation
according to 5246; should be "uint8 padding" instead?

Best regards,
Pasi

From wwwrun@core3.amsl.com  Mon Aug 24 07:01:46 2009
Return-Path: <wwwrun@core3.amsl.com>
X-Original-To: tls@ietf.org
Delivered-To: tls@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id 54C2528C1DD; Mon, 24 Aug 2009 07:01:46 -0700 (PDT)
X-idtracker: yes
To: IETF-Announce <ietf-announce@ietf.org> 
From: The IESG <iesg-secretary@ietf.org>
Message-Id: <20090824140146.54C2528C1DD@core3.amsl.com>
Date: Mon, 24 Aug 2009 07:01:46 -0700 (PDT)
Cc: tls@ietf.org
Subject: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer Security (TLS) Extensions: Extension Definitions) to Proposed Standard
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: ietf@ietf.org
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Aug 2009 14:01:46 -0000

The IESG has received a request from the Transport Layer Security WG 
(tls) to consider the following document:

- 'Transport Layer Security (TLS) Extensions: Extension Definitions '
   <draft-ietf-tls-rfc4366-bis-05.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2009-09-07. Exceptionally, 
comments may be sent to iesg@ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4366-bis-05.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16186&rfc_flag=0


From stpeter@stpeter.im  Mon Aug 24 09:20:55 2009
Return-Path: <stpeter@stpeter.im>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FAE428C23B for <tls@core3.amsl.com>; Mon, 24 Aug 2009 09:20:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.535
X-Spam-Level: 
X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsXlXO4+dMF3 for <tls@core3.amsl.com>; Mon, 24 Aug 2009 09:20:54 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id BA3E328C22B for <tls@ietf.org>; Mon, 24 Aug 2009 09:20:54 -0700 (PDT)
Received: from squire.local (unknown [64.101.72.216]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DA9B34007B; Mon, 24 Aug 2009 10:21:00 -0600 (MDT)
Message-ID: <4A92BDEB.8020608@stpeter.im>
Date: Mon, 24 Aug 2009 10:20:59 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Nicolas Williams <Nicolas.Williams@sun.com>
References: <20090818213427.GU1043@Sun.COM>
In-Reply-To: <20090818213427.GU1043@Sun.COM>
X-Enigmail-Version: 0.96.0
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: ietf-sasl@imc.org, tls@ietf.org
Subject: Re: [TLS] "Last call" on draft-altman-tls-channel-bindings-05.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Aug 2009 16:20:55 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 8/18/09 3:34 PM, Nicolas Williams wrote:
> Per RFC5056, three channel binding types for TLS have been registered in
> the IANA channel binding type registry.  Recently we've decided that we
> actually need a Standards-Track RFC to define these channel binding
> types so as to make it easier to make normative reference to them.

Thanks, this is helpful.

> Therefore we've revived and updated draft-altman-tls-channel-bindings to
> include the text of those three channel binding type registrations, as
> well as to update introductory and security considerations text.
> 
> We seek comments on draft-altman-tls-channel-bindings-05.  In two weeks
> we'll request that an AD shepherd this individual submission.  We seek
> Proposed Standard status for the resulting RFC.

The TLS list seems more appropriate than ietf@ietf.org as the location
for expert review.

Nit: cryptographycally => cryptographically

Peter

- --
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqSvesACgkQNL8k5A2w/vylXQCfc9VgJXxuu8P/kjn58bwZK4Po
O7AAn2ahPVkvYcVPSsEH4csG4tMQmBEO
=S4nY
-----END PGP SIGNATURE-----

From Nicolas.Williams@sun.com  Mon Aug 24 11:00:04 2009
Return-Path: <Nicolas.Williams@sun.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3660528C309 for <tls@core3.amsl.com>; Mon, 24 Aug 2009 11:00:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.895
X-Spam-Level: 
X-Spam-Status: No, score=-5.895 tagged_above=-999 required=5 tests=[AWL=0.151,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNl6swJF0KGh for <tls@core3.amsl.com>; Mon, 24 Aug 2009 11:00:03 -0700 (PDT)
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id C0F9E28C2FE for <tls@ietf.org>; Mon, 24 Aug 2009 10:59:58 -0700 (PDT)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7OI049X028759 for <tls@ietf.org>; Mon, 24 Aug 2009 18:00:04 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n7OI04xJ048915 for <tls@ietf.org>; Mon, 24 Aug 2009 12:00:04 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7OHnHho008094; Mon, 24 Aug 2009 12:49:17 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7OHnGgm008093;  Mon, 24 Aug 2009 12:49:16 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Mon, 24 Aug 2009 12:49:16 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Peter Saint-Andre <stpeter@stpeter.im>
Message-ID: <20090824174916.GW1043@Sun.COM>
References: <20090818213427.GU1043@Sun.COM> <4A92BDEB.8020608@stpeter.im>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4A92BDEB.8020608@stpeter.im>
User-Agent: Mutt/1.5.7i
Cc: ietf-sasl@imc.org, tls@ietf.org
Subject: Re: [TLS] "Last call" on draft-altman-tls-channel-bindings-05.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Aug 2009 18:00:04 -0000

On Mon, Aug 24, 2009 at 10:20:59AM -0600, Peter Saint-Andre wrote:
> The TLS list seems more appropriate than ietf@ietf.org as the location
> for expert review.
                   ^ of changes to these channel binding types.

Good point.  I'll make the change.  (But perhaps the TLS WG doesn't
agree?  If so, pipe up!)

Nico
-- 

From Nicolas.Williams@sun.com  Mon Aug 31 13:07:47 2009
Return-Path: <Nicolas.Williams@sun.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A04D428C430 for <tls@core3.amsl.com>; Mon, 31 Aug 2009 13:07:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.853
X-Spam-Level: 
X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[AWL=0.193,  BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLO-dGiKRzkA for <tls@core3.amsl.com>; Mon, 31 Aug 2009 13:07:46 -0700 (PDT)
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id BFA373A6BBC for <tls@ietf.org>; Mon, 31 Aug 2009 13:07:46 -0700 (PDT)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7VK7oGv016885 for <tls@ietf.org>; Mon, 31 Aug 2009 20:07:50 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n7VK7nIA023351 for <tls@ietf.org>; Mon, 31 Aug 2009 14:07:50 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7VJur8L007611; Mon, 31 Aug 2009 14:56:53 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7VJuq2f007610;  Mon, 31 Aug 2009 14:56:52 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Mon, 31 Aug 2009 14:56:52 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: ietf-sasl@imc.org, tls@ietf.org
Message-ID: <20090831195652.GV1033@Sun.COM>
References: <20090818213427.GU1043@Sun.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20090818213427.GU1043@Sun.COM>
User-Agent: Mutt/1.5.7i
Subject: Re: [TLS] "Last call" on draft-altman-tls-channel-bindings-05.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2009 20:07:47 -0000

I've just posted version -06, incorporating all changes agreed so far.

This pseudo-WGLC started on August 18th.  Tomorrow I'll ask Pasi to take
the next step in the publication process.

Thanks,

Nico
-- 

From stpeter@stpeter.im  Mon Aug 31 15:22:52 2009
Return-Path: <stpeter@stpeter.im>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 585213A6B93 for <tls@core3.amsl.com>; Mon, 31 Aug 2009 15:22:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.585
X-Spam-Level: 
X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLeDj6Yq2dq8 for <tls@core3.amsl.com>; Mon, 31 Aug 2009 15:22:51 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 5BAE53A6B1E for <tls@ietf.org>; Mon, 31 Aug 2009 15:22:51 -0700 (PDT)
Received: from squire.local (unknown [64.101.72.216]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 612AA40C29 for <tls@ietf.org>; Mon, 31 Aug 2009 16:23:03 -0600 (MDT)
Message-ID: <4A9C4D46.7060605@stpeter.im>
Date: Mon, 31 Aug 2009 16:23:02 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: tls@ietf.org
X-Enigmail-Version: 0.96.0
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: [TLS] [Fwd: I-D Action:draft-saintandre-tls-server-id-check-01.txt]
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2009 22:22:52 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This might be of interest to the TLS community. Please discuss on the
apps-discuss@ietf.org list:

https://www.ietf.org/mailman/listinfo/apps-discuss

/psa


- -------- Original Message --------
Subject: I-D Action:draft-saintandre-tls-server-id-check-01.txt
Date: Mon, 31 Aug 2009 15:15:02 -0700 (PDT)
From: Internet-Drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Server Identity Verification in Application Protocols
	Author(s)       : P. Saint-Andre, et al.
	Filename        : draft-saintandre-tls-server-id-check-01.txt
	Pages           : 13
	Date            : 2009-08-31

Technologies such as Transport Layer Security (TLS) and IPsec enable
a secure connection between two entities (a "client" and a "server")
using X.509 certificates.  This document specifies recommended
procedures for checking the identity of the server in such an
interaction.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-saintandre-tls-server-id-check-01.txt


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqcTUYACgkQNL8k5A2w/vxuTwCfS80CzfRb5xhMfvAnT4uqKG9X
zAsAoPgu+GghTc3Dc/Y2nkjiTmqQkkaT
=InuB
-----END PGP SIGNATURE-----