Subject: [saag] POODLE avant le chein

From: Watson Ladd <[email-masked]>
Date: Tue, 14 Oct 2014 18:20:30 -0700

Dear all,

Now that we've all disabled SSLv3 on every machine in reach, let's
review when this attack was discovered. Not in 2014, but in 2001: It's
in Vaudenay, section 5, applied to randomized padding in SSHv2, where
it was fixed. Credit belongs to Luca Bruno for pointing this out on
Twitter.

No one took the time to sit down with a copy of the paper and a copy
of the spec, and compare them until now. I should have, but didn't.
TLS isn't alone in this regard: I spent quite a bit of time trying to
understand which way CMS composes encryption and authentication, and
gave up in frustration reading the pile of RFCs. (The answer I believe
is that CMS does not use a MAC by default: there is a different
content type that does support AES-GCM, but I have no idea how often
it is used. People more familiar than I am with S/MIME should chime
in.)

What other protocols have random padding in CBC mode after a MAC? Is
there any way to determine this beyond asking everyone to help,
dividing up a list of nearly 8,000 RFCs, and looking at them all? And
perhaps most importantly, what process changes will prevent known
attacks from surprising us in the future?

There's also a question about how conservative we need to be when
doing new cryptographic protocols. But that's a more challenging one.

Sincerely,
Watson Ladd

---

From: Yoav Nir <[email-masked]>
Date: Wed, 15 Oct 2014 12:55:57 +0300

On Oct 15, 2014, at 4:20 AM, Watson Ladd <[email-masked]> wrote:

> Dear all,
> 
> Now that we've all disabled SSLv3 on every machine in reach,

Well, 4.2% of us have [1]. On the bright side, 97.5% support something better.

> let's

First, you don’t have to go over all 8000 RFCs, and there are some standards (wifi or web) that are defined by IEEE and W3C respectively.  And some of those RFCs are for things nobody uses (either now or ever). So it’s more important to survey stuff that people actually: TLS, SSH, and IPsec come to mind. There are a few other protocols that are in some use like MPPE and PPTP, but they are rarely used today for their security extensions that allowed encryption.

Yoav

[1] https://securitypitfalls.wordpress.com/2014/09/29/scan-results-for-september-2014/

---

From: ianG <[email-masked]>
Date: Wed, 15 Oct 2014 12:32:05 +0100

> it was fixed. Credit belongs to Luca Bruno for pointing this out on

(FWIW, when I was designing in the early 2000s, I was well aware of the
need to move the padding into the domain of the MAC, and out of
CBC-harm's way; we stuck the pad at the front.  Which is to say it was
not specialist knowledge.)

> What other protocols have random padding in CBC mode after a MAC?

I believe there's a better way to look at this.  The better question is,
do TLS versions have the random padding in CBC mode after a MAC?

At a guess, later ones do not.  Assuming that, then TLS is the solution.
 So the real question for engineers is this:  why is SSL 3.0 still in use?

> Is
> dividing up a list of nearly 8,000 RFCs, and looking at them all?

:)

> And

> doing new cryptographic protocols. But that's a more challenging one.

I believe it's the one that will answer the problem.  The process change
that is needed is how to upgrade protocols on a routine basis, so that
older designs can fall away without embarrassment.

(To put this in perspective, an oft-touted feature of the policy of
algorithm agility is the ability to switch from one algorithm to
another.  But even there, there lacks any sense of how we do the switch.)

Solve the problem that solves most of the attack space:  upgrade!

iang

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 15 Oct 2014 07:58:52 -0400

Sent from my iPhone

> On Oct 15, 2014, at 7:32 AM, ianG <[email-masked]> wrote:
> 

My take on this is that server operators are afraid to break their clients.  What if browsers deprecated support for older versions so that it becomes easier for server operators to turn off support? 

Could we work together with all the browser vendors to phase out SSLv3?  Then anything else we should deprecate.  Of course this requires people to upgrade browsers.

Thanks,
Kathleen
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: "Black, David" <[email-masked]>
Date: Wed, 15 Oct 2014 15:40:44 +0000

> What if browsers deprecated support for older versions so that it becomes
> easier for server operators to turn off support?

One down (Firefox) ...

https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/

"SSLv3 will be disabled by default in Firefox 34, which will be released on Nov 25."

