Glen Me again. Just after I posted my last message, I received a post on the ietf-ssh list, hosted by netbsd.org, and looking through the 'Received: from' headers, as one does on a wet Saturday morning of a Bank Holiday weekend, there was TLS, used to submit the message to the server, so even spammers have caught on that TLS should be used everywhere. End to end? Tom Petch ----- Original Message ----- From: "t.petch" <daedulus@xxxxxxxxxxxxx> To: "Glen Zorn" <glenzorn@xxxxxxxxx>; <ned+ietf@xxxxxxxxxxxxxxxxx> Cc: "IETF Discussion" <ietf@xxxxxxxx> Sent: Saturday, August 27, 2011 10:53 AM Subject: Re: https > ----- Original Message ----- > From: "Glen Zorn" <glenzorn@xxxxxxxxx> > To: <ned+ietf@xxxxxxxxxxxxxxxxx> > Cc: "John C Klensin" <john-ietf@xxxxxxx>; "IETF Discussion" <ietf@xxxxxxxx> > Sent: Saturday, August 27, 2011 7:29 AM > Subject: Re: https > > > > On 8/26/2011 11:14 PM, ned+ietf@xxxxxxxxxxxxxxxxx wrote: > > > > > +1. If you want signatures, do them properly. Don't pretend a transfer > > > protection mechanism covering exactly one hop provides real object security, > > > because it doesn't. > > > > I could have sworn that TLS was an e2e mechanism. Maybe you're using > > the term "hop" in a manner unfamiliar to me? > > Glen > > Without a precise context, then e2e can mean anything, from ends of a fibre link > to ends of a communication between two sentient beings. > > On other lists, there is sometimes disagreement as to what TLS is, transport, > application or what. What it is not is a secure channel from application to > application, for that you need channel binding or some such, a problem which a > number of WGs have wrestled with, such as isms for SNMPv3 (which used its own > form of binding for both SSH and TLS between the secure transport and the > application). > > I regularly hear, and cringe at, statements in the media that you must check for > the padlock to know that you are secure. > > A) you do not know what cryptography is in use (my local library recently liked > SSL2 as a default) > > B) you do not know where the endpoints of the channel are > > TLS and padlocks are often a spurious miasma of security. > > Tom Petch > > > > > > And as for the "encrypt so the really secret stuff doesn't stand out" > argument, > > > that's fine as long as it doesn't cause inconvenience to anyone. That's > clearly > > > not the case here. And I'm sorry, the "mistakes were made" notion doesn't > > > really fly: Certificates aren't a "set it and forget it" thing, so if you > > > haven't noted expiration dates on someone's to-do list so they can be > updated > > > before expiration, you're not doing it right. > > > > Isn't "not doing it right" pretty much the definition of "mistake" > > (assuming no evil intent)? > > _______________________________________________ > > Ietf mailing list > > Ietf@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf