Vipul Gupta | 1 May 21:39 2006
Picon

AUTH48, RFC 4492 <draft-ietf-tls-ecc-12.txt> NOW AVAILABLE

We are in the AUTH48 stage with draft-ietf-tls-ecc-12.txt.
The pre-release version of the RFC 4492 is currently available
at:

ftp://ftp.rfc-editor.org/in-notes/authors/rfc4492.txt

The coauthors would like to update the table in
Appendix A in response to a new release of X9.62. The
suggested change is in the attached email -- it adds a new column
for X9.62-2005 and lists aliases that spec defines for
18 of the 25 curves in the draft. This change has no material
impact on the specification and is purely informative --
intended to help implementers sort out different names
used by NIST, ANSI and SECG for the same curves.

If there are good reasons to not include this change, please
let us know as soon as possible. We'd like to come to a final
decision (either include or leave out the new column) later
this week.

thank you,

vipul

Begin forwarded message:

> From: Eric Rescorla <ekr <at> networkresonance.com>
> Date: May 1, 2006 12:11:47 PM PDT
> To: Vipul Gupta <Vipul.Gupta <at> sun.com>
> Cc: Alice Hagens <hagens <at> ISI.EDU>, "Nelson B. Bolyard"  
(Continue reading)

Bob Relyea | 2 May 20:28 2006
Picon

RFC 4346 - TLS 1.2

The TLS 1.2 spec attempts to define more flexibility in the choice of 
hashing, and does fix a number of problems in 1.1 when wanting to use 
hash functions other than SHA-1 and MD5, however there appears to be 
wording left over from the 1.1 spec that seems to contradict this goal. 
Shouldn't this wording be removed or changes, or was it left in 
intentionally:

Section 5 ... second paragraph:

HMAC can be used with a variety of different hash algorithms. TLS
uses it in the handshake with two different algorithms: MD5 and
SHA-1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret,
data). Additional hash algorithms can be defined by cipher suites and
used to protect record data, but MD5 and SHA-1 are hard coded into
the description of the handshaking for this version of the protocol.

Shouldn't the 'hard coded' wording be removed, or does TLS 1.2 initially
expect to continue to use MD5
and SHA-1 for the handshaking?

Thanks,

bob

Attachment (smime.p7s): application/x-pkcs7-signature, 4700 bytes
_______________________________________________
TLS mailing list
TLS <at> lists.ietf.org
(Continue reading)

Eric Rescorla | 2 May 20:33 2006

Re: RFC 4346 - TLS 1.2

Bob Relyea <rrelyea <at> redhat.com> writes:

> The TLS 1.2 spec attempts to define more flexibility in the choice of
> hashing, and does fix a number of problems in 1.1 when wanting to use
> hash functions other than SHA-1 and MD5, however there appears to be
> wording left over from the 1.1 spec that seems to contradict this
> goal. Shouldn't this wording be removed or changes, or was it left in
> intentionally:

It's a bug.

-Ekr
Stephen Corcoran | 3 May 12:33 2006

Certificate Unknown

Hi All,

 

When I run ethereal trace on our ssl port 443 we receive the following TLS alert over an over .

 

Our platform - 172.24.52.4

 

The  address 193.113.37.7  is a proxy server.

 

How do I stop the  “ TLS Alert (Level: Fatal, Description: Certificate Unknown) “ warning ?

 

Any help much appreciated

 

 

tethereal -R "tcp.port == 443"   

 