FYI,
--David
Nit: Le mot en francais est "le chien", pas "le chein" ;-).

> -----Original Message-----
> From: saag [mailto:[email-masked]] On Behalf Of Kathleen Moriarty
> Sent: Wednesday, October 15, 2014 7:59 AM
> To: ianG
> Cc: [email-masked]
> Subject: Re: [saag] POODLE avant le chein
> 
> 
> 
> Sent from my iPhone
> 
> My take on this is that server operators are afraid to break their clients.
> What if browsers deprecated support for older versions so that it becomes
> easier for server operators to turn off support?
> 
> Could we work together with all the browser vendors to phase out SSLv3?  Then
> anything else we should deprecate.  Of course this requires people to upgrade
> browsers.
> 
> Thanks,
> Kathleen
> >
> >> Is

---

From: joel jaeggli <[email-masked]>
Date: Wed, 15 Oct 2014 08:46:09 -0700

> "SSLv3 will be disabled by default in Firefox 34, which will be released on Nov 25."

basically server operators are already making the jump.

https://blogs.akamai.com/2014/10/ssl-is-dead-long-live-tls.html
https://blog.cloudflare.com/sslv3-support-disabled-by-default-due-to-vulnerability/
http://www.fastly.com/blog/

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 15 Oct 2014 11:46:48 -0400

> "SSLv3 will be disabled by default in Firefox 34, which will be released

Thanks for the article, it looks like the major browser vendors are already
working together, no surprise there, but a big thanks to each of them as
that's probably the best way to tackle this (from my experience).

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 15 Oct 2014 11:48:08 -0400

> http://www.fastly.com/blog/

Cool.  It's the enterprise level ones that may fall behind that is my
concern, this is all good news, thanks. Back to reading drafts :-)

-- 

Best regards,
Kathleen

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Oct 2014 16:56:28 +0100

> that's probably the best way to tackle this (from my experience).

Hopefully so, and good to see the browsers and some large
server sites moving.

If they can now get rid of SSLv3 within say a couple of months,
(and I hope they can), then we should maybe be asking ourselves
if we (the IETF) can help 'em somehow not let such stuff linger
for so long in future. Not sure how, but say if we'd published
an "SSLv3 considered possibly harmful" RFC about 8 years after
RFC 2246 was published, do we think that might have helped, or
might an equivalent help in future? Looking about randomly, I
see TLS1.1 is 8 years old now:-)

