headers
Xuelei Fan | 1 Feb 2011 05:38
Picon
Favicon

Re: TLS 1.2 test clients?

The recent JDK 7 snapshot releases support TLS 1.2 (see 
http://download.java.net/jdk7/). You're able to get and run the very 
simple sample code for simple HTTPS connections from 
http://download.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#HTTPSSample.

If you run Java with "-Djavax.net.debug=all -Dhttps.protocols=TLSv1.2" 
options, you would be able to find the detailed debugging log for 
TLS/SSL handshaking.

About the detained tech guides, please refer to 
http://download.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html.

Xuelei Fan
Java Platform, Oracle

On 2/1/2011 12:35 AM, Paul Hoffman wrote:
> Greetings again. I would like to test how servers react to a TLS 
> client that only does TLS 1.2. There are two browsers that can be put 
> into this state (IE under Win 7, and Opera), but neither give very 
> good diagnostics when a failure occurs. Further, Wireshark doesn't 
> give good dumps for TLS 1.2.
>
> Thus, if anyone here has a TLS 1.2 client that has reasonable 
> debugging of the TLS handshake and can do trivial HTTP (just send a 
> "GET /" and receive the response would be fine) after setting up a 
> tunnel, I'd greatly appreciate it. Also, if anyone has a Wireshark 
> plugin (?) that brings its TLS decoding up to 1.2, that would be great 
> as well.
>
> --Paul Hoffman, Director
(Continue reading)

Permalink | Reply | 1 comment |
headers
t.petch | 1 Feb 2011 10:28

IANA considerations I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt

Michael

I think that the IANA considerations could do with more work.

Dropping 'Heartbeat Modes' and 'Heartbeat Message Types'
into the IANA website could cause them to be lost for ever.  If they are
specific  to (D)TLS, then I would want to see that in the title, or else
have them subordinate to something that does.

Second, while I like starting with values with one, you leave zero 
open for the next person to use!  I would suggest reserving 
zero and 255 in both registries.

Tom Petch
Permalink | Reply | 2 comments |
headers
t.petch | 1 Feb 2011 10:23

Re: I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt

----- Original Message -----
From: "Michael Tüxen" <Michael.Tuexen <at> lurchi.franken.de>
To: "Florian Weimer" <fweimer <at> bfk.de>
Cc: <tls <at> ietf.org>
Sent: Thursday, January 27, 2011 2:49 PM

On Jan 27, 2011, at 2:00 PM, Florian Weimer wrote:

>> This document describes the Heartbeat Extension for the Transport
>> Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
>> protocol.
>
> I think this paragraph
>
> | There MUST NOT be more than one HeartbeatRequest message in flight
> | at a time.
>
> should be changed to:
>
> | Retransmissions MUST use the same payload as the original
> | HeartbeatRequest message.
The intention of the sentence in the ID is that you can not send
multiple HeartbeatRequest out. This could overload the network since
DTLS uses transport layers which do not necessary provide a congestion
control. That is why you can only have one request in flight.
Please note that it is not in flight anymore if the corresponding
HeartbeatReply has been received or the retransmission timer fires.

Michael
(Continue reading)

Permalink | Reply | 11 comments |
headers
Michael Tüxen | 1 Feb 2011 14:37
Picon

Re: IANA considerations I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt

On Feb 1, 2011, at 10:28 AM, t.petch wrote:

> Michael
> 
> I think that the IANA considerations could do with more work.
> 
> Dropping 'Heartbeat Modes' and 'Heartbeat Message Types'
> into the IANA website could cause them to be lost for ever.  If they are
> specific  to (D)TLS, then I would want to see that in the title, or else
> have them subordinate to something that does.
We can name them "DTLS and TLS Heartbeat Modes" and
"DTLS and TLS Heartbeat Message Types" or "(D)TLS Heartbeat Modes"
and "(D)TLS Heartbeat Message Types", whatever you prefer. Any opinion?
> 
> Second, while I like starting with values with one, you leave zero 
> open for the next person to use!  I would suggest reserving 
> zero and 255 in both registries.
Good idea. Well do that in the next ref.

Best regards
Michael
> 
> Tom Petch
>
Permalink | Reply | 1 comment |
headers
Sean Turner | 1 Feb 2011 15:31

Re: I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt

On 2/1/11 4:23 AM, t.petch wrote:
> ----- Original Message -----
> From: "Michael Tüxen"<Michael.Tuexen <at> lurchi.franken.de>
> To: "Florian Weimer"<fweimer <at> bfk.de>
> Cc:<tls <at> ietf.org>
> Sent: Thursday, January 27, 2011 2:49 PM
>
> On Jan 27, 2011, at 2:00 PM, Florian Weimer wrote:
>
>>> This document describes the Heartbeat Extension for the Transport
>>> Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
>>> protocol.
>>
>> I think this paragraph
>>
>> | There MUST NOT be more than one HeartbeatRequest message in flight
>> | at a time.
>>
>> should be changed to:
>>
>> | Retransmissions MUST use the same payload as the original
>> | HeartbeatRequest message.
> The intention of the sentence in the ID is that you can not send
> multiple HeartbeatRequest out. This could overload the network since
> DTLS uses transport layers which do not necessary provide a congestion
> control. That is why you can only have one request in flight.
> Please note that it is not in flight anymore if the corresponding
> HeartbeatReply has been received or the retransmission timer fires.
>
> Michael
(Continue reading)

Permalink | Reply | 2 comments |
headers
Davies, Joshua | 1 Feb 2011 15:47
Favicon

Re: TLS 1.2 test clients?

I wrote a sample TLS 1.2 client as a companion to a book - you can download the source from
http://media.wiley.com/product_ancillary/16/04709204/DOWNLOAD/920411%20implementing_ssl_gcc.zip
.  The TLS 1.2 client is in the "after/ch9" directory; just run:

$ make
$ ./https https://whatever.com

It's not especially robust (it will crash if you try to connect to a pre-TLS 1.2 server, for example), but you
might find it useful for experimentation purposes if you want to change, for example, the PRF hash
function or allow null cipher specs.
________________________________________
From: tls-bounces <at> ietf.org [tls-bounces <at> ietf.org] On Behalf Of Xuelei Fan [Xuelei.Fan <at> oracle.com]
Sent: Monday, January 31, 2011 10:38 PM
To: Paul Hoffman
Cc: tls <at> ietf.org
Subject: Re: [TLS] TLS 1.2 test clients?

The recent JDK 7 snapshot releases support TLS 1.2 (see
http://download.java.net/jdk7/). You're able to get and run the very
simple sample code for simple HTTPS connections from
http://download.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#HTTPSSample.

If you run Java with "-Djavax.net.debug=all -Dhttps.protocols=TLSv1.2"
options, you would be able to find the detailed debugging log for
TLS/SSL handshaking.

About the detained tech guides, please refer to
http://download.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html.

Xuelei Fan
(Continue reading)

Permalink | Reply | 0 comments |
headers
t.petch | 1 Feb 2011 15:50

Re: IANA considerations I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt

----- Original Message -----
From: "Michael Tüxen" <Michael.Tuexen <at> lurchi.franken.de>
To: "t.petch" <ietfc <at> btconnect.com>
Cc: <tls <at> ietf.org>
Sent: Tuesday, February 01, 2011 2:37 PM
> On Feb 1, 2011, at 10:28 AM, t.petch wrote:
>
> > Michael
> >
> > I think that the IANA considerations could do with more work.
> >
> > Dropping 'Heartbeat Modes' and 'Heartbeat Message Types'
> > into the IANA website could cause them to be lost for ever.  If they are
> > specific  to (D)TLS, then I would want to see that in the title, or else
> > have them subordinate to something that does.
>
> We can name them "DTLS and TLS Heartbeat Modes" and
> "DTLS and TLS Heartbeat Message Types" or "(D)TLS Heartbeat Modes"
> and "(D)TLS Heartbeat Message Types", whatever you prefer. Any opinion?

I would go for just TLS Heartbeat Modes, and TLS Heartbeat Message Types.

DTLS is a delta to TLS and there is a statement that everything is expected to
carry across unless otherwise stated, so for me, TLS implies DTLS.

Tom Petch

> >
> > Second, while I like starting with values with one, you leave zero
> > open for the next person to use!  I would suggest reserving
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Tüxen | 1 Feb 2011 21:20
Picon

Re: I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt

On Feb 1, 2011, at 3:31 PM, Sean Turner wrote:

> On 2/1/11 4:23 AM, t.petch wrote:
>> ----- Original Message -----
>> From: "Michael Tüxen"<Michael.Tuexen <at> lurchi.franken.de>
>> To: "Florian Weimer"<fweimer <at> bfk.de>
>> Cc:<tls <at> ietf.org>
>> Sent: Thursday, January 27, 2011 2:49 PM
>> 
>> On Jan 27, 2011, at 2:00 PM, Florian Weimer wrote:
>> 
>>>> This document describes the Heartbeat Extension for the Transport
>>>> Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
>>>> protocol.
>>> 
>>> I think this paragraph
>>> 
>>> | There MUST NOT be more than one HeartbeatRequest message in flight
>>> | at a time.
>>> 
>>> should be changed to:
>>> 
>>> | Retransmissions MUST use the same payload as the original
>>> | HeartbeatRequest message.
>> The intention of the sentence in the ID is that you can not send
>> multiple HeartbeatRequest out. This could overload the network since
>> DTLS uses transport layers which do not necessary provide a congestion
>> control. That is why you can only have one request in flight.
>> Please note that it is not in flight anymore if the corresponding
>> HeartbeatReply has been received or the retransmission timer fires.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nikos Mavrogiannopoulos | 3 Feb 2011 23:12

Using OpenPGP Keys for Transport Layer Security (TLS) Authentication

FYI.

> A new Request for Comments is now available in online RFC libraries.
> 
> 
> RFC 6091
> 
> Title:      Using OpenPGP Keys for Transport
> Layer Security (TLS) Authentication
> Author:     N. Mavrogiannopoulos, D. Gillmor
> Status:     Informational
> Stream:     IETF
> Date:       February 2011
> Mailbox:    nikos.mavrogiannopoulos <at> esat.kuleuven.be,
> dkg <at> fifthhorseman.net
> Pages:      9
> Characters: 18529
> Obsoletes:  RFC5081
> 
> I-D Tag:    draft-mavrogiannopoulos-rfc5081bis-09.txt
> 
> URL:        http://www.rfc-editor.org/rfc/rfc6091.txt
> 
> This memo defines Transport Layer Security (TLS) extensions and
> associated semantics that allow clients and servers to negotiate the
> use of OpenPGP certificates for a TLS session, and specifies how to
> transport OpenPGP certificates via TLS.  It also defines the registry
> for non-X.509 certificate types.  This document is not an Internet
> Standards Track specification; it is published for informational purposes.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Satoru Kanno | 4 Feb 2011 10:25
Picon

Request for review: Camellia cipher suites for TLS

Folks,

I've submitted "draft-kanno-tls-camellia-00".
 URL: http://www.ietf.org/internet-drafts/draft-kanno-tls-camellia-00.txt

We merged three drafts into one draft. We included all additional cipher
suites in a single draft to make it easier on implementers.
But the cipher suites with SHA-1 are not included in this draft.

Existing three drafts:
 - draft-kanno-tls-camellia-ecc-sha
 - draft-kanno-tls-camellia-psk
 - draft-kanno-tls-camellia-gcm

New draft includes features as a following:
 - SHA2 variants
 - ECDH(E) and ECDSA
 - Galois/Counter Mode
 - Pre-shared key

Comments about our document would be welcome.

We plan to make this draft to next step 'Publication Request'
within two weeks.

Regards,

----------------------------------------------------------------
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
(Continue reading)

Permalink | Reply | 2 comments |

Gmane