3.415589 193.113.37.7 -> 172.24.52.4  SSLv2 Client Hello

  3.416193  172.24.52.4 -> 193.113.37.7 TLS Server Hello, Certificate, Server Hello Done

  3.433146 193.113.37.7 -> 172.24.52.4  TCP 33136 > 443 [ACK] Seq=101 Ack=1274 Win=24820 Len=0

  3.455153 193.113.48.7 -> 172.24.52.4  TCP 51983 > 443 [SYN] Seq=0 Ack=0 Win=24820 Len=0 MSS=1460

  3.455433  172.24.52.4 -> 193.113.48.7 TCP 443 > 51983 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=1460

  3.459320 193.113.37.7 -> 172.24.52.4  TLS Alert (Level: Fatal, Description: Certificate Unknown)

  3.459727  172.24.52.4 -> 193.113.37.7 TCP 443 > 33136 [FIN, ACK] Seq=1274 Ack=108 Win=32768 Len=0

  3.463295 193.113.48.7 -> 172.24.52.4  TCP 51983 > 443 [ACK] Seq=1 Ack=1 Win=24820 Len=0

  3.472032 193.113.37.7 -> 172.24.52.4  TCP 33136 > 443 [ACK] Seq=108 Ack=1275 Win=24820 Len=0

  3.472293 193.113.37.7 -> 172.24.52.4  TCP 33136 > 443 [FIN, ACK] Seq=108 Ack=1275 Win=24820 Len=0

  3.472385  172.24.52.4 -> 193.113.37.7 TCP 443 > 33136 [ACK] Seq=1275 Ack=109 Win=32768 Len=0

  3.483303 193.113.48.7 -> 172.24.52.4  SSLv2 Client Hello

  3.483813  172.24.52.4 -> 193.113.48.7 TLS Server Hello, Certificate, Server Hello Done

  3.494287 193.113.37.7 -> 172.24.52.4  TCP 33150 > 443 [SYN] Seq=0 Ack=0 Win=24820 Len=0 MSS=1460

  3.494564  172.24.52.4 -> 193.113.37.7 TCP 443 > 33150 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=1460

  3.499953 193.113.48.7 -> 172.24.52.4  TCP 51983 > 443 [ACK] Seq=101 Ack=1274 Win=24820 Len=0

  3.503798 193.113.37.7 -> 172.24.52.4  TCP 33150 > 443 [ACK] Seq=1 Ack=1 Win=24820 Len=0

  3.524528 193.113.48.7 -> 172.24.52.4  TLS Alert (Level: Fatal, Description: Certificate Unknown)

  3.524914  172.24.52.4 -> 193.113.48.7 TCP 443 > 51983 [FIN, ACK] Seq=1274 Ack=108 Win=32768 Len=0

  3.533605 193.113.37.7 -> 172.24.52.4  SSLv2 Client Hello

  3.534025 193.113.48.7 -> 172.24.52.4  TCP 51983 > 443 [ACK] Seq=108 Ack=1275 Win=24820 Len=0

  3.534343  172.24.52.4 -> 193.113.37.7 TLS Server Hello, Certificate, Server Hello Done

  3.542732 193.113.48.7 -> 172.24.52.4  TCP 51983 > 443 [FIN, ACK] Seq=108 Ack=1275 Win=24820 Len=0

  3.542829  172.24.52.4 -> 193.113.48.7 TCP 443 > 51983 [ACK] Seq=1275 Ack=109 Win=32768 Len=0

  3.549016 193.113.48.7 -> 172.24.52.4  TCP 51999 > 443 [SYN] Seq=0 Ack=0 Win=24820 Len=0 MSS=1460

  3.549284  172.24.52.4 -> 193.113.48.7 TCP 443 > 51999 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=1460

  3.551178 193.113.37.7 -> 172.24.52.4  TCP 33150 > 443 [ACK] Seq=101 Ack=1274 Win=24820 Len=0

  3.557709 193.113.48.7 -> 172.24.52.4  TCP 51999 > 443 [ACK] Seq=1 Ack=1 Win=24820 Len=0

  3.576305 193.113.48.7 -> 172.24.52.4  SSLv2 Client Hello

  3.576801  172.24.52.4 -> 193.113.48.7 TLS Server Hello, Certificate, Server Hello Done

  3.579662 193.113.37.7 -> 172.24.52.4  TLS Alert (Level: Fatal, Description: Certificate Unknown)

  3.580041  172.24.52.4 -> 193.113.37.7 TCP 443 > 33150 [FIN, ACK] Seq=1274 Ack=108 Win=32768 Len=0

  3.593021 193.113.48.7 -> 172.24.52.4  TCP 51999 > 443 [ACK] Seq=101 Ack=1274 Win=24820 Len=0

  3.593379 193.113.37.7 -> 172.24.52.4  TCP 33150 > 443 [ACK] Seq=108 Ack=1275 Win=24820 Len=0

  3.594083 193.113.37.7 -> 172.24.52.4  TCP 33150 > 443 [FIN, ACK] Seq=108 Ack=1275 Win=24820 Len=0

  3.594186  172.24.52.4 -> 193.113.37.7 TCP 443 > 33150 [ACK] Seq=1275 Ack=109 Win=32768 Len=0

  3.612595 193.113.48.7 -> 172.24.52.4  TLS Alert (Level: Fatal, Description: Certificate Unknown)

  3.612999  172.24.52.4 -> 193.113.48.7 TCP 443 > 51999 [FIN, ACK] Seq=1274 Ack=108 Win=32768 Len=0

  3.621631 193.113.48.7 -> 172.24.52.4  TCP 51999 > 443 [ACK] Seq=108 Ack=1275 Win=24820 Len=0

  3.621906 193.113.48.7 -> 172.24.52.4  TCP 51999 > 443 [FIN, ACK] Seq=108 Ack=1275 Win=24820 Len=0

  3.621999  172.24.52.4 -> 193.113.48.7 TCP 443 > 51999 [ACK] Seq=1275 Ack=109 Win=32768 Len=0

  3.638459 193.113.48.7 -> 172.24.52.4  TCP 52013 > 443 [SYN] Seq=0 Ack=0 Win=24820 Len=0 MSS=1460

  3.638745  172.24.52.4 -> 193.113.48.7 TCP 443 > 52013 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=1460

  3.646542 193.113.48.7 -> 172.24.52.4  TCP 52013 > 443 [ACK] Seq=1 Ack=1 Win=24820 Len=0

  3.668297 193.113.48.7 -> 172.24.52.4  SSLv2 Client Hello

  3.668821  172.24.52.4 -> 193.113.48.7 TLS Server Hello, Certificate, Server Hello Done

  3.684799 193.113.48.7 -> 172.24.52.4  TCP 52013 > 443 [ACK] Seq=101 Ack=1274 Win=24820 Len=0

  3.702860 193.113.48.7 -> 172.24.52.4  TLS Alert (Level: Fatal, Description: Certificate Unknown)

  3.703250  172.24.52.4 -> 193.113.48.7 TCP 443 > 52013 [FIN, ACK] Seq=1274 Ack=108 Win=32768 Len=0

  3.712084 193.113.48.7 -> 172.24.52.4  TCP 52013 > 443 [ACK] Seq=108 Ack=1275 Win=24820 Len=0

  3.712346 193.113.48.7 -> 172.24.52.4  TCP 52013 > 443 [FIN, ACK] Seq=108 Ack=1275 Win=24820 Len=0

  3.712439  172.24.52.4 -> 193.113.48.7 TCP 443 > 52013 [ACK] Seq=1275 Ack=109 Win=32768 Len=0

 

