headers
Nikos Mavrogiannopoulos | 1 Jun 2012 11:38

Re: Preventing cross-protocol attacks in TLS protocol

On Thu, May 17, 2012 at 9:52 PM, Marsh Ray <marsh <at> extendedsubset.com> wrote:

> I think this is a good robustness improvement to the protocol and may bring
> other benefits. I actually considered including a very similar change in
> draft-ray-encrypted-handshake, but did not do so primarily due to scope.
> However, draft-mavrogiannopoulos-tls-server-key-exchage does not protect
> against the attack described.

I have improved the document to handle the case where both server and
client support the extension but the client does not require it to be
present. This comes at the cost of reducing the server random bytes to
28.

http://www.ietf.org/id/draft-mavrogiannopoulos-tls-cross-protocol-00.txt

regards,
Nikos
Permalink | Reply | 0 comments |
headers
Martin Rex | 1 Jun 2012 17:08
Picon
Favicon

Re: CRL Stapling? (was Re: I-D Action: draft-ietf-tls-multiple-cert-status-extension-00.txt)

Rob Stradling wrote:
> 
> IIRC, when Opera does an online revocation check, it currently checks 
> CRLs for intermediate CA certificates and OCSP for end-entity 
> certificates.  This makes sense because:
>    - CRLs covering intermediate CA certificates tend to be roughly the 
> same size (sometimes smaller!) as the equivalent OCSP Responses (since 
> it's quite rare for intermediate CA certificates to be revoked).
>    - Possessing a current CRL means you won't have to do an online 
> revocation check if you encounter another certificate issued by the same 
> issuer.
>
>   [...]
> 
> How about changing the scope of the multi-stapling I-D so that it *only* 
> covers the intermediate CA certificate(s) in the chain?

This would significantly increase the complexity without adding value.
OCSP responses can be cached just as long as the CRLs on which they're
based.

> 
> With this approach, an end-entity OCSP Response could be stapled using 
> the RFC6066 TLS extension, and the intermediate CRL(s) could be stapled 
> using the new multi-stapling TLS extension.

This would require the complexity of two TLS extensions where a single
TLS extension is perfectly sufficient (i.e. a lot more code and a lot
more bugs).
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric Rescorla | 1 Jun 2012 17:13

Re: CRL Stapling? (was Re: I-D Action: draft-ietf-tls-multiple-cert-status-extension-00.txt)

On Fri, Jun 1, 2012 at 8:08 AM, Martin Rex <mrex <at> sap.com> wrote:
> Rob Stradling wrote:
>>
>> IIRC, when Opera does an online revocation check, it currently checks
>> CRLs for intermediate CA certificates and OCSP for end-entity
>> certificates.  This makes sense because:
>>    - CRLs covering intermediate CA certificates tend to be roughly the
>> same size (sometimes smaller!) as the equivalent OCSP Responses (since
>> it's quite rare for intermediate CA certificates to be revoked).
>>    - Possessing a current CRL means you won't have to do an online
>> revocation check if you encounter another certificate issued by the same
>> issuer.
>>
>>   [...]
>>
>> How about changing the scope of the multi-stapling I-D so that it *only*
>> covers the intermediate CA certificate(s) in the chain?
>
> This would significantly increase the complexity without adding value.
> OCSP responses can be cached just as long as the CRLs on which they're
> based.
>
>>
>> With this approach, an end-entity OCSP Response could be stapled using
>> the RFC6066 TLS extension, and the intermediate CRL(s) could be stapled
>> using the new multi-stapling TLS extension.
>
> This would require the complexity of two TLS extensions where a single
> TLS extension is perfectly sufficient (i.e. a lot more code and a lot
> more bugs).
(Continue reading)

Permalink | Reply | 0 comments |
headers
IESG Secretary | 1 Jun 2012 18:42
Picon
Favicon

Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard

The IESG has received a request from the TLS Working Group to reclassify RFC 2818 (HTTP Over TLS) to 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 at ietf.org mailing lists by 2012-06-15. Exceptionally, comments
may be sent to iesg at ietf.org instead. In either case, please retain the beginning of the Subject line to
allow automated sorting.

Abstract     

This memo describes how to use TLS to secure HTTP connections over the Internet. Current practice is to
layer HTTP over SSL (the predecessor to TLS), distinguishing secured traffic from insecure traffic by
the use of a different server port. This document documents that practice using TLS. A companion document
describes a method for using HTTP/TLS over the same port as normal HTTP [RFC2817].

The file can be obtained via
http://www.rfc-editor.org/rfc/rfc2818.txt

No IPR declarations have been submitted directly on this I-D.
Permalink | Reply | 25 comments |
headers
Peter Saint-Andre | 1 Jun 2012 18:45
Favicon

Re: Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard

On 6/1/12 10:42 AM, IESG Secretary wrote:
> The IESG has received a request from the TLS Working Group to reclassify RFC 2818 (HTTP Over TLS) to
Proposed Standard.

Interesting. Are there also plans to modernize this spec by working on
2818bis?

Peter

--

-- 
Peter Saint-Andre
https://stpeter.im/
Permalink | Reply | 10 comments |
headers
Kyle Hamilton | 1 Jun 2012 19:15
Picon

Re: Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard

This is damaging, and I recommend against.  This is something which must be handled by HTTP and its demands of
its transports, not TLS and its claim to support what it thinks its clients want.

Among other things, this RFC more than any other is responsible for the "Server Name Indication"
requirement.  If it had not been the case, SNI would never have been necessary, and IESG/IETF would never
have had to deal with it.

I suggest instead that it be moved to HISTORIC, and a 2818bis drafted which describes how the various TLS
extensions play with HTTP.

-Kyle H

On Fri, Jun 1, 2012 at 9:42 AM, IESG Secretary <iesg-secretary <at> ietf.org> wrote:
> The IESG has received a request from the TLS Working Group to reclassify RFC 2818 (HTTP Over TLS) to
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 at ietf.org mailing lists by 2012-06-15. Exceptionally, comments
may be sent to iesg at ietf.org instead. In either case, please retain the beginning of the Subject line to
allow automated sorting.
>
> Abstract
>
> This memo describes how to use TLS to secure HTTP connections over the Internet. Current practice is to
layer HTTP over SSL (the predecessor to TLS), distinguishing secured traffic from insecure traffic by
the use of a different server port. This document documents that practice using TLS. A companion document
describes a method for using HTTP/TLS over the same port as normal HTTP [RFC2817].
>
> The file can be obtained via
> http://www.rfc-editor.org/rfc/rfc2818.txt
(Continue reading)

Permalink | Reply | 2 comments |
headers
Eric Rescorla | 1 Jun 2012 19:28

Re: Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard

On Fri, Jun 1, 2012 at 10:15 AM, Kyle Hamilton <aerowolf <at> gmail.com> wrote:
> This is damaging, and I recommend against.  This is something which must be
> handled by HTTP and its demands of its transports, not TLS and its claim to
> support what it thinks its clients want.
>
> Among other things, this RFC more than any other is responsible for the
> "Server Name Indication" requirement.  If it had not been the case, SNI
> would never have been necessary, and IESG/IETF would never have had to deal
> with it.

Huh? As stated in the abstract, RFC 2818 documented what was already
established practice at the time it was published. Yes, that practice
leads directly to SNI, but it's not like it's the fault of 2818.

> I suggest instead that it be moved to HISTORIC, and a 2818bis drafted which
> describes how the various TLS extensions play with HTTP.

I don't understand what that would mean. At the time 2818 was published,
there were already complaints about the HTTPS mechanism (though
primarily directed towards the use of a separate port) and the IETF
took a stab at trying to define a protocol that it liked better (2817).
That was hardly a success. It's hard to believe that we're going to
make fundamental architectural changes now, given that HTTPS
is far more entrenched.

-Ekr
Permalink | Reply | 0 comments |
headers
Eric Rescorla | 1 Jun 2012 19:29

Re: Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard

On Fri, Jun 1, 2012 at 9:45 AM, Peter Saint-Andre <stpeter <at> stpeter.im> wrote:
> On 6/1/12 10:42 AM, IESG Secretary wrote:
>> The IESG has received a request from the TLS Working Group to reclassify RFC 2818 (HTTP Over TLS) to
Proposed Standard.
>
> Interesting. Are there also plans to modernize this spec by working on
> 2818bis?

I would be willing to work on this if we could come up with
a clear list of improvements.

-Ekr
Permalink | Reply | 9 comments |
headers
Martin Rex | 1 Jun 2012 19:44
Picon
Favicon

Re: Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard

Kyle Hamilton wrote:
> This is damaging, and I recommend against.  This is something which must
> be handled by HTTP and its demands of its transports, not TLS and its
> claim to support what it thinks its clients want.
> 
> Among other things, this RFC more than any other is responsible for the
> "Server Name Indication" requirement.  If it had not been the case,
> SNI would never have been necessary, and IESG/IETF would never have
> had to deal with it.

The RFC(s) responsible for the "Server Name Indication" requirement is/are
2068/2616 "HTTP/1.1", which introduced the concept of virtual hosting:

  http://tools.ietf.org/html/rfc2068#section-14.23
  http://tools.ietf.org/html/rfc2616#section-14.23

> 
> I suggest instead that it be moved to HISTORIC, and a 2818bis drafted
> which describes how the various TLS extensions play with HTTP.

While I would be OK with creating rfc2818bis that explicitly describes
additional requirements implied by the virtual hosting concept of HTTP/1.1
and refers to TLS extension SNI rfc4366 (for TLSv1.0+v1.1) and
rfc6066 (for TLSv1.2+),  I fail to see why we should move rfc2818
to historic _before_ such a 2818bis is ready for publication.

-Martin
Permalink | Reply | 0 comments |
headers
Sean Turner | 1 Jun 2012 20:49

Re: Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard

So....I wasn't clear enough when I asked for this IETF LC.  I initiated 
this process as an AD not at the request of the WG.

My rationale was that it's in the downref registry and that there's 66 
or so RFCs that refer to 2818 and a lot of them are normative.  If it 
ends up that folks prefer the 2818bis -> PS coupled with 2818 -> 
Historic.  I'd be all right with that too.

spt

On 6/1/12 12:42 PM, IESG Secretary wrote:
> The IESG has received a request from the TLS Working Group to reclassify RFC 2818 (HTTP Over TLS) to
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 at ietf.org mailing lists by 2012-06-15. Exceptionally, comments
may be sent to iesg at ietf.org instead. In either case, please retain the beginning of the Subject line to
allow automated sorting.
>
> Abstract
>
> This memo describes how to use TLS to secure HTTP connections over the Internet. Current practice is to
layer HTTP over SSL (the predecessor to TLS), distinguishing secured traffic from insecure traffic by
the use of a different server port. This document documents that practice using TLS. A companion document
describes a method for using HTTP/TLS over the same port as normal HTTP [RFC2817].
>
> The file can be obtained via
> http://www.rfc-editor.org/rfc/rfc2818.txt
>
> No IPR declarations have been submitted directly on this I-D.
(Continue reading)

Permalink | Reply | 4 comments |

Gmane