On 20/04/15 22:03, Viktor Dukhovni wrote:
> On Mon, Apr 20, 2015 at 08:36:39PM +0100, Stephen Farrell wrote:
>
>>> Can we move forward with s/SSL 3.0/TLS 1.0/g? This modifies just
>>> the first paragraph of 8.1 and is not a big deal.
>>>
>>> I don't recall seeing any other recent BCPs at issue
On Mon, Apr 20, 2015 at 08:36:39PM +0100, Stephen Farrell wrote:
> > Can we move forward with s/SSL 3.0/TLS 1.0/g? This modifies just
> > the first paragraph of 8.1 and is not a big deal.
> >
> > I don't recall seeing any other recent BCPs at issue in this thread.
>
> One could encourage adheri
On 20/04/15 17:34, Viktor Dukhovni wrote:
> On Mon, Apr 20, 2015 at 05:08:45PM +0100, Stephen Farrell wrote:
>
>> On 20/04/15 17:01, Viktor Dukhovni wrote:
>
>>> Should I cut another version with editorial changes based on your
>>> review prior to IETF LC?
>>
>> I guess that's one for the WG ch
> On Apr 20, 2015, at 12:34 PM, Viktor Dukhovni wrote:
>
> On Mon, Apr 20, 2015 at 05:08:45PM +0100, Stephen Farrell wrote:
>
>> On 20/04/15 17:01, Viktor Dukhovni wrote:
>
>>> Should I cut another version with editorial changes based on your
>>> review prior to IETF LC?
>>
>> I guess that's
On Mon, Apr 20, 2015 at 05:08:45PM +0100, Stephen Farrell wrote:
> On 20/04/15 17:01, Viktor Dukhovni wrote:
> > Should I cut another version with editorial changes based on your
> > review prior to IETF LC?
>
> I guess that's one for the WG chairs.
OK. Any word from the chairs then?
> But I
On 20/04/15 17:01, Viktor Dukhovni wrote:
>
> Should I cut another version with editorial changes based on your
> review prior to IETF LC?
I guess that's one for the WG chairs.
But I don't think we bottomed out on the TLS versioning thing and
the relationship with recent related BCPs did we?
Should I cut another version with editorial changes based on your
review prior to IETF LC?
--
Viktor.
___
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane
On Sat Apr 18 03:25:47 2015 GMT+0100, Viktor Dukhovni wrote:
> On Sat, Apr 18, 2015 at 12:10:55AM +0100, Stephen Farrell wrote:
>
> > On 17/04/15 17:39, Viktor Dukhovni wrote:
> >
> > > Well, though I don't know why we'd care protecting about the address
> > > records also (given routing layer a
On Sat, 18 Apr 2015, Stephen Farrell wrote:
On 17/04/15 21:41, Nico Williams wrote:
As Paul says, there is a UI here: logs for sysadmins, Received headers
for users and sysadmins.
Paul's initial mail on this referred to UI and downgrade
attack possibilities. I don't believe there is any such
On Sat, Apr 18, 2015 at 12:10:55AM +0100, Stephen Farrell wrote:
> On 17/04/15 17:39, Viktor Dukhovni wrote:
>
> > Well, though I don't know why we'd care protecting about the address
> > records also (given routing layer attacks), ... There is (full
> > disclosure) a corner case where the addres
On 17/04/15 21:41, Nico Williams wrote:
> As Paul says, there is a UI here: logs for sysadmins, Received headers
> for users and sysadmins.
Paul's initial mail on this referred to UI and downgrade
attack possibilities. I don't believe there is any such UI
related downgrade attack in this case, b
On 17/04/15 17:39, Viktor Dukhovni wrote:
> Well, though I don't know why we'd care protecting about the address
> records also (given routing layer attacks), ... There is (full
> disclosure) a corner case where the address records are not secure,
> but the TLSA records are.
Right, that's what
On Fri, Apr 17, 2015 at 01:17:45PM +0100, Stephen Farrell wrote:
> I still think I've been answered but just to clarify. The context
> here has no UI at all given it's between MTAs. And the people who
> wanted to experiment I believe wanted to play about with no DNSSEC
> at all, rather than with lo
On Fri, Apr 17, 2015 at 04:39:42PM +, Viktor Dukhovni wrote:
> Well, though I don't know why we'd care protecting about the address
> records also (given routing layer attacks), ... There is (full
> disclosure) a corner case where the address records are not secure,
> but the TLSA records are.
On Fri, Apr 17, 2015 at 12:47:45PM -0400, Olafur Gudmundsson wrote:
> > On Apr 16, 2015, at 2:28 PM, Stephen Farrell
> > wrote:
> > On 16/04/15 18:37, Viktor Dukhovni wrote:
> >> On Thu, Apr 16, 2015 at 04:27:33PM +0100, Stephen Farrell wrote:
> >>> (1) What is the behaviour when all RRs required
On Fri, Apr 17, 2015 at 12:47:45PM -0400, Olafur Gudmundsson wrote:
> > My understanding is that some people wanted to experiment with TLSA
> > without having to have had DNSSEC deployed. But I take your answer
> > to be that no such behaviour is defined here, which is fine. So
> > consider this o
> On Apr 16, 2015, at 2:28 PM, Stephen Farrell
> wrote:
>
>
> Hiya,
>
> On 16/04/15 18:37, Viktor Dukhovni wrote:
>> On Thu, Apr 16, 2015 at 04:27:33PM +0100, Stephen Farrell wrote:
>>
>>> (1) What is the behaviour when all RRs required for this are
>>> published except for no DNSSEC RRs? I
On Fri, Apr 17, 2015 at 01:58:34PM +0100, Stephen Farrell wrote:
> > Note that for this protocol, both the address records and the TLSA
> > records of the MX host are DNSSEC-validated, since when the address
> > records are not, we don't even ask for the TLSA RRs. So I am not
> > sure what you ha
Hiya,
On 16/04/15 19:45, Viktor Dukhovni wrote:
> On Thu, Apr 16, 2015 at 07:28:58PM +0100, Stephen Farrell wrote:
>
>>> While, the A records don't a-priori need to be secured, we skip
>>> TLSA records for MX hosts whose A/ records are "insecure" in
>>> order to avoid interop problems with (
On Fri, 17 Apr 2015, Stephen Farrell wrote:
My understanding is that some people wanted to experiment with TLSA
without having to have had DNSSEC deployed. But I take your answer
to be that no such behaviour is defined here, which is fine. So
consider this one answered.
I go back and forth wit
On 16/04/15 20:36, Jeremy Harris wrote:
> On 16/04/15 19:28, Stephen Farrell wrote:
- 2.2, Could "authenticated" here mean mutually authenticated
with TLS client certs? If not, maybe say so. (And for the
last sentence before 2.2.1, what about the client cert names
- what's don
On 16/04/15 20:10, Paul Wouters wrote:
> On Thu, 16 Apr 2015, Stephen Farrell wrote:
>
>> My understanding is that some people wanted to experiment with TLSA
>> without having to have had DNSSEC deployed. But I take your answer
>> to be that no such behaviour is defined here, which is fine. So
>
On 16/04/15 19:28, Stephen Farrell wrote:
>>> - 2.2, Could "authenticated" here mean mutually authenticated
>>> with TLS client certs? If not, maybe say so. (And for the
>>> last sentence before 2.2.1, what about the client cert names
>>> - what's done with those?)
>>
>> There is no protocol for sp
On Thu, 16 Apr 2015, Stephen Farrell wrote:
My understanding is that some people wanted to experiment with TLSA
without having to have had DNSSEC deployed. But I take your answer
to be that no such behaviour is defined here, which is fine. So
consider this one answered.
I go back and forth wit
On Thu, Apr 16, 2015 at 07:28:58PM +0100, Stephen Farrell wrote:
> > While, the A records don't a-priori need to be secured, we skip
> > TLSA records for MX hosts whose A/ records are "insecure" in
> > order to avoid interop problems with (Microsoft's and similar)
> > domains whose non-DNSSEC
Hiya,
On 16/04/15 18:37, Viktor Dukhovni wrote:
> On Thu, Apr 16, 2015 at 04:27:33PM +0100, Stephen Farrell wrote:
>
>> (1) What is the behaviour when all RRs required for this are
>> published except for no DNSSEC RRs? I have heard tell of some
>> people who would like to experiment in that way
On Thu, Apr 16, 2015 at 01:50:42PM -0400, Paul Wouters wrote:
> On Thu, 16 Apr 2015, Viktor Dukhovni wrote:
>
> >In any case this draft was ready (and has been largely unchanged)
> >for about a year now, *before* all the fuss about SSL 3.0. Clients
> >MUST support at least TLS 1.0 (to use SNI).
On Thu, 16 Apr 2015, Viktor Dukhovni wrote:
In any case this draft was ready (and has been largely unchanged)
for about a year now, *before* all the fuss about SSL 3.0. Clients
MUST support at least TLS 1.0 (to use SNI). Servers MAY support
SSL 3.0 (allowing them to publish TLSA RRs with whate
On Thu, Apr 16, 2015 at 04:27:33PM +0100, Stephen Farrell wrote:
> (1) What is the behaviour when all RRs required for this are
> published except for no DNSSEC RRs? I have heard tell of some
> people who would like to experiment in that way, and would
> like to know if the WG have a clear answer
Hiya,
Sorry for being slow with this but I've finally gotten
my AD review for this done. (See below.)
A couple of things to check before starting IETF LC:
(1) What is the behaviour when all RRs required for this are
published except for no DNSSEC RRs? I have heard tell of some
people who would
30 matches
Mail list logo