Kind Regards

Steve

_______________________________________________
TLS mailing list
TLS <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls
Pasi.Eronen | 5 May 12:15 2006
Picon

WG last call on draft-ietf-tls-openpgp-keys-08

This message starts a TLS WG last call on "Using OpenPGP keys for TLS
authentication" (draft-ietf-tls-openpgp-keys-08), prior to sending the
document to the IESG for consideration as Experimental. 

Please send your comments to the WG mailing list by Sunday May 21st.
Comments along the lines "I've read it and it looks OK" are helpful
and encouraged.

Best regards,
Pasi & Eric
Simon Josefsson | 5 May 12:28 2006

Re: WG last call on draft-ietf-tls-openpgp-keys-08

<Pasi.Eronen <at> nokia.com> writes:

> This message starts a TLS WG last call on "Using OpenPGP keys for TLS
> authentication" (draft-ietf-tls-openpgp-keys-08), prior to sending the
> document to the IESG for consideration as Experimental. 
>
> Please send your comments to the WG mailing list by Sunday May 21st.
> Comments along the lines "I've read it and it looks OK" are helpful
> and encouraged.

I've read it and it looks OK.

/Simon
Systemadministration | 9 May 16:00 2006
Picon

STARTTLS sendmail Errors


Sollten Sie noch weitere Fragen haben, stehe ich Ihnen natürlich gerne 
jederzeit zur Verfügung.

Mit freundlichen Grüßen

Thomas Bennek
Systemadministrator
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Billhöfer Maschinenfabrik GmbH & Co. KG
Gutenstetter Strasse 20
90449 Nuremberg

phone: 	+ 49 911 65785-208
fax:    + 49 911 65785 -50
www:   	http://www.billhoefer.com
mail:   bennek <at> billhoefer.de
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hello to all!

I?m new to this list, and I had a question about a lot of errors with
starttls in my log. My E-Mail communication seems not to be affected,
but it is really unattractive.

The error - messages look like these

