headers
Mike | 1 Jan 2007 02:11
Picon
Favicon

Re: TLS1.2: focus on non X.509 certs, cert URLs, authoirzation spaces, registration practices

> In TLS 1.1 however, we suddenly get constrained in 2006 re the encoding 
> of the DNs. The field has to
> be DER encoded, now. In SSL and TLS1.0 it was an opaque type (I.e. the 
> format/encoding is defined
> by the ClientCertificateType). (Tell Peter DER, and he assumes he has to 
> type check it, now, as DER,
> raising an exception if it fails the encoding rules for each attribute 
> type's value; this is a lot of code!)

I don't think you need to validate the DER encoding (or not) of the
distinguished names.  Just compare them to your own and if you find
a match, it must be DER encoded.  If you don't find a match, maybe
it wasn't DER encoded, or maybe your DN isn't supported.  Either way
you know what to do.

Mike
Permalink | Reply | 1 comment |
headers
home_pw | 1 Jan 2007 03:49
Picon
Favicon
Gravatar

Re: TLS1.2: focus on non X.509 certs, cert URLs, authoirzationspaces, registration practices

I agree; that's very practical and simple. The declaration is also opaque. 
So, what you say is what one SHOULD do, using formal reasoning, too. Its not 
the problem of the protocol state machine; its FOR a message/value handling 
module to deal with. The protocol machine is NOT ALLOWED to interpret an 
opaque byte.

The certificates in the traditional messages can still be BER, as far as I 
can tell. But, again, they are opaques. Most if not all the other recent 
imports of ASN.1 into the standard are required to be DER on the wire.

Once CA certs and trust anchors etc are cached, presumably upon signature 
verification (which necessarily includes DER recoding), the index of the 
cache can be a suitably hashed-DER-form of the issuerDN, for
efficient search.

--------------

There is an interesting legal side-argument there, for TLS Evidence. If the 
SSL Record Layer
is signing handshakes, it necessarily is signing uninterpreted bytes, vs 
signing "information".

it would be funny if when pinging the whitehouse.gov SSL server, one could 
be getting the formal
record in the national archives to have a digitally signed rendition of 
"long live Sadaam's stockpile; good riddance to Pinochet & torture" etc etc, 
as present in the uninterpreted data. One could be disclosing one's patent 
idea, in the cert fields, more usefully. Its going to get signed and data 
retained, even before the https application gets to decode it as syntactic 
rubbish. Stick your social security number in it, claim it as PII, add a
(Continue reading)

Permalink | Reply | 0 comments |
headers
home_pw | 1 Jan 2007 05:03
Picon
Favicon
Gravatar

CRLFs and comments

Well I finally got my beta software to be IETF friendly, not
that there is much left for me to say: I think I'm through
for all that's worth commenting on. At send, the beta
software finally now word wraps at 76 char in rich text's
plain alternative if the encoding is set to none, vs the
default (quoted-printable). If one selects plain as the base
option (vs richtext) the encoding is indeed none, and
therefore it should re-format this note at <65 char word
wrap, 7bit clean, and CRLF line endings.

I don't believe Grandma would have figured all this, tho!
Perhaps the usability rules ought to move up a generation.
My 70 year old boss loves telling me about 75baud acoustic
coupled, rotor keyed, dialup devices he installed
nationwide. He doesn't force me to use them tho!
Permalink | Reply | 0 comments |
headers
Ben Laurie | 1 Jan 2007 12:07
Picon
Favicon

Re: sending error alerts: MUST? SHOULD? MAY?

On 12/31/06, Nelson B Bolyard <nelson <at> bolyard.com> wrote:
> Last August, I wrote to this list about the lack of "MUST" in the RFCs and
> drafts concerning the use of error and warning alerts.  That message is
> quoted below.  I only got one reply, from Peter Gutmann.
>
> I really want to see this situation get fixed in TLS 1.2.  What can I do
> to make that happen?  Do I need to submit a draft with the suggested changes?
> Erik, if I send you a set of suggested changes as edits to the current 1.2
> draft, will you incorporate them?

If you're going to make errors MUSTs you need to do so carefully,
since information leakage through alerts has been the basis of several
attacks on SSL/TLS.

> OBTW, the "newer implementation" that nevre sends error alerts has been
> released since I wrote that first message.  Can you guess what it is?
>
> Nelson B Bolyard wrote:
> > The existing TLS RFCs and IDs don't say that an implementation MUST send
> > any error alerts.
> >
> > There's lots of "will", "should", "may", but not nearly enough "MUST"
> > (IMO) regarding error alerts (whether fatal or not).
> >
> >
> > Consequently, one of the newer implementations (which I won't name here),
> > one with which I've been doing interoperability testing, simply NEVER sends
> > error alerts.  When any problem occurs, it silently closes the connection
> > without offering any clues to the peer about why it has done so.  The
> > developer's explanation to me for the implementation's behavior was simple:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kyle Hamilton | 1 Jan 2007 14:57
Picon

Re: sending error alerts: MUST? SHOULD? MAY?

I think that probably the only "MUST" that should be in place is "if
there is an error, a fatal error MUST be sent".  I'd also go so far as
to suggest that "protocol_error" be the generic one that must be sent
if the implementation wishes not to leak any information at all.  (the
remote is an untrusted entity in the grand scheme of things... I
wouldn't listen if it said I was speaking improperly anyway.)

-Kyle H

On 1/1/07, Ben Laurie <benl <at> google.com> wrote:
> On 12/31/06, Nelson B Bolyard <nelson <at> bolyard.com> wrote:
> > Last August, I wrote to this list about the lack of "MUST" in the RFCs and
> > drafts concerning the use of error and warning alerts.  That message is
> > quoted below.  I only got one reply, from Peter Gutmann.
> >
> > I really want to see this situation get fixed in TLS 1.2.  What can I do
> > to make that happen?  Do I need to submit a draft with the suggested changes?
> > Erik, if I send you a set of suggested changes as edits to the current 1.2
> > draft, will you incorporate them?
>
> If you're going to make errors MUSTs you need to do so carefully,
> since information leakage through alerts has been the basis of several
> attacks on SSL/TLS.
>
> > OBTW, the "newer implementation" that nevre sends error alerts has been
> > released since I wrote that first message.  Can you guess what it is?
> >
> > Nelson B Bolyard wrote:
> > > The existing TLS RFCs and IDs don't say that an implementation MUST send
> > > any error alerts.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pasi.Eronen | 1 Jan 2007 15:39
Picon

RE: Re: WGLC: draft-ietf-tls-srp-13

Simon Josefsson wrote:

> The document seems fine, but the intended status bothers me.  Changing
> the cipher suite numbers because the document now targets experimental
> status will disrupt deployed implementations and harms adoption of the
> protocol.  Also, for this particular protocol, I believe its already
> wide deployment suggests that PS is the appropriate choice.

Note that all deployed implementation will be disrupted anyway, since 
they use  extension number 6, which has been already allocated for 
RFC 4681.

Best regards,
Pasi
Permalink | Reply | 4 comments |
headers
Whyte, William | 2 Jan 2007 11:54

RE: sending error alerts: MUST? SHOULD? MAY?

When I open this mail, or any of the replies to it, in Outlook:
* Outlook goes up to taking up 95% of my CPU time
* Outlook's memory requirements go up from 50(ish) MB to 190(ish)
* Outlook, unsurprisingly, becomes unresponsive and has to be shut
  down from the Task Manager.
 
Is anyone else experiencing this?
 
William

From: Nelson B Bolyard [mailto:nelson <at> bolyard.com]
Sent: Sun 12/31/2006 6:13 PM
To: tls <at> ietf.org
Subject: Re: [TLS] sending error alerts: MUST? SHOULD? MAY?

Last August, I wrote to this list about the lack of "MUST" in the RFCs and
drafts concerning the use of error and warning alerts.  That message is
quoted below.  I only got one reply, from Peter Gutmann.

I really want to see this situation get fixed in TLS 1.2.  What can I do
to make that happen?  Do I need to submit a draft with the suggested changes?
Erik, if I send you a set of suggested changes as edits to the current 1.2
draft, will you incorporate them?

OBTW, the "newer implementation" that nevre sends error alerts has been
released since I wrote that first message.  Can you guess what it is?

Nelson B Bolyard wrote:
> The existing TLS RFCs and IDs don't say that an implementation MUST send
> any error alerts.
>
> There's lots of "will", "should", "may", but not nearly enough "MUST"
> (IMO) regarding error alerts (whether fatal or not).
>
>
> Consequently, one of the newer implementations (which I won't name here),
> one with which I've been doing interoperability testing, simply NEVER sends
> error alerts.  When any problem occurs, it silently closes the connection
> without offering any clues to the peer about why it has done so.  The
> developer's explanation to me for the implementation's behavior was simple:
> the RFCs do not require that error alerts be sent.  Sending error alerts is
> simply not a MUST.  Doing so is implicitly a MAY, at most.
>
> I think this is going to be a nightmare for trouble shooting.  When a peer
> system drops a TLS connection, we're going to have to rely on the ability
> of the user or administrator who runs that peer to determine why it did so,
> rather than relying on alerts.
>
> So, I put the question to the TLS WG:  Is there consensus that the RFC
> language should be strengthened in the next version (e.g. rfc4346-bis)
> to say that the error alerts MUST be sent, and when?
>
>
> A survey of error alert discussion in the first 40-some pages of the draft.
>
> Regarding close notify alerts, the existing RFC and drafts say that "each
> party is required to" (why not MUST?) send a close_notify alert if no error
> condition has occurred and that upon receiving a close-notify alert, the
> peer MUST send one in respnse.  So, close_notify alerts will get sent,
> but not error alerts.
>
> The latest draft says that when an error alert is sent or received, the
> session MUST be invalidated, but doesn't require that it be sent.
>
> The draft says:
>    "When an error is detected, the detecting party sends a
>     message to the other party."
> I think that should be MUST SEND, but as written it's not a MUST.
>
> There are some "SHOULD"s in the current draft rfc4346-bis:
>    "The receiver MUST check this padding and SHOULD use the
>     bad_record_mac alert to indicate padding errors."
>
> I think this was intended to be understood as "MUST check, MUST send an
> alert to indicate errors, and SHOULD use bad_record_mac alert when
> appropriate".  But as written, it clearly makes sending any alert at all
> at most a SHOULD for bad macs.
>
> no_renegotiation is a should, (and a MUST NOT) but never a SHOULD nor a
> MUST.  certificate_unobtainable is a MAY.
>
> The text for client_hello says
>    "The server will select a cipher suite or, if no acceptable choices are
>     presented, return a handshake failure alert and close the connection."
> No MUST in there.
>
> The alerts on page 30 MUST NOT be sent except when the client used a
> hello extension.  But there is no time when they MUST be used.
>
> In the current draft, I did find a few MUSTs.
>
> Page 37 has an inferred "will":
>    The server will select a cipher suite or, if no acceptable choices are
>    presented, return a handshake failure alert and close the connection.
>
> page 39 has a MUST:
>    "... if not then it MUST send a fatal "decode_error" alert."
>
> section 7.4.1.3 says: "it will respond with a handshake failure alert."
>     no MUST there.
>
> I found two MUSTS in 7.4.1.4.2 on page 44.  Also a SHALL (isn't that
> supposed to be a MUST?)
>
> I'll stop there without reviewing every weak description of an error alert.
> Let's please have more MUSTs.
>


--
Nelson B
12345678901234567890123456789012345678901234567890123456789012345678901234567890
00000000011111111112222222222333333333344444444445555555555666666666677777777778

_______________________________________________
TLS mailing list
TLS <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls
Permalink | Reply | 1 comment |
headers
Whyte, William | 2 Jan 2007 12:25

RE: sending error alerts: MUST? SHOULD? MAY?

It turns out to be something to do with the Skype toolbar trying to convert
Nelson's
 
12345678901234567890123456789012345678901234567890123456789012345678901234567890
00000000011111111112222222222333333333344444444445555555555666666666677777777778
into a phone number. (I got similar behavior when I looked at Nelson's
in Firefox, where I also have the Skype toolbar installed). Nice one, Skype!
 
William

From: Whyte, William [mailto:WWhyte <at> ntru.com]
Sent: Tue 1/2/2007 5:54 AM
To: Nelson B Bolyard; tls <at> ietf.org
Subject: RE: [TLS] sending error alerts: MUST? SHOULD? MAY?

When I open this mail, or any of the replies to it, in Outlook:
* Outlook goes up to taking up 95% of my CPU time
* Outlook's memory requirements go up from 50(ish) MB to 190(ish)
* Outlook, unsurprisingly, becomes unresponsive and has to be shut
  down from the Task Manager.
 
Is anyone else experiencing this?
 
William

From: Nelson B Bolyard [mailto:nelson <at> bolyard.com]
Sent: Sun 12/31/2006 6:13 PM
To: tls <at> ietf.org
Subject: Re: [TLS] sending error alerts: MUST? SHOULD? MAY?

Last August, I wrote to this list about the lack of "MUST" in the RFCs and
drafts concerning the use of error and warning alerts.  That message is
quoted below.  I only got one reply, from Peter Gutmann.

I really want to see this situation get fixed in TLS 1.2.  What can I do
to make that happen?  Do I need to submit a draft with the suggested changes?
Erik, if I send you a set of suggested changes as edits to the current 1.2
draft, will you incorporate them?

OBTW, the "newer implementation" that nevre sends error alerts has been
released since I wrote that first message.  Can you guess what it is?

Nelson B Bolyard wrote:
> The existing TLS RFCs and IDs don't say that an implementation MUST send
> any error alerts.
>
> There's lots of "will", "should", "may", but not nearly enough "MUST"
> (IMO) regarding error alerts (whether fatal or not).
>
>
> Consequently, one of the newer implementations (which I won't name here),
> one with which I've been doing interoperability testing, simply NEVER sends
> error alerts.  When any problem occurs, it silently closes the connection
> without offering any clues to the peer about why it has done so.  The
> developer's explanation to me for the implementation's behavior was simple:
> the RFCs do not require that error alerts be sent.  Sending error alerts is
> simply not a MUST.  Doing so is implicitly a MAY, at most.
>
> I think this is going to be a nightmare for trouble shooting.  When a peer
> system drops a TLS connection, we're going to have to rely on the ability
> of the user or administrator who runs that peer to determine why it did so,
> rather than relying on alerts.
>
> So, I put the question to the TLS WG:  Is there consensus that the RFC
> language should be strengthened in the next version (e.g. rfc4346-bis)
> to say that the error alerts MUST be sent, and when?
>
>
> A survey of error alert discussion in the first 40-some pages of the draft.
>
> Regarding close notify alerts, the existing RFC and drafts say that "each
> party is required to" (why not MUST?) send a close_notify alert if no error
> condition has occurred and that upon receiving a close-notify alert, the
> peer MUST send one in respnse.  So, close_notify alerts will get sent,
> but not error alerts.
>
> The latest draft says that when an error alert is sent or received, the
> session MUST be invalidated, but doesn't require that it be sent.
>
> The draft says:
>    "When an error is detected, the detecting party sends a
>     message to the other party."
> I think that should be MUST SEND, but as written it's not a MUST.
>
> There are some "SHOULD"s in the current draft rfc4346-bis:
>    "The receiver MUST check this padding and SHOULD use the
>     bad_record_mac alert to indicate padding errors."
>
> I think this was intended to be understood as "MUST check, MUST send an
> alert to indicate errors, and SHOULD use bad_record_mac alert when
> appropriate".  But as written, it clearly makes sending any alert at all
> at most a SHOULD for bad macs.
>
> no_renegotiation is a should, (and a MUST NOT) but never a SHOULD nor a
> MUST.  certificate_unobtainable is a MAY.
>
> The text for client_hello says
>    "The server will select a cipher suite or, if no acceptable choices are
>     presented, return a handshake failure alert and close the connection."
> No MUST in there.
>
> The alerts on page 30 MUST NOT be sent except when the client used a
> hello extension.  But there is no time when they MUST be used.
>
> In the current draft, I did find a few MUSTs.
>
> Page 37 has an inferred "will":
>    The server will select a cipher suite or, if no acceptable choices are
>    presented, return a handshake failure alert and close the connection.
>
> page 39 has a MUST:
>    "... if not then it MUST send a fatal "decode_error" alert."
>
> section 7.4.1.3 says: "it will respond with a handshake failure alert."
>     no MUST there.
>
> I found two MUSTS in 7.4.1.4.2 on page 44.  Also a SHALL (isn't that
> supposed to be a MUST?)
>
> I'll stop there without reviewing every weak description of an error alert.
> Let's please have more MUSTs.
>


--
Nelson B
12345678901234567890123456789012345678901234567890123456789012345678901234567890
00000000011111111112222222222333333333344444444445555555555666666666677777777778

_______________________________________________
TLS mailing list
TLS <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls
Permalink | Reply | 0 comments |
headers
Martin Rex | 2 Jan 2007 17:31
Picon
Favicon

Re: TLS1.2: focus on non X.509 certs, cert URLs,

home_pw <at> msn.com wrote:
> 
> Concerning 7.4.5. Certificate request
> 
>            "A list of the distinguished names of acceptable certificate
>            authorities. These distinguished names may specify a desired
>            distinguished name for a root CA or for a subordinate CA;
>            thus, this message can be used both to describe known roots
>            and a desired authorization space. If the
>            certificate_authorities list is empty then the client MAY
>            send any certificate of the appropriate
>            ClientCertificateType, unless there is some external
>            arrangement to the contrary."
> 
> 
> So, what does this all really mean,
> just staying within the traditional PKI world?

This is *NOT* about PKI.
It is about X.509 certificates and certificate chains.

It means that the client should search his credentials and see
whether there is a match between one of the CAs from that list
of the Server and the issuer field of the certificate of
the clients credentials (itself, or of (one) of its chain(s)).

If there's at least one match, the client can use that credentials
for client authentication, including the certification path up
to at least the matching CA from the servers list.

X.509 certs must be DER-encoded, and there MUST be a binary/opaque
match of the CA name sent by the server with the issuer name in
the clients (end-entity or path) certificate, therefore all
the DNames in that list must be DER-encoded (or will likely not
match issuer names - except for broken CAs issuing defective certs
with non-DER encoded issuer names).

-Martin
Permalink | Reply | 501 comments |
headers
Ali Fessi | 3 Jan 2007 18:32
Picon

Key exchange with DH_RSA

Hi all,

The TLS specification says (RFC4346 - Section 7.4.3. "Server Key 
Exchange Message")

"It is not legal to send the server key exchange message for the
following key exchange methods:

      RSA
      DH_DSS
      DH_RSA"

But in case of *DH_RSA*, how can the DH exchange be completed if the 
client does not receive any DH value from the server in the "Server Key 
Exchange Message", nor does the certificate in the "Server Certificate" 
message include any helpful information to complete the DH exchange 
(since the public key of the certificate is an RSA public key)?

In other words: how can a *non-ephemeral* DH be achieved, if the 
server's certificate key type is RSA?

Thanks in advance!

  Ali

--

-- 
Ali Fessi
Computer Networks and Internet
Wilhelm Schickard Institute for Computer Science
University of Tuebingen, Germany
Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220
EMail: ali.fessi <at> uni-tuebingen.de
Web: http://net.informatik.uni-tuebingen.de/~fessi/
Permalink | Reply | 1 comment |

Gmane