And just to clarify, my question isn't really about TLS, but
about whether there's an IETF thing to be done here that might
help. (And the answer for now is I'm not sure.)

S.

---

From: joel jaeggli <[email-masked]>
Date: Wed, 15 Oct 2014 09:02:02 -0700

On 10/15/14 8:48 AM, Kathleen Moriarty wrote:
> 
> 
> On Wed, Oct 15, 2014 at 11:46 AM, joel jaeggli <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

there's definitely a herd immunity here. if your pre sp3 ie6 no longer
works on important sites then you'll get a new browser, which provides
everyone else cover to change their servers accordingly.

>     >> From: saag [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Kathleen Moriarty
>     >> Cc: [email-masked] <mailto:[email-masked]>
>     >>> On Oct 15, 2014, at 7:32 AM, ianG <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >>>
>     >>> [email-masked] <mailto:[email-masked]>
>     >> [email-masked] <mailto:[email-masked]>
>     > [email-masked] <mailto:[email-masked]>

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 15 Oct 2014 12:23:02 -0400

On Wed, Oct 15, 2014 at 11:56 AM, Stephen Farrell <[email-masked]
> wrote:

> help. (And the answer for now is I'm not sure.)

It sounds like the browser vendors in this case worked together and made a
decision to deprecate SSLv3.  It may have to be a mix of working with a set
of vendors on next steps that can drive the market coupled with social
media campaigns.  Tweets can be pretty effective when they start getting
attention.

A few folks mentioned that they were looking to see what other protocols
might also be vulnerable, if some are found, that might be a good place to
start.  Then working with a set of IETF participating vendors on next steps
and announcements.  Vulnerability disclosure practices are well defined and
following them may help us.

For other known issues where there has not been movement, it might be good
to work through a list and see what we can do/influence with each in
priority order... ok, all should be pretty obvious, but requires work ;-)

Thanks.

-- 

Best regards,
Kathleen

---

From: Ronald del Rosario <[email-masked]>
Date: Wed, 15 Oct 2014 16:27:26 +0000

"Cool.  It's the enterprise level ones that may fall behind that is my concern, this is all good news, thanks. Back to reading drafts :-)”

+1

Once all major browsers start dropping support for SSLv3 in favor of TLS, Cloud Service Providers like us relying on browsers will now have the authority to remind our customer base  that we are dropping support for SSLv3.

Ron F. del Rosario
Information Security Officer

Five9, Inc.
Cloud Contact Center Software
4000 Executive Pkwy, Ste 400 San Ramon, CA 94583
www.Five9.com<http://www.five9.com/>

From: Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 15, 2014 at 8:48 AM
To: joel jaeggli <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [saag] POODLE avant le chein

On Wed, Oct 15, 2014 at 11:46 AM, joel jaeggli <[email-masked]<mailto:[email-masked]>> wrote:

Cool.  It's the enterprise level ones that may fall behind that is my concern, this is all good news, thanks. Back to reading drafts :-)

>> From: saag [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Kathleen Moriarty
>> Cc: [email-masked]<mailto:[email-masked]>
>>> On Oct 15, 2014, at 7:32 AM, ianG <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

--

Best regards,
Kathleen

________________________________

CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential information of Five9 and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Five9 and/or its affiliated entities.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 15 Oct 2014 19:33:11 +0300

> everyone else cover to change their servers accordingly.

IDK. Pre-SP3 IE6 is a checkbox away from working. They had TLS disabled by default for some reason, but it can even be turned on by an administrator through Microsoft’s tools.

It would be interesting to see in the next two iterations of the survey how many sites will still have SSLv3 turned on. My guess is that the percentage will be depressingly high, considering that 11.7% still support SSLv2.

https://securitypitfalls.wordpress.com/2014/09/29/scan-results-for-september-2014/

I think there are two flavors to consider in enterprise servers. There’s the intranet servers (erp.mycompany.com, exchange.mycompany.com, order-lunch.mycompany.com). It’s hard to justify upgrading them, because (a) they work, and (b) they’re behind the firewall, and (c) who knows if the “order lunch” application will keep working if we upgrade IIS, which we’ll have to if we upgrade the Windows 2000 server. Of course being behind the firewall doesn’t help if your favorite browser (including Firefox until late November) is going to accept Javascript from outside sources that will run queries against your lunch ordering system. Firewalls try to deal with this, but that battle hasn’t been won yet.

Internet-facing servers are a different matter. On the one hand, they have to deal with anything that’s out there, but on the other hand, a lot of them are hosted these days, so the hosting companies (or CDNs) can make a lot of difference. A decision by the likes of Akamai or Cloudflare can do a lot for the statistics.

While the browser vendors are pretty much working together, there are a lot of programmatic clients out there. Think of the app on your phone that shows a pretty picture of a rainy or sunny day on your phone based on data pulled from weather.com, or some client using SOAP or JSON or any other web services technology. These can also live for a long time unchanged since they “just work”. 

Yoav

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 15 Oct 2014 12:42:33 -0400

Sent from my iPhone

> On Oct 15, 2014, at 12:33 PM, Yoav Nir <[email-masked]> wrote:
> 
> 
Depressing stat, but thanks for the info.
> I think there are two flavors to consider in enterprise servers. There’s the intranet servers (erp.mycompany.com, exchange.mycompany.com, order-lunch.mycompany.com). It’s hard to justify upgrading…

You're right, but I'd hope upgrades if browsers would help.
> While the browser vendors are pretty much working together, there are a lot of programmatic clients out there. Think of the app on your phone that shows a pretty picture of a rainy or sunny day on…
All good points.  How do we help here?  For Apple, they have a single place for apps, so they likely have a notification to authors of apps.  I know EMC has the ability to post apps, but with Apple, there is a strict process around it.  We could reach out to see what can be done there.

Is anyone aware of options for other apps on other devices?  

Or other places this will surface where we can help?

Thanks,
Kathleen

---

From: ianG <[email-masked]>
Date: Wed, 15 Oct 2014 17:46:34 +0100

> My take on this is that server operators are afraid to break their clients.  What if browsers deprecated support for older versions so that it becomes easier for server operators to turn off suppor…

Yes, a big long look at the situation leads to identification of a lot
of "what if's" that combine to put the industry in deadly embrace.

> Could we work together with all the browser vendors to phase out SSLv3?  Then anything else we should deprecate.  Of course this requires people to upgrade browsers.

As a practical matter of Poodle, it's already a done deal.  Google have
already announced they'll kill SSLv3 within months, and they're prepared
to break the net to do it.  Mozilla too, no doubt MS is writing its PR
as we speak.

On the wider front, the next big failure -- I think the question may
well be "who do we work with" ?  Or, "what advice do we give?"  Or, "how
do we deliver a kill-bill in protocol/policy such that it bites in the
field?"

I don't have answers, only questions.  But sometimes framing the right
question is half the battle.

iang

---

From: ianG <[email-masked]>
Date: Wed, 15 Oct 2014 17:56:08 +0100

> see TLS1.1 is 8 years old now:-)

Not sure where 8 years came from, but I'm fine with it because in my
handwavy thinking, I settled on 7 years...

So, let's say we settle on 8, either for all or independently negotiated
per protocol.

Perhaps a standard practice then in an RFC is that there should be a
date by which the work is declared out-of-date.  A sunset clause in the
Security section, mandatory, based on the best view of the authors of
the time.

Thereby forcing a reconvening at that time to either vote to move the
sunset date forward another 8 years (well done, nice design!) or to
prepare V2 for replacement.

     This RFC will expire in 2022, by which time
     a new generation protocol will be prepared and
     all users encouraged to have transitioned, and/or
     this current version will be marked abandoned.

or words to effect.

iang

---

From: Yoav Nir <[email-masked]>
Date: Wed, 15 Oct 2014 20:29:28 +0300

>     this current version will be marked abandoned.

So are vendors supposed to ship products that just suddenly stop working in 2022? It’s hard to argue with the feeling of administrators that “the product works now. Why should I upgrade?”

Let’s keep picking on TLS. A TLS 1.3 specification is going to come out at some point. There’s dozens of implementations out there, and I’m sure all of those that are maintained will implement 1.3. Some will implement it with bugs. Some combinations of client and server implementations will not interoperate. Sure, OpenSSL and NSS and whatever Microsoft calls their library internally (SCHANNEL?) will work together. But it will be a good chance to remember that your firewall, your ERP and your home router also have their own TLS implementation. So the first administrators to upgrade their software *and* enable TLS 1.3 are going to be the early adopters who get hit with interop problems. 

Sure, if you have a modern code base, and you’re using SSLv3 and now enable TLS 1.0, you’re very likely safe. But there was a reason why Microsoft disabled TLS when XP first came out. And when Apple released TLS 1.2 in iOS (they were pretty early in doing so) they got hit with interop problems (which were in their code, but still…)

It’s very tempting for administrators to wait until everyone does something. But if you’re waiting for “everybody”, that likely means that you’re disabling SSLv3 in late 2014 or early 2015, not shortly after the publication of TLS 1.0 15 years earlier.

Yoav

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 15 Oct 2014 13:37:49 -0400

Sent from my iPhone

> On Oct 15, 2014, at 1:29 PM, Yoav Nir <[email-masked]> wrote:
> 
> 

+1

I think there are enough issues that have been identified already that we could help fix and have a bigger impact.  Appreciate the continued discussion on what can we do.

Thanks,
Kathleen

---

From: Michael Richardson <[email-masked]>
Date: Wed, 15 Oct 2014 14:33:22 -0400

> it was fixed. Credit belongs to Luca Bruno for pointing this out on

...

    > there any way to determine this beyond asking everyone to help,

IPsec ESP pads with sequential padding, encrypts, and then HMAC-x.
So I think IPsec doesn't "CBC mode after a MAC" but rather, "CBC mode before
a MAC".

I haven't read the details of the attack yet; I figure I'll wait a day.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Oct 2014 22:34:55 +0100

On 15/10/14 18:29, Yoav Nir wrote:
> So are vendors supposed to ship products that just suddenly stop
> working in 2022? 

Yeah, not sure I buy the "best-before date in the RFC" thing
myself. Another issue is who'd do the work required.

> It’s hard to argue with the feeling of
> administrators that “the product works now. Why should I upgrade?”
> 
> Let’s keep picking on TLS. A TLS 1.3 specification is going to come
> out at some point. There’s dozens of implementations out there, and
> I’m sure all of those that are maintained will implement 1.3. Some
> will implement it with bugs. Some combinations of client and server
> implementations will not interoperate. Sure, OpenSSL and NSS and
> whatever Microsoft calls their library internally (SCHANNEL?) will
> work together. But it will be a good chance to remember that your
> firewall, your ERP and your home router also have their own TLS
> implementation. So the first administrators to upgrade their software
> *and* enable TLS 1.3 are going to be the early adopters who get hit
> with interop problems.
> 
> Sure, if you have a modern code base, and you’re using SSLv3 and now
> enable TLS 1.0, you’re very likely safe. But there was a reason why
> Microsoft disabled TLS when XP first came out. And when Apple
> released TLS 1.2 in iOS (they were pretty early in doing so) they got
> hit with interop problems (which were in their code, but still…)
> 
> It’s very tempting for administrators to wait until everyone does
> something. But if you’re waiting for “everybody”, that likely means
> that you’re disabling SSLv3 in late 2014 or early 2015, not shortly
> after the publication of TLS 1.0 15 years earlier.

I don't think anyone would say that TLS1.2 ought be quickly
deprecated once TLS1.3 is done.

More like, is now the time to write an RFC deprecating TLS 1.0?
Or, would TLS1.3 being done be the time to try deprecate TLS1.1?

I still don't know if that'd be useful, but I do know that we're
all paying some costs for there being such old stuff still in
code bases that can't be gotten rid of 1.5 decades after its no
longer needed really.

S.

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 15 Oct 2014 19:39:39 -0700

> From: saag [mailto:[email-masked]] On Behalf Of Watson Ladd
> Sent: Tuesday, October 14, 2014 6:21 PM
> To: [email-masked]
> Subject: [saag] POODLE avant le chein
> 
> Dear all,
> 
> Now that we've all disabled SSLv3 on every machine in reach, let's review
> when this attack was discovered. Not in 2014, but in 2001: It's in
Vaudenay,
> section 5, applied to randomized padding in SSHv2, where it was fixed.
Credit
> belongs to Luca Bruno for pointing this out on Twitter.
> 
> No one took the time to sit down with a copy of the paper and a copy of
the
> spec, and compare them until now. I should have, but didn't.
understand
> which way CMS composes encryption and authentication, and gave up in
> frustration reading the pile of RFCs. (The answer I believe is that CMS
does
> not use a MAC by default: there is a different content type that does
support
> AES-GCM, but I have no idea how often it is used. People more familiar
than I
> am with S/MIME should chime
> in.)

S/MIME is not going to be affected by this since it has never been updated
to use authenticated encryption algorithms

CMS has defined an AEAD structure to be used with authenticated algorithms.
The only algorithms currently defined are AES-CCM, AES-GCM and RFC 6476.
The first two don't use CBC so are not affected.  The last one does encrypt
then MAC so that the entire encryption stream is MAC-ed.  My understanding
is that this means that it should not be an issue as the pad is covered by
the MAC value.

Jim

> there any way to determine this beyond asking everyone to help, dividing
up
> a list of nearly 8,000 RFCs, and looking at them all? And perhaps most
> importantly, what process changes will prevent known attacks from
> surprising us in the future?
> 
> There's also a question about how conservative we need to be when doing
> new cryptographic protocols. But that's a more challenging one.
> 
> Sincerely,
> Watson Ladd
>

---

From: Watson Ladd <[email-masked]>
Date: Thu, 16 Oct 2014 07:35:19 -0700

> to use authenticated encryption algorithms

So, what is the actual security S/MIME provides? It's probably
violates several assumptions about the authenticity of messages, by
not authenticating ciphertext, and has plaintext revealing padding
oracles as a result. Add it to the list of protocols that need fixing.
PGP is already on it: that checksummed message format is weird, and
MACs then encrypts.
> is that this means that it should not be an issue as the pad is covered by

This understanding is correct. But the fact that there is an option
where there is no MAC means we have a problem.

The issue is not that SSL is 18 years old. The issue is that we have
known for over a decade that many of the design choices were
dangerous, that due to interop problems clients still had to support
it, and did exactly nothing. This isn't isolated to TLS: OpenPGP is a
similarly strange design. What will stop the IETF from making the same
mistakes again?

(Why "before the dog"? Because the attack was described in Vaudenay,
2001, long before it got the name POODLE. That's right: the most-read
crypto paper in the world had an attack that no one realized was in
there.)

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Matthew Chalmers <[email-masked]>
Date: Thu, 16 Oct 2014 10:06:29 -0500

'Avant' is usually for the physical meaning of before; a better phrase
might be "Plus tôt que le chien."

On Thu, Oct 16, 2014 at 9:35 AM, Watson Ladd <[email-masked]> wrote:

> review

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 16 Oct 2014 17:33:07 +0200

Watson Ladd <[email-masked]>:

> it was fixed. Credit belongs to Luca Bruno for pointing this out on

Your references leave something to be desired ... what exactly do you mean
by "Vaudenay, 2001" (aka "the most-read crypto paper in the world") and
what is its section 5? I'm guessing that you mean "CBC Padding: Security
Flaws in SSL, IPSEC, WTLS, ...", but at least the 2001 version doesn't
appear to mention SSH at all.

That said, certainly the observation that SSL 3.0 padding is
cryptographically weak is not new (and all padding attacks ultimately go
back to Serge). The "POODLE" paper is all about lifting the known weakness
to fully recovering cookies or passwords, using BEAST techniques. What can
I say, the POODLE attack didn't really surprise me.

Bodo

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 29 Oct 2014 09:19:08 -0400

> help. (And the answer for now is I'm not sure.)

We don't have any maintenance processes other than letting the
specification rot for a decade then digging it up and seeing if we can
bring it back to life.

Note also the rather peculiar dichotomy in the DPRIVE work versus the
TLS group. In DPRIVE we are being told 'just use DTLS' and in TLS we
have 'time to redesign from the ground up'.

I think we need a more modular approach. At the moment we have IPSEC
and TLS and they both have a key agreement scheme. Why are these
different? Do the security issues for key agreement change depending
on what level you work at?

We need a key agreement at the application layer for Web services as
well. But we don't have one right now.

Rather than doing TLS 2.0 as just a continuation of TLS/1.1, I would
like to see us split TLS into two separate problems, a key agreement
part which is a general purpose module that can be reused everywhere
and a packaging part that applies a prenegotiated key to transport
protocol. Then we would have a part that applies the prenegotiated key
to packets (i.e. IPsec 2.0) and HTTP sessions.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 29 Oct 2014 13:31:24 +0000

Hiya,

> have 'time to redesign from the ground up'.

Well, DPRIVE may end up having a similar discussion as will
happen in TCPINC; that is, whether to re-use (D)TLS or to
do a new thing (tcpcrypt-like in the TCPINC case).

> well. But we don't have one right now.

One data point there: I'm told that the webpush WG [1] will
define a thing like that with a real chance of being widely
deployed, which could be interesting.

S.

[1] https://datatracker.ietf.org/wg/webpush/charter/

---

From: "Black, David" <[email-masked]>
Date: Wed, 29 Oct 2014 14:38:55 +0000

> do a new thing (tcpcrypt-like in the TCPINC case).

And even 'just use DTLS' is not that simple :-( ...

draft-ietf-tsvwg-sctp-dtls-encaps is effectively stalled at the
moment courtesy of confusion over which version of DTLS to use for
WebRTC and why.

I hesitate to ask - but who in the Security Area thinks they're
responsible for the Security-side aspects of resolving this confusion?

Thanks,
--David (as a tsvwg WG chair)

> From: saag [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Wednesday, October 29, 2014 9:31 AM
> To: Phillip Hallam-Baker
> Cc: [email-masked]
> Subject: Re: [saag] getting rid of fairly old stuff
> 
> 
> Hiya,
>

---

From: Nico Williams <[email-masked]>
Date: Thu, 30 Oct 2014 15:11:23 -0500

I've no interest in prohibiting RC4, SSL3, at least in an oppotunistic
security context where the alternative would be sending plaintext.
I'm much more interested in prohibiting fallback to SSL3 in UAs, and
prohibiting the use of broken protocols in required security cases
(including opportunistic ones where the client securely discovers that
the server can use the latest and greatest).

Nico
--