Apr 26 17:11:52 mail2 sendmail[19576]: STARTTLS=client, start=ok
Apr 26 17:11:52 mail2 sendmail[19576]: STARTTLS=client, info: fds=9/8, err=2
Apr 26 17:11:53 mail2 sendmail[19572]: STARTTLS=write, info: fds=9/8, err=3
Apr 26 17:11:53 mail2 sendmail[19576]: STARTTLS=client, info: fds=9/8, err=2
Apr 26 17:11:53 mail2 sendmail[19576]: STARTTLS=client, info: fds=9/8, err=2
Apr 26 17:11:53 mail2 sendmail[19572]: STARTTLS=write, info: fds=9/8, err=3
Apr 26 17:11:53 mail2 sendmail[19576]: STARTTLS=client, info: fds=9/8, err=2
Apr 26 17:11:54 mail2 sendmail[19572]: STARTTLS=write, info: fds=9/8, err=3
Apr 26 17:11:54 mail2 sendmail[19576]: STARTTLS=client, info: fds=9/8, err=2
Apr 26 17:11:54 mail2 sendmail[19576]: STARTTLS=client, get_verify: 0
get_peer: 0x8194868

or like this:

May  9 14:21:32 mail2 sm-mta[7461]: STARTTLS=read, info: fds=8/3, err=2

May  9 14:26:10 mail2 sm-mta[7611]: STARTTLS=read, info: fds=8/3, err=2
May  9 14:26:10 mail2 last message repeated 125 times

The numbers behind fds will vary from time to time.

I have no idea from where it will come from - so can anyone give me a
hint about these errors?!

Many thanks

Thomas
Pasi.Eronen | 10 May 19:21 2006
Picon

Review of draft-ietf-tls-openpgp-keys-08


The document looks mostly OK, but I think some details need 
clarification/polishing before we send this to the IESG.

Somewhat substantive comments:

1) Section 3.3: The TLS Certificate message defined in RFC4346 
   contains a list of X.509 certificates, while this section allows
   only a single PGPKey structure. IMHO we should keep this aligned
   with RFC4346, even though usually one key is enough. In other 
   words, something like this:

      struct {
          PGPKeyDescriptorType descriptorType;
          select (descriptorType) {
              case key_fingerprint: opaque fingerprint<16..20>; 
              case key:             opaque key<0..2^24-1>; 
          }
      } PGPCert;

      struct {
          PGPCert certificate_list<0..2^24-1>;
      } Certificate;

2) Section 3.5: "then a Certificate that contains an empty PGPKey
   should be sent": If the change suggested above is made, a 
   Certificate message that contains one zero-length PGPKey is 
   not the same thing as a Certificate message that contains zero 
   certificates (and it's the latter that should be sent).

3) Section 3.4: I don't think there is any need to define a new
   CertificateRequest message (the "certificate_authorities" part
   doesn't make much sense for OpenPGP, but RFC4346 clarified that
   it can be empty; and I believe many TLS 1.0 implementations also
   did this). So I'd suggest rewriting this section as follows:

   "If the certificate request message is sent, and the negotiated
   certificate type is OpenPGP, the certificate_authorities list 
   MUST be empty."

4) I'd suggest moving whole Section 2 to later in the document 
   (e.g., after Security Considerations), renaming it to "IANA
   Considerations", and rewriting it something like this:

   "This document defines a new TLS extension, "cert_type", assigned
   a value of TBD-BY-IANA (the value 7 is suggested) from the TLS
   ExtensionType registry defined in [RFC4366].

   This document establishes a new registry, to be maintained by
   IANA, for TLS certificate types. Initially, the registry contains
   the values 0 (X.509) and 1 (OpenPGP). Values from the range 2-223
   are assigned via IETF Consensus [RFC2434]. Values from the range
   224-255 are reserved for Private Use [RFC2434]."

5) Section 3.1: "...extension SHOULD be omitted if the client only
   supports X.509 certificates" and "Servers that only support X.509
   certificates MAY omit... ": Unnecessary options are a recipe for
   interoperability problems; unless there are good reasons to keep
   these, I'd suggest changing these to MUSTs.

6) Section 4: I'd suggest merging this section (only four lines)
   with Section 3.1. Also, the text should apply to all ciphersuites
   using the RSA/DHE_DSS/DHE_RSA key exchange methods, not just
   those in RFC 2246. (And with this change, the text about
   exportable ciphersuites is no longer necessary.)

Purely editorial comments:

7) Overall: I believe nowadays the RFC Editor recommends using 
   symbolic citations [RFC2119] instead of numeric ones [1].

8) Section 1, 2nd paragraph: extra comma before "provide"

9) Sections 3.6..3.8: I'd suggest removing these.  

