RE: [TLS] Re: NIST TLS recomendations

["Kemp David P." <DPKemp@xxxxxxxxxxxxxx>]

"Opportunistic encryption" sounds like a much more accurate
characterization
of anonymous/ephemeral sessions than does "protect against MITM
attacks",
the latter being precisely what unauthenticated encryption does NOT
provide.

-------

I believe the purpose of Mr. Perlner's request was to gain a sense of
the working group's opinion on the role of IETF security standards -- 
should the TLS spec focus on interoperability and permit a wide
spectrum in the protocol assurance of compliant implementations, with
NIST
Special Publications or FIPS profiling the higher end of the spectrum
for Government applications, or should the higher assurance
wire options become mandatory for TLS compliance?

My sense is that the AD's expectation is unrealistic and that NIST
will need to profile a subset of TLS for FIPS compliance after 2010,
but I'd be happy to be proven wrong.

Dave


-----Original Message-----
From: Peter Gutmann [mailto:pgut001@xxxxxxxxxxxxxxxxx] 
Sent: Wednesday, November 01, 2006 10:03 AM
To: jas@xxxxxxxxxxx; ray.perlner@xxxxxxxx
Cc: tls@xxxxxxxxxxxxxx
Subject: Re: [TLS] Re: NIST TLS recomendations

Simon Josefsson <jas@xxxxxxxxxxx> writes:

>I believe fully anonymous ciphers are a useful feature of TLS, and that
they
>should stay.  Client/server authentication can and do happen via other
>protocols than TLS, and those protocols can use TLS channel bindings to
>protect against man in the middle attacks, if necessary.

DH_anon is very widely used for opportunistic encryption in systems
supporting
STARTTLS/STLS/AUTH TLS and similar mechanisms.

(Actually that's not 100% accurate, what's used is something like DHE
with a
 self-signed cert that typically isn't checked, so it's a mechanism that
acts
 like DH_anon without actually being DH_anon.  So I don't know if
deprecating
 DH_anon will have much effect when the situations where it would be
needed
 are using other mechanisms in the manner of DH_anon.  This is an
interesting
 question, are you trying to deprecate the thing labelled DH_anon, or to
 deprecate the practice of making unauthenticated connections?).

Peter.

_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls