Subject: RE: (D)TLS considered harmful: was Re: [Isms] Coming to consensus

From: "Blumenthal, Uri" <[email-masked]>
Date: Fri, 1 Jul 2005 14:57:02 -0400

Let's get some things straight.

1. TLS is Transport Layer SECURITY (as SSL is SECURE Socket LAYER). It
happens to run over reliable transport (because it allows leaving some
problems alone that would otherwise have to be addressed), but
reliability of the delivery was never a goal of either protocol - just a
byproduct.

2. DTLS is TLS adopted to unreliable transport, and thus it deals with
the issues that reliable protocol would've shielded from. It never cared
and isn't going to "achieve realiable transport". All that transport
layer change means - is that DTLS has now to deal with potential message
drop and/or reordering. Which it does by adding extra fields.

It is misleading to imply something else.

P.S. From TLS, SSH and DTLS - DTLS is the most versatile choice for SNMP
protocol.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Tom Petch
Sent: Friday, July 01, 2005 1:22 PM
To: Fleischman, Eric; [email-masked]
Subject: (D)TLS considered harmful: was Re: [Isms] Coming to consensus 

I think the use of the term (D)TLS somewhat misleading.

TLS, reliable transport based, a comprehensive set of I-Ds updating well
established RFC, in turn building on extensive experience of the similar
but
differently named SSL, I regard as a mature standard, worthy of serious
consideration for any security issue.

DTLS is a single I-D, in the RFC editor queue (thanks for that), expects
to
achieve reliable transport with 64 bits of extra header.  Its pedigree
is
impeccable but it is untested. Will it fly? will it prove vulnerable to
some
class of attacks, will it be widely available, will it go on being
updated in
parallel with TLS?

So I see two very different protocols even if in their elements of
security they
share a common set of methods.  To refer to them together as (D)TLS as
if were
something like FTP which can be configured to run over TCP or UDP I
think
misleading.

Tom Petch

----- Original Message -----
From: "Fleischman, Eric" <[email-masked]>
To: "Tom Petch" <[email-masked]>; <[email-masked]>
Sent: Friday, July 01, 2005 6:29 PM
Subject: RE: [Isms] Coming to consensus

Tom,

The quote you read means that SSH should not operate on top of an
unreliable data stream such as UDP but it can operate on top of a
reliable data stream such as TCP and probably SCTP.

Based on this quote it would seem to me that to select SSH would imply
that SNMP must use TCP transports only. If so, then I personally advise
against the SSH option because our experience is that SNMP behaves
poorly using TCP within bandwidth limited environments. Therefore, I
prefer SNMP to be able to use UDP. Therefore, based on this limited
information, it appears to me that (D)TLS is a preferable alternative
when compared to SSH.

--Eric

-----Original Message-----
From: Tom Petch [mailto:[email-masked]]
Sent: Friday, July 01, 2005 12:54 AM

>Don't both TLS and SSH require TCP transports while only DTLS can
>support UDP?

To quote from "draft-ietf-secsh-architecture-22.txt"

"The transport layer will typically be
      run over a TCP/IP connection, but might also be used on top of any
      other reliable data stream."

so SSH does not need everything TCP has to offer, just reliability.  (I
seem to recall this coming up in other places, that neither UDP nor TCP
are right for the upper layers, leading protocol designers to cast
around for something that fits better.)

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: "Fleischman, Eric" <[email-masked]>
Date: Wed, 6 Jul 2005 11:04:06 -0700

>> SNMP over TCP is SNMP over TCP. If someone specifies SNMP over SSH
(or 
>> TLS) then this is SNMP over SSH (or TLS). I don't think you need SNMP

>> over TCP to specify and implement SNMP over SSH (or TLS).
>
>Yeeeeees, I agree ... in protocol stack terms.  But turning to 
>the SSH I-D I quoted earlier, SSH needs a reliable transport.  
>I did not say reliable equals TCP at that time, Eric was rather 
>stronger in support of that.

I am sorry to have implied that reliable transport equals TCP. I am
aware of SCTP but not SCTP use under SNMP. 

My own arguments are to support flexibility due to the large number of
different environments in which SNMP is deployed. Current SNMP
applications support both UDP and TCP. I note that some in our WG
apparently prefer to limit this to TCP only for ISMS in order to cleanly
support SSH or TLS. However, are there advocates in our WG that believe
that we should support other transports in addition to current SNMP use?
If there are, would they please explain the issue they are trying to
address? Thanks.

---

From: "Fleischman, Eric" <[email-masked]>
Date: Wed, 6 Jul 2005 10:57:23 -0700

----Original Message-----
From: Eliot Lear [mailto:[email-masked]] 
>Juergen Schoenwaelder wrote:
>> P.S. Looking at the boxes I have access to, many do ssh. Some do TLS
and 
>>      none of them does DTLS or BEEP. (At least not that I am aware of
this.
>>      Perhaps I am having the wrong boxes. ;-)

>This is a fair point, but it is not the only consideration.  The 
>flexibility we need today, pragmatically speaking, is for a way for 
>either side to initiate queries through NATs, firewalls, and associated

>gook.  You *could* implement this flexibility in SSH, but nobody has,
so 
>far as I know.

Eliot,

This is a good observation but I become lost when I try to follow your
point "into the details." The "firewall" reference ultimately appears to
me to be a red herring because corporations will establish whatever
firewall policies we see fit, so whatever ISMS will decide will
ultimately be subject to firewall policies -- and that is a good thing.

You know a whole lot more about NATs than I, but isn't it possible to
build NAT responses on Transport Layer protocols? For example, didn't
Christian Huetima have an ID about UDP over NATs?

Regardless, my ignorant question to you is "isn't all this 'associated
gook' handled by the 'gook' itself such that whatever approach ISMS
comes up with (whether BEEP, or SSH, or TLS or DTLS) is ultimately
orthogonal to 'gook' behavior? That is, is any of this really a problem
for our WG and, if so, why is it our problem?

--Eric