10) Section 3.3: "The process of fingerprint generation is described 
   in OpenPGP [2]": I'd suggest adding a more specific pointer:
   Section 11.2 of [RFC2440].

11) Section 6.1: RFC 3546 is obsoleted by RFC 4366.

12) Section 6.1: Should include RFC 2119 and RFC 2434 here.

13) Section 6.2: Reference [5] is never cited in the text (and
   IMHO could be removed)

Best regards,
Pasi
Nikos Mavrogiannopoulos | 11 May 16:42 2006

Re: Review of draft-ietf-tls-openpgp-keys-08

On 5/10/06, Pasi.Eronen <at> nokia.com <Pasi.Eronen <at> nokia.com> wrote:

Hello Pasi,
 Thank you for the comments. I address them below.

> Somewhat substantive comments:
> 1) Section 3.3: The TLS Certificate message defined in RFC4346
>    contains a list of X.509 certificates, while this section allows
>    only a single PGPKey structure. IMHO we should keep this aligned

This was a deliberate change. The rationale behind this change was
that there is no point in sending more than one pgp keys. There is no
notion of certificate chain in openpgp, thus having a list of 
certificates would
confuse on what should be sent.

> 3) Section 3.4: I don't think there is any need to define a new
>    CertificateRequest message (the "certificate_authorities" part
>    doesn't make much sense for OpenPGP, but RFC4346 clarified that
>    it can be empty; and I believe many TLS 1.0 implementations also
>    did this). So I'd suggest rewriting this section as follows:
>    "If the certificate request message is sent, and the negotiated
>    certificate type is OpenPGP, the certificate_authorities list
>    MUST be empty."

I will address this.

> 4) I'd suggest moving whole Section 2 to later in the document
>    (e.g., after Security Considerations), renaming it to "IANA
>    Considerations", and rewriting it something like this:
>    "This document defines a new TLS extension, "cert_type", assigned
>    a value of TBD-BY-IANA (the value 7 is suggested) from the TLS
>    ExtensionType registry defined in [RFC4366].
>    This document establishes a new registry, to be maintained by
>    IANA, for TLS certificate types. Initially, the registry contains
>    the values 0 (X.509) and 1 (OpenPGP). Values from the range 2-223
>    are assigned via IETF Consensus [RFC2434]. Values from the range
>    224-255 are reserved for Private Use [RFC2434]."

Will be addressed.
(I just noticed that in http://www.iana.org/numbers.html there is 
nothing
about the TLS extension numbers. Is restristration possible?)

> 5) Section 3.1: "...extension SHOULD be omitted if the client only
>    supports X.509 certificates" and "Servers that only support X.509
>    certificates MAY omit... ": Unnecessary options are a recipe for
>    interoperability problems; unless there are good reasons to keep
>    these, I'd suggest changing these to MUSTs.

I agree for the first one. But the second is only to address the case 
where
the server doesn't support this extension (thus he doesn't add the
extension reply
to his hello). But I'd expect a server that is aware of this extension
to properly
reply with an extension that indicates that he selected the X509
certificate choice.

> 6) Section 4: I'd suggest merging this section (only four lines)
>    with Section 3.1. Also, the text should apply to all ciphersuites
>    using the RSA/DHE_DSS/DHE_RSA key exchange methods, not just
>    those in RFC 2246. (And with this change, the text about
>    exportable ciphersuites is no longer necessary.)

True. I'll update it.

> 9) Sections 3.6..3.8: I'd suggest removing these.
> 10) Section 3.3: "The process of fingerprint generation is described
>    in OpenPGP [2]": I'd suggest adding a more specific pointer:
>    Section 11.2 of [RFC2440].
> 11) Section 6.1: RFC 3546 is obsoleted by RFC 4366.
> 12) Section 6.1: Should include RFC 2119 and RFC 2434 here.
> 13) Section 6.2: Reference [5] is never cited in the text (and
>    IMHO could be removed)

Thanks I'll try to address the comments in a new draft.
David Hopwood | 12 May 00:48 2006
Picon

Errata for RFC 4346

Section 6:
# See Section 11 for IANA Considerations for ContentType values.

Section 7.2.2:
# See Section 11 for IANA Considerations for alert values.

Section 7.4:
# See Section 11 for IANA Considerations for these values.

Section 7.4.4:
# Additional information describing the role of IANA in the allocation
# of ClientCertificateType code points is described in Section 11.

These references should all be to Section 12.

--

-- 
David Hopwood <david.nospam.hopwood <at> blueyonder.co.uk>

Gmane